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

Riepilogo Tecnico: Stress-test per l'Innalzamento di Livello degli Incidenti AI

Enunciato del Problema
Con l'emergere di quadri normativi per la segnalazione degli incidenti AI (ad esempio, l'AI Act dell'UE, SB 53 della California), esiste un divario critico nella valutazione della capacità dei criteri di innalzamento di livello contenuti in tali quadri di rilevare in modo affidabile gli incidenti che sono progettati per intercettare. La letteratura attuale si concentra sulla progettazione di database di incidenti e sul rilevamento di danni sistemici, ma manca di una valutazione se i criteri a monte – definizioni, soglie e trigger – funzionino efficacemente quando applicati a scenari del mondo reale. Criteri scarsamente progettati rischiano di produrre punti ciechi sistematici, non innalzando di livello incidenti che meritano attenzione.

Metodologia
Gli autori impiegano un processo di progettazione sequenziale in tre fasi:

1. Sviluppo del Quadro: È stato costruito un quadro di innalzamento di livello a otto criteri esaminando precedenti cross-settoriali (ad esempio, Regolamenti Sanitari Internazionali dell'OMS, DORA dell'UE, Basilea II) e le normative AI esistenti.
2. Stress-test: Il quadro è stato sottoposto a una metodologia di "walkthrough", ispirata agli esercizi da tavolo sulla cybersecurity e alle prime esperienze di implementazione della DORA. Dieci incidenti AI documentati e varianti strutturate sono stati analizzati in quattro domini ad alto rischio: cyber, CBRN (Chimico, Biologico, Radiologico, Nucleare), danno psicologico e rischio multi-agente.
3. Analisi Controfattuale: Per ogni incidente, gli autori hanno determinato se il quadro avrebbe attivato l'innalzamento di livello, a quale cancello decisionale e basandosi su quali prove disponibili in specifici punti temporali. Sono state introdotte variazioni strutturate per identificare le condizioni in cui le classificazioni sarebbero cambiate.

Il Quadro di Innalzamento di Livello
Il quadro proposto classifica gli incidenti in tre esiti: Innalzamento (richiede coordinamento internazionale), Allerta (supporto alle capacità/condivisione di informazioni) o Scartare. Utilizza un diagramma di flusso sequenziale con otto criteri a cancello:

1. Causalità AI: L'AI è stata un fattore causale?
2. Ambito: Esclusioni basate sul dominio (ad esempio, militare).
3. Innalzamento Immediato: Trigger pre-danno (ad esempio, assistenza CBRN, perdita di controllo da parte dello sviluppatore) indipendentemente dal danno confermato.
4. Rilevamento di Modelli: Aggregazione di incidenti che condividono una causa radice (tecnica, di capacità o contestuale).
5. Categoria e Gravità del Danno: Valutazione rispetto a tassonomie riconosciute (ad esempio, MIT) e livelli di gravità (Livello 4+).
6. Propagazione Transfrontaliera: Necessità di coordinamento internazionale.
7. Danno Transfrontaliero Irreversibile: Danno permanente con effetti a valle.
8. Quasi Incidente: Incidenti evitati che rivelano modalità di guasto che influenzano altri sistemi.

Risultati Chiave
Lo stress-test ha rivelato che il quadro funziona in modo affidabile per incidenti a insorgenza discreta e individualmente gravi, dove il ruolo causale dell'AI è chiaro. Tuttavia, tre categorie di incidenti si sono rivelate strutturalmente problematiche, portando a una sottorilevazione sistematica nei quadri normativi attuali:

• Danni Cumulativi, Individualmente Sotto-soglia: Incidenti come deepfake non consensuali e danni psicologici derivanti dall'interazione uomo-IA coinvolgono milioni di interazioni a bassa gravità. I quadri attuali che valutano gli incidenti individualmente non riescono a catturare la gravità aggregata, che diventa visibile solo attraverso il rilevamento di modelli e l'aggregazione.
• Quasi Incidenti e Danno Potenziale: Incidenti con alta gravità potenziale ma basso danno realizzato (ad esempio, vulnerabilità di piattaforme agenti) sono spesso mancati a meno che non vengano applicati criteri specifici per quasi incidenti.
• Lacune nella Scala di Gravità: Danni diffusi (disagio psicologico, violazioni della dignità) non si mappano bene sui descrittori quantitativi di gravità esistenti. I quadri attuali mancano di meccanismi per l'aggregazione cross-categoriale, facendo sì che gli incidenti rimangano al di sotto delle soglie di innalzamento di livello nonostante il trattamento normativo come gravi.

Risultati: La Catena di Dipendenza e i Modelli di Progettazione
Gli autori identificano una catena di dipendenza a tre livelli che spiega questi fallimenti:

1. Livello 1 (Infrastruttura Dati): Cosa può essere rilevato.
2. Livello 2 (Fondamenta Definitorie): Come gli incidenti e i danni sono categorizzati e valutati.
3. Livello 3 (Trigger di Innalzamento): Soglie e logica decisionale.

Le lacune nei livelli a monte si propagano a valle. Il documento identifica quattro specifici modelli di progettazione nei quadri attuali (AI Act dell'UE, SB 53) che guidano la sottorilevazione:

1. Trigger che Richiedono Danno Confermato per Rischi Pre-danno: Richiedere esiti di danno effettivi prima della segnalazione impedisce l'innalzamento di livello di eventi ad alto rischio (ad esempio, un modello che fornisce assistenza CBRN) dove lo sviluppatore vede il trigger ma non il danno a valle.
2. Valutazione Solo Individuale che Manca i Danni Cumulativi: La mancanza di disposizioni di aggregazione significa che gli effetti a livello di popolazione (ad esempio, 500.000 utenti che mostrano fattori di rischio) sono invisibili quando valutati come eventi discreti.
3. Soglie Definite Legalmente che Non Sono Praticamente Testabili: Definizioni che si basano su "violazione dei diritti fondamentali" o soglie quantitative specifiche (ad esempio, 50 vittime) sono o non misurabili dagli sviluppatori o mancano di incidenti di gravità moderata ma reale.
4. Architettura ad Eventi Discreti Applicata a Condizioni Permanenti: Applicare una logica basata su eventi a condizioni continue e permanenti (ad esempio, danno psicologico in corso, erosione graduale dell'integrità delle informazioni) rende questi rischi invisibili, poiché non esiste un punto di insorgenza o risoluzione discreto.

Soluzione Proposta
Per affrontare le "condizioni permanenti", gli autori propongono un monitoraggio basato sulla tolleranza, attingendo a precedenti dei servizi finanziari (ad esempio, Basilea II, Banca d'Inghilterra). Ciò comporta:

1. Standardizzare le categorizzazioni del danno tra i fornitori.
2. Operazionalizzare il monitoraggio continuo (passando da istantanee in un punto temporale a flussi continui).
3. Stabilire tolleranze dove gli eventi segnalabili sono definiti da cambiamenti anomali nel tasso, nella gravità o nella distribuzione del danno (ad esempio, picchi di prevalenza sopra la linea di base) piuttosto che dalla mera presenza di danno.

Significato e Affermazioni
Il documento afferma che progettare migliori trigger da soli è insufficiente. Il lavoro definitorio (Livello 2) e l'infrastruttura dati (Livello 1) sono prerequisiti per i criteri operativi di innalzamento di livello. Senza affrontare questi livelli a monte, i quadri rischiano di essere formalmente completi ma operativamente non implementabili, in particolare per i domini di rischio dove la sottorilevazione ha conseguenze gravi.

Il lavoro contribuisce alla capacità di "Operazionalizzazione" della governance tecnica dell'AI fornendo:

• Un quadro a otto criteri basato su precedenti cross-settoriali.
• Dimostrando attraverso lo stress-test che i progetti normativi attuali contengono caratteristiche strutturali che portano a punti ciechi sistematici.
• Proponendo una struttura di dipendenza che spiega perché certi rischi (cumulativi, psicologici, condizioni permanenti) sono attualmente invisibili ai meccanismi di innalzamento di livello.
• Offrendo una proposta costruttiva per il monitoraggio basato sulla tolleranza per affrontare danni in corso a livello di popolazione.

Gli autori notano limitazioni, inclusa la dimensione del campione di dieci incidenti e l'affidamento su giudizi soggettivi nella metodologia walkthrough, suggerendo che il lavoro futuro dovrebbe coinvolgere la validazione multi-stakeholder e il perfezionamento dei trigger specifici per dominio.