Un recente articolo del MIT Technology Review ha sostenuto che la cosiddetta “truth crisis” dell’intelligenza artificiale non è ciò che crediamo: il problema non sarebbe l’inaffidabilità dei modelli generativi, ma le aspettative errate che proiettiamo su di essi.
I modelli di intelligenza artificiale generativa non sono progettati per accertare la verità, ma con algoritmi in grado di generare contenuti su analisi di tipo statisticamente plausibile, ovvero operano per predizione probabilistica, non per validazione dei fatti.
Questo equivoco rischia di avere ricadute concrete su regolatorio, compliance e responsabilità organizzativa. L’AI, se trattato come un soggetto epistemico, capace cioè di generare certezze inconfutabili, ci fa spostare l’attenzione sulla qualità dell’output invece che su competenze e responsabilità nei processi di utilizzo.
La questione decisiva diventa allora la governance dell’uso: chi valida? Con quali competenze? Secondo quali procedure e con quali livelli di accountability. E il punto decisivo è proprio la validazione umana. Non basta un generico “human-in-the-loop”, ma occorre che l’intervento sia esercitato da soggetti dotati di competenze tecniche e specifiche adeguate. Senza conoscenza del contesto normativo, scientifico o operativo, la verifica dell’output dell’AI si riduce a una mera lettura superficiale, incapace di intercettare errori sottili ma sostanziali.
Indice degli argomenti
La governance dell’intelligenza artificiale e l’equivoco della verità
Si parla sempre più spesso di “crisi della verità” dell’intelligenza artificiale. L’espressione suggerisce che i sistemi generativi producano contenuti falsi in modo strutturale e che questo rappresenti una patologia tecnica.
Ma il presupposto è sbagliato.
La cosiddetta “truth crisis” nasce da un’aspettativa impropria: attribuiamo ai modelli generativi una funzione epistemica che non possiedono. Non sono progettati per accertare la verità, bensì per generare sequenze linguistiche statisticamente plausibili.
Il problema non è l’inaffidabilità dell’AI. È l’errata proiezione di categorie umane su sistemi probabilistici.
La governance dell’intelligenza artificiale tra plausibilità e verifica
Le Large Language Models (LLM), ovvero quelle sottocategorie di AI generativa, modelli neurali di grandi dimensioni addestrati su enormi corpora testuali (come ad esempio ChatGPT), operano secondo una logica strettamente probabilistica: stimano cioè la distribuzione di probabilità del token successivo dato un contesto, sulla base di correlazioni statistiche apprese durante l’addestramento.
Non svolgono attività epistemica in senso proprio, che è tipica dell’intelligenza umana. Le LLM non verificano fonti, non accertano fatti, non applicano criteri di verità, non distinguono ontologicamente tra vero e falso.
Ottimizzano una funzione matematica — tipicamente la massimizzazione della verosimiglianza — rispetto a pattern linguistici osservati nei dati di training.
La loro metrica interna è la coerenza statistica con il contesto, non la validità fattuale dell’enunciato.
Da un punto di vista tecnico, un output può essere perfettamente plausibile sul piano linguistico, può essere coerente sintatticamente e semanticamente, può riprodurre strutture argomentative corrette e tuttavia risultare fattualmente inesatto.
Questo non costituisce una “menzogna” in senso proprio, perché manca l’intenzionalità, la consapevolezza, la rappresentazione del vero come criterio normativo.
L’LLM non ha accesso a uno spazio ontologico dei fatti, ma opera in uno spazio statistico di sequenze linguistiche.
Il termine “allucinazione” è efficace sul piano comunicativo, ma tecnicamente improprio. Suggerisce, infatti, una deviazione patologica che può considerare un errore anomalo o un malfunzionamento.
In realtà, ciò che viene definito “allucinazione” è l’esito fisiologico di un sistema che produce testo pur in assenza di un meccanismo interno di fact-checking o grounding esterno, ossia atti verificabili, basi dati strutturate, sensori o mondo fisico, sistemi informativi certificati.
Un modello generativo puro opera in uno spazio simbolico-statistico, ma non ha accesso diretto alla realtà. Sul piano giuridico, parlare di “bugia” rischia di spostare impropriamente l’analisi verso categorie soggettive (dolo, colpa, intenzione) che non sono applicabili a un modello statistico.
Se la metrica dell’LLM è la plausibilità linguistica, allora la gestione del rischio non può concentrarsi sulla pretesa di “verità intrinseca” dell’output, ma deve invece intervenire sul contesto d’uso, sulla qualificazione dell’output (bozza, supporto, decisione finale), su una supervisione umana competente, sui sistemi di verifica a valle, sulla tracciabilità e sul processo di logging.
Qui si innesta la coerenza con l’impostazione del AI Act: il legislatore non tratta l’AI come soggetto capace di mentire, ma come tecnologia da governare.
In sintesi, un LLM non “dice il falso” ma produce la sequenza linguisticamente più probabile. Il problema dunque non è morale, ma è connesso nell’architettura del suo governo: in quale processo quell’output viene inserito? con quali presidi e con quale responsabilità?
Ancora una volta, il centro non è la macchina.
È la struttura che la utilizza.
Quando la governance dell’intelligenza artificiale fallisce per antropomorfizzazione
Nel momento in cui attribuiamo intenzionalità o capacità epistemica a un modello statistico, produciamo due effetti distorsivi:
Sopravvalutiamo la sua affidabilità e sottovalutiamo la nostra responsabilità.
L’errore concettuale diventa così un errore organizzativo: si delega alla macchina ciò che resta, giuridicamente, una decisione umana.
Dalla macchina al processo decisionale
Quando un sistema di AI produce un contenuto errato, la reazione istintiva è interrogarsi sulla causa tecnica dell’errore.
Ma dal punto di vista giuridico e organizzativo, la domanda realmente rilevante è un’altra. Non: “perché ha sbagliato?”, bensì:
• a chi era destinato quell’output?
• in quale processo decisionale era inserito?
• era un supporto istruttorio o una decisione finale?
• chi lo ha validato?
• con quali competenze?
• con quale livello di autonomia?
• con quale tracciabilità delle verifiche effettuate?
Queste domande spostano il fuoco dalla macchina alla catena decisionale.
Un output AI non è mai un fatto isolato. È un elemento che entra in un flusso organizzativo.
Processo amministrativo, decisione creditizia, valutazione clinica, selezione del personale, controllo antifrode, sono tutti esempi di processi decisionali su cui si devono innestare quegli elementi di governance.
Il problema non è, dunque, l’errore in sé – fisiologico in qualunque sistema complesso – ma come quell’errore viene assorbito o amplificato dal processo. Se l’output è:
• chiaramente qualificato come ausilio,
• sottoposto a revisione competente,
• inserito in un sistema di controlli multilivello,
• registrato e motivato,
• l’errore resta governabile.
Se invece l’output:
• è recepito automaticamente,
• non è compreso da chi lo utilizza,
• non è sottoposto a validazione sostanziale,
• non lascia tracce documentali,
• l’errore diventa sistemico.
L’idea di “correttezza assoluta” presuppone che il problema sia epistemico.
In realtà è strutturale.
Il baricentro si sposta dunque sul disegno organizzativo.
Qui emerge la coerenza con l’impianto del General Data Protection Regulation e del AI Act: il legislatore non impone l’assenza di errore, ma pretende che l’errore sia riconoscibile, documentabile e attribuibile.
In assenza di questa architettura, anche un sistema tecnicamente eccellente diventa giuridicamente vulnerabile.
In presenza di essa, anche un sistema imperfetto resta governabile.
Il nodo non è la perfezione dell’algoritmo.
È la solidità del processo che lo incardina.
La governance, non l’infallibilità, è il vero centro di gravità della regolazione contemporanea dell’intelligenza artificiale.
Perché la governance dell’intelligenza artificiale conta più della veridicità
L’evoluzione della regolazione europea sull’intelligenza artificiale è concettualmente chiara: l’oggetto non è la verità dell’algoritmo, ma la governabilità del rischio.
L’AI Act – in continuità con il General Data Protection Regulation GDPR – non insegue l’illusione dell’infallibilità tecnica, ma assume, realisticamente, che ogni sistema complesso produca margini di errore, incertezza, distorsione statistica.
Il problema giuridico non è eliminare l’errore. È renderlo gestibile, tracciabile e imputabile.
La nozione di “verità algoritmica” presupporrebbe un determinismo assoluto, la neutralità dei dati, l’assenza di bias. In altri termini, perfetta traducibilità del mondo reale in modelli matematici. Si tratta di ipotesi, ad oggi, tecnicamente infondate.
Il legislatore europeo adotta invece una logica più sofisticata: ogni sistema AI è una fonte di rischio regolabile attraverso architetture organizzative adeguate.
La sostenibilità giuridica dell’AI non dipende dalla sua perfezione tecnica, ma dalla presenza di presidi procedurali, risk assessment strutturato, procedure di validazione e revisione, meccanismi di escalation e controlli qualificati con una supervisione umana competente e non meramente formale.
Ma soprattutto una separazione tra sviluppo, validazione e utilizzo, corredata da verifiche periodiche indipendenti.
Un chiaro perimetro di accountability con l’identificazione dei ruoli (provider, deployer, responsabili interni) è la chiave, oltre alla tracciabilità con la custodia della documentazione tecnica, delle decisioni e delle revisioni, in modo da consentire verifiche di terzo.
In altri termini, la possibilità di ricostruire ex post il processo decisionale.
Senza auditabilità non esiste responsabilità e senza responsabilità non esiste sostenibilità normativa.
In sintesi, è l’architettura organizzativa la condizione di legittimità. La vera variabile critica non è la sofisticazione del modello, ma la struttura di governance che lo circonda.
Un sistema tecnicamente avanzato ma privo di:
• controlli interni,
• protocolli di validazione,
• flussi documentali,
• formazione del personale,
è giuridicamente fragile.
Al contrario, anche sistemi imperfetti possono essere sostenibili se inseriti in un contesto organizzativo che ne monitora l’impatto, intercetta le anomalie, consente interventi correttivi, garantisce trasparenza verso l’esterno.
In sintesi: l’ordinamento europeo non chiede macchine infallibili, ma organizzazioni responsabili.
La questione non è epistemologica.
È strutturalmente giuridica: chi governa il rischio, come lo documenta e chi ne risponde.
AI Act: il regolatore europeo guarda alla gestione del rischio
Sulla scia della impostazione logica del GDPR, di cui si dirà più avanti, il paradigma del AI Act non introduce una pretesa metafisica di “verità”, ma un’architettura di governance del rischio.
Il regolatore europeo non impone che l’output sia ontologicamente corretto in ogni circostanza — obiettivo tecnicamente irrealistico — ma che il processo di sviluppo, immissione sul mercato e utilizzo sia strutturato secondo criteri verificabili.
È un modello risk-based, nel senso che il fulcro è la proporzionalità al rischio.
I sistemi vengono distinti in rischio inaccettabile e quindi vietati, alto rischio, sottoposti a requisiti stringenti, rischio limitato e rischio minimo.
La disciplina dei controlli cresce con l’impatto potenziale su diritti fondamentali, sicurezza e mercato.
Per i sistemi ad alto rischio è richiesto un sistema di gestione del rischio permanente, che preveda:
• identificazione dei pericoli prevedibili,
• analisi e valutazione,
• misure di mitigazione,
• riesame periodico.
Non una compliance statica, ma un ciclo dinamico, secondo il ciclo di Deming (plan, do, check, act).
Il regolamento interviene sulla qualità dei dataset, ossia la rilevanza, la rappresentatività statistica, l’assenza di distorsioni sistemiche, la tracciabilità delle fonti.
L’errore non si corregge solo a valle; si previene a monte, nella costruzione del modello.
Circa la documentazione tecnica e il logging è previsto l’obbligo di un fascicolo tecnico, della registrazione degli eventi (log) e della conservazione della documentazione per controlli successivi.
Il sistema deve essere auditabile. Senza documentazione non esiste verificabilità.
Inoltre introduce il concetto di Human oversight effettivo, ossia la supervisione umana deve essere:
• progettata sin dall’architettura del sistema,
• esercitabile in modo consapevole,
• dotata di potere reale di intervento.
Non una clausola simbolica, ma un presidio strutturale.
Anche qui il legislatore europeo non pretende che il sistema “dica il vero”, ma esige che sia progettato con criteri di affidabilità, sia monitorato, sia governato da soggetti identificabili, sia controllabile ex post dalle autorità.
È una regolazione della responsabilità e del processo, non del contenuto epistemico dell’output.
Ancora una volta, l’Unione privilegia accountability, tracciabilità, proporzionalità, controllo umano qualificato.
Non la perfezione dell’algoritmo, ma la governabilità del suo impatto.
Supervisione umana e responsabilità nell’intelligenza artificiale
Il tema decisivo è la validazione umana.
Il punto non è la “presenza umana”, ma la qualità dell’intervento umano.
L’art. 22 del General Data Protection Regulation, precursore del AI Act, su cui si tornerà nel paragrafo successivo, non richiede un gesto notarile — qualcuno che clicchi approve — ma un controllo significativo (meaningful human intervention, nella lettura consolidata delle autorità europee).
Qui sta la distinzione decisiva: chi conferma l’output senza riesaminarne le premesse o manca di competenze tecniche o normative adeguate o che non disponga di potere effettivo di modifica o rigetto, indebolisce la governance traducendola in un puro maquillage.
In uno scenario come quello descritto, l’automazione resta il vero decisore. Un intervento è “umano” in senso giuridicamente rilevante solo se il soggetto:
• comprende il contesto normativo (vincoli legali applicabili);
• ha cognizione del dominio tecnico/scientifico sottostante;
• conosce il processo operativo da cui derivano i dati;
• può discostarsi motivatamente dall’output algoritmico.
Senza queste condizioni, la verifica degrada a lettura superficiale.
E gli errori più insidiosi non sono quelli palesemente illogici, ma quelli coerenti dal punto di vista tecnico e tuttavia concettualmente errati (bias statistici mascherati da regolarità, inferenze formalmente corrette ma giuridicamente irrilevanti, correlazioni scambiate per causalità).
Se il GDPR, come ricorderemo, introduce la garanzia, la prassi organizzativa deve darle sostanza. Una supervisione adeguata dovrebbe essere:
a. qualificata: con competenze formalmente individuate (job description, requisiti professionali, formazione periodica);
b. formalizzata: ossia con procedure scritte che definiscano quando scatta la revisione umana, quali elementi devono essere verificati, quali criteri giustificano lo scostamento dall’output algoritmico;
c. tracciabile, ossia log delle revisioni, motivazioni annotate, versioning dell’output e della decisione finale. Senza tracciabilità, non esiste accountability;
d. responsabilizzata, ossia attribuzione chiara di ruolo e responsabilità.
L’intervento umano deve avere un titolare identificabile, non una funzione impersonale.
In termini sistemici, la supervisione umana non è un atto correttivo ex post ma un momento integrato nel processo decisionale.
In altri termini non basta che l’uomo “possa” intervenire, ma deve essere posto nelle condizioni di capire, valutare e assumersi la titolarità della decisione.
Solo così l’automazione resta uno strumento. Altrimenti diventa il decisore occulto.
GDPR e decisioni automatizzate: il precedente dimenticato
Il precedente normativo è chiaro, ma spesso rimosso nel dibattito attuale sull’AI: il General Data Protection Regulation aveva già disciplinato le decisioni automatizzate con l’art. 22.
Cosa prevede l’art. 22 GDPR? Non introduce un divieto generalizzato di automazione. Stabilisce invece che l’interessato ha il diritto di non essere sottoposto a una decisione basata unicamente su trattamenti automatizzati, compresa la profilazione, che produca effetti giuridici nei suoi confronti, oppure effetti analogamente significativi.
Sono previste deroghe quando la decisione è necessaria per la conclusione o esecuzione di un contratto o autorizzata dal diritto dell’Unione o degli Stati membri e, ovviamente, quando si fonda sul consenso esplicito dell’interessato.
Ma anche in presenza di tali presupposti, il titolare deve assicurare garanzie rafforzate di carattere strutturale ed organizzativo.
Viene infatti richiesto al titolare di fornire informazioni significative sulla logica algoritmica utilizzata che non significa disclosure del codice sorgente né infallibilità dell’algoritmo. Anche perché tutto questo sarebbe incomprensibile per la maggior parte degli utenti. Ma si pretende intelligibilità sostanziale.
Inoltre l’interessato ha diritto a:
• ottenere l’intervento umano;
• esprimere la propria opinione;
• ottenere una rivalutazione.
Qui emerge il punto decisivo: l’ordinamento europeo non accetta che l’automazione sia l’ultimo decisore senza possibilità di revisione umana.
L’intervento deve essere reale, competente e non meramente simbolico.
È garantita la possibilità di:
• impugnare la decisione;
• chiedere una verifica;
• attivare i rimedi previsti dagli artt. 77–82 GDPR (reclamo, ricorso giurisdizionale, risarcimento).
La logica sottesa, ancora una volta, sono le garanzie procedurali, non verità ontologiche.
Quindi anche il GDPR non entra nel merito dell’“esattezza ontologica” della decisione algoritmica. Non stabilisce che l’algoritmo debba essere infallibile.
Ciò che impone è un impianto di accountability del titolare, la tracciabilità decisionale, la controllabilità ex post.
È la stessa architettura che permea tutto il regolamento: responsabilizzazione (art. 5 e 24), DPIA nei casi ad alto rischio (art. 35), documentazione delle scelte.
Il diritto europeo, coerentemente con la propria tradizione amministrativistica e costituzionale, privilegia quindi:
• gli aspetti procedurali, ovvero, come si decide, chi decide, chi controlla;
• le garanzie, ovvero chi può intervenire;
• la responsabilità, ossia chi ne risponde.
Ma nessuna presunta “verità tecnica” della macchina.
Questo precedente è centrale oggi perché nel dibattito contemporaneo sull’intelligenza artificiale (e sulle normative come l’AI Act), l’art. 22 del GDPR rappresenta l’antesignano del riconoscimento formale del problema della decisione algoritmica, con un modello di regolazione fondato su diritti soggettivi e controllabilità, non su divieti astratti. Un paradigma che integra tecnologia e stato di diritto.
Responsabilità 231: quando l’AI diventa fattore abilitante di reato
In ambito nazionale, l’utilizzo dell’AI si interseca direttamente con il Decreto Legislativo 231/2001.
Se un output generato da un sistema AI contribuisce — anche indirettamente — alla commissione di un reato presupposto, la questione non riguarda la “colpa” dell’algoritmo. L’algoritmo né il suo produttore sono un centro di imputazione giuridica.
Il punto è verificare se l’Ente abbia adottato ed efficacemente attuato un modello organizzativo idoneo a prevenire quel tipo di rischio.
Ricordiamo che l’utilizzo dell’AI (Legge 23 settembre 2025, n. 132, art. 61 co. 11-decies) costituisce un aggravante ed in concreto un fattore di cui tener conto in diversi ambiti sensibili:
• Falso in comunicazioni sociali: generazione di report, bilanci o relazioni “ottimizzati” senza adeguata verifica tecnica.
• Truffa ai danni di terzi o della PA: predisposizione automatizzata di documentazione progettuale o tecnica non aderente alla realtà.
• Manipolazione del mercato: produzione di comunicazioni finanziarie o informative fuorvianti.
• Reati informatici: utilizzo dell’AI per automatizzare attività intrusive o per aggirare controlli.
In tutti questi casi, l’elemento critico non è l’errore dell’output in sé, ma l’integrazione non governata dell’AI nei processi decisionali.
In chiave 231, le domande diventano strutturali, ovvero: l’uso dell’AI è stato mappato nei processi sensibili? È stata effettuata una risk assessment specifica sull’integrazione dei sistemi AI? Sono previste procedure formalizzate di validazione dell’output? È garantita la segregazione dei ruoli tra chi utilizza l’AI e chi valida il risultato? Esistono logging e tracciabilità dell’utilizzo? Sono stati attivati flussi informativi verso l’Organismo di Vigilanza?
L’assenza di tali presidi può configurare un deficit organizzativo, cioè una non idoneità del modello esimente o una sua sostanziale inefficacia.
Con l’adozione sempre più diffusa dell’AI nei processi aziendali, il rischio non è più astratto. Diventa prevedibile.
E ciò incide sulla valutazione della cosiddetta “colpa di organizzazione”. Se l’Ente introduce strumenti capaci di supportare comunicazioni societarie, gare pubbliche, relazioni tecniche o processi finanziari, senza aggiornare il proprio Modello 231, la lacuna organizzativa può emergere con evidenza in sede giudiziaria.
Il ricorso alla AI non attenua la responsabilità. Non si potrà sostenere “ci siamo avvalsi di un prodotto non affidabile e abbiamo citato il fornitore”. Al contrario può amplificarla se non è accompagnata da adeguati presidi.
In sintesi l’integrazione dell’AI nei sistemi aziendali richiede:
• l’aggiornamento della mappatura dei rischi;
• la revisione delle parti speciali relative ai reati informatici, societari e contro la PA;
• la formazione mirata del management;
• procedure di validazione tecnica obbligatorie;
• audit periodici sull’utilizzo dei sistemi AI.
In questa prospettiva, l’AI non è un problema tecnologico ma organizzativo.
La vera questione 231 non è se il sistema “abbia mentito”, ma se l’ente abbia costruito un assetto di controllo adeguato a governarne l’uso.
NIS2 e sicurezza: l’AI come nuova superficie di attacco
La Direttiva NIS2 amplia in modo significativo gli obblighi di gestione del rischio ICT per soggetti essenziali e importanti, imponendo misure tecniche, operative e organizzative proporzionate al livello di esposizione.
L’integrazione di sistemi di intelligenza artificiale in processi critici — decisioni operative, analisi di rischio, gestione clienti, compliance, cybersecurity — modifica la superficie di attacco aziendale. L’AI non è solo uno strumento applicativo: è un’infrastruttura logica che elabora dati, apprende pattern e produce output utilizzabili nei flussi decisionali.
Le vulnerabilità tipiche includono il data poisoning, ovvero il rischio di alterazione intenzionale dei dati di addestramento o di aggiornamento per influenzare sistematicamente le risposte del modello, la manipolazione degli input (prompt injection), con l’inserimento di istruzioni malevole che aggirano i controlli o inducono il sistema a rivelare informazioni sensibili. O la compromissione della supply chain del modello: vulnerabilità nei provider, nelle librerie, nei dataset o nelle API esterne su cui il sistema si appoggia.
Infine l’abuso interno, ossia l’utilizzo improprio da parte di dipendenti che impiegano l’AI per aggirare procedure o produrre documentazione formalmente corretta ma sostanzialmente fuorviante.
Anche nel perimetro NIS2, il tema non è la “verità” dell’output generato dall’AI, ma la resilienza del sistema, la sua capacità di prevenire, rilevare e mitigare compromissioni che possano produrre impatti operativi, reputazionali o regolatori.
La governance dell’AI diventa quindi parte integrante del sistema di gestione del rischio cyber:
• mappatura degli utilizzi AI nei processi critici;
• valutazione delle interdipendenze tecnologiche;
• privilegi e controlli sugli accessi;
• logging e monitoraggio degli utilizzi;
• test di vulnerabilità e scenari di attacco simulati;
• procedure di incident response che includano specificamente i sistemi AI.
L’intelligenza artificiale, in questo quadro, non è un problema epistemologico. È un asset tecnologico ad alta esposizione, che richiede misure di sicurezza coerenti con il suo peso sistemico.
Dalla compliance apparente alla governance sostanziale
Molte organizzazioni adottano policy generiche sull’uso dell’AI: linee guida etiche, raccomandazioni di prudenza, clausole di non affidamento esclusivo.
Ma basta? Diremmo proprio di no. Senza procedure operative dettagliate, responsabilità formalizzate, audit periodici, registri di utilizzo, la compliance resta apparente.
È questa la differenza tra una governance reale ed una governance cosmetica. Questo sarà il vero discrimine nei contenziosi futuri.
Possiamo quindi dire che la “truth crisis” non è una patologia tecnica dell’IA. È una crisi di aspettative e di responsabilità. Le LLM non sono soggetti epistemici, ma strumenti statistici. Ed il diritto europeo lo sa bene. Non pretende che l’AI sia vera, ma che sia solo un supporto nei processi di lavoro utilizzato da organizzazioni responsabili.
Ed è su questa scia che si muoverà il regolatorio futuro, non sull’idea di verità algoritmica, responsabilizzando oltre misura i produttori di strumenti di IA generativa, se non sulla qualità del dato su cui si basano gli algoritmi di natura probabilistica, ma sulla qualità della governance.
Su questo terreno che si misurerà la maturità digitale delle imprese.
