Come Fermare le Allucinazioni di ChatGPT nel Lavoro di Compliance Regolamentato

Un team di Responsible Gambling (RG) nel Regno Unito si è rivolto a noi con un problema che chiunque automatizzi lavoro regolamentato riconoscerà. Utilizzano ChatGPT per trasformare i trigger automatici di compliance in note formali per gli analisti. Quando un cliente supera una soglia — turnover in aumento di oltre il 100% in 30 giorni, una sessione che va oltre il proprio limite — un analista copia i dati rilevanti in ChatGPT, e il modello, seguendo un prompt pre-caricato, redige una nota per il fascicolo di compliance del cliente.

Quella nota non è una bozza di email. È un documento legale revisionabile dalla UK Gambling Commission. E dopo un po’, ChatGPT ha iniziato ad allucinare cifre, omettere informazioni chiave, inserire trattini lunghi che rompevano lo stile aziendale e derivare silenziosamente dalle regole nel pomeriggio. Su un fascicolo regolamentato, ognuno di questi è un problema di compliance.

La domanda che si sono posti era semplice: è possibile ottenere da un modello linguistico la coerenza richiesta dal lavoro regolamentato? La risposta è sì — ma non modificando la formulazione di un prompt dentro una finestra di chat. Serve un cambiamento architetturale unito a una riscrittura disciplinata. Questo articolo illustra il metodo esatto, usando il workflow RG come esempio pratico, così da poterlo applicare a qualsiasi processo regolamentato in cui lo stesso input debba produrre sempre lo stesso output affidabile.

Perché ChatGPT deriva nel lavoro regolamentato

Prima di risolvere qualcosa, è utile identificare con precisione le modalità di fallimento. Nel workflow RG abbiamo riprodotto cinque modalità distinte con cui l’output si rompeva, che vanno da critiche a semplicemente fastidiose.

Le due critiche sono la coppia pericolosa. Le cifre allucinate inseriscono un deposito o un numero di profitto e perdita errato su un fascicolo regolamentato — il modello colma una lacuna attingendo dalla memoria di addestramento anziché ammettere che il dato è assente. L’inversione di convenzione è più sottile: questo operatore usa una convenzione di profitto e perdita invertita, dove un numero positivo significa che il cliente sta perdendo. È controintuitivo, quindi il modello torna alla convenzione standard appresa in addestramento e scrive che un cliente sta perdendo quando in realtà sta vincendo.

I problemi ad alta gravità — trattini lunghi che violano lo stile aziendale, e il session drift in cui le regole vengono ignorate più tardi nella giornata — non mettono una cifra sbagliata sul fascicolo, ma erodono la fiducia nell’output e creano lavoro aggiuntivo. Il problema medio, nomi informali degli interventi invece dei termini regolatori esatti, corrompe silenziosamente il registro di compliance.

La causa principale è la statelessness — o la sua assenza

Quattro di questi cinque fallimenti condividono un’unica causa principale. In un’unica sessione ChatGPT, ogni caso esaminato viene aggiunto alla context window. Esaminando il primo caso, il modello vede il prompt e un solo caso. Al quindicesimo caso, vede il prompt più il residuo statistico dei quattordici scambi precedenti. Le regole del prompt sono ancora lì, ma competono con un cumulo crescente di contesto, e l’attenzione a esse decade.

Ecco perché lo stesso prompt produce una nota perfetta alle 9 del mattino e una viziata alle 16. La soluzione architetturale è la statelessness: ogni caso deve essere una chiamata completamente nuova e isolata che vede solo il prompt bloccato e il caso corrente. Nulla viene riportato da un caso all’altro. Un agente AI configurato in questo modo dà al prompt la stessa attenzione sul cinquantesimo caso che aveva sul primo.

La statelessness è necessaria ma non sufficiente. Ferma la deriva, ma riprodurrà fedelmente un cattivo prompt a ogni chiamata. Quindi il prompt stesso deve essere irrobustito.

Pronto a far crescere il tuo business?

Inizia oggi la tua prova gratuita e vedi i risultati in pochi giorni.

Richiedi demo Accedi

Passo 1: Irrobustire il prompt per primacy e recency

I modelli linguistici non pesano ogni riga di un prompt allo stesso modo. L’attenzione ha una forma approssimativamente a U — più forte all’inizio e alla fine, più debole nel mezzo. Il prompt RG originale contrastava questo schema. La sua regola più importante, la convenzione invertita di profitto e perdita, si trovava nel mezzo del prompt, dichiarata una sola volta. Il divieto dei trattini lunghi era l’ultimissima riga, anch’esso dichiarato una sola volta.

La riscrittura ha spostato le regole critiche dove il modello guarda effettivamente e ha rielaborato le parti deboli del system prompt . Ecco cosa è cambiato e perché.

La lezione più importante di tutte: gli aggettivi vaghi non sono istruzioni. Dire a un modello di essere “naturale” incoraggiava attivamente i trattini lunghi e i fronzoli retorici che rompevano lo stile aziendale. Sostituire questo con regole concrete e verificabili è ciò che ha reso lo stile coerente.

Passo 2: Gestire i dati mancanti invece di inventarli

L’allucinazione viene spesso inquadrata come un difetto del modello. Nel lavoro strutturato è di solito un difetto del prompt: il prompt non ha mai detto al modello cosa fare quando un campo è assente, quindi ha fatto la cosa statisticamente più probabile e ha prodotto un valore plausibile.

La soluzione è un protocollo per i dati mancanti. Suddividi i tuoi campi in obbligatori e opzionali. I campi opzionali vengono omessi silenziosamente quando assenti. I campi obbligatori fanno l’opposto — se ne manca uno, il modello deve fermarsi e richiederlo in un formato esatto invece di generare una nota. Quella singola regola trasforma un’allucinazione silenziosa in una richiesta visibile e verificabile di ulteriori dati. È la differenza tra una cifra sbagliata su un fascicolo regolamentato e una nota che non è mai stata prodotta perché l’input era incompleto.

Iscriviti alla nostra newsletter

Ricevi gratuitamente gli ultimi consigli, tendenze e offerte.

Indirizzo email

Iscriviti

Passo 3: Bloccare la configurazione dell’agente

Con un prompt irrobustito, anche l’agente stesso deve essere bloccato affinché nulla reintroduca variabilità. L’intero flusso è volutamente minimale — tre nodi e nient’altro.

Le scelte di configurazione che hanno fatto la differenza:

• System prompt nel campo System Message, mai nel campo Input, così viene letto come istruzione e non come dato.
• Temperatura 0,2. Abbastanza bassa per la massima coerenza, abbastanza alta da evitare una prosa robotica. Zero era troppo rigido; uno era troppo creativo.
• Nessuno strumento collegato. I recuperatori di file e URL introducono imprevedibilità e possono aggirare il ragionamento dell’agente. Per questo compito il modello non ha bisogno di nulla oltre al prompt e al caso incollato.
• Token massimi lasciati al valore predefinito. Limitare i token causava il troncamento delle note a metà frase, e una nota troncata su un fascicolo cliente è essa stessa un rischio regolatorio.
• Un’istruzione di avvio silenzioso in cima al prompt, così l’agente non conferma le regole all’analista quando il flusso si carica per la prima volta.

L’unica regola operativa che conta di più

Ogni correzione sopra descritta viene vanificata da una cattiva abitudine: riutilizzare la stessa chat. La regola operativa più importante per il team di analisti è avviare una nuova conversazione per ogni singolo caso. Mai continuare a esaminare casi nella stessa finestra. È questa la regola che elimina il session drift — la causa principale della maggior parte dei fallimenti originali — e non costa nulla da seguire.

Funziona davvero? 9 modelli, 27 esecuzioni

Un metodo vale quanto le sue prove. Abbiamo testato nove modelli rispetto al prompt irrobustito, usando un caso reale identico (un trigger di Gambling Intensity con una storia pregressa di durata delle sessioni) su tre esecuzioni ciascuno — 27 esecuzioni in totale — e valutato ogni esecuzione rispetto a 16 criteri di compliance.

Su tutte le 27 esecuzioni, nessun modello pronto per la produzione ha allucinato una cifra, invertito la convenzione P/L, usato un trattino lungo o troncato l’output. Il prompt irrobustito ha eliminato ognuna delle modalità di fallimento originali sui modelli che si sono qualificati. Le differenze rimaste riguardavano la profondità analitica e la coerenza, non la correttezza.

Le squalifiche sono istruttive. Claude Sonnet 4.6 ha prodotto una prosa splendida ma ha confuso la soglia del trigger con il limite di deposito — una cifra fattualmente errata su un fascicolo regolamentato, il che è squalificante a prescindere da quanto bene si legga. L’oscillazione di DeepSeek da un’esecuzione all’altra (6, 8,5, 9) è il vero problema: nel lavoro regolamentato, una qualità che dipende dalla fortuna non è affatto qualità.

Il costo non è il vincolo

È allettante ottimizzare per il prezzo, ma i numeri dimostrano il contrario. Anche il modello più costoso tra quelli pronti per la produzione, Claude Opus 4.8, costa circa sei centesimi per nota. Per un team che esamina 50 casi al giorno, sono meno di 90 dollari al mese. Il costo di un singolo rilievo regolatorio dovuto a una nota errata supererebbe di gran lunga il costo annuale di qualsiasi modello dell’elenco. Per la compliance regolamentata, scegli il modello più affidabile che puoi permetterti, non il più economico.

Come appare una nota irrobustita

La migliore nota singola tra tutte le 27 esecuzioni è arrivata da Claude Fable 5. Nota cosa fa: dichiara la posizione nella convenzione corretta, cita le cifre testualmente, usa il nome esatto dell’intervento e — cosa fondamentale — spiega perché l’escalation sarebbe sproporzionata invece di limitarsi a dichiarare un esito.

The customer is currently in a winning position of £1,612.50 with an account balance of £8,962.50, which represents an improvement on the winning position of £1,275.00 recorded at the previous review… Session duration was reviewed under Session Duration Level 1 on 19/07 and again on 20/07… Given that those decisions were made within the last few days, insufficient time has elapsed to assess their effectiveness, and repeating or escalating on the same behaviour at this stage would be disproportionate… In this context, No Further Action Required is the proportionate outcome.

Questo è lo standard che il lavoro regolamentato richiede: basato su evidenze, proporzionato e identico in qualità sul primo caso della giornata come sul cinquantesimo.

Applicare questo metodo al proprio workflow regolamentato

Il generatore di note RG è un caso specifico, ma il metodo si generalizza a qualsiasi processo in cui un modello linguistico debba produrre un output affidabile e ripetibile su dati regolamentati o ad alto rischio:

1. Abbandona la finestra di chat. Esegui ogni caso come una chiamata stateless così il contesto non può accumularsi e derivare.
2. Irrobustisci il prompt per primacy e recency. Metti le regole critiche per prime e ripetile per ultime. Aggiungi autoverifiche.
3. Fornisci al modello un protocollo per i dati mancanti. I campi obbligatori bloccano la generazione se assenti; i campi opzionali vengono omessi silenziosamente. Non lasciare mai che indovini.
4. Blocca la configurazione. Temperatura bassa ma non nulla, nessuno strumento superfluo, output senza limite, prompt nel messaggio di sistema.
5. Testa prima di fidarti. Esegui lo stesso caso più volte su modelli candidati e valuta rispetto a criteri espliciti. La coerenza tra le esecuzioni è la metrica che conta.

Fai queste cinque cose e trasformerai un modello che allucina nel pomeriggio in uno che produce output pronto per l’audit ogni volta. La coerenza richiesta dal lavoro regolamentato è raggiungibile — è un problema di architettura e di prompt engineering, ed entrambi sono risolvibili.