Artigo 9.º do AI Act: transformar riscos em controlos e testes verificáveis

O que abrange este guia — e o que fica de fora

O artigo 9.º do Regulamento Europeu da Inteligência Artificial (AI Act) exige que os fornecedores de sistemas de IA de alto risco estabeleçam, apliquem, documentem e mantenham um sistema de gestão de riscos. A ideia prática desenvolvida neste guia é simples: associar cada risco identificado a uma medida e definir como verificar se essa medida ajuda a reduzi-lo.

Este guia limita-se a esse artigo. Não é uma explicação completa do Regulamento, uma avaliação jurídica de um produto nem um método para decidir, por si só, se um sistema é de alto risco. Também não transforma todas as ferramentas de IA em sistemas abrangidos pelo artigo 9.º. Primeiro, é necessário determinar se o sistema e a finalidade da sua utilização se enquadram no âmbito pertinente do Regulamento; só depois faz sentido usar este modelo como apoio ao trabalho.

O artigo estabelece obrigações para os fornecedores de sistemas de IA de alto risco. Isso não significa que qualquer pessoa que utilize um sistema tenha automaticamente de criar e manter o sistema de gestão de riscos exigido aos fornecedores. Os deveres de outros intervenientes, como os responsáveis pela implantação, devem ser analisados separadamente. Para uma perspetiva mais geral, consulte os guias da Inferama sobre segurança, comparação de sistemas e descoberta de ferramentas de IA; estes não substituem a verificação das obrigações aplicáveis a um caso concreto.

Ao longo do artigo, distinguimos dois níveis. «Requisito do Regulamento» identifica o que consta do artigo 9.º. «Recomendação operacional» assinala uma forma prática de organizar o trabalho que pode ajudar a demonstrar o cumprimento, mas que não deve ser confundida com um formulário ou campo obrigatório definido literalmente pela lei.

Verificação prévia: o sistema está abrangido?

Antes de registar riscos ao abrigo do artigo 9.º, identifique o sistema concreto e a finalidade prevista. A classificação não depende apenas de o produto utilizar um modelo avançado, de a organização o considerar sensível ou de os resultados terem consequências importantes. O Regulamento determina quais os sistemas considerados de alto risco através de categorias e condições, e o enquadramento pode depender da forma como o sistema é utilizado e da função que desempenha.

Como verificação inicial, descreva com precisão suficiente a utilização efetiva e prevista: quem opera o sistema, quem recebe ou utiliza os seus resultados, que decisão ou processo apoia e em que contexto é integrado. Em seguida, compare essa descrição com as disposições aplicáveis do Regulamento, incluindo as categorias pertinentes e as condições ou exceções que possam afetar a classificação. Se houver dúvidas sobre a categoria, o papel da organização ou a aplicação temporal de uma obrigação, solicite uma análise jurídica antes de tratar uma conclusão provisória como facto.

Não classifique um sistema apenas com base numa descrição comercial, na tecnologia que incorpora ou no nome de uma categoria. Um mesmo sistema pode ter utilizações diferentes; a avaliação deve centrar-se na utilização concreta que se pretende analisar. O exemplo de seleção de candidaturas apresentado mais adiante é hipotético e serve para mostrar como documentar um risco. Não afirma que todos os sistemas de seleção de candidaturas tenham automaticamente a mesma classificação jurídica.

Registe as informações que sustentam a conclusão inicial: documentação do produto, finalidade declarada, descrição do processo e condições de implantação. Se a conclusão depender de pressupostos ainda não confirmados, assinale-os como pendentes. Esta precaução evita que o modelo transforme uma hipótese de classificação numa premissa aparentemente definitiva.

Do contexto a um risco que possa ser analisado

O artigo 9.º prevê um processo contínuo e iterativo que deve abranger o ciclo de vida do sistema. Para começar de forma útil, descreva o contexto de utilização antes de enumerar possíveis danos. A mesma saída do sistema pode ter consequências diferentes consoante quem a interpreta, que outras verificações existem e se uma pessoa pode corrigir um erro antes de este afetar alguém.

O Regulamento refere-se aos riscos conhecidos e razoavelmente previsíveis para a saúde, a segurança e os direitos fundamentais quando o sistema é utilizado de acordo com a finalidade prevista. Exige também que se estimem e avaliem os riscos que possam surgir com essa finalidade e em condições de utilização indevida razoavelmente previsíveis. Por isso, convém analisar tanto a utilização prevista como os desvios previsíveis, sem transformar qualquer possibilidade remota num risco comprovado.

Para cada cenário, separe três elementos: o facto conhecido, a hipótese que pretende verificar e o possível dano. Por exemplo, pode ser um facto que o sistema produz uma classificação; uma hipótese, que determinados registos incompletos aumentam a probabilidade de uma classificação incorreta; e um dano plausível, que uma pessoa seja excluída de uma fase de avaliação sem uma análise adequada. O teste deverá determinar se a hipótese se confirma e em que condições.

Inclua as pessoas potencialmente afetadas e as condições que podem alterar o resultado: qualidade ou ausência de dados, idioma, ambiente de utilização, intervenção humana, dependência de outros componentes e alterações do processo. Não é necessário fingir certeza quando existe apenas uma hipótese. É preferível indicar que informação falta e como será investigada a apresentar uma estimativa sem fundamento como se fosse uma medição.

Associar cada risco a uma medida pertinente

Depois de descrever o cenário, defina que alteração pode prevenir ou reduzir o risco e por que motivo espera que funcione. O artigo 9.º exige a adoção de medidas de gestão de riscos adequadas e orientadas para os riscos identificados. Estabelece também que os riscos devem ser eliminados ou reduzidos tanto quanto possível do ponto de vista técnico, através de uma conceção e de um desenvolvimento adequados; quando não puderem ser eliminados, devem ser aplicadas medidas apropriadas de mitigação e controlo.

Na prática, uma medida pode estar ligada à conceção do sistema, à sua configuração, a instruções ou à forma como é integrado no processo. A escolha depende do risco e do sistema. Não presuma que um aviso na interface ou uma revisão humana genérica são suficientes: descreva o que a medida fará, em que momento será aplicada, quem pode intervir e quais são as suas limitações. Se uma pessoa precisar de informações ou formação para implantar o sistema de forma adequada, especifique o que deve saber e como receberá essa informação; o artigo contempla também, quando aplicável, informações e formação para os responsáveis pela implantação.

A justificação de uma medida deve estar ligada ao mecanismo do risco. Se o problema identificado for o de dados incompletos produzirem resultados pouco fiáveis, um controlo que apenas registe a data de execução pode deixar a causa intacta. Em contrapartida, podem ser avaliados mecanismos que detetem dados incompletos, impeçam a utilização de um resultado inválido sem revisão ou alertem a pessoa que opera o sistema. São opções a investigar, não prescrições universais: o teste deve mostrar se são pertinentes e eficazes no contexto concreto.

Tenha em conta que o Regulamento relaciona a gestão com o conhecimento e o estado da técnica, além da finalidade prevista e da utilização indevida razoavelmente previsível. Por isso, o registo deve permitir explicar por que motivo foi escolhida uma medida e que informações sustentaram essa escolha. Quando a medida não eliminar o risco, registe o que permanece e as condições em que o controlo pode falhar.

Conceber os testes antes de os executar

O artigo 9.º prevê testes dos sistemas de alto risco para identificar as medidas de gestão de riscos mais adequadas. Determina também que, quando aplicável, os testes sejam realizados em diferentes fases do desenvolvimento e, em qualquer caso, antes da colocação no mercado ou da entrada em serviço. A lei indica que devem ser realizados de acordo com métricas e limiares probabilísticos definidos previamente e adequados à finalidade prevista. O próprio artigo não estabelece uma métrica única aplicável a todos os sistemas.

Para que um teste permita tomar uma decisão, defina antecipadamente o cenário que abrange, os dados ou as condições envolvidos, o resultado a observar e o critério que considerará suficiente. Explique por que razão esse critério é pertinente para a utilização prevista. Se o definir depois de ver os resultados, aumenta o risco de adaptar a avaliação ao que já aconteceu e de não detetar falhas importantes.

Teste também as condições relevantes para o risco: por exemplo, dados em falta, alterações de idioma, casos-limite, entradas fora das condições habituais ou a intervenção humana prevista. A seleção deve ter uma justificação documentada; não é necessário enumerar cenários sem relação com a utilização. Se for utilizada uma amostra, explique as suas limitações e que grupos, situações ou condições não representa. Um resultado favorável num teste limitado não demonstra, por si só, que o sistema é seguro em qualquer ambiente.

O resultado pode ser favorável, insuficiente ou inconclusivo. Nos dois últimos casos, descreva o que falhou ou o que impede uma conclusão, ajuste a medida se for adequado e defina um novo teste. Guarde os resultados e as decisões pertinentes como evidência da forma como o risco foi gerido. A obrigação de testar não deve ser reduzida ao registo de uma pontuação: o objetivo é avaliar medidas adequadas e verificar o comportamento do sistema em relação à sua finalidade.

Modelo: ligar risco, controlo, teste e decisão

Uma linha de registo útil permite acompanhar toda a lógica sem confundir uma proposta de controlo com uma medida já validada. No exemplo hipotético de seleção de candidaturas, a questão não é afirmar que existe um enviesamento ou um dano comprovado. O objetivo é mostrar que informações devem ser reunidas antes de decidir se um controlo reduz o risco identificado.

A medida deve corresponder ao cenário e o teste deve avaliar essa medida, não apenas o sistema em abstrato. No exemplo, se o cenário for o de um dado em falta influenciar uma classificação que depois não é revista, um teste pertinente poderá examinar o que acontece quando esse dado falta e se o procedimento de revisão previsto é ativado. Os critérios concretos e o resultado não podem ser inventados: devem ser definidos e medidos para o sistema real.

Registe separadamente quem preparou a avaliação, quem aprovou uma decisão interna e quem deve analisar as questões jurídicas. A atribuição destas funções pode ser uma boa prática de governação, mas não atribua ao artigo 9.º um cargo universal que o texto não especifica. A pessoa ou entidade responsável depende do papel que desempenha nos termos do Regulamento e do caso concreto.

O que fazer com resultados insuficientes e riscos residuais

Um resultado que não atinge o critério previsto não deve ser corrigido retroativamente através da alteração do limiar para parecer aceitável. Registe o resultado tal como foi obtido, explique que condição não foi cumprida e analise se a causa exige uma alteração da conceção, a inclusão ou modificação de uma medida de mitigação, uma alteração do processo de implantação ou uma restrição da utilização avaliada. Em seguida, planeie uma nova avaliação, quando for pertinente.

Se o teste não permitir chegar a uma conclusão, identifique o motivo: falta de dados adequados, um cenário que não pode ser reproduzido, uma amostra limitada ou uma condição de utilização que não foi observada. Essa incerteza também é uma informação relevante. Indique o que é necessário para a resolver e quem deve decidir se é preciso continuar a investigação, limitar a utilização ou encaminhar a questão para análise.

Não descreva um risco como eliminado se a única ação tomada tiver sido reduzir a sua probabilidade ou limitar o seu impacto. A documentação deve tornar visível a diferença entre o risco inicial, o efeito das medidas e aquilo que ainda não foi testado. Esta distinção ajuda quem analisa o processo a não interpretar uma ação prevista como eficácia demonstrada.

O artigo 9.º exige a documentação do sistema de gestão de riscos e das decisões pertinentes. Como recomendação operacional, guarde com o registo as versões dos testes, as condições de execução, os resultados e a justificação das decisões. Antes de definir prazos de conservação, confirme as disposições aplicáveis ao sistema e à organização: este guia não estabelece um prazo universal.

Revisão ao longo do ciclo de vida e relação com outros processos

A gestão de riscos prevista no artigo 9.º não é concebida como uma avaliação única que termina quando um teste é concluído. O sistema deve funcionar como um processo contínuo e iterativo ao longo do ciclo de vida, sujeito a revisão e atualização regulares e sistemáticas. As informações recolhidas após a implantação podem ser pertinentes para avaliar os riscos; o artigo contempla também os dados obtidos através da monitorização pós-comercialização a que o Regulamento se refere.

Como proposta organizativa, defina que alterações podem desencadear uma revisão: modificações relevantes do sistema, mudanças da finalidade ou do contexto de utilização, problemas detetados, novas informações sobre riscos ou resultados da monitorização. Estabeleça quem recebe essas informações e como se decide se é necessário atualizar a análise, as medidas ou os testes. Estes desencadeadores concretos são uma recomendação para tornar a revisão operacional, não uma lista literal do artigo 9.º.

Se o sistema já estiver sujeito a requisitos de gestão de riscos previstos noutra legislação da União, o artigo 9.º prevê que o sistema de gestão correspondente possa integrar os processos exigidos por essa legislação ou contribuir para eles, nas condições indicadas no Regulamento. Não presuma que um procedimento existente cumpre automaticamente todas as obrigações do AI Act: verifique quais os riscos, evidências e requisitos efetivamente abrangidos por cada processo.

A data em que uma obrigação se torna aplicável depende das disposições temporais pertinentes e pode exigir a consulta das alterações e medidas transitórias em vigor. O calendário não pode ser deduzido apenas do artigo 9.º. Antes de definir uma data de cumprimento, consulte a versão oficial em vigor e as disposições aplicáveis ao tipo de sistema e ao papel da organização. Se a data tiver impacto numa decisão imediata, solicite aconselhamento jurídico atualizado.

Critérios práticos antes de concluir a avaliação

Antes de considerar o trabalho concluído, verifique se cada risco está descrito de forma compreensível e se os elementos observados estão distinguidos das hipóteses. Confirme que cada medida responde a um risco específico, que é possível reconstruir a respetiva justificação e que o teste inclui critérios definidos antes da sua execução. Se uma medida ainda não tiver sido testada, assinale-a como pendente; se um teste abranger apenas certas condições, não estenda o resultado a outras.

Verifique também se a análise diz respeito à finalidade e ao contexto efetivamente avaliados, se considera as utilizações indevidas razoavelmente previsíveis que sejam pertinentes e se não omite pessoas potencialmente afetadas. Documente as limitações do trabalho e as questões que exigem análise jurídica ou técnica. Quando existirem processos anteriores, confirme o que abrangem, que evidências fornecem e que lacunas permanecem.

O artigo 9.º não é uma certificação automática de que um sistema é seguro nem uma garantia de que não ocorrerão danos. É a base de um processo de gestão de riscos que deve ser mantido e documentado. A utilidade de uma matriz não se mede pelo número de linhas, mas pela possibilidade de compreender por que motivo foi escolhida uma medida, que teste a sustenta, que resultado foi observado e o que continua por resolver.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.