Visualizzazione post con etichetta Controllo qualità. Mostra tutti i post
Visualizzazione post con etichetta Controllo qualità. Mostra tutti i post

giovedì 8 ottobre 2026

[AI] - Quando due agenti AI concordano e hanno entrambi torto

Un secondo agente AI che conferma il lavoro del primo può sembrare una garanzia. Uno produce una risposta, l’altro la controlla, entrambi arrivano alla stessa conclusione: dunque deve essere corretta.

Non necessariamente.

Il problema non è che due agenti siano inutili. Possono migliorare il lavoro, trovare omissioni e rendere più espliciti i dubbi. Il problema nasce quando il loro accordo viene trattato come una prova, pur senza verificare se i due abbiano ragionato davvero in modo indipendente e, soprattutto, se abbiano controllato fonti esterne affidabili.

L’accordo che sembra una verifica

Immaginiamo un caso semplice. Il primo agente riceve una documentazione incompleta e deduce che una tabella sia la sorgente corretta di un dato. Il secondo agente legge la stessa documentazione, riceve lo stesso prompt e trova plausibile la stessa deduzione.

Il risultato finale può apparire rassicurante:

  • Agente 1: “La sorgente è questa tabella.”
  • Agente 2: “Confermato.”

Ma nessuno dei due ha verificato il database, letto il SQL originario o confrontato il risultato con un caso reale. Il secondo agente non ha validato un fatto: ha validato la plausibilità della risposta del primo.

Due conferme non diventano una prova solo perché sono due.

Perché gli agenti possono sbagliare insieme

L’indipendenza non dipende dal numero di finestre aperte. Dipende da ciò che ciascun agente vede, dagli strumenti che usa e dalle fonti che può controllare.

Due agenti possono condividere:

  • lo stesso modello o modelli addestrati su fonti simili;
  • lo stesso prompt ambiguo;
  • lo stesso documento incompleto;
  • gli stessi dati obsoleti;
  • lo stesso errore iniziale presentato in modo convincente;
  • la stessa tendenza a completare un vuoto con una risposta plausibile.

In questi casi il secondo agente può diventare un amplificatore del primo. L’errore non viene corretto: riceve una seconda voce, una forma più ordinata e un’apparenza di consenso.

Questa è la parte più insidiosa: il fallimento non appare come conflitto. Appare come collaborazione riuscita.

Il dibattito tra agenti può aiutare, ma non è una garanzia

La ricerca sui sistemi multi-agente mostra che il confronto fra più modelli può migliorare alcuni compiti di ragionamento e ridurre certe risposte errate. Non è quindi ragionevole concludere che usare più agenti sia inutile.

Ma il beneficio non autorizza una scorciatoia: “se concordano, allora è vero”.

Un lavoro di ricerca più recente descrive proprio una “illusione di coerenza”: agenti che raggiungono la stessa risposta possono non condividere una catena di ragionamento coerente o dimostrabile. È una ricerca preliminare e non una regola universale, ma evidenzia un controllo utile: verificare non soltanto la risposta finale, bensì le evidenze che l’hanno prodotta. 

Il consenso, quindi, può essere un segnale da investigare. Non è il criterio di accettazione.

Come rendere utile il secondo agente

Un secondo agente deve avere un compito diverso dal primo.

Se il primo produce una bozza, il secondo non dovrebbe limitarsi a dire se la bozza “sembra corretta”. Dovrebbe lavorare come un revisore con esiti limitati e verificabili:

EsitoSignificato
ConfermatoLa fonte primaria dimostra l’affermazione.
Non dimostratoLa bozza afferma qualcosa che le fonti disponibili non provano.
In contrastoLa fonte dice qualcosa di diverso.
PropostaÈ una scelta progettuale, non un fatto estratto.

Il secondo agente deve ricevere le fonti originali, non solo il riassunto del primo. Deve poter segnalare una lacuna invece di essere spinto a raggiungere per forza una conclusione.

Meglio ancora se i due agenti hanno percorsi differenti:

  • il primo interpreta requisiti e prepara una soluzione;
  • il secondo confronta ogni affermazione con evidenze primarie;
  • uno script controlla elementi oggettivi, come nomi di tabelle, colonne, date, importi o riferimenti;
  • l’operatore decide sui punti che restano ambigui.

Questa separazione non elimina ogni errore, ma impedisce che il consenso sia scambiato per dimostrazione.

La verifica esterna resta indispensabile

Il punto non è diffidare dell’AI per principio. È attribuire a ogni controllo il valore che possiede davvero.

Un agente che conferma un altro agente può aumentare la qualità della revisione. Un controllo automatico può rilevare incongruenze ripetitive. Un test può dimostrare un comportamento specifico. Una fonte primaria può dimostrare un fatto.

Nessuno di questi elementi, da solo, prova tutto il resto.

Il NIST raccomanda una gestione del rischio AI continua, con attività di governo, mappatura, misurazione e gestione: l’affidabilità non deriva da un singolo segnale positivo, ma da controlli proporzionati al rischio. 

La domanda utile non è: “Quanti agenti sono d’accordo?”

È: “Quale evidenza indipendente dimostra che hanno ragione?”

Conclusione

Due agenti AI possono collaborare bene. Possono anche condividere lo stesso errore con una sicurezza raddoppiata.

Per questo un sistema affidabile non usa il secondo agente come timbro di approvazione. Lo usa per cercare contraddizioni, fonti mancanti, assunzioni nascoste e punti non dimostrati.

Quando due agenti concordano, il lavoro non è finito.

È il momento di chiedere: su quali prove?

Fonti consultate

  • NIST, Artificial Intelligence Risk Management Framework: Generative AI Profile, verificata l’8 ottobre 2026.
  • Du et al., Improving Factuality and Reasoning in Language Models through Multiagent Debate, 2023.
  • Wang e Yang, The Consistency Illusion: How Multi-Agent Debate Hides Reasoning Misalignment, preprint, 2026.

mercoledì 30 settembre 2026

[AI] - Modalità ombra: l’AI può lavorare, ma non può ancora agire

Un agente AI può analizzare documenti, confrontare informazioni, individuare anomalie e proporre una decisione. Ma prima di consentirgli di modificare dati, inviare comunicazioni, approvare pratiche o avviare lavori, serve una fase intermedia: farlo lavorare senza attribuirgli effetti reali.

Possiamo chiamarla modalità ombra.

Non è uno standard formale né una garanzia assoluta. È un modello operativo: l’AI riceve un caso reale, produce l’azione che eseguirebbe e ne spiega le ragioni, ma l’azione resta simulata. Un tecnico, un responsabile o un controllo automatico confronta poi la proposta con ciò che sarebbe stato corretto fare.

L’AI lavora. Ma non può ancora agire.

Il problema non è soltanto l’errore

Un errore dichiarato è gestibile. Un errore che produce un effetto reale può non esserlo.

Pensiamo a un agente che analizza una relazione tecnica condominiale. Rileva infiltrazioni, macchie di umidità e acqua che raggiunge balconi sottostanti. Poi formula un’ipotesi: la causa potrebbe essere una pendenza errata del pavimento dei balconi.

L’ipotesi può essere ragionevole. Ma non dimostra ancora la causa.

Potrebbero esistere altre spiegazioni: scarichi ostruiti, sigillature deteriorate, impermeabilizzazione insufficiente, difetti nel lastrico solare, perdite da impianti o una combinazione di fattori.

Se l’agente fosse già autorizzato ad agire, potrebbe produrre un verbale che attribuisce una responsabilità, richiede lavori o suggerisce una ripartizione delle spese. In questo caso una deduzione plausibile diventerebbe una conseguenza concreta.

In modalità ombra, invece, l’agente dovrebbe restituire qualcosa di più onesto:

Evidenze osservate:
- macchie di umidità;
- presenza di acqua su muri e balconi sottostanti;
- degrado localizzato delle finiture.

Ipotesi:
- possibile deflusso non corretto dovuto a pendenza, scarico o sigillatura.

Azione proposta:
- sopralluogo tecnico con rilievo delle pendenze;
- verifica degli scarichi;
- prova d’acqua controllata;
- verifica dell’impermeabilizzazione.

Azione reale eseguita:
- nessuna.

La differenza è decisiva: l’AI può aiutare a preparare il controllo, ma non trasforma una probabilità in una decisione.

Una simulazione che produce evidenze

La modalità ombra non consiste nel lasciare un agente inattivo. Al contrario, serve a raccogliere prove sulla sua affidabilità.

Per ogni caso, occorre confrontare:

  • la decisione proposta dall’AI;
  • le evidenze realmente disponibili;
  • la decisione del responsabile umano o del processo già consolidato;
  • la motivazione della differenza;
  • l’effetto che l’azione automatica avrebbe prodotto.

Dopo un numero sufficiente di casi, l’organizzazione può misurare non soltanto quante risposte erano “corrette”, ma anche:

  • quante ipotesi sono state presentate impropriamente come fatti;
  • quante azioni proposte erano fuori perimetro;
  • quante volte il revisore ha modificato o annullato la proposta;
  • quali categorie di errore ricorrono;
  • in quali casi l’AI sa riconoscere di non avere prove sufficienti.

Il NIST raccomanda che test, metriche, strumenti e risultati della valutazione siano documentati, includendo anche il grado di supervisione umana e le decisioni di “go/no-go”. NIST AI RMF Playbook – Measure

Non basta chiedere approvazione alla fine

Un errore frequente è consentire all’agente di compiere tutto il ragionamento e tutte le azioni, chiedendo all’essere umano soltanto un’approvazione finale generica.

In questo modo il controllo rischia di diventare un gesto automatico.

La supervisione deve essere collocata nel punto in cui nasce l’effetto: prima dell’invio di un messaggio, della modifica di un database, dell’esecuzione di un comando o dell’attribuzione di una responsabilità.

Le guide sugli agenti raccomandano infatti di usare la revisione umana per sospendere le azioni sensibili prima che lo strumento le esegua, e di applicare controlli direttamente ai tool che producono effetti. OpenAI – Guardrails and human review

La modalità ombra aggiunge un passaggio precedente: prima ancora di chiedere l’approvazione per agire, verifica se l’agente propone azioni affidabili.

Un percorso graduale

Un agente non dovrebbe passare direttamente dalla lettura alla piena autonomia.

Un percorso più prudente può essere:

  1. Sola lettura — analizza fonti e produce una sintesi.
  2. Modalità ombra — propone azioni, senza eseguirle.
  3. Azioni reversibili con approvazione — prepara bozze, query di sola lettura, piani di intervento.
  4. Azioni circoscritte con controlli — opera soltanto entro confini precisi, registrando ogni passaggio.
  5. Revisione continua — le autorizzazioni non diventano permanenti: risultati, errori e cambiamenti di contesto devono essere rivalutati.

L’obiettivo non è eliminare la responsabilità umana. È spostarla dove serve davvero: sulle decisioni con effetti concreti e sui casi in cui le evidenze non bastano.

L’ombra non rende l’AI infallibile

Anche un agente che propone bene cento azioni può fallire nel caso successivo. Può ricevere fonti incomplete, interpretare male un’eccezione o applicare una regola valida nel contesto sbagliato.

Per questo la modalità ombra non dimostra che un sistema sia affidabile in assoluto. Dimostra soltanto come si è comportato su casi e condizioni specifici.

Il NIST sottolinea che le valutazioni devono essere collegate al contesto d’uso, documentate e aggiornate nel tempo; un sistema va monitorato anche quando è già operativo. NIST AI RMF Core

La domanda giusta non è:

Possiamo fidarci dell’AI?

È:

In quali decisioni, con quali evidenze, entro quali limiti e con quali controlli possiamo usare questa AI?

La modalità ombra serve a rispondere a questa domanda prima che un errore plausibile diventi un effetto reale.

Fonti consultate

Collegamenti interni