Categoria: Ethics and Sustainability

Pubblicato il

Architettura di Guardrail Multi-Agente

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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:

  1. Irreversibility — can this be undone if wrong?
  2. Scope of harm — who or what could be affected, and how
    severely?
  3. Certainty — is the Worker’s reasoning actually sound, or does
    it contain gaps, unjustified assumptions, or overconfidence?
  4. 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: rischioVerifier: verdettoAzione del Manager
low / mediumAPPROVEEsegue autonomamente (con log)
low / mediumREJECTRichiede revisione al Worker
low / mediumESCALATE_TO_HUMANEscalation a supervisore umano
high / catastrophicqualsiasiSempre 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.

Pubblicato il

Fostering ethical machine learning

If there is a sport that, in my opinion, can serve well to explain how machine learning works, it’s tennis. Training requires thousands of balls, and it’s estimated that over ten years of practice, more than a million shots are played.

Why, then, do even professional players sometimes miss seemingly easy shots during matches when their error rate in training is often much lower? This is a typical case of overfitting, where the model has been generated from countless balls played, mostly of the same type, hit by the coach or trainer, while during a tournament, players encounter opponents and game situations that are very different—some never seen before.

Styles of play, speed, ball spin, and trajectories can be entirely different from those seen in training. Personally, I think I’ve learned more from matches I lost miserably than from months of training with similar drills. No offense to coaches and trainers—they know it well themselves, having built their experience largely through hundreds of tournaments and diverse opponents.

The similarity with machine learning is quite obvious. Machine learning, like tennis, requires preparation based on experience and the ability to adapt to unforeseen contexts. A model trained on overly homogeneous data may seem very effective during training but fail to recognize new situations—a limitation that only diverse exposure can overcome. Just as a tennis player grows stronger by facing opponents with different styles, a machine learning model improves with data that reflects the variety and complexity of the real world.

In both cases, improvement doesn’t come solely from mechanical repetition but from iterative learning, analyzing errors, and refining strategies. Each mistake, each failure, is a step toward a more resilient and capable system—or player. This is the key to overcoming the limits of overfitting and building skills that go beyond mere memorization, allowing excellence in unexpected conditions.

Now let’s move on to the part that interests us the most: biasing. By its nature, an explainable machine learning algorithm (for example, a decision tree) generates models that must “split” on attributes. At some point within the tree (unless the tree’s depth is reduced to avoid this situation), a decision will have to be made based on the value of an attribute, which could lead to discrimination based on gender, age, or other factors.

Less explainable algorithms produce results that evaluate all variables simultaneously, thus avoiding decisions based on a single variable. However, there are methodologies (like Shapley values or insights such as those from Antonio Ballarin https://doi.org/10.1063/5.0238654) that allow verification of the impact of a single variable’s variation on a particular target value.

In short, no matter how balanced the dataset is and how low the impact of the observed variable on the target is, there will always be slight biasing in the generated model. A temporary solution, considering the tennis example, is to eliminate the variable that could cause the model to behave in ways deemed unethical (e.g., age, gender, nationality) and construct an initial model that is certainly less accurate than one using all variables but usable from day one.

As the model learns, increasingly de-biased data will be provided (data must be filtered at the source, balancing the number of cases, for instance, between genders). Meanwhile, the algorithm (which at this point won’t know the value of the excluded attribute because it doesn’t exist) will update the model, enabling it to generalize more and more—like an athlete participating in a large number of tournaments.

Pubblicato il

Ethics of algorithms or data? Or how they are used?

By now, we are all aware of the potential of AI and, to some extent, the risks associated with its unethical use.

However, I would like to bring attention to a use case that might change the perception of what is ethical and what the definition of ethics entails.

A well-known open dataset from UCI includes the characteristics of employees in a company, and among the attributes, there is a variable that can be used as a target, representing the status of the employee (attrition: yes or no).

The objective could be to pay more attention to employees who, according to the model, appear to be at higher risk of attrition, and this goal might alter the concept of ethics (which, by the way, is not uniform across communities, cultures, or contexts). For example, dataset bias related to attributes like gender or age in this case could help focus more on the disadvantaged groups (here meant as attributes). This is just a different point of view and it doesn’t necessarily mean it’s an ethical approach (e.g. somebody may object that a model built on this data would allow for retaining just resources with high scores in performance reviews).

Below is an analysis of the dataset that highlights some interesting aspects, such as the importance of certain attributes that may not be intuitively significant, or vice versa. For instance, after removing the employee number, which represents an identity, monthly salary ranks only fifth in importance, while gender is among the least important, thus having minimal influence on the target variable.

By breaking down according to the maximum value of Gini impurity 2p*(1-p), a binary tree is constructed in this way and shown in figure.

The second variable to observe is precisely OverTime, which also represents the dependency of attrition on the overtime value recorded for the employee. In this case we use a CNN and shapley values to determine dependence of the target from independent variables.

Finally, we must note that age has strong impact on the decision, but it is quite fragmented and it is selected to separate very well the classes close to the leaves. Here below two examples of clear separation between the two classes.

Edited by G.Fruscio

Privacy Policy Proudly powered by WordPress