Chi risponde quando una strategia redatta dall'IA si rivela sbagliata?

Quando una raccomandazione strategica redatta dall'IA si rivela sbagliata, la responsabilità ricade sulle figure umane nominate nella catena decisionale – non sullo strumento. La domanda è: quali figure? La risposta onesta è: tre ruoli che spesso si sovrappongono o sono ricoperti dalla stessa persona, ed è proprio lì che si concentra il rischio.

Questo articolo tratta i tre ruoli e le ragioni per cui confonderli crea rischi; il documento di governance scritto che assegna le responsabilità prima che una decisione venga presa; gli obblighi del regolamento IA europeo in materia di supervisione umana; e il registro di approvazione a cinque campi minimi che rende una traccia decisionale ricostruibile quando occorre esaminarla in un secondo momento.

• I tre ruoli di responsabilità: redattore del brief o titolare del prompt, revisore o autorità di approvazione, decisore.
• Il documento di governance scritto: cosa deve contenere e perché ISO/IEC 42001 considera la tracciabilità un requisito di progettazione.
• Articolo 14 del regolamento IA europeo: gli obblighi di supervisione umana per i sistemi IA ad alto rischio.
• Disposizione 29 del UK Corporate Governance Code: dichiarazioni del consiglio sui controlli interni rilevanti per gli esercizi finanziari che iniziano a partire dal 1° gennaio 2026.

Una raccomandazione strategica redatta con l'assistenza dell'IA non ha un unico autore umano. Una persona formula la domanda, un'altra fornisce la data room, una terza definisce il prompt, una quarta rivede l'output e una quinta porta la decisione al consiglio. Quando la raccomandazione si rivela poi sbagliata, ognuno può indicare un'altra persona. Questo è il classico problema delle «troppe mani», reso più acuto dall'IA, perché la fase di redazione – che in passato lasciava una traccia visibile di documenti di lavoro – ora avviene all'interno di uno strumento che di default non lascia traccia alcuna.

La prospettiva forense è netta. I team di forensic and integrity services di EY osservano che in molte implementazioni di IA la documentazione è limitata e i percorsi decisionali non sono progettati per essere ricostruiti a posteriori, rendendo difficile spiegare, verificare o indagare gli esiti guidati dall'IA quando vengono messi in discussione.^[1]

L'AI Index 2026 di Stanford HAI riporta che l'AI Incident Database ha registrato 362 incidenti IA documentati nel 2025, rispetto ai 233 del 2024.^[2] La quota di aziende prive di politiche per un'IA responsabile è scesa dal 24% all'11%. Il divario che persiste è tra politica e prassi.

Cosa va perduto quando la traccia non viene messa per iscritto

• La domanda: nessuno riesce a dimostrare quale versione del brief o del prompt ha prodotto l'analisi, né chi ha approvato quella formulazione.
• Gli input: i documenti e i dati su cui l'IA si è basata sono dispersi tra upload, chat e cartelle personali.
• La revisione: ciò che il revisore ha contestato, corretto o accettato è spesso invisibile.
• La decisione: il momento della scelta, e la persona che l'ha compiuta, sono sepolti in una riunione o in un thread di posta.
• Lo stato dello strumento: la versione della piattaforma, il modello e le impostazioni utilizzati non vengono acquisiti.

Nessuno di questi problemi si risolve chiedendo alle persone di essere più attente. Si risolve con un documento scritto che assegna ciascun elemento a una figura umana nominativa prima che la decisione venga presa.

La responsabilità per una raccomandazione strategica assistita dall'IA è condivisa tra tre ruoli distinti. Confonderli – per esempio, facendo sì che la stessa persona rediga il brief, riveda l'output e prenda la decisione – concentra il rischio e rende strutturalmente impossibile una contestazione indipendente.

• Il redattore del brief o titolare del prompt è responsabile della domanda posta e degli input forniti. La responsabilità include il garantire che la formulazione sia completa, priva di distorsioni e rappresentativa della decisione che l'organizzazione deve effettivamente prendere.
• Il revisore o autorità di approvazione è responsabile della contestazione e della validazione dell'analisi. La responsabilità include l'interrogazione dell'output, la verifica delle fonti, l'identificazione delle lacune e l'escalation quando l'analisi non può essere suffragata.
• Il decisore è responsabile della scelta e delle sue conseguenze. La responsabilità include la ponderazione della raccomandazione rispetto al contesto che l'analisi potrebbe non aver catturato, e l'assunzione di responsabilità per il risultato.

Separare i ruoli non richiede nuove risorse umane. Richiede che il documento di governance indichi chi ricopre ciascun ruolo per ogni decisione significativa. Questo rispecchia il modello di responsabilità condivisa utilizzato nei framework di governance dell'IA: sviluppatore, organizzazione che la adotta, utente. Ogni livello porta responsabilità per ciò che contribuisce; nessuno può liberarsi della propria puntando a un altro.

Le criticità emergono quando una persona ricopre due o tre di questi ruoli. La sovrapposizione più comune è quella del redattore del brief che svolge anche la revisione: non c'è contestazione indipendente e nessuno con una prospettiva diversa valuta se la domanda è stata posta in un modo che poteva produrre solo una risposta.

Un documento di governance IA difendibile per le decisioni strategiche si compone di due parti: una policy permanente che descrive i tre ruoli e il percorso di escalation, e un registro di approvazione per singola decisione che documenta, per ogni decisione significativa, chi ha ricoperto ciascun ruolo e cosa ha fatto ciascuno.

ISO/IEC 42001 richiede ruoli e responsabilità definiti per i sistemi IA, documentazione mantenuta delle decisioni nel ciclo di vita dell'IA e tracciabilità delle decisioni.^[3] Il minimo che la policy permanente deve coprire:

1. Individui nominativi per livello decisionale – persone specifiche, non qualifiche professionali, così che la responsabilità sia personale e non possa essere deviata verso un ruolo che nel frattempo ha cambiato titolare.
2. Un percorso di escalation – cosa succede quando il revisore non è disponibile, o quando il redattore del brief e il revisore coincidono.
3. La versione dell'analisi allegata – la data, la piattaforma e la versione utilizzata, e il brief o il prompt così come è stato inviato.
4. La data e la modalità di approvazione – riunione verbalizzata, firma digitale o approvazione scritta.

Perché l'allegazione della versione è importante

L'allegazione della versione è il campo che i team tendono a saltare e che le indagini richiedono più spesso. Lo stesso brief eseguito su una versione diversa della piattaforma, del modello o della configurazione può produrre una raccomandazione materialmente diversa. Senza la versione registrata, nessuno può ricostruire su cosa si è basata effettivamente la decisione. Il requisito di tracciabilità di ISO/IEC 42001 copre esattamente questo aspetto.

Come si presenta il percorso di escalation nella pratica

Il percorso di escalation risponde in anticipo a tre domande: (1) Se il revisore designato non può completare la revisione entro la scadenza, chi è il sostituto? (2) Se l'analisi supporta un'opzione che il redattore del brief favoriva chiaramente, la revisione deve essere effettuata da qualcuno che non ha contribuito alla stesura del brief. (3) Se il livello decisionale sale – da raccomandazione del team a documento per il consiglio – l'approvazione deve salire di conseguenza.

La distinzione più utile nella governance dell'IA è tra IA assistita – dove un essere umano decide sulla base dell'analisi – e IA decisionale – dove l'output del sistema viene messo in atto senza una revisione umana significativa. Nel secondo caso la responsabilità si dissolve nello strumento, che secondo il diritto vigente non ha personalità giuridica e non può essere ritenuto responsabile.

Gli obblighi di supervisione umana del regolamento IA europeo si trovano nell'articolo 14.^[4] Per i sistemi IA ad alto rischio ai sensi dell'allegato III, l'articolo 14 richiede che le persone fisiche che sovrintendono al sistema:

• Comprendano adeguatamente le capacità e i limiti del sistema.
• Rimangano consapevoli della tendenza all'eccessivo affidamento sull'output del sistema (automation bias).
• Interpretino correttamente l'output del sistema.
• Siano in grado di decidere, in qualsiasi situazione specifica, di non utilizzare il sistema o di ignorarne o annullarne l'output.

Per i sistemi ad alto rischio ai sensi dell'allegato III, questi obblighi si applicano a partire dal 2 dicembre 2027. Le aziende che costruiscono strutture di governance ora – mentre gli obblighi sono ancora attesi e non ancora applicati – hanno il vantaggio di impostare correttamente la documentazione prima che aumenti il livello di scrutinio.

La classificazione IA assistita versus IA decisionale appartiene al registro di approvazione. Obbliga l'organizzazione ad affrontare il confine nel momento della decisione, quando è ancora possibile correggerlo, anziché in un'indagine successiva, quando la distinzione è importante ma le prove sono scomparse.

Il UK Corporate Governance Code 2024 si applica alle società quotate nel segmento premium per gli esercizi finanziari che iniziano a partire dal 1° gennaio 2025, su base «comply or explain».^[5]

La disposizione 29, che si applica a partire dagli esercizi finanziari che iniziano il 1° gennaio 2026, richiede ai consigli di rilasciare una dichiarazione sull'efficacia dei propri controlli interni rilevanti. Un processo strategico guidato dall'IA – in cui le raccomandazioni presentate al consiglio sono prodotte con assistenza IA – è esattamente il tipo di controllo interno rilevante su cui il consiglio deve essere in grado di dichiarare.

Cosa implica la dichiarazione in termini di prove

• Un processo documentato: la policy di responsabilità esiste, è aggiornata e indica i titolari.
• Registri per singola decisione: esistono registri di approvazione per le analisi significative assistite dall'IA, con la versione dell'analisi allegata.
• Prove di supervisione: il registro mostra una contestazione genuina, compresi i casi in cui il revisore ha ignorato il sistema o attivato l'escalation.
• Visibilità del consiglio: il consiglio o i suoi comitati sono in grado di descrivere come monitora il framework.

Il meccanismo comply-or-explain offre una valvola di sicurezza: una società che non ha ancora costruito la traccia può spiegare cosa fa in alternativa e perché. Ma la spiegazione deve essere sostanziale. Spiegazioni che si riducono a «ci fidiamo del team» difficilmente soddisferanno i regolatori o gli azionisti se una raccomandazione IA sbagliata diventa un caso di governance.

Un registro di approvazione difendibile richiede cinque campi. I primi quattro garantiscono che la traccia sia ricostruibile; il quinto è la classificazione che rende esplicita la responsabilità nel momento in cui conta.

Il quinto campo è quello che i team trovano più scomodo, perché impone una risposta pubblica a una domanda che la maggior parte preferisce lasciare ambigua. Ma è il campo che, più di ogni altro, crea la responsabilità che la struttura di governance è chiamata a garantire.

Questo esempio è illustrativo. Un team di strategia aziendale prepara una raccomandazione sull'ingresso in un mercato del Sud-est asiatico utilizzando una piattaforma di strategia nativa per l'IA.

1. Brief e input: l'analista invia un brief e carica studi di mercato e dati finanziari interni. Il registro di approvazione riporta il testo del brief, l'elenco dei documenti e la data di invio.
2. Versione dell'analisi: la piattaforma restituisce una raccomandazione con fonti citate. Il registro riporta la versione dell'analisi – nome della piattaforma, versione del modello e data di generazione.
3. Revisione: la direttrice dello sviluppo aziendale del gruppo agisce da revisore. Contesta le ipotesi sulla dimensione del mercato, verifica le fonti citate e chiede una nuova elaborazione con un insieme più ampio di opzioni. Approva con firma digitale, con data registrata.
4. Classificazione della decisione: il chief strategy officer classifica la decisione come IA assistita. La classificazione viene registrata prima che la raccomandazione salga di livello.
5. Documento per il consiglio: la raccomandazione viene presentata al consiglio con una nota sulla provenienza. Il registro di approvazione è archiviato con il documento.

Diciotto mesi dopo, l'ingresso nel mercato risulta inferiore alle aspettative. La traccia mostra: chi ha deciso, su quali prove e con quale supervisione. Non che la raccomandazione fosse corretta – non lo era – ma che la responsabilità per essa non è mai stata in dubbio, e l'organizzazione può esaminare quanto accaduto senza controversie su chi fosse responsabile di cosa.

Decisity è una piattaforma di consulenza strategica nativa per l'IA che allega citazioni delle fonti a ogni affermazione e mantiene l'analisi tracciabile fino ai suoi input, rendendo l'allegazione della versione e la mappa affermazione-fonte parte del flusso di lavoro standard anziché un ulteriore onere documentale.

Letture correlate:

• AI Governance Framework for Boards
• AI Risk Management for Boards: A Framework for Directors
• Divulgazione della versione del modello IA: cosa deve sapere il consiglio
• Perché i deck strategici IA ricevono revisioni superficiali: la soluzione di governance

• EY Forensic & Integrity Services: The governance and accountability gap in AI adoption
• Stanford HAI AI Index 2026: Responsible AI
• ISO/IEC 42001: AI Management Systems Standard explained
• Regolamento IA europeo: articolo 14, Misure di supervisione umana
• Financial Reporting Council: UK Corporate Governance Code 2024