Incidentes graves de IA: como preservar provas, conter os danos e decidir se uma falha deve ser notificada ao abrigo do artigo 73.º do AI Act

Uma falha não é automaticamente um incidente grave

A resposta a um resultado perigoso de um sistema de IA começa por separar conceitos que são frequentemente confundidos. Um erro do modelo pode ser uma saída inexata, incoerente ou indesejada. Um incidente operacional pode incluir uma indisponibilidade do serviço, uma configuração incorreta, uma integração falhada ou uma utilização de ferramentas fora do comportamento previsto. Um dano é uma consequência negativa concreta para uma pessoa, uma organização, bens, o ambiente ou um processo. Um incidente grave, no sentido regulamentar aplicável a este guia, é uma categoria mais restrita e associada a efeitos específicos definidos pelo AI Act.

Nem toda a alucinação, redução de qualidade, reclamação de utilizador ou resposta ofensiva aciona, por si só, o regime do artigo 73.º. Também não seria prudente descartar um caso porque a saída isolada parece menor: uma resposta aparentemente comum pode ter influenciado uma decisão clínica, de recrutamento, de acesso a um serviço, de segurança física ou de operação de infraestruturas. A análise deve partir de factos observáveis, e não de rótulos internos como «bug menor» ou «reclamação não crítica».

O texto consolidado do AI Act define o incidente grave através de categorias de resultado, incluindo morte ou danos graves para a saúde, perturbação grave e sustentada da gestão ou operação de infraestruturas críticas, violação de obrigações destinadas a proteger direitos fundamentais e danos graves a bens ou ao ambiente. A classificação exige examinar o facto, o sistema afetado e a possível ligação entre ambos. Não deve ser substituída por uma pontuação interna de severidade sem correspondência documentada com essas categorias.

É aconselhável manter duas vias desde o primeiro alerta. A via técnica procura interromper um comportamento inseguro e restaurar um serviço controlado. A via de prova e conformidade procura preservar os factos, avaliar o possível nexo causal, coordenar fornecedor e responsável pela utilização e determinar se deve ser preparada uma comunicação à autoridade competente. Podem avançar em paralelo, mas uma correção precipitada pode dificultar a segunda via se modificar ou eliminar a informação necessária para explicar o que aconteceu.

Âmbito: identificar o sistema, o operador e a via de risco elevado

O artigo 73.º dirige-se aos fornecedores de sistemas de IA de risco elevado que tenham sido colocados no mercado da União. Por isso, o primeiro dado a verificar não é a gravidade percebida pela equipa, mas sim qual foi o sistema exato que interveio, quem é o seu fornecedor para efeitos do Regulamento e se estava sujeito à classificação de risco elevado relevante. O AI Act prevê duas vias principais de classificação no seu artigo 6.º: determinados sistemas relacionados com produtos ou componentes de segurança regulados e os casos de utilização enumerados no anexo III, nas condições e exceções previstas no próprio Regulamento.

Não basta afirmar que um modelo de finalidade geral, uma interface conversacional ou uma automatização «é de risco elevado» pelo seu tema. A unidade de análise deve ser o sistema disponibilizado ou utilizado no contexto concreto: versão, finalidade prevista, integração, funções ativadas, utilizadores, dados de entrada e resultado produzido. Um mesmo componente pode integrar configurações com obrigações diferentes. O projeto de orientações da Comissão sobre classificação pode ajudar a estruturar a revisão, mas continua a ser um projeto e não substitui o texto vinculativo nem a apreciação jurídica do caso.

O planeamento temporal deve distinguir entre preparação e aplicabilidade efetiva. As organizações podem construir desde já os seus processos de registo, preservação, contacto e escalonamento. Contudo, as datas concretas de aplicação para diferentes categorias de risco elevado devem ser verificadas face à versão juridicamente aplicável do Regulamento e a qualquer alteração em vigor no momento de decidir um caso. Não é recomendável transformar uma data de planeamento interno numa conclusão de que uma obrigação já é exigível.

Para orientar o trabalho relacionado, a equipa pode separar este protocolo das revisões gerais de Segurança, da avaliação de alternativas em Comparar e da identificação de capacidades em Descobrir. Estas atividades podem fornecer contexto, mas a investigação de um incidente exige um processo centrado no facto ocorrido e na configuração efetivamente utilizada.

As primeiras horas: preservar antes de corrigir

Quando for detetado um caso potencialmente relevante, designe um responsável pelo incidente com capacidade para coordenar operações, produto, segurança, qualidade e conformidade. A sua primeira obrigação operacional é fixar uma cronologia: quando ocorreu o facto, quando foi detetado, quem recebeu cada alerta, que sistemas permaneceram ativos e que decisões foram tomadas. A hora de conhecimento pelo fornecedor e, quando aplicável, pelo responsável pela utilização deve ser registada separadamente, juntamente com a fonte que a comprova.

Preservar provas não significa copiar indiscriminadamente todos os dados disponíveis. Significa conservar, de forma proporcional, íntegra e com acesso controlado, os elementos que permitam reconstruir o comportamento investigado. No mínimo, o processo deve associar identificadores de pedido e de sessão, entradas e saídas, versão e parâmetros do modelo, prompt de sistema e modelos de prompt, políticas, configuração de recuperação, documentos recuperados ou os seus identificadores, chamadas e respostas de ferramentas, autorizações humanas, identidade ou função do operador e alterações de configuração próximas do evento.

A preservação deve incluir metadados de integridade: origem, data de extração, responsável, método de exportação, impressão digital do ficheiro quando viável, controlos de acesso e qualquer transformação posterior. Se existirem dados pessoais, segredos comerciais ou informação de segurança, o acesso deve ser limitado de acordo com as regras aplicáveis. Restringir o acesso não justifica apagar os elementos necessários à investigação. Quando um dado não puder ser conservado, o processo deve explicar o que foi eliminado, porquê, quando e que alternativa probatória permanece disponível.

O AI Act exige que o fornecedor investigue imediatamente o incidente grave e o sistema em causa, incluindo uma avaliação de riscos e medidas corretivas. Estabelece igualmente que o sistema não deve ser alterado antes da comunicação quando essa alteração puder afetar a posterior avaliação das causas do incidente. Na prática, isto obriga a conceber a contenção de modo a limitar os danos sem apagar o estado que deve ser analisado.

Conter os danos sem inviabilizar a investigação

A contenção não tem uma única forma correta. Suspender todo o sistema pode ser necessário se persistir um risco grave, mas também pode afetar processos essenciais ou levar os utilizadores a soluções não controladas. Outras medidas podem ser mais proporcionais: retirar temporariamente uma ferramenta de execução, reduzir permissões, impedir ações automatizadas de elevado impacto, bloquear um conjunto identificado de entradas, desativar uma fonte de recuperação comprometida ou exigir uma verificação humana para uma decisão específica.

Cada medida deve responder a uma hipótese explícita de dano e ter condições de revisão. «Colocar o sistema em modo seguro» não é uma descrição verificável se não definir que capacidade foi bloqueada, o que continuou disponível, que população foi afetada, que alternativas foram oferecidas e como foi verificado o efeito. A comunicação a clientes, utilizadores e operadores pode fazer parte da contenção, mas deve basear-se em factos confirmados e não atribuir causalidade antes de a investigação a sustentar.

A reversão para uma versão anterior exige prudência. Pode resolver o sintoma imediato, mas não prova que a causa estivesse na versão retirada e pode introduzir diferenças que impeçam reproduzir o caso. Antes de alterar, preserve o artefacto implantado, a configuração e os registos que permitam comparar o estado anterior com o posterior. Se a alteração for inevitável para evitar danos, documente a necessidade e o âmbito do desvio.

A autoridade de fiscalização do mercado pode dispor de poderes próprios perante produtos que apresentem um risco grave, incluindo medidas de avaliação e restrições. Essas atuações não substituem a investigação interna nem transformam a organização numa autoridade. A equipa deve estar preparada para fornecer factos verificáveis, avaliações e medidas aplicadas se receber um pedido.

Reconstruir o caso como uma cadeia de decisões

Uma investigação útil deve conseguir responder a uma pergunta simples: que sistema exato produziu ou contribuiu para o resultado e através de que sequência? Para isso, não basta a transcrição de uma conversa. Um processo reprodutível liga o identificador do caso ao modelo e à sua versão, aos parâmetros de inferência, às instruções de sistema, ao prompt montado, aos dados anexados, à configuração de recuperação, aos documentos selecionados, às ferramentas disponíveis, às chamadas efetuadas, às políticas ativas e às decisões humanas.

Também é necessário separar os factos do mecanismo suposto. Facto: uma ferramenta recebeu determinados parâmetros e foi produzida uma ação registada. Hipótese: o modelo interpretou incorretamente uma instrução ambígua. Facto: um operador aprovou uma recomendação. Hipótese: a interface não mostrava contexto suficiente para detetar o erro. Esta separação impede que o primeiro diagnóstico se transforme numa narrativa definitiva e permite rever hipóteses alternativas, incluindo falhas de dados, integração, interface, formação, processos humanos ou fatores externos.

A reprodutibilidade completa nem sempre será possível. O serviço externo pode ter mudado, pode faltar uma entrada, um resultado pode depender de aleatoriedade ou a conservação de dados pode ser limitada. Nesses casos, o processo deve descrever com precisão a lacuna, o seu impacto nas conclusões e os testes substitutos utilizados. A ausência de reprodução não demonstra, por si só, que o sistema não estivesse relacionado com o incidente.

A reconstrução deve incluir as alterações introduzidas durante a resposta. Sem esse registo, uma melhoria posterior pode ser confundida com a configuração original, e um resultado seguro obtido depois da contenção pode ser apresentado erradamente como prova de que o incidente não era possível. Manter a comparabilidade entre o estado inicial, o estado contido e o estado corrigido é uma condição prática para aprender com o caso.

Classificar a gravidade e o nexo causal sem antecipar o veredito

A classificação deve começar por perguntas concretas. Houve morte ou danos graves para a saúde? A operação ou gestão de infraestruturas críticas sofreu uma perturbação grave e sustentada? Ocorreu uma violação de obrigações orientadas para a proteção de direitos fundamentais? Houve danos graves a bens ou ao ambiente? Para cada pergunta, o processo deve identificar o facto alegado, as fontes que o sustentam, a extensão conhecida, as pessoas ou ativos afetados e os elementos que permanecem incertos.

Depois, deve ser analisada a ligação ao sistema. O artigo 73.º não exige que a organização aguarde uma prova causal definitiva se existir uma probabilidade razoável de relação, mas também não permite usar uma mera coincidência temporal como substituto de análise. Devem ser documentadas as vias causais plausíveis, as provas que as apoiam, os fatores alternativos e os testes pendentes. Por exemplo, uma saída incorreta pode ser relevante, mas a decisão final pode ter dependido de uma revisão humana independente ou de dados externos incorretos; ambos os elementos devem ser investigados.

Uma matriz interna de severidade pode facilitar o escalonamento, mas não deve substituir a definição jurídica. É recomendável que o formulário interno contenha campos separados para «impacto observado», «risco de impacto adicional», «categoria regulamentar potencial», «nexo confirmado», «nexo razoavelmente provável» e «nexo não estabelecido». Esta estrutura torna visível qual a parte que é facto e qual a que corresponde a uma análise provisória.

A decisão de que um caso não cumpre o limiar deve ser fundamentada e passível de revisão. Podem surgir novas informações de um responsável pela utilização, de um utilizador, de uma ferramenta ligada ou de uma autoridade. Encerrar a notificação não equivale a encerrar o processo técnico nem a eliminar as provas.

Fornecedor e responsável pela utilização: coordenar informação, não transferir o problema

O fornecedor e o responsável pela utilização podem deter partes diferentes das provas. O fornecedor controla normalmente a documentação do sistema, as versões, os testes, os registos de operação e as medidas corretivas do produto. O responsável pela utilização pode conhecer o contexto de utilização, a população afetada, as decisões humanas, os dados locais, as consequências materiais e as comunicações recebidas. Um contrato pode distribuir tarefas operacionais, mas não deve impedir a entrega rápida da informação necessária para cumprir as obrigações aplicáveis.

É aconselhável preparar uma matriz de contactos e uma cláusula operacional de incidente antes de ocorrer um caso. Deve incluir interlocutores disponíveis fora do horário normal, categorias mínimas de informação, canais seguros, prazos internos mais curtos do que os máximos regulamentares, regras de preservação, procedimento de aprovação de comunicações e tratamento de dados protegidos. O objetivo não é transferir automaticamente a responsabilidade, mas reduzir o tempo entre o conhecimento de um facto e a obtenção dos elementos necessários para o avaliar.

O responsável pela utilização deve conservar e disponibilizar os dados que estejam sob o seu controlo e sejam necessários, dentro dos limites legais aplicáveis. O fornecedor não deve exigir uma reprodução perfeita como condição para iniciar a avaliação. Por outro lado, o responsável pela utilização não deve aplicar alterações locais, apagar registos ou comunicar uma causa técnica como confirmada sem coordenar o processo. Quando intervêm várias entidades, um registo partilhado dos pedidos de prova ajuda a distinguir o que foi entregue, o que está pendente e o que não pode ser obtido.

As obrigações de transparência, registo e cooperação associadas a sistemas de risco elevado podem ser relevantes para o funcionamento desta coordenação, mas não tornam automaticamente o responsável pela utilização responsável pela notificação prevista para o fornecedor no artigo 73.º. A atribuição final depende do papel efetivo de cada entidade e das circunstâncias do sistema investigado.

Notificação: gerir os relógios sem os transformar numa fórmula automática

O artigo 73.º estabelece uma obrigação de comunicar incidentes graves às autoridades de fiscalização do mercado dos Estados-Membros nos quais o incidente tenha ocorrido, nas condições previstas pelo Regulamento. A comunicação está ligada tanto ao conhecimento do incidente como à determinação de um nexo causal ou da sua probabilidade razoável. Por isso, a equipa deve registar separadamente o momento de conhecimento, o momento em que foi adotada uma conclusão provisória sobre a ligação e as provas que sustentaram ambos os marcos.

O Regulamento prevê prazos máximos de dois, dez e quinze dias para situações diferentes, bem como a possibilidade de um relatório inicial incompleto seguido de informação adicional. A atribuição exata de cada prazo depende da categoria concreta do incidente e da redação aplicável à situação. Não deve ser deduzida de uma tabela interna abreviada nem da mera severidade técnica. O protocolo deve acionar uma revisão jurídica imediata, calcular o prazo a partir de um marco documentado e registar por que motivo foi escolhido esse relógio.

Um relatório inicial não deve ser preenchido com uma certeza artificial. Se a causa não for conhecida, deve indicar que está sob investigação, descrever os factos confirmados, o âmbito conhecido, as medidas de contenção, as provas disponíveis e o plano para completar a informação. A possibilidade de apresentar um relatório incompleto não justifica atrasar uma comunicação exigida nem omitir uma investigação diligente.

O modelo e as orientações publicados pela Comissão sobre incidentes graves são materiais de consulta úteis para organizar campos e sequências, mas são apresentados como projetos sujeitos a consulta. Não devem ser tratados como orientação final vinculativa. Num caso real, a equipa deve confrontar o conteúdo da comunicação com o Regulamento aplicável e com as instruções da autoridade competente.

Investigação, correção e retoma controlada

A investigação não termina com o envio de uma comunicação. Deve explicar a causa ou as causas contribuintes com um nível de confiança proporcional: comportamento do modelo, dados de entrada, recuperação, ferramenta, interface, permissões, configuração, supervisão humana, formação, processo operacional ou uma combinação destes fatores. Uma única causa raiz pode ser uma simplificação enganadora quando o incidente depende de vários controlos que falharam ou não existiam.

A ação corretiva deve estar ligada à via de dano identificada. Ajustar um prompt pode ser insuficiente se o problema for uma permissão excessiva de uma ferramenta; acrescentar uma revisão humana pode ser insuficiente se o revisor não receber os dados necessários; eliminar um documento pode ser insuficiente se o conector continuar a incorporar fontes não autorizadas. Para cada medida, defina que risco reduz, que risco residual deixa, que efeitos secundários poderá introduzir e como será validada.

A validação deve incorporar o caso do incidente e uma regressão mais ampla. Testar apenas a conversa original pode favorecer uma correção demasiado ajustada. É preferível combinar testes representativos, casos-limite, testes de permissões e fluxos completos até à ação externa, além de rever o efeito sobre utilizadores e grupos afetados quando adequado. Conserve os resultados, o ambiente de teste, as versões e os critérios de aceitação.

A retoma não deve ser uma decisão implícita tomada quando se fecha um ticket. Deve ter um responsável, critérios de autorização, âmbito inicial, métricas de vigilância reforçada, mecanismo de reversão e condições que obriguem a voltar a suspender. Se subsistir uma incerteza material, a organização pode optar por manter limitada a capacidade afetada enquanto conclui a investigação. Essa decisão e o seu fundamento devem constar do processo.

Preparação trimestral: verificar se o protocolo funciona antes do incidente

A capacidade de responder não se demonstra pela mera existência de registos técnicos ou de uma política escrita. É necessário provar que a equipa consegue recuperar um caso realista sem depender de uma única pessoa nem de ferramentas que não retêm os dados necessários. Um exercício trimestral pode selecionar um fluxo de risco, simular um alerta e medir quanto tempo a organização demora a identificar a versão implantada, isolar a capacidade afetada, obter registos do responsável pela utilização e produzir uma cronologia com fontes verificáveis.

A revisão deve incluir alterações de fornecedores, modelos, ferramentas, corpus, permissões, responsáveis e mercados de implantação. Um protocolo preparado para um modelo estático pode falhar quando existe encaminhamento entre modelos, implantações graduais, recuperação dinâmica ou ferramentas de terceiros. Também é aconselhável verificar se os acordos com clientes e fornecedores permitem partilhar rapidamente as provas necessárias, com controlos adequados de confidencialidade e proteção de dados.

O resultado de cada exercício deve gerar melhorias observáveis: campos em falta nos registos, decisões sem responsável, impossibilidade de recuperar configurações, ausência de um canal de emergência ou critérios ambíguos de suspensão. Não se trata de declarar conformidade geral com o AI Act, mas de reduzir a incerteza numa resposta concreta a um incidente. A preparação mais útil é a que permite dizer o que se sabe, o que não se sabe e o que foi feito para evitar que o dano continue.

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.