La multa da 400.000 dollari che dovrebbe terrorizzare ogni azienda di IA — e cosa sto costruendo invece

Ero al telefono con un potenziale cliente bancario quando la SEC ha annunciato i provvedimenti sanzionatori contro Delphia e Global Predictions. 18 marzo 2024. La responsabile della compliance del cliente ha letteralmente interrotto la nostra conversazione per leggere il comunicato stampa ad alta voce. Quando ha finito, è calato un lungo silenzio. Poi ha detto: «Quindi, in pratica, la SEC ci ha appena detto che tutto ciò che il nostro attuale fornitore di IA ci ha promesso è una causa legale in agguato».

Non aveva torto. La SEC aveva appena multato due società di consulenza in materia di investimenti per un totale di 400.000 dollari per quello che le autorità di vigilanza avevano formalmente definito AI washing — dichiarazioni false e fuorvianti sull'uso dell'intelligenza artificiale. Una delle due società, Delphia, dal 2019 diceva ai clienti di utilizzare il machine learning per analizzare le loro abitudini di spesa e la loro attività sui social media per «prevedere quali aziende e quali tendenze stanno per esplodere». La realtà? Non aveva mai integrato nessuno di quei dati nel proprio processo di investimento. Nemmeno una volta. Stava commercializzando una capacità che letteralmente non esisteva.

Quella telefonata ha cambiato la traiettoria della mia azienda. Non perché i provvedimenti mi avessero sorpreso — osservavo da mesi questa collisione tra l'hype sull'IA e la realtà normativa. Ciò che è cambiato è stata l'urgenza. All'improvviso, ogni banca, ogni sistema sanitario, ogni studio legale con cui parlavo non chiedeva più «come adottiamo l'IA?». Chiedeva «come dimostriamo che la nostra IA fa davvero ciò che diciamo che fa?».

Quella domanda — come si progetta una verità dimostrabile dentro un sistema di IA — è ciò a cui da allora cerco ossessivamente di rispondere.

Che cos'è esattamente l'AI washing e perché dovrebbe interessarti?

Pensa al greenwashing, ma per gli algoritmi. Un'azienda appiccica «powered by AI» sui propri materiali di marketing, guarda il titolo salire o la pipeline di clienti riempirsi, e nessuno si chiede se la tecnologia sottostante funzioni davvero come pubblicizzato. La SEC ha preso in prestito il termine deliberatamente: i meccanismi dell'inganno sono identici.

Delphia sosteneva di usare un «modello algoritmico predittivo» basato sul machine learning. La SEC l'ha ispezionata e nel 2021 le ha detto di smettere di mentire, e ha continuato a farlo per altri due anni. Questo le è costato una sanzione da 225.000 dollari e una censura. Global Predictions, dal canto suo, si definiva «il primo consulente finanziario regolamentato basato sull'IA» e prometteva «previsioni esperte guidate dall'IA». Quando le autorità hanno chiesto la documentazione tecnica a sostegno di quelle affermazioni, la società non è riuscita a produrla. Altri 175.000 dollari in fumo.

Alla SEC non è servita una nuova normativa specifica sull'IA per perseguire questi casi. Ha usato le stesse norme antifrode in vigore da decenni. Se menti su ciò che fa la tua tecnologia, stai commettendo una frode. La parte «IA» è irrilevante.

Ecco cosa rende tutto questo diverso da una tipica tirata d'orecchie normativa: il presidente della SEC, Gary Gensler, ha chiarito che questo era l'inizio, non un caso isolato. E la SEC non è sola. La FTC ha lanciato «Operation AI Comply» e ha preso di mira DoNotPay — l'azienda che si presentava come «il primo avvocato robot al mondo» — perché non è riuscita a comprovare le affermazioni secondo cui la sua IA poteva sostituire un avvocato in carne e ossa. Il Dipartimento di Giustizia ha annunciato che valuterà la gestione del rischio legato all'IA nell'ambito delle verifiche di compliance aziendale e che chiederà pene più severe per i reati agevolati da un uso improprio dell'IA.

Tre agenzie federali, tutte convergenti sullo stesso messaggio: dimostralo o pagane le conseguenze.

La sera in cui ho capito che gran parte dell'IA aziendale è costruita sulla sabbia

Ricordo una sera in particolare: io e il mio team stavamo facendo il benchmark di uno «strumento di ricerca legale basato sull'IA» di un concorrente, che un cliente stava valutando. Gli abbiamo posto una domanda diretta su una recente sentenza di una corte d'appello federale. Lo strumento ha restituito una risposta formattata magnificamente, con tre citazioni di casi. Tono sicuro. Linguaggio professionale. Un problema: una delle citazioni era completamente inventata. Il caso non esisteva. Gli altri due esistevano, ma dicevano l'opposto di ciò che lo strumento sosteneva.

Il mio cofondatore mi ha guardato e ha detto: «Questa cosa scrive come un avvocato e ragiona come un pappagallo».

È questo il problema tecnico di fondo, e non è un bug: è l'architettura. La maggior parte dei Large Language Model funziona tramite la predizione del token successivo. Calcolano la probabilità della parola che dovrebbe venire dopo, dato tutto ciò che è venuto prima. La matematica è elegante: una funzione softmax sui punteggi di output del modello, che seleziona la continuazione più probabile. Ma «più probabile» e «vero» sono cose fondamentalmente diverse. Il modello non ha alcun concetto interno di verità. Non ha mai letto una legge comprendendola davvero. Ha elaborato miliardi di token e ha imparato quali parole tendono a comparire vicino ad altre parole.

Per generare testi di marketing o riassumere gli appunti di una riunione va benissimo. Per dire a una banca se una transazione è conforme alle normative antiriciclaggio, o per dire a un medico se un'interazione tra farmaci è pericolosa, «statisticamente plausibile» è giuridicamente identico a «sbagliato».

Negli ambienti regolamentati, «per lo più corretto» non è un livello di qualità: è una categoria di responsabilità legale.

Eppure la stragrande maggioranza delle «soluzioni di IA» vendute oggi alle aziende è ciò che il settore chiama eufemisticamente «wrapper». Si prende un'API pubblica di OpenAI o Anthropic, si aggiunge un po' di prompt engineering e una bella interfaccia utente, e si mette sul mercato. Il wrapper non ha alcun modo di verificare il proprio ragionamento. Non può dimostrare da dove vengano le sue risposte. Si limita a ritrasmettere ciò che il modello di base genera, allucinazioni comprese.

Ho trattato questo problema in modo approfondito nella versione interattiva della nostra ricerca — il divario tra ciò che questi sistemi dichiarano e ciò che architetturalmente possono fare è sbalorditivo.

Perché il RAG fallisce nelle decisioni ad alto rischio?

Quando spiego questo problema a un pubblico tecnico, qualcuno dice immancabilmente: «Ma il RAG?». Retrieval-Augmented Generation — l'approccio in cui si dà al modello accesso a un database di documenti, così può andare a cercare le informazioni invece di inventarle. È il cerotto preferito del settore.

Ecco il problema. Il Vector RAG standard funziona convertendo la tua domanda e i tuoi documenti in rappresentazioni matematiche (vettori), per poi trovare i documenti «più vicini» alla tua domanda in quello spazio astratto. È una ricerca per similarità semantica. E per molte applicazioni funziona ragionevolmente bene.

Ma il «ragionevolmente bene» crolla nei domini in cui le relazioni tra le informazioni contano quanto le informazioni stesse. Prendi la ricerca legale. Un caso giudiziario non si limita a esistere — cita altri casi, ne supera alcuni, ne conferma altri e opera all'interno di una specifica gerarchia giurisdizionale. Quando chiedi a un'IA legale «questo precedente è ancora diritto vigente?», una ricerca vettoriale potrebbe far emergere il caso perché le parole corrispondono. Ma non ha modo di dirti che quel caso è stato superato da una corte superiore sei mesi dopo. Non sa distinguere tra una citazione e una sconfessione.

Il mio team ne ha discusso per settimane. Un ingegnere voleva continuare a migliorare il nostro retrieval vettoriale — embedding migliori, strategie di chunking migliori, reranking più sofisticato. Un'altra ingegnera continuava a insistere che il problema non fosse la qualità del retrieval, ma l'architettura del retrieval. Che l'intero paradigma del «trovare il documento più vicino» fosse sbagliato per i domini in cui sono le relazioni tra i documenti a portare il significato.

Aveva ragione. Ed è quella discussione che ci ha spinti verso il GraphRAG.

Cosa succede quando costruisci un'IA capace di dimostrare il proprio ragionamento?

Il GraphRAG — nello specifico quello che chiamiamo Citation-Enforced GraphRAG — sostituisce la ricerca semantica approssimativa con un knowledge graph strutturato. Invece di vettori che fluttuano in uno spazio astratto, si costruisce una mappa esplicita di come le informazioni si collegano tra loro. In un knowledge graph legale, una sentenza è un nodo. La sua relazione con altre sentenze è un arco — CITES, OVERRULES, AFFIRMS, INTERPRETS. Le leggi si collegano ai casi che le interpretano. Le gerarchie giurisdizionali sono codificate direttamente.

Quando l'IA genera una risposta, non si limita a trovare testo «simile». Attraversa percorsi verificati nel grafo. Se afferma che il Caso A supporta la Proposizione B, deve esistere un collegamento reale e tracciabile nel grafo che li connette. Usiamo la decodifica vincolata dal grafo per impedire fisicamente al modello di produrre una citazione che non può verificare. Il modello non può letteralmente allucinare una citazione, perché l'architettura non glielo consente.

È questo che intendo per IA deterministica. Non «probabilmente corretta». Dimostrabilmente fondata.

La differenza tra Vector RAG e GraphRAG non è un miglioramento incrementale: è la differenza tra indovinare quale libro sia pertinente e leggere davvero le note a piè di pagina.

Affianchiamo a tutto questo l'orchestrazione multi-agente. Invece di un unico modello che fa tutto — ricerca, verifica, scrittura — usiamo agenti specializzati. Un Research Agent recupera l'informazione grezza. Un Verification Agent la incrocia con il knowledge graph. Un Writer Agent produce l'output usando solo fatti verificati. Questi agenti operano attraverso quello che chiamiamo Cyclic Reflection Pattern, rivedendo iterativamente le bozze alla ricerca di allucinazioni prima che un qualsiasi essere umano ne veda mai il risultato.

È più lento di un wrapper. Costa di più da costruire. Ed è l'unica architettura a cui affiderei una decisione che potrebbe finire davanti a un'autorità di vigilanza.

Il problema della sovranità dei dati di cui nessuno vuole parlare

C'è un'altra dimensione della questione che il dibattito sull'AI washing per lo più ignora: dove risiedono i dati.

Una volta un cliente del settore sanitario mi ha chiesto a bruciapelo: «Se usiamo il vostro sistema, dove finiscono i dati dei nostri pazienti?». Quando gli ho detto che non lasciano mai la loro infrastruttura, è sembrato sollevato. Poi mi ha raccontato che il suo fornitore precedente — una nota azienda di IA — non era riuscito a rispondere chiaramente a quella domanda. I dati finivano nel cloud del fornitore, venivano elaborati su un'infrastruttura condivisa, e i termini di servizio del fornitore tecnicamente ne consentivano l'uso per migliorare i propri modelli.

Per un'azienda che tratta dati soggetti a HIPAA, GDPR o CCPA, quella non è una zona grigia. È una violazione.

Effettuiamo il deployment su infrastruttura sovrana — interamente self-hosted presso le sedi del cliente, oppure all'interno del suo cloud privato (VPC), dove le istanze di IA sono isolate da internet pubblico. Richiede un investimento iniziale maggiore. Il cliente ha bisogno di GPU e di un'infrastruttura specializzata. Ma ottiene qualcosa che nessuna API pubblica può offrire: zero fughe di dati e una completa tracciabilità. Ogni query, ogni risposta, ogni versione del modello — tutto all'interno del suo framework di governance.

Per l'architettura tecnica completa di come costruiamo tutto questo — inclusi lo schema del knowledge graph, il framework di orchestrazione multi-agente e il nostro approccio al deployment sovrano — consulta il nostro approfondimento tecnico.

Come si governa davvero l'IA senza annegare nella compliance?

Ho partecipato a riunioni del consiglio di amministrazione in cui i dirigenti trattano la governance dell'IA come una checklist da spuntare. Scegli un framework, compila i moduli, vai avanti. Con quell'approccio ti prenderai una multa.

Due framework si sono affermati come standard di settore, e servono a scopi diversi. Il NIST AI Risk Management Framework è una guida tattica volontaria: aiuta a identificare i rischi, a misurarli e a costruire processi interni. È rapido da implementare ed è ottimo per sviluppare quelli che chiamo i «muscoli del rischio IA» all'interno della tua organizzazione. Ma è autocertificato. Nessuno verifica che tu abbia davvero fatto ciò che hai dichiarato.

ISO/IEC 42001 è lo standard internazionale certificabile. Un auditor terzo esamina il tuo sistema di gestione dell'IA e ti certifica oppure no. Quella certificazione conta quando un'autorità di vigilanza, un cliente o un acquirente ti chiede «dimostrami che la tua governance dell'IA è reale».

La mossa intelligente è metterli in sequenza: usare il NIST per costruire rapidamente controlli interni agili, poi mappare quei controlli sui requisiti della ISO 42001 per la certificazione formale. Uno ti dà velocità, l'altro ti dà la prova.

E sotto entrambi i framework c'è un requisito emergente di cui la maggior parte delle aziende non ha ancora nemmeno sentito parlare: l'AI Bill of Materials (AIBOM). Pensalo come l'etichetta nutrizionale del tuo sistema di IA. È un registro leggibile dalle macchine di tutto ciò che è servito a costruirlo — dataset di addestramento, modelli di base, librerie di terze parti, dipendenze infrastrutturali. Quando un auditor chiede «con quali dati è stato addestrato questo modello?» oppure «quale versione di PyTorch era in esecuzione quando è stata presa questa decisione?», l'AIBOM risponde all'istante.

Generiamo gli AIBOM automaticamente come parte della nostra pipeline di deployment. Ogni versione del modello risale alle versioni esatte del codice e dei dataset. Non è un lavoro affascinante. Ma è la differenza tra superare un audit e affannarsi a ricostruire una documentazione che sarebbe dovuta esistere fin dal primo giorno.

L'investitore che mi ha detto di «usare semplicemente GPT»

Devo raccontare questa storia perché cattura esattamente la mentalità che l'azione sanzionatoria contro l'AI washing è pensata per punire.

Agli inizi di Veriprajna, stavo facendo un pitch a un investitore. Gli ho spiegato la nostra architettura — i knowledge graph, la verifica multi-agente, il modello di deployment sovrano. Ha ascoltato educatamente, poi ha detto: «Perché non ti limiti a fare un wrapper su GPT-4, far pagare meno e scalare più in fretta? Nessuno andrà a fare l'audit del backend».

Gli ho detto che la SEC aveva appena multato due aziende esattamente per quella logica. Ha fatto spallucce.

Sei mesi dopo, una delle società del suo portafoglio — una fintech «basata sull'IA» — ha ricevuto una richiesta di chiarimenti dalle autorità sulle proprie affermazioni di marketing. Non è riuscita a produrre documentazione che dimostrasse che la sua IA facesse davvero ciò che il pitch deck sosteneva. L'ultima cosa che ho saputo è che stavano correndo ad assumere consulenti di compliance a tariffe d'emergenza.

Mi chiedono sempre se il clima sanzionatorio si ammorbidirà — se una nuova amministrazione o un cambio di priorità possano rendere l'AI washing meno rischioso. La mia risposta onesta: non ha importanza. La SEC ha usato norme antifrode esistenti. La FTC ha usato la Section 5 del FTC Act, in vigore dal 1914. I procuratori generali dei singoli stati hanno le proprie leggi a tutela dei consumatori. Anche se le priorità sanzionatorie federali cambiassero, l'impianto giuridico per perseguire l'inganno sull'IA è permanente e stratificato su più livelli.

L'AI washing non è una moda normativa passeggera. È una frode travestita da scienza, e ogni livello di governo ha ora gli strumenti e la volontà di perseguirla.

La domanda più importante è cosa accade al mercato. Quando le aziende hanno successo grazie a capacità di IA inventate, distorcono la concorrenza ed erodono la fiducia di cui le aziende di IA legittime hanno bisogno per operare. Ogni wrapper venduto come «IA avanzata» rende più difficile, per chi fa ingegneria vera, spiegare perché le proprie soluzioni costano di più e richiedono più tempo per essere costruite.

Che aspetto ha davvero un sistema di IA affidabile?

Se togli i framework e gli acronimi, costruire un'IA capace di sopravvivere al vaglio delle autorità di vigilanza si riduce a quattro cose.

Ingegnerizza il determinismo. Vai oltre gli output probabilistici, verso architetture — sistemi neuro-simbolici, knowledge graph, decodifica vincolata dal grafo — capaci di dimostrare il proprio ragionamento. Se la tua IA non sa mostrare il procedimento, non è pronta per gli ambienti regolamentati.

Progetta la sovranità. Fai il deployment all'interno di un'infrastruttura che controlli. Se i dati sensibili del tuo cliente toccano un'infrastruttura pubblica condivisa, hai creato una responsabilità di compliance che nessuna quantità di prompt engineering può sanare.

Standardizza la governance. Adotta framework certificabili. Mantieni gli AI Bill of Materials. Rendi la documentazione un processo continuo e automatizzato, non una corsa affannosa annuale.

Valida in modo continuo. Implementa il red-teaming avversariale, monitora i tassi di allucinazione e di grounding come KPI e mantieni gli esseri umani nel loop per le decisioni ad alto rischio. Il modello che era accurato al momento del deployment andrà in drift. Monitoralo come monitoreresti un algoritmo di trading — perché le conseguenze di un fallimento sono comparabili.

I 400.000 dollari di sanzioni della SEC sono stati un errore di arrotondamento per il settore finanziario. Il messaggio dietro quelle sanzioni no. Siamo usciti dall'epoca in cui si potevano pubblicizzare capacità di IA che non si possedevano, fare il deployment di scatole nere dentro workflow regolamentati e dare per scontato che nessuno andasse a controllare. Ogni sistema di IA aziendale opera ora sotto un implicito onere della prova: puoi dimostrare che fa ciò che dichiari?

Ho fondato Veriprajna — il nome unisce «Veri» (verità) e «Prajna» (saggezza) — perché credo che la crisi di credibilità del settore dell'IA sia fondamentalmente una crisi di architettura. Non puoi risolvere un problema di verità con un sistema che non è mai stato progettato per curarsi della verità. Devi ingegnerizzarla nel sistema, a partire dal knowledge graph, attraverso ogni agente, ogni ciclo di verifica, ogni decisione di deployment.

Le aziende che lo capiranno costruiranno IA che funziona davvero. Quelle che non lo capiranno continueranno a fare wrapper sulle API, a scrivere pitch deck impressionanti e a sperare che nessuno guardi sotto il cofano. Le autorità di vigilanza ora guardano. E non hanno intenzione di smettere.