Designing escalation criteria for international AI incident response: criteria, triggers, and thresholds

Resumo Técnico: Testes de Estresse em Escalonamento de Incidentes de IA

Declaração do Problema
À medida que surgem estruturas regulatórias para relatórios de incidentes de IA (por exemplo, o Ato de IA da UE, SB 53 da Califórnia), existe uma lacuna crítica na avaliação de se os critérios de escalonamento dentro dessas estruturas detectam de forma confiável os incidentes que foram projetados para capturar. A literatura atual foca no design de bancos de dados de incidentes e na detecção de danos sistêmicos, mas carece de uma avaliação de se os critérios a montante — definições, limiares e gatilhos — funcionam efetivamente quando aplicados a cenários do mundo real. Critérios mal projetados correm o risco de produzir pontos cegos sistemáticos, falhando em escalar incidentes que merecem atenção.

Metodologia
Os autores empregam um processo de design sequencial de três etapas:

1. Desenvolvimento do Framework: Um framework de escalonamento de oito critérios foi construído revisando precedentes de domínios cruzados (por exemplo, Regulamentos Sanitários Internacionais da OMS, DORA da UE, Basileia II) e regulamentações de IA existentes.
2. Testes de Estresse: O framework foi submetido a uma metodologia de "revisão passo a passo" (walkthrough), inspirada em exercícios de mesa de cibersegurança e experiências iniciais de implementação da DORA. Dez incidentes de IA documentados e variantes estruturadas foram analisados em quatro domínios de alto risco: cibernético, CBRN (Químico, Biológico, Radiológico, Nuclear), dano psicológico e risco multiagente.
3. Análise Contrafactual: Para cada incidente, os autores determinaram se o framework acionaria o escalonamento, em qual porta de decisão e com base em quais evidências disponíveis em pontos temporais específicos. Variações estruturadas foram introduzidas para identificar condições sob as quais as classificações mudariam.

O Framework de Escalonamento
O framework proposto classifica incidentes em três resultados: Escalar (coordenação internacional necessária), Alertar (suporte de capacidade/compartilhamento de informações) ou Descartar. Ele utiliza um fluxograma sequencial com oito critérios de porta:

1. Causalidade da IA: A IA foi um fator causal?
2. Escopo: Exclusões baseadas em domínio (por exemplo, militar).
3. Escalonamento Imediato: Gatilhos pré-dano (por exemplo, assistência CBRN, perda de controle do desenvolvedor) independentemente de dano confirmado.
4. Detecção de Padrões: Agregação de incidentes compartilhando uma causa raiz (técnica, de capacidade ou contextual).
5. Categoria e Gravidade do Dano: Avaliação contra taxonomias reconhecidas (por exemplo, MIT) e níveis de gravidade (Nível 4+).
6. Propagação Transfronteiriça: Necessidade de coordenação internacional.
7. Dano Transfronteiriço Irreversível: Dano permanente com efeitos a jusante.
8. Quase Acidente: Incidentes evitados que revelam modos de falha afetando outros sistemas.

Principais Resultados
Os testes de estresse revelaram que o framework desempenha de forma confiável para incidentes de início discreto e individualmente graves, onde o papel causal da IA é claro. No entanto, três categorias de incidentes provaram ser estruturalmente desafiadoras, levando a uma subdetecção sistemática nas estruturas regulatórias atuais:

• Danos Cumulativos, Individualmente Abaixo do Limiar: Incidentes como deepfakes não consensuais e dano psicológico da interação humano-IA envolvem milhões de interações de baixa gravidade. Estruturas atuais que avaliam incidentes individualmente falham em capturar a gravidade agregada, que só se torna visível através da detecção de padrões e agregação.
• Quase Acidentes e Dano Potencial: Incidentes com alta gravidade potencial, mas baixo dano realizado (por exemplo, vulnerabilidades de plataformas agênticas), são frequentemente perdidos, a menos que critérios específicos de quase acidente sejam aplicados.
• Lacunas na Escala de Gravidade: Danos difusos (angústia psicológica, violações de dignidade) não mapeiam bem para descritores quantitativos de gravidade existentes. Estruturas atuais carecem de mecanismos para agregação entre categorias, fazendo com que incidentes fiquem abaixo dos limiares de escalonamento, apesar de serem tratados regulatóriamente como graves.

Descobertas: A Cadeia de Dependência e Padrões de Design
Os autores identificam uma cadeia de dependência de três camadas que explica essas falhas:

1. Camada 1 (Infraestrutura de Dados): O que pode ser detectado.
2. Camada 2 (Fundamentos Definicionais): Como incidentes e danos são categorizados e pontuados.
3. Camada 3 (Gatilhos de Escalonamento): Limiares e lógica de decisão.

Lacunas nas camadas a montante propagam-se a jusante. O artigo identifica quatro padrões de design específicos em estruturas atuais (Ato de IA da UE, SB 53) que impulsionam a subdetecção:

1. Gatilhos que Requerem Dano Confirmado para Riscos Pré-Dano: Exigir resultados de dano real antes do relatório impede o escalonamento de eventos de alto risco (por exemplo, modelo fornecendo assistência CBRN) onde o desenvolvedor vê o gatilho, mas não o dano a jusante.
2. Avaliação Apenas Individual Perdendo Danos Cumulativos: A falta de disposições de agregação significa que efeitos em nível populacional (por exemplo, 500.000 usuários exibindo fatores de risco) são invisíveis quando avaliados como eventos discretos.
3. Limiares Legalmente Definidos que Não São Praticamente Testáveis: Definições que dependem de "violação de direitos fundamentais" ou limiares quantitativos específicos (por exemplo, 50 vítimas) são ou inmensuráveis pelos desenvolvedores ou perdem incidentes de gravidade moderada, mas reais.
4. Arquitetura de Evento Discreto Aplicada a Condições Permanentes: Aplicar lógica baseada em eventos a condições contínuas e permanentes (por exemplo, dano psicológico contínuo, erosão gradual da integridade da informação) torna esses riscos invisíveis, pois não há ponto de início ou resolução discreto.

Solução Proposta
Para abordar "condições permanentes", os autores propõem monitoramento baseado em tolerância, baseando-se em precedentes dos serviços financeiros (por exemplo, Basileia II, Banco da Inglaterra). Isso envolve:

1. Padronizar categorizações de danos entre provedores.
2. Operacionalizar monitoramento contínuo (migrando de instantâneos pontuais para feeds contínuos).
3. Estabelecer tolerâncias onde eventos reportáveis são definidos por mudanças anormais na taxa, gravidade ou distribuição do dano (por exemplo, picos de prevalência acima da linha de base) em vez da mera presença de dano.

Significado e Alegações
O artigo alega que projetar melhores gatilhos sozinho é insuficiente. Trabalho definicional (Camada 2) e infraestrutura de dados (Camada 1) são pré-condições para critérios de escalonamento operacionais. Sem abordar essas camadas a montante, as estruturas correm o risco de serem formalmente completas, mas operacionalmente não implementáveis, particularmente para domínios de risco onde a subdetecção tem consequências graves.

O trabalho contribui para a capacidade de "Operacionalização" da governança técnica de IA ao:

• Fornecer um framework de oito critérios fundamentado em precedentes de domínios cruzados.
• Demonstrar, por meio de testes de estresse, que designs regulatórios atuais contêm características estruturais que levam a pontos cegos sistemáticos.
• Propor uma estrutura de dependência que explica por que certos riscos (cumulativos, psicológicos, condições permanentes) são atualmente invisíveis aos mecanismos de escalonamento.
• Oferecer uma proposta construtiva de monitoramento baseado em tolerância para abordar danos contínuos em nível populacional.

Os autores notam limitações, incluindo o tamanho da amostra de dez incidentes e a dependência de julgamentos na metodologia de revisão passo a passo, sugerindo que trabalhos futuros devem envolver validação multissetorial e refinamento de gatilhos específicos de domínio.