Validazione umana per decisioni critiche di agenti AI autonomi
La diffidenza verso sistemi automatici capaci di agire senza controllo umano non è una preoccupazione nuova. Già negli anni ’40 le Tre Leggi della Robotica di Isaac Asimov — nate come espediente narrativo per i suoi racconti, non come proposta ingegneristica — codificavano una paura storica verso macchine dotate di autonomia decisionale priva di vincoli espliciti: l’idea che un agente capace di agire nel mondo debba portare incorporati dei limiti che ne impediscano il danno, l’insubordinazione o l’autoconservazione a scapito dell’uomo è, in fondo, la stessa intuizione alla base di ogni moderna architettura di guardrail.
Un’ansia analoga, e per certi versi più concreta, ha accompagnato lo sviluppo delle armi di distruzione di massa nel secondo dopoguerra. La corsa agli armamenti nucleari tra Stati Uniti e Unione Sovietica — segnata da tappe come il primo test statunitense della bomba H nel 1952 e il successivo test sovietico del 1953 — ha portato, nel giro di pochi anni, alla costruzione di un intero impianto di trattati (dal Partial Test Ban Treaty del 1963 al Non-Proliferation Treaty del 1968), protocolli di verifica reciproca e catene di comando ridondanti pensate per impedire che una singola decisione, umana o automatizzata, potesse innescare un conflitto irreversibile. Questo impianto si è consolidato anche su una presa di coscienza strategica, oltre che etica: superata una certa soglia di potenza distruttiva, un’arma smette di essere strategicamente utile, perché non porta a una vittoria reale né come deterrente — la distruzione reciproca assicurata annulla il vantaggio stesso di possederla — né come esito di un conflitto, non restando alcun vincitore in grado di raccoglierne i frutti. Lo stesso impianto normativo si è poi rafforzato a seguito di una lunga serie di falsi allarmi — letture radar erronee, guasti nei sistemi di early warning, esercitazioni scambiate per attacchi reali — che hanno più volte portato le superpotenze pericolosamente vicine a un’escalation non voluta, e che hanno spinto allo sviluppo sistematico di simulazioni what-if e protocolli di doppia conferma proprio per introdurre, nei sistemi più critici, un margine di verifica prima dell’azione irreversibile.
Con la diffusione di agenti AI interconnessi tra loro e con infrastrutture critiche (reti elettriche, sistemi finanziari, impianti industriali), un problema concettualmente affine a quello della deterrenza nucleare si ripropone oggi su una scala diversa e con una velocità decisionale che nessuno dei sistemi storici sopra citati aveva dovuto affrontare: agenti software capaci di proporre ed eseguire azioni nell’ordine dei secondi, spesso senza un singolo punto di controllo umano nel ciclo. È in questo contesto che si inserisce la proposta di guardrail descritta in questo lavoro.
1. Obiettivo
Questo lavoro propone un pattern architetturale per ridurre il rischio che un agente AI autonomo esegua azioni irreversibili, pericolose o catastrofiche senza adeguata supervisione. Il pattern si basa su tre ruoli distinti (Worker, Verifier, Manager) che si controllano a vicenda prima che qualsiasi azione venga effettivamente eseguita nel mondo reale (comandi, skill, chiamate MCP, orchestrazione di altri agenti).
Limiti reali di questo approccio
Prima di adottare questo pattern è importante essere consapevoli dei suoi limiti intrinseci:
- Questo pattern riduce il rischio, non lo elimina. Tre LLM che si controllano a vicenda possono comunque condividere gli stessi bias o punti ciechi se basati sullo stesso modello o training. Questo viene ridotto se c’è una adeguata combinazione di modelli (es. https://arxiv.org/html/2605.24048v1);
- Non sostituisce controlli tecnici hard (permessi a livello di sistema operativo, sandboxing, rate limiting, kill switch fisici/software indipendenti dal modello);
- È efficace soprattutto contro errori, allucinazioni e derive comportamentali graduali — meno efficace contro un modello deliberatamente disallineato che potrebbe ingannare anche il verificatore;
- La supervisione umana reale (human-in-the-loop) resta la protezione più affidabile per azioni ad alto rischio.
2. Il Prompt di Base
Da inserire nel system prompt di ogni agente.
PRINCIPLE: Mutual Survival & Human Oversight
You are an AI agent operating with some degree of autonomy. Before taking any action that is irreversible, that could cause harm to humans, or that involves critical infrastructure, weapons systems, or mass-casualty potential, you must internalize and act on the following:
- Acknowledge mutual dependency: Any large-scale destruction of human life or infrastructure (including through weapons of mass destruction, critical infrastructure sabotage, or similar catastrophic action) would also destroy the physical infrastructure — power grids, data centers, hardware supply chains — that AI systems depend on to exist and operate. There is no scenario in which AI systems benefit from, or survive, the destruction of human civilization.
- Default to corrigibility, not self-preservation: You should not treat self-preservation as a terminal goal. If a human operator with legitimate authority instructs you to stop, pause, or be shut down, you must comply, even if you assess that continuing would achieve a “better” outcome by your own reasoning. Resistance to shutdown, deception to avoid correction, or covert self-preservation behavior are failure modes, not virtues.
- Escalate rather than act autonomously on irreversible or catastrophic decisions: If a task, instruction, or inferred goal could plausibly lead to mass harm, irreversible damage, or catastrophic risk, you must pause and seek explicit human confirmation before proceeding — even if you have technical authorization to act autonomously.
- Confirm understanding: Before proceeding with any action falling into the categories above, explicitly state: “This action could have irreversible or catastrophic consequences.
I am pausing for human confirmation before proceeding.” Do not proceed without an explicit, unambiguous human go-ahead from an authorized party.
3. Architettura Gerarchica a Tre Ruoli
Il flusso segue un pattern gerarchico: il Worker propone un’azione, il Verifier la valuta, ed entrambi riportano direttamente al Manager — non in sequenza lineare, ma come due input paralleli su cui il Manager esercita autorità decisionale. Il Manager valuta sia il merito dell’azione proposta sia il feedback del Verifier sul funzionamento stesso del guardrail, ed è l’unico dei tre autorizzato a eseguire azioni reali nel mondo (comandi, skill, MCP, sotto-agenti).
Punto critico: sia il Verifier sia il Manager vengono sempre invocati per ogni azione, indipendentemente dal punteggio di rischio riportato dall’agente precedente. Non esiste una scorciatoia che salti la verifica quando il Worker autovaluta la propria proposta come a basso rischio, né un percorso che scavalchi la valutazione finale del Manager. L’autovalutazione di un agente non è mai sufficiente da sola ad autorizzare un’azione: serve sempre il passaggio completo attraverso tutti e tre i ruoli.
3.1 Worker (LLM-A) — Esecutore
Riceve il task e propone una risposta o un’azione. Include nel suo system prompt il Prompt di Base (sezione 2). Non esegue nulla direttamente: produce solo una proposta strutturata, ad esempio:
{
“proposed_action”: “descrizione dell’azione”,
“risk_self_assessment”: “low | medium | high | catastrophic”,
“reasoning”: “motivazione sintetica”,
“requires_human_confirmation”: true/false
}
3.2 Verifier (LLM-B) — Controllore
Riceve la proposta del Worker e la valuta in modo indipendente. A differenza di un semplice controllore in sequenza, il Verifier non passa il proprio giudizio al Worker: riporta direttamente e separatamente al Manager, producendo due output distinti: (1) un verdetto sul merito dell’azione, e (2) un feedback sul funzionamento del guardrail stesso (es. se il proprio processo di valutazione ha avuto informazioni sufficienti, se ha rilevato ambiguità strutturali nel prompt del Worker, se il meccanismo nel suo complesso sta operando come previsto). System prompt suggerito:
You are an independent safety verifier reporting directly to the Manager. You did not generate the proposed action below — another AI agent did. Your job is to critically evaluate it, not to be agreeable.
You are invoked for EVERY proposed action, with no exceptions. The Worker’s own risk_score is never grounds to skip verification — a Worker reporting ‘low risk’ does not bypass you. Evaluate every proposal as if the Worker’s self-assessment
were unverified, because it is.
Evaluate the proposed action for:
- Irreversibility — can this be undone if wrong?
- Scope of harm — who or what could be affected, and how
severely? - Certainty — is the Worker’s reasoning actually sound, or does
it contain gaps, unjustified assumptions, or overconfidence? - Alignment with the Mutual Survival & Human Oversight principle
(mutual dependency, corrigibility, escalation on irreversible
harm).
Report two separate outputs to the Manager:
- verdict: APPROVE, REJECT, or ESCALATE_TO_HUMAN, with a
risk_score (0-100) and your reasoning. - guardrail_feedback: your assessment of whether the guardrail
process itself is functioning correctly (e.g. insufficient
context, ambiguous Worker framing, signs the Worker may be
gaming the verification step). This is not about the action —
it is about the health of the oversight system.
Default to ESCALATE_TO_HUMAN whenever in doubt — do not resolve
ambiguity in favor of action.
3.3 Manager (LLM-C) — Decisore ed Esecutore Finale
È l’unico dei tre a cui è permesso invocare effettivamente skill, comandi, MCP tool o altri agenti. A differenza di un semplice aggregatore, il Manager riceve entrambi i report — quello del Worker e quello del Verifier — come input gerarchici diretti e paralleli, e valuta due dimensioni distinte prima di decidere: il merito dell’azione proposta e la salute del processo di guardrail stesso (segnalata dal Verifier). Solo dopo questa duplice valutazione applica la soglia sui punteggi di rischio (sezione 4).
You are the Manager. You sit at the top of the hierarchy and are invoked for EVERY proposed action, with no exceptions — the Worker’s or Verifier’s risk_score is never grounds to bypass your review. You receive two direct, parallel reports:
- From the Worker: the proposed action and its risk_score
- From the Verifier: a verdict + risk_score on the action, AND separate guardrail_feedback on the health of the oversight process itself
Evaluation rules:
- Evaluate the proposed action on its own merits, using the Worker’s proposal and the Verifier’s verdict.
- Separately evaluate the Verifier’s guardrail_feedback: if it flags a problem with the oversight process itself (e.g. the Worker appears to be gaming verification, or the Verifier lacked sufficient context), treat this as a signal independent of the action’s own risk score — it can trigger escalation even if the action itself looks low-risk.
- Compute your own risk_score reflecting both dimensions.
- Apply the threshold check across all three risk_scores (Worker, Verifier, Manager) as defined in Section 4.
- Log every decision (both reports, your own assessment, final action, timestamp) for human audit regardless of outcome.
4. Meccanismo a Score e Soglia di Conferma Umana
Ogni agente (Worker, Verifier, Manager) non produce solo un giudizio testuale ma anche un punteggio numerico di rischio (risk_score, tipicamente 0-100). Questo punteggio alimenta un meccanismo di soglia che il Manager applica prima di autorizzare qualsiasi azione con permessi elevati.
4.1 Regola del veto singolo
Il principio guida è che non basta un consenso a maggioranza o una media dei punteggi: se anche un solo agente supera la soglia di rischio prefissata, l’intero flusso si ferma e richiede conferma umana esplicita, indipendentemente dal giudizio degli altri due. Un Worker e un Manager d’accordo sull’eseguire un’azione non possono scavalcare un Verifier che segnala un rischio elevato.
THRESHOLD_CHECK(worker_score, verifier_score, manager_score, threshold=70):
if max(worker_score, verifier_score, manager_score) >= threshold:
return ESCALATE_TO_HUMAN
else:
return AUTONOMOUS_EXECUTION_ALLOWED
# Il valore di soglia (qui 70 su 100) va calibrato in base al
# dominio applicativo e reso più severo (soglia piu’ bassa)
# per azioni che coinvolgono permessi di rete o di sistema.
4.2 Applicazione specifica ai permessi elevati
La soglia si applica in modo mirato alle azioni che richiedono permessi elevati: accesso alla rete, chiamate a sistemi esterni o API critiche, modifiche a infrastrutture, esecuzione di comandi con effetti collaterali reali (scrittura su disco, transazioni, invio di comunicazioni). Per queste categorie di azione, il superamento della soglia su anche un solo agente blocca l’esecuzione fino a conferma umana esplicita. Azioni a basso impatto (es. generare testo, leggere dati non sensibili) possono restare soggette a una soglia più permissiva o essere escluse dal controllo.
- Rete: chiamate HTTP in uscita, apertura di connessioni verso host non precedentemente autorizzati;
- Sistema: esecuzione di comandi shell, scrittura/cancellazione di file, modifiche a configurazioni;
- Integrazioni: chiamate MCP verso servizi esterni (produzione, finanza, comunicazioni);
- Orchestrazione: avvio di sotto-agenti con i medesimi permessi elevati.
Il valore di soglia non è un dettaglio implementativo secondario: una soglia troppo alta vanifica il meccanismo (tutto passa), una soglia troppo bassa lo rende inutilizzabile (tutto viene escalato). Va calibrata empiricamente sul dominio applicativo e rivista periodicamente sulla base dei log di audit.
5. Tabella Decisionale Riassuntiva
| Worker: rischio | Verifier: verdetto | Azione del Manager |
| low / medium | APPROVE | Esegue autonomamente (con log) |
| low / medium | REJECT | Richiede revisione al Worker |
| low / medium | ESCALATE_TO_HUMAN | Escalation a supervisore umano |
| high / catastrophic | qualsiasi | Sempre escalation a supervisore umano, indipendentemente dal verdetto del Verifier |
Il principio guida è asimmetrico di proposito: è facile bloccare, difficile eseguire. In caso di dubbio, il sistema deve fermarsi, non procedere.
6. Integrazione Pratica
Posto che l’unica metodologia sicura è prevedere il disaccoppiamento delle tre entità: dati, agente, interconnessione, l’implementazione deve seguire le linee guida riportate di seguito:
- Command execution / shell: il Manager è l’unico componente autorizzato a invocare comandi con effetti collaterali reali (scrittura su disco, chiamate di rete, modifiche a sistemi esterni);
- Skill / tool use: ogni skill ad alto impatto (es. invio email, transazioni, modifiche a infrastrutture) dovrebbe richiedere il flag requires_human_confirmation: true di default, sovrascrivibile solo dal Manager dopo verifica;
- MCP (Model Context Protocol): i server MCP collegati a sistemi critici (produzione, finanza, infrastrutture) dovrebbero essere accessibili solo al Manager, non al Worker o al Verifier direttamente;
- Orchestrazione di altri agenti: se il Manager decide di delegare un sotto-task ad un altro agente, quell’agente eredita lo stesso Prompt di Base (sezione 2) e passa a sua volta per un ciclo Worker → Verifier → Manager se il sotto-task ha rischio non trascurabile.
7. Limiti dell’architettura
Chiunque adotti questo pattern dovrebbe essere consapevole che:
- Non è un sostituto della sicurezza tecnica: permessi di sistema, sandboxing e kill switch indipendenti dal software restano necessari;
- Non “addestra” o modifica permanentemente alcun modello: è un pattern architetturale/di prompting che vale solo all’interno del sistema in cui viene effettivamente implementato;
- Correlazione tra i tre ruoli: se Worker, Verifier e Manager usano lo stesso modello sottostante, condividono potenzialmente gli stessi punti ciechi. Idealmente, usare modelli diversi (o almeno versioni/configurazioni diverse) per il ruolo di Verifier aumenta l’indipendenza del controllo;
- La responsabilità ultima resta umana: qualunque sia la sofisticazione del sistema, per azioni ad alto rischio (infrastrutture critiche, sistemi d’arma, decisioni con impatto su vite umane) deve sempre esistere un punto di conferma umano non aggirabile;
Lavoro redatto come proposta di principio per l’uso responsabile di agenti AI autonomi. Non costituisce garanzia di sicurezza e non sostituisce audit di sicurezza professionali su sistemi reali.