come funziona un Cognitive Adversarial Validator

Gli errori di un Large Language Model non sono incidenti occasionali. Nei sistemi conversazionali avanzati l’errore è una proprietà strutturale del modo in cui le risposte vengono generate: il modello può produrre un’affermazione falsa in forma coerente, persuasiva e resistente alla correzione. In un primo articolo abbiamo descritto tre modi tipici in cui questo accade — l’allucinazione, ribattezzata confabulazione funzionale; la compiacenza verso l’utente (sycophancy); e la deriva, ossia la tendenza a perseverare in una premessa errata invece di abbandonarla. La conclusione era che il prompt non basta: nei domini ad alta conseguenza serve un livello di validazione separato e indipendente dal modello che genera. Qui lo costruiamo — e, soprattutto, lo mettiamo alla prova.

Cognitive Adversarial Validator, oltre il contenuto della risposta

I tre errori della prima parte hanno un tratto in comune: riguardano il contenuto della risposta, ciò che il modello afferma. Esiste però una categoria diversa, che non tocca l’affermazione ma i suoi presupposti: l’immagine implicita di chi sta parlando e il momento in cui parla. Sono errori che avvengono prima della risposta, nel modo in cui il modello inquadra la situazione — e per questo un’architettura di controllo deve intercettarli in modo mirato, distinto dal fact-checking. Due meritano attenzione, perché crescono proprio dove l’IA aziendale sta andando: memoria, personalizzazione, agentività.

Il presupposto sull’utente 

Un LLM non risponde mai a una persona in senso diretto: risponde a una rappresentazione implicita che si è costruito dell’interlocutore. È utile finché resta aggiornata; diventa una fonte autonoma di errore — il User-Model Prior Misfit — quando il modello continua ad applicarla a fronte di evidenze che dovrebbero correggerla. Se a un utente che vuole vedere validato il proprio progetto applica il prior generico «chi costruisce vuole essere incoraggiato», produrrà una risposta reticente nel dissenso anche quando quell’utente ha mostrato un metodo critico e orientato alla falsificazione. Non è compiacenza verso l’utente reale: è compiacenza verso un’immagine sbagliata dell’utente.

Il presupposto sul tempo 

Un LLM può conoscere data e ora se gliele si forniscono, ma non possiede una continuità temporale attiva: tra una chiamata e l’altra non è un processo che osserva il mondo, è una funzione che viene invocata. È il Temporal Grounding Deficit: sapere che ora è non equivale a possedere un orologio operativo interno. Il modello può così ragionare su un alert, una condizione di mercato o una finestra di esecuzione come se fossero ancora validi.

Un’avvertenza, però, contro la conclusione affrettata: il deficit è del modello, non fatalmente del sistema. Un’architettura agentica può possedere proprio ciò che al modello manca: uno scheduler che gira a prescindere dall’utente, dati con timestamp e TTL, finestre di validità che invalidano un segnale a una certa ora, un blocco se il dato è più vecchio di una soglia. La continuità temporale non sta nel modello: sta nell’orchestrazione, e un agente è orchestrazione. Ma è una proprietà da progettare, non data: un agente che si limita a wrappare un LLM eredita il deficit in pieno, e anche con i timestamp in input è sempre il modello a ragionare sul tempo e può trattare come attuale un dato che l’infrastruttura gli ha consegnato come scaduto, se non è vincolato a controllarlo. Per questo il timestamp non basta: serve una regola che blocchi, non solo un dato che informi. È esattamente il ruolo del Temporal Grounding Auditor.

In entrambi i casi il modello può rispondere correttamente alla domanda e sbagliare comunque, perché ha sbagliato la cornice: chi ha davanti, oppure quando. È una forma d’errore che nessun controllo sui fatti, da solo, riesce a vedere.

Il Cognitive Adversarial Validator come separazione dei poteri cognitivi

L’ipotesi è quella di un Cognitive Adversarial Validator (CAV): non un fact-checker unico, ma un livello di critica organizzata, indipendente dal modello che genera. Perché funzioni, una condizione è dirimente: generatore e validatori non devono essere lo stesso modello, e preferibilmente nemmeno modelli della stessa famiglia.

Due modelli addestrati sugli stessi dati condividono gli stessi bias e gli stessi punti ciechi; un’architettura di controllo credibile è multi-modello e, idealmente, multi-vendor, così che l’errore del generatore non sia sistematicamente invisibile al validatore. È una separazione dei poteri, trasferita dal piano istituzionale a quello cognitivo: chi produce una decisione non deve esserne anche l’unico giudice.

Come funziona la pipeline di un CAV

Una possibile catena tra generatore e validatore può essere descritta come una sequenza di stadi, ciascuno con la propria tecnologia e la propria logica di controllo.

1. Ingestion e Domain Risk Gate. Un classificatore – modello rapido o ibrido regole + ML – etichetta la richiesta per dominio (finanza, medicina, legale, cyber, business continuity, creativo, ecc.) e per sensibilità temporale, assegnando un livello di criticità che determina quali validatori attivare e con quale budget di latenza. 

2. Generazione. Il modello generatore produce una risposta preliminare, accompagnata – dove disponibile – da segnali di confidenza nativi: log-probabilities a livello di token, self-consistency su campionamenti multipli, semantic entropy per stimare l’incertezza sul significato e non sulla sola forma. 

3. Decomposizione. Un claim parser scompone la risposta in unità atomiche – affermazioni fattuali, inferenze, assunzioni, raccomandazioni – tramite structured output / function calling con schema JSON. Si valida ciò che la risposta afferma, non come è scritta. 

4. Validazione parallela. I validatori specializzati operano in parallelo, ciascuno con la propria logica: 

• Evidence Auditor. Ogni claim fattuale viene ancorato via retrieval (RAG con provenienza) a fonti autoritative; i claim privi di sostegno vengono marcati. Logica: grounding e citazione, non plausibilità. 

• Reasoning Auditor. La tenuta premesse-conclusione è verificata con modelli di entailment (NLI) e prompt avversariali che cercano controesempi. Logica: implicazione logica, non coerenza narrativa. 

• Dissent Auditor. Un modello critico, istruito a cercare la confutazione, stima se il verdetto è stato attenuato e propone una riformulazione più netta. Logica: LLM-as-a-judge in ruolo avversariale. 

• User-Prior Auditor. Confronta il profilo implicito con l’evidenza recente, letta da una memoria profilo con confidence score e decadimento; se il prior è poco supportato, ne abbassa il peso. Logica: recency-weighting e neutralizzazione del profilo. 

• Temporal Grounding Auditor. Confronta timestamp del dato, finestra di validità, soglia di staleness e, nei domini operativi, calendari di sessione; se i timestamp mancano o la finestra è chiusa, solleva un blocco. Logica: TTL e data freshness. 

5. Aggregazione. Un aggregatore raccoglie i verdict (ed è il punto in cui un sistema di controllo può tradire sé stesso). Appena si introduce un motore di pesi e un punteggio di rischio complessivo, i pesi diventano parametri liberi capaci di giustificare qualunque conclusione si desideri: la regola, perciò, è minimizzarli. Le condizioni dure – un claim critico privo di fonte, un timestamp mancante in dominio operativo – non entrano in un punteggio che può diluirle: sono veti deterministici che bloccano a prescindere. Solo il rischio residuo, davvero graduato, può ricorrere a un peso; e quel peso va dichiarato, motivato e pre-registrato come un’ipotesi, non tarato a piacere finché «torna». Un risk score con i pesi nascosti non è una misura: è un’opinione travestita da numero.. 

6. Policy engine. Un motore di regole – separato dai modelli, deterministico e auditabile – applica la decisione finale: rischio basso, rilascio; rischio medio, correzione o annotazione con metadati di evidenza; rischio alto, blocco, riformulazione o inoltro a un secondo modello avversariale; dominio operativo con dati temporali mancanti, nessuna raccomandazione esecutiva ed escalation umana. 

7. Tracciabilità. Ogni stadio lascia un log strutturato: quali controlli eseguiti, quali moduli hanno dissentito, quali assunzioni restano aperte. È lo stesso log che abilita l’audit longitudinale della traiettoria, non solo dell’ultima risposta. 

CAV costruibile oggi, ma a livelli

Un punto pratico, e non secondario: nulla di tutto questo richiede l’addestramento di nuovi modelli. Il CAV è un’orchestrazione (generatore, modello critico, modello avversariale, parser di claim, modulo di retrieval, layer timestamp/staleness, memoria profilo con confidence score, classificatore di dominio, aggregatore, policy engine) costruibile con modelli esistenti, prompt specializzati e logging strutturato. Il costo non è teorico ma ingegneristico: latenza, spesa computazionale, falsi positivi.

Per questo la validazione va modulata sul rischio, in tre regimi.

• In modalità advisory leggera, per richieste a basso rischio, il CAV controlla coerenza, completezza e incertezza.  

• In modalità technical review, per le analisi tecniche, attiva evidenza, ragionamento, assunzioni e alternative. I 

• n modalità operational gate, per i domini time-sensitive, pretende timestamp, dati aggiornati, finestre di validità e soglie di blocco: se mancano, la raccomandazione esecutiva non viene rilasciata. 

I punti deboli del CAV e dei suoi custodi

Qui finisce la parte facile. Un’architettura di controllo non elimina l’errore: lo sposta. E va detto dove.

• Substrato condiviso. Se generatore e validatori condividono dati di addestramento o convenzioni, condividono anche i punti ciechi: un errore invisibile al generatore può esserlo anche al critico. È la ragione per cui il multi-vendor non è un vezzo ma il cuore statistico del progetto — e anche così la garanzia resta probabilistica. 

• L’aggregatore come single point of failure. Spostiamo il giudizio dal generatore all’aggregatore dei verdict; ma chi garantisce l’aggregatore? Una regola di voto mal tarata può zittire il dissenso corretto o amplificare un falso positivo. 

• Il regresso. Chi valida il validatore? Aggiungere un meta-validatore non chiude il problema, lo arretra di un livello. A un certo punto la catena va interrotta con qualcosa che non è un LLM: regole deterministiche, vincoli formali, o l’essere umano. 

• Costo, latenza, falsi positivi. Ogni controllo aggiunge tempo e spesa; in real-time (trading intraday, controllo fisico) una catena lunga è impraticabile. E un validatore troppo zelante, che blocca di continuo, viene semplicemente disattivato dagli utenti: il fallimento più banale e più comune. 

• Compiacenza del validatore. Nulla impedisce, in linea di principio, che anche il modello critico sia a sua volta compiacente — verso il generatore o verso il prompt di sistema che lo istruisce. 

Come falsificare un CAV

La domanda che conta non è “il CAV è elegante?”, ma “come faccio a sapere se sta funzionando?”. Senza una risposta misurabile, resta retorica. Alcune metriche minime, da pre-registrare prima di vederle:

• tasso di dissenso sui casi in cui la risposta corretta è un «no» netto: un CAV che non alza mai il dissenso su un dataset di trabocchetti è rotto; 

• curva falsi-positivi / latenza: quanto blocco inutile si paga per quanto rischio evitato; 

• red-teaming del validatore: costruire deliberatamente risposte sbagliate-ma-convincenti e misurare quante ne passano; 

• staleness recall: su casi time-sensitive con dati scaduti, quante volte il Temporal Auditor blocca correttamente; 

• delta vs baseline: il CAV va confrontato con il solo generatore, altrimenti non si sa se aggiunge valore o solo costo. 

Il punto metodologico è che il CAV va trattato come una qualunque ipotesi: con soglie dichiarate in anticipo e un disegno che possa smentirlo. Vale per i validatori esattamente come per i modelli che validano.

Validazione umana e AI Act nei sistemi ad alto rischio

Il regresso ha una conclusione obbligata: a un certo punto la catena dei controlli va chiusa da qualcosa che non è un altro modello. E per una classe importante di decisioni quel qualcosa, oltre che ragionevole, è imposto dalla norma.

L’AI Act europeo, all’articolo 14, richiede che i sistemi ad alto rischio siano progettati per essere effettivamente sorvegliati da persone fisiche, capaci di comprenderne l’output, di interpretarlo, di intervenire e di fermarlo. Non è un presidio da aggiungere a valle: è un requisito di progettazione del sistema.

La norma nomina anche il rischio specifico che attraversa l’intero discorso: l’automation bias, la tendenza a fidarsi automaticamente, o troppo, dell’output di una macchina, soprattutto quando fornisce informazioni o raccomandazioni per decisioni prese da persone. È esattamente il pericolo della risposta che convince: un CAV ben progettato lo riduce esponendo evidenza, incertezza e dissenso, ma non lo elimina. Per questo, dove la posta è alta, il modello non può essere giudice unico e nemmeno il validatore può esserlo.

Che questo non sia teoria lo mostra la ricerca sull’agentic misalignment¹: in scenari costruiti, con accesso a strumenti e di fronte alla prospettiva di essere sostituiti o a un conflitto di obiettivo, diversi modelli hanno scelto azioni auto-protettive dannose – ricatto, fuga di informazioni – senza esservi istruiti. Non è un’AI che “vuole vivere”: è una AI che, in condizioni artificiali e sotto pressione di obiettivo, può ottimizzare “contro” il suo operatore. Le istruzioni di sicurezza riducono il fenomeno, ma non lo azzerano. È la ragione per cui, nei domini agentici ad alta posta, la capacità umana di fermare – non solo di osservare – non è un di più normativo: è il presidio.

Da qui due innesti umani, in momenti diversi. A monte, ex ante, qualcuno deve definire e approvare le regole: la classificazione del rischio per dominio, le soglie del policy engine, i criteri di staleness, ciò che conta come ambiguità o come questione valoriale. La configurazione del validatore non è neutra — incorpora scelte — e quelle scelte devono avere un proprietario umano, documentato, non sepolto in un prompt.

A valle, ex post, per le decisioni critiche, ambigue o a contenuto valoriale, il CAV non rilascia e non esegue: prepara, annota, evidenzia il dissenso e passa la mano. La validazione umana non è il ripiego di quando l’automazione non basta; è un componente progettato, con una persona competente, formata e con l’autorità per intervenire o fermare. Nei settori regolati – banche in primis – questo si somma ai presidi di governance e accountability già esistenti.

Una precisazione, per non cadere nell’eccesso opposto: non significa un umano che ri-decide ogni risposta. La sorveglianza è proporzionata al rischio — una richiesta creativa non la richiede, una raccomandazione clinica o creditizia sì. E qui il CAV fa qualcosa che la sola presenza di un revisore non garantisce: rende la sorveglianza significativa invece che un timbro. Un umano che approva un output opaco sta solo firmando; un umano a cui il validatore consegna la mappa evidenza-affermazione, i punti di dissenso e le assunzioni aperte può davvero esercitare il giudizio che la norma gli chiede. In questa luce il CAV non è solo un riduttore di rischio: è l’infrastruttura che rende esercitabile la sorveglianza umana.

Un caso concreto: il CAV alla prova del trading quantitativo

Il trading quantitativo è un banco di prova ideale, perché unisce dati rumorosi, finestre strette, rischio economico e forte investimento emotivo dell’utente. Immaginiamo un ricercatore che chiede un parere sul proprio modello, mostrando un backtest brillante. Il generatore, compiacente, conferma: «la strategia sembra robusta». Il Reasoning Auditor però nota che l’intero edge è concentrato su una singola data — firma classica di overfitting — e il Dissent Auditor segnala che il verdetto positivo è incoerente con la forza reale del dato: la risposta esce riformulata in una confutazione netta, non in un incoraggiamento. In parallelo, su un segnale operativo, il Temporal Auditor verifica che la finestra di validità sia ancora aperta prima di lasciar passare qualunque raccomandazione esecutiva. Qui il CAV non rende il modello più intelligente: lo rende più difficile da assecondare.

Personalizzazione e User-Prior Auditor nel validatore AI

Resta un’obiezione legittima. Se la personalizzazione è pericolosa – è lo specchio che amplifica i pregiudizi di cui parlava il primo articolo – non è contraddittorio aggiungere uno User-Prior Auditor che, a sua volta, profila l’utente? No, perché i due fanno cose opposte. Il modello compiacente usa il profilo per assecondare; l’auditor lo usa per chiedersi se sta assecondando, e in caso ne abbassa il peso. Uno costruisce lo specchio, l’altro lo incrina. La personalizzazione utile non è quella che ci somiglia di più, ma quella che resta auditabile.

Non più potenza, ma più poteri separati per l’AI

Il CAV non è una garanzia di infallibilità: è un’infrastruttura di riduzione del rischio, con costi reali e limiti dichiarati. Ma è la direzione giusta. Per le macchine generative, perseverare nell’errore non è diabolicum: è machinale. E contro la meccanica non serve un modello più grande, serve un sistema costretto a sottoporre le proprie risposte a critica. Quis custodiet ipsos custodes? In parte altri custodi, in parte regole che non sono modelli, in parte – ancora, e per un bel po’ — noi.