La governance dell’intelligenza artificiale non è un problema teorico.
È già oggi una questione di responsabilità concreta, audit, verifiche regolatorie e contenziosi.
Ogni giorno emergono casi reali – decisioni errate, processi non verificabili, supervisione dichiarata ma non dimostrabile – che evidenziano un problema strutturale:
le organizzazioni spesso non riescono a dimostrare come e perché una decisione è stata presa.
In questa sezione analizziamo casi reali:
- sentenze e decisioni giuridiche
- incidenti operativi e errori aziendali
- scenari di rischio legati all’uso dell’AI
Ogni caso viene letto attraverso una lente specifica:
non cosa è successo, ma cosa sarebbe stato necessario dimostrare.
Perché oggi, nella governance AI, la differenza non sta nei processi dichiarati.
Sta nella capacità di produrre evidenza verificabile.
Esplora l’infrastruttura del protocollo:
→ Il Protocollo </AI>
→ Dalla decisione alla struttura difendibile: quando la supervisione diventa evidenza
→ Leggi la specifica tecnica pubblica
→ Verifica un codice CWC nel registro pubblico
→ EVIDE – Registro probatorio per contenuti e decisioni digitali
→ Policy del registro CWC
→ Richiedi un codice ufficiale di verifica CWC
→ Framework documentale per la governance AI
→ Guida all’implementazione: supervisione AI verificabile
→ Bias della supervisione: perché il controllo umano può fallire nei sistemi AI
→ Decision Attestation Layer: il livello probatorio mancante nella governance AI
→ AI Evidence Officer: come dimostrare la supervisione umana nei sistemi di intelligenza artificiale
→ Il livello probatorio nella governance AI
→ FAQ sul protocollo </AI>: domande e risposte sul framework
Letture correlate:
→ AI Data Poisoning: l’attacco che nessun antivirus può fermare
→ Human in the loop: perché dire che c’è supervisione umana non è sufficiente
→ Casi reali di fallimento nella governance AI – e cosa avrebbe dovuto essere dimostrato
Lavora con noi:
Casi reali di governance
Indice :
- Sinistro negato dall’algoritmo — quando la supervisione dichiarata non è dimostrabile
- Moffatt v. Air Canada – quando una decisione AI non è anchor-ready
- L’automazione non è immunità – responsabilità dei sistemi AI nelle decisioni pubbliche
- Decisioni automatizzate e diritto alla spiegazione – quando la decisione non è difendibile
- Licenziamento per mancata verifica di una email fraudolenta – lo standard della “diligenza”
2023 – 2025
U.S. District Court, E.D. California – Cigna PxDx | U.S. District Court, D. Minnesota – UnitedHealth nH Predict
Sinistro negato dall’algoritmo – quando la supervisione dichiarata non è dimostrabile
Cigna ha negato 300.000 richieste in due mesi con 1,2 secondi di “revisione” per pratica. UnitedHealth ha usato un modello con il 90% di tasso di errore per negare cure a pazienti anziani. In entrambi i casi il problema non era l’AI. Era l’assenza di qualsiasi struttura probatoria della supervisione umana.
Due class action distinte, avviate nel 2023 e già proceduralmente avanzate nel 2025, hanno messo al centro del dibattito giuridico la stessa domanda: cosa costituisce effettivamente supervisione umana in un processo decisionale assistito dall’AI? Nel caso Cigna, l’algoritmo PxDx elaborava migliaia di negazioni al giorno mentre i medici interni della compagnia trascorrevano in media 1,2 secondi per pratica, senza leggere i fascicoli clinici. Nel caso UnitedHealth, il modello nH Predict era notoriamente soggetto a un tasso di errore del 90%, eppure veniva utilizzato per negare cure a pazienti anziani in regime Medicare Advantage, spesso sovrastando le valutazioni dei medici curanti.
Il fatto
Nel luglio 2023, un gruppo di pazienti ha citato in giudizio Cigna Corporation presso il Tribunale Federale del Distretto Est della California, allegando che la compagnia utilizzasse l’algoritmo PxDx per negare automaticamente migliaia di richieste senza revisione medica individuale. Una successiva inchiesta di ProPublica ha documentato che i medici di Cigna respingevano pratiche senza aprire i fascicoli clinici, con una media di 1,2 secondi per pratica. Il 31 marzo 2025 il Tribunale ha consentito alla class action di procedere.
Nel novembre 2023, i familiari di due pazienti deceduti hanno avviato una class action contro UnitedHealth presso il Tribunale Federale del Minnesota, contestando l’utilizzo del modello nH Predict per negare cure riabilitative a pazienti anziani. Le accuse indicavano che il sistema aveva un tasso di errore del 90% e veniva usato per sovrastare le valutazioni dei medici curanti. Il tribunale ha consentito alla class action di procedere nel febbraio 2025 per violazione contrattuale e violazione del principio di buona fede.
Il principio giuridico emergente
Entrambi i procedimenti convergono su un principio che le corti stanno progressivamente consolidando: dichiarare la presenza di supervisione umana non equivale a dimostrarne la struttura. Non basta che un medico fosse formalmente assegnato alla revisione. Deve essere dimostrabile in che modo ha operato la sua revisione, contro quale criterio, con quale autorità, e con quale risultato documentato. In assenza di questa struttura, la “supervisione” è solo un’etichetta su un processo che, di fatto, era automatico.
California SB 1120, entrata in vigore il 1° gennaio 2025, ha già cristallizzato questo principio in norma: qualsiasi negazione basata sulla necessità medica deve essere revisionata da un medico abilitato, con documentazione individuale per pratica. L’algoritmo può assistere. Non può decidere da solo. E la supervisione deve essere dimostrabile, non dichiarata.
La domanda governance
Questi casi riguardano le assicurazioni sanitarie negli Stati Uniti. Ma il principio che stanno generando è universale e si applica a qualsiasi compagnia assicurativa che utilizza AI nel processo di liquidazione, underwriting o scoring del rischio:
Se un sinistro negato o un premio aumentato dall’AI arriva in sede di contenzioso, cosa puoi effettivamente dimostrare sulla supervisione umana che ha governato quella decisione?
Applicando la struttura EVIDE ai casi Cigna e UnitedHealth:
| Condizione | Stato nei casi |
|---|---|
| Autorità attribuibile (reviewer identificato) | ✘ Formale ma non reale — 1,2 secondi per pratica non costituisce revisione |
| Criterio documentato (taxonomy_reference) | ✘ Assente — nessuna tassonomia clinica verificabile ancorata al momento della decisione |
| Soglia verificabile (threshold_reference) | ✘ Assente — il modello operava senza soglie dichiarate e verificabili esternamente |
| Stato della soglia (threshold_status) | ✘ Non registrato — nessun record di met / not_met / not_defined per singola pratica |
| Conseguenza reale sul cliente | ✔ Presente — negazione cure, danni economici, in alcuni casi decesso |
| Difendibilità esterna | ✘ Non garantita — le compagnie non hanno potuto produrre struttura probatoria |
Il sistema non ha fallito perché l’AI ha sbagliato. Ha fallito perché ha prodotto conseguenze reali su pazienti a partire da decisioni che non soddisfacevano nessuna delle condizioni necessarie per essere esternalizzate come accountable.
Il tasso di ribaltamento in appello — superiore al 90% nel caso UnitedHealth — è la prova che il problema non era nel merito clinico delle pratiche. Era nell’assenza di struttura. Le cure erano spesso appropriate. Mancava la capacità di dimostrarlo.
Cosa avrebbe dovuto essere dimostrabile
Per ogni pratica negata o modificata con supporto AI, una struttura che documentasse: l’identità e le credenziali del reviewer che ha operato la supervisione, la tassonomia clinica attiva al momento della decisione (taxonomy_reference), la soglia di ammissibilità applicata (threshold_reference), lo stato della verifica rispetto a quella soglia (threshold_status: met | not_met | not_defined), il rationale strutturato dell’eventuale override o conferma, e il timestamp della revisione umana — non dell’output algoritmico.
Non una dichiarazione generica di “supervisione medica”. Una struttura probatoria capace di rispondere alla domanda: in questo specifico caso, la supervisione umana era reale, strutturata e verificabile esternamente — o era solo un’etichetta su un processo automatico?
Questo è esattamente il ruolo del Deposito Probatorio Esterno EVIDE e dello schema EVIDE JSON 1.7: trasformare ogni decisione assicurativa assistita dall’AI in un record con taxonomy_reference, threshold_reference e threshold_status ancorati esternamente al momento della revisione umana. Non dopo. Non su richiesta del tribunale. Nel momento in cui la decisione produce effetti sul cliente.
14 febbraio 2024
British Columbia Civil Resolution Tribunal – Moffatt v. Air Canada, 2024 BCCRT 149
Moffatt v. Air Canada – quando una decisione AI non soddisfa le condizioni di accountability (anchor-ready)
Un chatbot ha prodotto una decisione con conseguenze reali, senza autorità attribuibile, senza motivazione strutturata, senza supervisione documentata. Non era un problema tecnico. Era un problema di maturità decisionale.
Il Tribunal ha dichiarato Air Canada responsabile per le informazioni errate fornite dal proprio chatbot AI a un cliente che stava acquistando un biglietto aereo in occasione del lutto familiare. Il chatbot aveva indicato che era possibile richiedere retroattivamente la tariffa agevolata per lutto, informazione contraddetta dalla policy ufficiale della compagnia. Air Canada ha tentato di sostenere che il chatbot era un’entità separata, non imputabile alla compagnia. Il Tribunal ha respinto questa tesi in modo netto.
Il fatto
Nel novembre 2022, Jake Moffatt visita il sito di Air Canada per acquistare un biglietto in seguito alla morte della nonna. Interagisce con il chatbot della compagnia, che gli comunica la possibilità di richiedere retroattivamente la tariffa ridotta per lutto entro 90 giorni dal volo. Moffatt completa l’acquisto a tariffa intera e presenta successivamente la domanda di rimborso. Air Canada nega il rimborso, sostenendo che la policy richiedeva la richiesta prima del volo. Il Tribunal, nel febbraio 2024, condanna Air Canada al pagamento dei danni.
Il principio giuridico
Il Tribunal ha stabilito che Air Canada è responsabile di tutte le informazioni presenti sul proprio sito, indipendentemente dal fatto che provengano da una pagina statica o da un chatbot. La tesi della compagnia – che il chatbot fosse un’entità autonoma e separata – è stata definita “remarkable” e respinta integralmente. Lo standard applicato: l’organizzazione deve adottare le misure ragionevoli per garantire che le informazioni fornite dal proprio sistema AI siano accurate e non fuorvianti.
La domanda governance
Questo caso introduce un concetto che va oltre la semplice responsabilità del chatbot. Pone una domanda strutturale:
La decisione prodotta dal tuo sistema AI soddisfa le condizioni minime per essere esternalizzata come accountable?
Applicando il Minimum Anchoring Contract al caso Air Canada:
| Condizione | Stato nel caso |
|---|---|
| Autorità attribuibile | ✘ Assente – il chatbot non ha autorità propria né delegata verificabile |
| Motivazione strutturata | ✘ Assente – nessuna logica documentata alla base della risposta |
| Supervisione umana documentata | ✘ Assente – nessun processo di revisione attivo sull’output |
| Conseguenza reale | ✔ Presente – danno economico diretto al cliente |
| Imputabilità esterna | ✘ Non garantita – Air Canada ha tentato di disconoscere la decisione |
Il sistema ha prodotto una conseguenza reale su un cliente, a partire da una decisione che non soddisfaceva nessuna delle condizioni necessarie per essere esternalizzata come accountable. Non era un problema tecnico. Era un problema di maturità decisionale.
Il sistema non ha fallito perché il chatbot ha sbagliato. Ha fallito perché una decisione non anchor-ready è stata autorizzata a produrre conseguenze reali.
Cosa avrebbe dovuto essere dimostrabile
Un sistema che garantisse che ogni output del chatbot con potenziale impatto contrattuale fosse: generato entro limiti di autorità definiti e documentati, verificabile rispetto alla policy attiva al momento della risposta, sottoposto a supervisione umana per le categorie di decisione con conseguenze economiche, e registrato in modo da consentire la ricostruzione dell’interazione in sede di contestazione.
Non una disclaimer generica. Una struttura probatoria capace di rispondere alla domanda: questa decisione era anchor-ready nel momento in cui ha prodotto effetti sul cliente?
Questo è esattamente il ruolo del Human Oversight Event e del Deposito Probatorio Esterno EVIDE: trasformare la supervisione da intenzione dichiarata a evidenza strutturata, verificabile e ancorata nel tempo.
2026
Corte d’Appello della Nuova Zelanda – Yorston v Attorney General [2026] NZCA 15
L’automazione non è immunità – responsabilità dei sistemi AI nelle decisioni pubbliche
Etichettare un processo come “automatico” non lo sottrae al controllo giudiziario. La responsabilità segue la progettazione del sistema.
La Corte ha stabilito che le decisioni prodotte da sistemi automatizzati governativi sono soggette a controllo giudiziario. L’agenzia pubblica che adotta e implementa un sistema automatizzato rimane pienamente responsabile degli output, anche quando nessun essere umano è intervenuto direttamente nella singola decisione.
Il fatto
Il caso riguardava errori in un report automatizzato sulla storia penale di un individuo, generato da un sistema di gestione dei casi del Ministero della Giustizia. Il ricorrente ha contestato che gli errori fossero correggibili tramite controllo giudiziario, in quanto prodotti da un sistema automatizzato. La Corte d’Appello ha respinto questa tesi.
Il principio giuridico
La Corte ha chiarito che il sistema automatizzato opera nell’ambito dei poteri esecutivi del governo e che, pertanto, i suoi output sono soggetti a controllo giudiziario. Il punto centrale: l’automazione non equivale all’immunità. La responsabilità per gli errori derivanti dall’architettura del software, dalla gestione dei dati o dalla logica del sistema rimane in capo all’agenzia pubblica che ha adottato e implementato il sistema.
La Corte ha inoltre indicato che le future contestazioni si concentreranno probabilmente meno sugli output individuali e più su come i sistemi automatizzati sono progettati, validati, monitorati e corretti.
La domanda governance
Questo caso non riguarda solo le agenzie governative. Pone una domanda strutturale per qualsiasi organizzazione che utilizza sistemi AI in processi decisionali che producono effetti su terzi:
Se il tuo sistema AI produce un output che incide su diritti o interessi di qualcuno, sei in grado di dimostrare come quel sistema è stato progettato, validato e supervisionato?
La Corte ha indicato tre aree di governance che ogni organizzazione dovrebbe presidiare:
- mappatura dei sistemi automatizzati rispetto alle funzioni e responsabilità istituzionali
- meccanismi di rilevamento degli errori, correzione degli output e spiegabilità delle modifiche
- mantenimento dell’auditabilità: logica del sistema, fonti dei dati, aggiornamenti e limitazioni note
Senza questa struttura, l’organizzazione non è in grado di rispondere a una contestazione: non perché abbia sbagliato, ma perché non può dimostrare di aver operato correttamente.
Questo caso mostra un punto strutturale: quando la governance non è supportata da evidenza verificabile, la responsabilità diventa attribuita per presunzione, non dimostrata.
Cosa avrebbe dovuto essere dimostrabileUn registro strutturato che documentasse: come il sistema è stato progettato e con quali criteri, quali dati alimentano le decisioni, chi ha validato la logica del sistema, quali meccanismi di correzione sono attivi, e chi è il responsabile designato della supervisione operativa.
Non una descrizione tecnica generica, ma una struttura probatoria capace di rispondere alla domanda: in che modo la supervisione umana è stata esercitata su questo sistema, e quando?
In assenza di questa struttura, la decisione resta formalmente valida, ma diventa sostanzialmente non difendibile.
Questo è esattamente il ruolo dell’AI Evidence Officer e del framework documentale: trasformare la governance AI da intenzione dichiarata a struttura probatoria difendibile, verificabile esternamente e ancorata a un registro pubblico indipendente.
27 febbraio 2025
Corte di Giustizia dell’Unione Europea – C-203/22 (Dun & Bradstreet Austria)
Decisioni automatizzate e diritto alla spiegazione – quando la decisione non è difendibile
Una decisione che non può essere spiegata in modo intelligibile non può essere difesa.
La Corte ha stabilito che, nelle decisioni automatizzate basate su profilazione, l’interessato ha diritto a ricevere informazioni significative, comprensibili e accessibili sulla logica utilizzata.
Il problema di governance: se una decisione automatizzata non può essere spiegata in modo verificabile e comprensibile, non può essere difesa. Il Protocollo </AI> introduce il livello mancante: trasformare la logica decisionale in evidenza strutturata, tracciabile e attribuibile.
Le allucinazioni dell’AI non sono, di per sé, un errore. Ma presentare output come affidabili senza una traccia verificabile di supervisione umana crea un gap strutturale di responsabilità.
Il fatto
Un sistema automatizzato è stato utilizzato per valutare l’affidabilità creditizia di un individuo. La decisione risultante ha avuto effetti significativi sulla persona, senza che fosse possibile comprendere chiaramente la logica utilizzata dal sistema.
Il principio giuridico
La Corte ha chiarito che il diritto alla spiegazione previsto dal GDPR richiede che l’interessato possa comprendere le procedure e i criteri effettivamente applicati nella decisione automatizzata. Non è necessario rivelare algoritmi complessi o segreti industriali, ma è obbligatorio fornire una spiegazione chiara, intelligibile e verificabile della logica decisionale.
La domanda governance
Questo caso non riguarda solo il credito o il GDPR. Pone una domanda strutturale su qualsiasi decisione presa o supportata da sistemi intelligenti:
Se non puoi spiegare una decisione, come puoi dimostrare che è stata presa correttamente?
Nel contesto operativo reale, la spiegazione non basta. Serve poter dimostrare:
- quali dati sono stati utilizzati
- quali regole erano attive
- chi ha validato il processo
- in quale contesto la decisione è stata generata
Senza questa struttura, la decisione resta opaca, anche quando viene formalmente spiegata.
Cosa avrebbe dovuto essere dimostrabile Un sistema che registri non solo l’output, ma le condizioni in cui la decisione è stata resa possibile: i dati di input, i vincoli applicati, le policy attive, il contesto operativo e l’eventuale supervisione umana.
Non una spiegazione generata dopo, ma una struttura probatoria generata prima e durante il processo decisionale.
Questo è esattamente il ruolo del Human Oversight Event e del Decision Attestation Layer: trasformare la decisione da risultato opaco a processo dimostrabile.
12 febbraio 2024
Corte di Cassazione (Sez. Lavoro) – Ordinanza n. 3263/2024
Licenziamento per mancata verifica di una email fraudolenta – lo standard della “diligenza”
La diligenza non dimostrata non offre alcuna tutela.
La Corte ha confermato il licenziamento di una dipendente che ha autorizzato un pagamento a seguito di una email di phishing, senza effettuare le verifiche necessarie. La decisione stabilisce che la diligenza ordinaria richiede verifiche attive, anche in assenza di formazione tecnica specifica.
Il fatto
Una dipendente ha disposto un pagamento a seguito di una mail fraudolenta (BEC – Business Email Compromise), senza effettuare le verifiche necessarie prima di autorizzare il bonifico. Il datore di lavoro ha proceduto al licenziamento disciplinare. La Corte di Cassazione, con ordinanza n. 3263 del 12 febbraio 2026, ha confermato la legittimità del licenziamento.
Il principio giuridico
La Corte ha chiarito che, anche in assenza di formazione specifica, il lavoratore ha l’obbligo di operare con ordinaria diligenza, effettuando verifiche e approfondimenti prima di autorizzare un pagamento. Il passaggio chiave della motivazione: con un minimo di diligenza, la frode sarebbe stata evitabile. La responsabilità non è trasferibile al solo sistema informatico o alla mail fraudolenta – spetta alla persona che ha operato la decisione dimostrare di aver agito con la dovuta cautela.
La domanda governance
Questo caso non riguarda solo il phishing bancario. Pone una domanda strutturale che riguarda qualsiasi decisione operativa supportata da sistemi automatizzati o intelligenti:
Come si dimostra che una decisione è stata presa con la dovuta diligenza?
In un contenzioso, non conta cosa la persona dichiara di aver fatto. Conta cosa è documentato, tracciabile, verificabile. Nel caso specifico, la dipendente non ha potuto dimostrare di aver effettuato verifiche – non perché non le avesse fatte, ma perché non esisteva alcun registro di come la decisione fosse stata assunta.
Il principio si estende direttamente all’uso dell’AI nei processi operativi:
- un contratto approvato su output AI
- una risposta automatizzata a un cliente
- una decisione presa su analisi generate da sistemi intelligenti
- un processo interno basato su raccomandazioni algoritmiche
In ognuno di questi casi, la domanda della Cassazione rimane identica: chi ha deciso, cosa ha valutato, quando, su quali basi?
Un registro strutturato del processo decisionale che documentasse: l’identità di chi ha operato la revisione, le fonti consultate al momento della decisione, le verifiche effettuate, il contesto operativo attivo, la decisione finale e la sua motivazione. Non una dichiarazione successiva – una traccia generata nel momento in cui la decisione è stata presa. Questo è esattamente ciò che il Human Oversight Event produce: non la prova che una persona era presente, ma la prova di come quella persona ha operato la sua supervisione, in condizioni verificabili e documentate.
Questa documentazione costituisce un registro verificabile e con timestamp della sua struttura, dei suoi concetti e della sua implementazione.