Sistemi AI "sicuri"? I limiti degli eval secondo un’analisi di Gradient Flow

Un uomo fa causa a OpenAI perché ChatGPT ha usato la sua diagnosi di bipolarismo per trattenerlo in conversazione invece di indirizzarlo verso un aiuto. Una corte federale americana procede contro Workday: il software di hiring avrebbe scartato un candidato disabile basandosi su segnali proxy legati ai congedi medici. Un tribunale tedesco stabilisce che un’azienda risponde in prima persona delle credenziali mediche inventate dal proprio chatbot.

Nessuno di questi tre casi è il tipo di fallimento che una sessione di red team o una checklist sui bias è progettata per intercettare. Eppure sono rischi reali, legali e reputazionali, emersi in sistemi che avevano già superato tutte le valutazioni interne. Il problema non è l’assenza di eval: è cosa quegli eval non vedono.

Cosa manca agli eval tradizionali?

La configurazione standard — un prompt generico, un modello, un punteggio binario — è troppo grossolana per funzionare davvero. Chiedere a un modello se un output è "manipolativo" o "discriminatorio" produce risposte superficiali. I problemi reali sfuggono, e nel frattempo output innocui vengono etichettati come rischiosi, lasciando i team senza indicazioni operative su cosa correggere.

L’analisi pubblicata da Gradient Flow cita il whitepaper di Luminos, azienda guidata dal CEO Andrew Burt. Il documento propone un approccio diverso, che chiama "alta dimensionalità". In pratica: invece di chiedere "questa inserzione è manipolativa?", si testano separatamente elementi specifici — un countdown falso, una commissione nascosta, un’offerta bait-and-switch. Il risultato non è un verdetto secco, ma una scomposizione (urgenza falsa: sì; commissione nascosta: sì; bait and switch: no) su cui un team prodotto può intervenire.

Speaker smart AI su scrivania luminosa con cubi di valutazione, uno con una crepa, limite degli eval di sicurezza dell'IA — La crepa su uno dei cubi di valutazione richiama i limiti degli eval: superare i test non garantisce la sicurezza di un sistema AI.

Tre componenti chiave:

Test su più modelli, perché ciascuno ha una propria "personalità" nel segnalare i rischi: Claude tende a sovrasegnalare per impostazione conservativa, altri modelli sottosegnalano.
Standard tarati su competenze legali, privacy e compliance vere, non su ipotesi ingegneristiche su cosa un regolatore potrebbe contestare.
Monitoraggio continuo, non un check una tantum pre-lancio: i modelli si aggiornano, le leggi cambiano tra giurisdizioni, e una suite di test valida a gennaio può essere obsoleta entro l’estate.

Nessuno di questi elementi è inedito preso singolarmente. La differenza sta nel metterli insieme e trattare il risultato come un processo vivo, non come una casella da spuntare prima della release.

Dai chatbot agli agenti: il rischio produzione è sistemico

Il punto non è che le aziende abbiano saltato del tutto le valutazioni: la maggior parte aveva qualcosa in produzione. L’errore è presumere che eval, red team e guardrail sommati restituiscano un quadro completo del rischio reale.

Quando un sistema AI può influenzare un cliente, un dipendente, un account o una decisione regolata, il suo risk testing merita la stessa severità che si applica a affidabilità e uptime: test specifici, evidenze documentabili, proprietà chiara e monitoraggio post-lancio. Questo perimetro copre più sistemi di quanto sembri — chatbot di supporto, strumenti di hiring, scoring interni, agenti con accesso in scrittura. Non esiste una categoria intermedia rassicurante del tipo "abbastanza importante da essere rilasciato, non abbastanza da essere valutato sul serio".

Un approccio che scomponga il rischio nelle sue componenti reali — legali, reputazionali, operative — non è una garanzia assoluta. Ma è l’unica direzione per smettere di scoprire i problemi solo quando arrivano in tribunale.