Leader di pensiero

Gli incidenti di intelligenza artificiale stanno diventando crisi operative. Dobbiamo trattarli di conseguenza.

mm

Negli ultimi anni, la maggior parte delle organizzazioni ha discusso del rischio di intelligenza artificiale nel linguaggio della governance.

Il modello è accurato? È equo? I dati sono approvati? Stiamo rispettando la normativa emergente? Queste sono domande importanti, ma non sono le uniche domande. La domanda più urgente è cosa succede quando qualcosa va storto?

Cosa succede quando un agente di intelligenza artificiale compie un’azione che non doveva compiere? Cosa succede quando un modello perde dati sensibili? Cosa succede quando una risposta allucinata crea un’esposizione legale, o una decisione automatizzata influenza un cliente, un dipendente, un paziente o un partner in un modo che non può essere facilmente annullato?

E forse più praticamente: dove va l’organizzazione per coordinare la risposta? Questo è il cambiamento in corso. Il rischio di intelligenza artificiale sta diventando una questione di resilienza operativa, non solo di governance.

L’intelligenza artificiale sta passando dall’esperimentazione alla macchina operativa dell’impresa. Sta essere integrata nel supporto clienti, nello sviluppo software, nelle operazioni finanziarie, nei flussi di lavoro sanitari, nell’assunzione, nell’elaborazione delle richieste, nelle catene di approvvigionamento e nell’automazione interna. Man mano che l’intelligenza artificiale diventa più connessa all’attività, i fallimenti dell’intelligenza artificiale diventano incidenti aziendali.

Il OECD AI Incidents Monitor ha tracciato 596 incidenti di intelligenza artificiale solo nel gennaio 2026, con una crescita del 200% rispetto all’anno precedente. Iniziative come l’OECD AI Incidents Monitor e l’AI Incident Database documentano esiti negativi o dannosi che coinvolgono sistemi di intelligenza artificiale in modo che l’industria possa imparare dall’esperienza allo stesso modo in cui l’aviazione e la sicurezza informatica hanno fatto per anni.

Quel confronto è importante. Le industrie mature chiedono come prevenire il fallimento E come rispondere quando il fallimento si verifica comunque.

Gli incidenti di intelligenza artificiale non si comportano come i bug del software tradizionale

Un bug del software tradizionale di solito ha un confine abbastanza chiaro. Qualcosa si rompe, gli ingegneri indagano e il team riproduce il problema, patcha il codice e spedisce una soluzione.

Tuttavia, gli incidenti di intelligenza artificiale sono più complicati. Possono essere probabilistici, intermittenti ed emergere dall’interazione tra un modello, un prompt, un sistema di recupero, un plug-in, un agente, un utente e un processo aziendale a valle. A volte il sistema di intelligenza artificiale funziona esattamente come progettato, ma la progettazione è incompleta per l’ambiente in cui viene utilizzato. Ciò rende la risposta più difficile.

Un’allucinazione in un chatbot per consumatori è un tipo di problema. Un’allucinazione all’interno di un flusso di lavoro legale, finanziario, clinico o di risorse umane è un altro. Un output distorto durante i test è serio. Un processo decisionale automatizzato che funziona su larga scala in produzione è qualcosa di completamente diverso. Un assistente di intelligenza artificiale che redige un’e-mail è una cosa, ma un agente che può cambiare le autorizzazioni, rilasciare rimborsi, aggiornare i record, attivare i flussi di lavoro o eseguire codice è una categoria di rischio molto diversa.

Il repository di rischi di intelligenza artificiale del MIT cattura una vasta gamma di rischi di intelligenza artificiale, tra cui informazioni false o fuorvianti, violazioni della privacy e della sicurezza, discriminazione, abuso e problemi di sicurezza del sistema. La classifica OWASP dei primi 10 per le applicazioni di modelli linguistici di grandi dimensioni evidenzia in modo simile rischi come l’iniezione di prompt, la divulgazione di informazioni sensibili, la gestione della produzione non sicura e l’eccessiva agenzia. Questi sono modi di fallimento pratici, piuttosto che preoccupazioni tecniche astratte.

Se un agente di intelligenza artificiale ha troppa autorità, potrebbe intraprendere azioni che nessun essere umano ha inteso. Se un’iniezione di prompt ha successo, il sistema potrebbe divulgare informazioni o seguire istruzioni ostili. Se i dati sensibili si verificano attraverso un modello o un sistema di recupero, la risposta ha implicazioni legali, normative, dei clienti e di reputazione. È per questo che il linguaggio della governance di intelligenza artificiale può talvolta diventare troppo passivo. La governance ci dice cosa dovrebbe essere vero. La risposta agli incidenti ci dice cosa fare quando la realtà si muove più velocemente della politica.

La risposta sarà cross-funzionale

Una delle più grandi lezioni dalla sicurezza informatica è che gli incidenti raramente rimangono all’interno del team di sicurezza. All’inizio, un evento può sembrare tecnico. Molto presto, coinvolge legale, comunicazioni, leadership aziendale, conformità, team dei clienti, consulenti esterni, assicuratori, specialisti forensi e talvolta il consiglio di amministrazione.

Gli incidenti di intelligenza artificiale seguiranno lo stesso modello.

Immagina un modello che espone informazioni sensibili dei clienti. I team di sicurezza e privacy devono capire cosa è successo. Il team legale deve valutare gli obblighi. Le comunicazioni potrebbero dover preparare i clienti, i regolatori o i media. L’ingegneria potrebbe dover disabilitare o riavviare un sistema. I leader aziendali potrebbero dover bilanciare la continuità con il contenimento.

O immagina un agente di intelligenza artificiale che inizia a intraprendere azioni non intenzionali attraverso i sistemi aziendali. Il team tecnico potrebbe essere in grado di disattivarlo, ma l’organizzazione deve ancora capire cosa ha fatto, chi è stato colpito, quali decisioni sono state prese, se gli obblighi contrattuali sono stati attivati e come lo stesso fallimento sarà prevenuto in futuro. Ciò non può essere risolto solo dal team di intelligenza artificiale.

Le organizzazioni dovrebbero costruire muscoli cross-funzionali prima di averne bisogno. Ciò significa trigger di escalation chiari, ruoli chiari, diritti decisionali chiari, percorsi di comunicazione chiari, documentazione chiara e pratica.

In una crisi, la coordinazione è un’infrastruttura, non solo una competenza morbida.

L’intelligenza artificiale che viene indagata non dovrebbe controllare la risposta

C’è un altro problema che le organizzazioni devono pensare molto più attentamente. Se il sistema di intelligenza artificiale sotto indagine può accedere alle stesse comunicazioni, documenti, flussi di lavoro o automazione utilizzati per coordinare la risposta, l’organizzazione ha un problema.

Nella sicurezza informatica, questo è un principio familiare. Se il ransomware ha compromesso la rete aziendale, non si coordina la risposta sui sistemi che l’attaccante potrebbe essere in grado di leggere, interrompere o manipolare. Si va fuori banda. Si separa l’incidente dalla risposta.

La stessa logica si applica all’intelligenza artificiale.

Un sistema di intelligenza artificiale potrebbe non essere malizioso nel senso umano, ma se può vedere il piano di risposta, riassumere la riunione di risposta, influenzare il flusso di lavoro, raccomandare il prossimo passo o operare all’interno dello stesso ambiente utilizzato per contenerlo, allora l’organizzazione non ha truly isolato la risposta.

Ciò diventa ancora più importante con l’intelligenza artificiale agente. Il framework di intelligenza artificiale sicura di Google evidenzia rischi come l’iniezione di prompt, l’avvelenamento dei dati e le azioni rogue, e li mappa ai controlli in tutta la durata di vita dell’intelligenza artificiale. Questo è il framing giusto. Man mano che i sistemi di intelligenza artificiale diventano più in grado di agire attraverso strumenti, dati e flussi di lavoro, le organizzazioni devono pensare alla sicurezza del modello E alla separazione operativa.

Pensalo come un’indagine su un incendio. Non vorresti che i controlli degli sprinkler fossero collegati allo stesso sistema difettoso che stai cercando di diagnosticare.

Prepararsi, praticare, rispondere, segnalare

Un framework utile per la preparazione agli incidenti di intelligenza artificiale è lo stesso che si è evoluto nella sicurezza informatica: prepararsi, praticare, rispondere, segnalare.

Prepararsi significa definire i tipi di incidenti prima che si verifichino, come pregiudizio, allucinazione, perdita di dati, deriva del modello, iniezione di prompt, agente fuori controllo, utilizzo di strumenti non autorizzato e fallimento del modello di terze parti. Ognuno richiede stakeholder diversi e decisioni diverse.

Un buon playbook non dovrebbe essere un documento di 200 pagine in una cartella. Nessuno apre la pagina 137 durante una crisi. Un buon playbook è basato sui ruoli, accessibile e azionabile. Il team legale sa cosa fare. L’ingegneria sa cosa fare. Le comunicazioni sanno quando coinvolgere. Il consiglio di amministrazione sa quando la gestione scalerà.

Praticare significa eseguire esercizi di simulazione. Non una volta all’anno come una casella di controllo, ma abbastanza spesso da costruire muscoli della memoria. La prima volta che il consiglio di amministrazione discute di un incidente di intelligenza artificiale non dovrebbe essere durante un reale incidente di intelligenza artificiale. La prima volta che il team legale, l’ingegneria, la privacy, la sicurezza e le comunicazioni lavorano insieme per un fallimento di intelligenza artificiale non dovrebbe essere quando i clienti stanno già facendo domande.

Rispondere significa coordinare l’evento live con disciplina. Chi è nella stanza? Quali fatti sono noti? Quali fatti sono ancora incerti? Quali decisioni sono state prese? Chi le ha approvate? Cosa è cambiato tra l’ora 12 e l’ora 48?

Segnalare significa riconoscere che la regolamentazione di intelligenza artificiale sta diventando più concreta. Il Atto sull’intelligenza artificiale dell’UE include obblighi di segnalazione di incidenti gravi per i fornitori di determinati sistemi di intelligenza artificiale ad alto rischio. I dettagli varieranno a seconda della giurisdizione, dell’industria e dell’uso, ma la direzione è chiara. Gli incidenti di intelligenza artificiale richiederanno sempre più un registro difendibile di cosa è successo, cosa era noto, quali azioni sono state intraprese e quando.

L’intelligenza artificiale può aiutare, ma non può sostituire il giudizio

C’è la tentazione di pensare che la risposta agli incidenti di intelligenza artificiale dovrebbe essere completamente automatizzata. Credo che questo sia il framing sbagliato.

L’intelligenza artificiale può aiutare enormemente. Può riassumere i fatti. Può identificare le informazioni mancanti. Può confrontare un incidente con modelli precedenti. Può redigere rapporti post-azione. Può aiutare a mappare gli obblighi normativi. Può ridurre l’onere amministrativo quando le persone sono sotto pressione.

Ma in un incidente grave, gli esseri umani rimangono indispensabili.

Qualcuno deve decidere se i fatti sono sufficienti. Qualcuno deve valutare l’impatto sul cliente. Qualcuno deve decidere se interrompere un sistema. Qualcuno deve determinare se l’organizzazione ha superato la soglia di segnalazione. Qualcuno deve comunicare con responsabilità e empatia.

Il ruolo giusto per l’intelligenza artificiale nella risposta agli incidenti non è sostituire il team di crisi. È dare al team di crisi un contesto migliore, più veloce.

Il framework di gestione del rischio di intelligenza artificiale del NIST è utile perché inquadra la gestione del rischio di intelligenza artificiale intorno a quattro funzioni: governare, mappare, misurare e gestire. Per la risposta agli incidenti, aggiungerei un’estensione pratica: provare.

Un piano che non è mai stato testato non è realmente un piano. È una teoria.

I consigli di amministrazione hanno bisogno di un playbook, troppo

Il rischio di intelligenza artificiale sta diventando un argomento di livello aziendale, ma il coinvolgimento del consiglio di amministrazione non può fermarsi alle diapositive di vigilanza. I consigli di amministrazione devono capire il loro ruolo prima che si verifichi una crisi.

Quando il consiglio di amministrazione sarà informato? Quali decisioni richiedono l’input del consiglio di amministrazione? Quali informazioni fornirà la gestione? Come verranno valutate la materialità, l’impatto sul cliente, l’esposizione legale, gli obblighi normativi e la disruzione operativa?

Molte organizzazioni hanno playbook di sicurezza, playbook di privacy, playbook di comunicazioni e playbook legali. Molto meno hanno un playbook di consiglio di amministrazione per gli incidenti di intelligenza artificiale. Quella lacuna diventerà più visibile man mano che i sistemi di intelligenza artificiale si muoveranno in flussi di lavoro regolamentati, generazione di entrate e orientati al cliente. Il ruolo del consiglio di amministrazione è aiutare l’organizzazione a prendere decisioni migliori sotto pressione, non diventare più tecnico.

L’intelligenza artificiale affidabile richiede resilienza operativa

C’è molta conversazione sull’intelligenza artificiale affidabile. Questa è l’aspirazione giusta, ma la fiducia non è creata solo da principi. La fiducia è creata quando le organizzazioni possono mostrare come si preparano, come rilevano i problemi, come rispondono, come comunicano, come documentano le decisioni e come migliorano.

La sicurezza informatica ha attraversato la stessa evoluzione. Le organizzazioni hanno speso anni investendo nella prevenzione e dovrebbero continuare a farlo. Ma le organizzazioni mature hanno eventualmente imparato che la prevenzione non è sufficiente. Avete anche bisogno di resilienza. L’intelligenza artificiale sta entrando nella stessa fase.

Dovremmo assolutamente costruire modelli più sicuri, controlli più forti, valutazioni migliori, miglior red teaming e miglior governance, ma dovremmo anche accettare che gli incidenti si verificheranno. I modelli falliranno, gli agenti si comporteranno in modo inatteso, i dati si verificheranno, gli esseri umani abuseranno dei sistemi, i fornitori commetteranno errori e le normative evolveranno.

La domanda è se l’organizzazione può rispondere con velocità, coordinazione, giudizio e responsabilità quando si verifica un incidente. È così che l’intelligenza artificiale passa dall’esperimentazione all’infrastruttura affidabile e è così che la resilienza diventa cultura.

Arvind Parthasarathi, Amministratore Delegato e fondatore di CYGNVS, si è dedicato alla missione di aiutare le organizzazioni a ridurre i rischi legati alla cybersicurezza e all'intelligenza artificiale. Recentemente, è stato il Fondatore/Direttore e ha lavorato pro bono per Cyber Crossroads, una collaborazione no-profit di ricercatori di nove università a livello globale che definisce uno standard di cura per la cybersicurezza.

In precedenza, Arvind era il Fondatore/Amministratore Delegato di Cyence (ora fusa con NYSE: GWRE), che ha creato una piattaforma di analisi dei rischi informatici per quantificare l'impatto finanziario dei rischi per la cybersicurezza.