O essencial
- Um incidente de IA é qualquer acontecimento em que o desenvolvimento, a utilização ou a falha de um sistema de IA provoca, direta ou indiretamente, um dano real. A noção vai além do simples erro de software e do acidente de trabalho.
- O artigo 73.º do Regulamento da IA obriga os fornecedores de sistemas de IA de risco elevado a comunicar os incidentes graves às autoridades de fiscalização do mercado. A obrigação aplica-se a partir de 2 de agosto de 2026.
- Os prazos são curtos e diferenciados: 2 dias em caso de infração de grande escala ou de perturbação grave de uma infraestrutura crítica, 10 dias em caso de morte, 15 dias para os restantes incidentes graves.
- O incidente grave é definido no artigo 3.º, ponto 49: morte ou dano grave para a saúde, perturbação grave e irreversível de uma infraestrutura crítica, violação de obrigações de proteção dos direitos fundamentais, ou dano grave a bens ou ao ambiente.
- A comunicação de incidentes de IA só se sustenta se assentar num processo interno repetível: detetar, qualificar, decidir a comunicabilidade, notificar dentro do prazo e, depois, investigar e corrigir.
O que é a comunicação de incidentes e o que torna diferente um incidente de IA
A comunicação de incidentes consiste em documentar um acontecimento inesperado para perceber o que sucedeu, conter o dano e evitar a repetição. Na segurança no trabalho, na saúde e na gestão de serviços de TI, a prática está consolidada: um quase-acidente, uma lesão ou uma falha de serviço são registados num formulário normalizado, e o registo alimenta a investigação e a ação corretiva. A IA desloca o problema, e é precisamente aí que a comunicação de incidentes de IA se distingue da sua versão genérica. O dano causado por um sistema de IA é muitas vezes indireto. O modelo não faz ninguém tropeçar nem derrama qualquer substância; produz uma saída sobre a qual uma pessoa ou outro sistema age, e o dano surge a jusante. Uma sugestão de triagem médica errada, uma recusa de crédito enviesada ou uma falha de moderação de conteúdos podem causar um dano sério sem qualquer avaria visível. A cadeia entre a causa e a consequência é longa, estatística e difícil de imputar. Por isso, reguladores e organismos de normalização elaboraram definições próprias da IA. No seu relatório de 2024 Defining AI Incidents and Related Terms, a OCDE fixa a taxonomia de referência: um incidente de IA é um acontecimento em que o desenvolvimento, o uso ou a falha de um sistema de IA conduz, direta ou indiretamente, a um dano (lesões em pessoas, perturbação de infraestruturas críticas, violação de direitos humanos, dano a bens ou ao ambiente). A OCDE distingue o perigo de IA, uma circunstância que poderia plausivelmente conduzir a um incidente, do incidente de IA, em que o dano se concretiza, e acrescenta o desastre de IA como incidente grave que desorganiza uma coletividade. Estas distinções determinam o que a organização deve vigiar, registar e, por vezes, comunicar. Orientam também o modo como a AI Sigil aborda a gestão do risco de IA.
A obrigação do Regulamento da IA: a comunicação de incidentes graves do artigo 73.º
Para quem opera no mercado da União ou aí vende, a boa prática torna-se obrigação legal. O mecanismo é o artigo 73.º do Regulamento da IA, o eixo de qualquer programa de conformidade com o Regulamento da IA para os sistemas de risco elevado.
Quem deve comunicar, e a quem
O texto é direto: os fornecedores de sistemas de IA de risco elevado colocados no mercado da União comunicam qualquer incidente grave às autoridades de fiscalização do mercado do Estado-Membro em que o incidente ocorreu (Regulamento da IA, artigo 73.º). O responsável pela implementação não é um mero espetador: quando toma conhecimento de um incidente grave, a obrigação leva-o a informar o fornecedor e, nos casos previstos, a autoridade. Em Portugal, a CNPD ocupa um lugar central no quadro nacional de supervisão, a par das autoridades setoriais designadas.
O que constitui um incidente grave
O gatilho é a definição do artigo 3.º, ponto 49. Um incidente grave é um incidente ou uma anomalia que provoca, direta ou indiretamente, uma de quatro consequências: a morte de uma pessoa ou um dano grave para a sua saúde; uma perturbação grave e irreversível da gestão ou do funcionamento de uma infraestrutura crítica; uma violação das obrigações do direito da União destinadas a proteger os direitos fundamentais; ou um dano grave a bens ou ao ambiente. Na sua ausência, o acontecimento pode merecer um registo interno sem ser, por isso, um incidente grave comunicável.
Os prazos de comunicação
O artigo 73.º fixa um relógio de várias velocidades, e ele corre depressa.
- 2 dias: uma infração de grande escala, ou uma perturbação grave e irreversível de uma infraestrutura crítica.
- 10 dias: a morte de uma pessoa.
- 15 dias: todos os restantes incidentes graves.
A regra de base liga tudo: o fornecedor comunica imediatamente após estabelecer um nexo de causalidade, ou a probabilidade razoável de tal nexo, entre o sistema de IA e o incidente, e em qualquer caso o mais tardar 15 dias após ter conhecimento. Como as janelas são estreitas, o Regulamento admite uma comunicação inicial incompleta, seguida de um relatório completo assim que os factos estiverem clarificados.
Depois da comunicação
A comunicação não é um ponto final. Na sequência de um incidente grave, o fornecedor realiza sem demora as investigações necessárias, incluindo uma avaliação do risco do incidente, e adota medidas corretivas. A autoridade de fiscalização do mercado dispõe então de sete dias para tomar as medidas adequadas.
Quando o relógio começa e as orientações da Comissão de setembro de 2025
A questão operacional mais delicada é saber quando o prazo começa. A obrigação liga-se ao conhecimento e ao nexo de causalidade: o prazo corre a partir do momento em que o fornecedor estabelece, ou poderia razoavelmente estabelecer, uma ligação entre o sistema de IA e o dano. Em setembro de 2025, a Comissão Europeia publicou um projeto de orientações e um modelo de comunicação para tornar o cumprimento praticável. O projeto, divulgado a 26 de setembro de 2025 e aberto a consulta até 7 de novembro de 2025, esclarece que um nexo de causalidade indireto basta, com exemplos como uma análise médica errada que provoca um dano posterior ou uma avaliação de crédito viciada (Latham & Watkins, 2025). Aborda também a sobreposição com as regras setoriais: para um operador de infraestruturas críticas já obrigado a comunicar ao abrigo da NIS2, apenas um incidente que afete os direitos fundamentais exige uma comunicação distinta ao abrigo do artigo 73.º, seguindo os restantes o canal setorial. A obrigação aplica-se a partir de 2 de agosto de 2026, data de eficácia das regras sobre sistemas de risco elevado. Adiar a conceção do processo até lá obriga a construí-lo sob pressão, durante um incidente real.
Incidentes dos modelos de fins gerais e risco sistémico
Os sistemas de risco elevado não são os únicos abrangidos. Os fornecedores de modelos de IA de fins gerais com risco sistémico carregam obrigações próprias ao abrigo do artigo 55.º: acompanhar, documentar e comunicar os incidentes graves ao Serviço para a IA, juntamente com as possíveis medidas corretivas. O código de boas práticas para os modelos de fins gerais, cujo capítulo de segurança e proteção foi finalizado em julho de 2025, traduz esse dever em compromissos concretos: manter um acompanhamento dos incidentes graves, transmitir a informação relevante ao Serviço para a IA e às autoridades nacionais em prazos definidos, e conservar a documentação que sustenta a análise posterior. Para os maiores fornecedores de modelos, a comunicação de incidentes de IA passa a ser uma obrigação de vigilância contínua em vez de uma apresentação ocasional. A AI Sigil integra-a numa única plataforma de governação da IA, não num silo separado.
Onde a comunicação se inscreve nas normas: NIST e ISO
A regulação fixa a base. As normas voluntárias fornecem o modelo operacional. O quadro de gestão do risco de IA do NIST organiza o trabalho em quatro funções: Govern, Map, Measure e Manage. A resposta a incidentes recai sobretudo em Manage, que exige uma monitorização pós-implementação, mecanismos para recolher e tratar os problemas, e uma resposta a incidentes, uma recuperação e uma gestão da mudança documentadas. Govern acrescenta as políticas e a prestação de contas que impedem esses mecanismos de caírem em desuso. A norma ISO/IEC 42001 sobre o sistema de gestão da IA coloca a gestão de incidentes num ciclo certificável Planear-Executar-Verificar-Atuar. A organização que opera um sistema 42001 mantém um processo definido para os incidentes de IA, liga-o ao tratamento do risco e demonstra ao auditor que o ciclo se fecha. Para uma equipa já certificada na ISO/IEC 27001, o processo de incidentes de IA pode encaixar no processo de incidentes de segurança existente em vez de o duplicar.
Construir um processo interno de comunicação de incidentes de IA
Uma obrigação de comunicação vale o que vale o processo que a sustenta. Um processo operacional de comunicação de incidentes de IA tem quatro fases, cada uma com um responsável designado.
Detetar e rececionar
A maioria dos incidentes de IA é notada primeiro por um utilizador, um agente de suporte ou um sistema a jusante, não por um painel de controlo. Dê a cada canal um único ponto de receção: um formulário, uma fila ou uma linha dedicada, aberto a todos sem ter de julgar antecipadamente a comunicabilidade. Recolha o essencial no momento da receção (o que aconteceu, que sistema, quando, que dano observado) para que os factos relevantes para o cálculo do prazo existam desde o primeiro minuto.
Qualificar e decidir a comunicabilidade
É a decisão de que dependem os prazos. Confronte cada receção com o teste do artigo 3.º, ponto 49: o acontecimento provocou, direta ou indiretamente, morte ou dano grave para a saúde, perturbação de uma infraestrutura crítica, violação de direitos fundamentais ou dano grave a bens ou ao ambiente? Uma árvore de decisão curta, confiada a um papel designado, mantém a qualificação coerente e rastreada. Registe o raciocínio mesmo quando a resposta é não, porque esse registo é a defesa da organização se a decisão for mais tarde contestada.
Notificar dentro do prazo
Uma vez qualificado o acontecimento como incidente grave, aplica-se o relógio diferenciado. Identifique a autoridade de fiscalização do mercado competente, prepare a comunicação no modelo da Comissão e transmita dentro de 2, 10 ou 15 dias consoante a categoria. Prefira a comunicação inicial incompleta a ultrapassar o prazo.
Investigar, corrigir e registar
Após a transmissão, procure a causa raiz, conduza a avaliação do risco exigida pelo artigo 73.º e adote medidas corretivas. Registe tudo num registo que ligue o incidente ao sistema, à versão do modelo, aos utilizadores afetados e à correção. Bases de dados externas como a AI Incident Database (AIID), o repositório AIAAIC e o OECD AI Incidents Monitor servem de pontos de referência para aprender com os incidentes do setor, uma prática que o CSET examinou na sua nota de janeiro de 2025.
Em que difere a comunicação de incidentes de IA de outros regimes
Um mesmo acontecimento pode ativar várias obrigações ao mesmo tempo. Uma fuga de dados num sistema de IA pode ser uma violação de dados pessoais nos termos do RGPD, com a sua notificação em 72 horas à autoridade de controlo nos termos do artigo 33.º, um incidente grave nos termos do artigo 73.º e, para uma entidade financeira, uma comunicação de incidente TIC nos termos da DORA. A NIS2 acrescenta obrigações para as entidades essenciais e importantes, e as regras setoriais para dispositivos médicos, aviação ou serviços financeiros acrescentam outras. A lição prática: cartografar as obrigações de comunicação uma vez, antecipadamente, e conceber um único ponto de receção capaz de ramificar para os regimes certos. A equipa que trata a comunicação de incidentes de IA como uma tarefa isolada do Regulamento da IA acabará por comunicar o mesmo acontecimento três vezes, em três formatos e sob três relógios, ou pior, esquecerá um. Centralizar o mapa das obrigações é exatamente aquilo para que uma plataforma de governação da IA foi construída.
Perguntas frequentes
O que é a comunicação de incidentes de IA? A comunicação de incidentes de IA é o processo estruturado de detetar, documentar e, quando a lei o exige, notificar as autoridades dos acontecimentos em que um sistema de IA causa ou contribui para um dano. Nos termos do Regulamento da IA, é uma obrigação legal para os fornecedores de sistemas de risco elevado e de certos modelos de fins gerais, não apenas uma boa prática interna. Quais são os passos para comunicar um incidente de IA? Detetar e registar o acontecimento num único ponto de receção; qualificá-lo face à definição de incidente grave do artigo 3.º, ponto 49; se se enquadrar, notificar a autoridade de fiscalização do mercado competente dentro do prazo aplicável; depois procurar a causa raiz, avaliar o risco e adotar medidas corretivas. Conserve um registo escrito em cada passo, incluindo o raciocínio para os acontecimentos não comunicados. O que contém um relatório de incidente de IA? No mínimo: uma descrição dos factos, o sistema de IA e a versão do modelos envolvidos, a data em que houve conhecimento, o tipo e a gravidade do dano, as pessoas ou os bens afetados, o nexo de causalidade presumido e as medidas corretivas adotadas ou previstas. O modelo de comunicação da Comissão para o artigo 73.º estrutura estes campos. O que é um incidente grave nos termos do Regulamento da IA? O artigo 3.º, ponto 49, define-o como um incidente ou uma anomalia que provoca, direta ou indiretamente, a morte de uma pessoa ou um dano grave para a saúde, uma perturbação grave e irreversível de uma infraestrutura crítica, uma violação das obrigações do direito da União de proteção dos direitos fundamentais, ou um dano grave a bens ou ao ambiente. Quando se aplica o artigo 73.º e com que rapidez é preciso comunicar? A obrigação aplica-se a partir de 2 de agosto de 2026. Os prazos correm a partir do conhecimento e da possibilidade de estabelecer um nexo de causalidade: 2 dias para uma infração de grande escala ou uma perturbação grave de infraestruturas críticas, 10 dias em caso de morte, 15 dias para os restantes incidentes graves. Em que difere de uma notificação de violação de dados? Uma violação nos termos do RGPD diz respeito a dados pessoais e impõe uma notificação em 72 horas. Um incidente grave nos termos do Regulamento da IA diz respeito ao dano causado pelo próprio sistema de IA, sobre o relógio de 2, 10 ou 15 dias. O mesmo acontecimento pode ativar ambos, além de regimes setoriais como a NIS2 ou a DORA: os deveres devem ser cartografados em conjunto.
Conclusão
A comunicação de incidentes de IA passa de um hábito de cultura de segurança a uma obrigação legal estrita, com prazos curtos e responsabilidades nomeadas. Vai abordá-la com serenidade quem decidir agora quem guarda a receção, como se qualifica um incidente grave e que autoridade notificar dentro de que janela. O trabalho a fazer antes de 2 de agosto de 2026 não é apenas interpretação jurídica: é o processo permanente que transforma o artigo 73.º numa rotina governável. A AI Sigil ajuda as equipas dos setores regulados a converter obrigações como esta em processos vivos e auditáveis dentro de um único sistema de governação.