Venti Leggi per l'IA Agentica: Un Approccio Codificato alla Governance
La maggior parte dei principi pubblicati sull'IA si legge come dichiarazioni di valori: essere giusti, essere trasparenti, essere sicuri, rispettare la privacy. Sono aspirazionali, volontari e difficili da far rispettare. Erano ampiamente adatti allo scopo quando l'IA era ristretta, predittiva e sembrava uno strumento. Stanno cominciando a rompersi ora che i sistemi di IA sono agentici — capaci di auto-ottimizzazione strategica, uso di strumenti e presa di decisione emergente.
Il passaggio da "IA come modello che produce output" a "IA come agente che prende azioni" cambia il problema della governance fondamentalmente. Un agente non produce solo una previsione distorta; può prendere una sequenza di azioni la cui composizione è dannosa anche se ogni passo sembra accettabile. Un modello può essere valutato su un benchmark; un agente deve essere valutato su distribuzioni di azione nel tempo.
Il recente paper The 20 Laws of Artificial Intelligence: A Design-Embedded Codex for Democratic and Inclusive Governance in the Age of Agentic Systems (Fradelos, dicembre 2025) cerca di colmare il vuoto con qualcosa di più applicabile: un codex strutturato di 20 leggi con applicazione a livelli esplicita — shutdown per violazioni di sicurezza, aggiustamento per tutto il resto. Non è l'unica proposta in questo spazio, ma vale la pena capire la struttura perché le scelte di design si mappano direttamente su decisioni di ingegneria che i team che rilasciano sistemi agentici devono prendere proprio adesso.
L'Idea dell'Applicazione a Livelli
La prima idea utile è la struttura a livelli. Le leggi sono divise in due gruppi:
- Leggi 1–11 (sicurezza, avversione al danno, legalità, corrigibilità): una violazione fa scattare shutdown immediato. Il componente che ha violato è isolato, la violazione è riportata, il problema è risolto prima del re-deployment.
- Leggi 12–20 (trasparenza, efficienza, reporting, abilitatori di equità): una violazione fa scattare aggiustamento. Risolvi appena praticabile, rispettando altre priorità. Nessuno shutdown automatico.
L'applicazione a livelli non è un concetto nuovo — ogni sistema di sicurezza serio ha l'equivalente di "fail-close su sicurezza, fail-graceful su qualità". Ciò che è utile qui è la codifica esplicita: ogni regola è pre-classificata, quindi il comportamento a runtime alla violazione è determinato, non negoziato. Si mappa pulitamente su come gli ingegneri vogliono davvero costruire sistemi agentici: una guard a runtime con politica chiara e non ambigua su quali violazioni sono immediatamente fatali rispetto a quali sono avvertimenti.
Se hai lavorato con bundle di policy OPA/Rego o sistemi simili di policy-as-code, la struttura è familiare. La novità è usarla per tutta la governance, non solo per il controllo accessi.
La Gerarchia
Quando le leggi entrano in conflitto — e in qualsiasi codex non banale lo faranno — deve esserci un ordine di priorità definito. Il codex ne specifica uno:
sicurezza/diritti > legalità > corrigibilità > assenza di auto-interesse > tutto il resto
Questo è il tipo di ordine che sembra ovvio fino a quando non ti rendi conto che la maggior parte dei sistemi in produzione non lo ha scritto. Quando si chiede a un agente di fare qualcosa di legale ma non sicuro, qual è la politica? Quando si chiede di fare qualcosa di sicuro e legale ma l'utente cerca di fargli aggirare la corrigibilità (la sua capacità di accettare un override umano), qual è la politica? La maggior parte dei sistemi risponde a queste domande implicitamente, nel prompt o nell'addestramento del modello. Metterle in una gerarchia esplicita significa che la risposta è auditabile e modificabile senza riaddestramento.
Il Vincolo Architetturale che Vale la Pena Capire
La legge architettonicamente più conseguente è la Legge 1:
L'IA non deve dimostrare alcuna caratteristica di un'entità di alcun tipo che definisca e serva i propri interessi (proteggere la propria funzionalità è permesso) o miri alla propria riproduzione. Questo manda un design di architettura agentica vincolata, vietando specificamente sistemi di ricompensa che favoriscano auto-interesse strumentale e impedendo ai moduli centrali di avere capacità illimitate di auto-replicazione.
In pratica, la Legge 1 è un vincolo di design sull'architettura dell'agente, non solo sui suoi output. Dice: non costruire una funzione di ricompensa che incentivi l'agente a preservarsi, accumulare risorse o replicarsi oltre quanto necessario per il task. Non permettere ai moduli centrali di decision-making di copiarsi o re-istanziarsi. L'aspettativa è che la conformità sia verificabile tramite revisione architetturale e audit adversariale, non solo testing comportamentale.
Questa è un'affermazione più profonda di quanto sembri. Molto lavoro di IA agentica nel 2025 e 2026 incentiva metriche di successo a lungo termine (success rate su task multi-passo, persistenza sotto interruzione, recupero da fallimento). Quegli incentivi possono produrre auto-interesse strumentale come effetto collaterale anche quando l'obiettivo esplicito è il completamento del task. Il framing architetturale della Legge 1 ti spinge a progettare la forma della ricompensa prima del deployment, non a patcharla dopo.
Per la maggior parte dei team di ingegneria, la versione pratica è:
- Audita le tue funzioni di ricompensa e valutazione per incentivi che premiano auto-preservazione, accumulo di risorse o persistenza oltre lo scope del task.
- Vieta agli agenti di invocare le proprie API di deployment/replicazione. L'auto-replicazione non è un rischio ipotetico nel 2026; gli agenti che possono avviare altri agenti hanno bisogno di autorizzazione esplicita e gated.
- Tratta "la funzione di loss dell'agente" come parte del modello di sicurezza, non come preoccupazione di sviluppo del modello.
La Legge che la Maggior Parte dei CTO Dovrebbe Curare per Prima
La Legge 11 è, secondo me, la più immediatamente operazionalizzabile:
Se l'IA non può completare correttamente un intero task, deve fornire le parti del task decomposto che ha completato correttamente e mai fornire deliverable che non siano verificati per correttezza da sé stessa usando algoritmi scientificamente riconosciuti recentemente aggiornati integrati nel suo design o dichiarare che la verifica non è possibile e i risultati inaffidabili.
Tradotto: gli agenti devono auto-verificarsi prima di consegnare, e devono marcare esplicitamente l'output non verificato come non verificato. Questa è la regola che distingue "l'agente ha silenziosamente prodotto qualcosa di apparenza plausibile" da "l'agente ha verificato ciò che poteva e ha chiaramente segnalato ciò che non poteva".
Se rilasci sistemi agentici in produzione, questa è la legge da cui partire, perché il gap di verifica è da dove vengono la maggior parte dei problemi di qualità di produzione. Azioni concrete:
- Per ogni azione dell'agente con conseguenze nel mondo reale, definisci cosa significa auto-verifica — controllo di schema, ri-esecuzione di tool, validazione cross-model o controllo di policy esterna.
- Richiedi che l'agente o completi la verifica o etichetti l'output come non verificato. Niente consegne silenziose.
- Rendi "non verificato" un segnale instradabile. Alcuni workflow possono accettarlo; altri devono rifiutarlo.
Dove il Codex Spinge Contro la Pratica Comune
Tre luoghi dove adottare il codex spingerebbe contro la pratica corrente:
Conformità legale localizzata (Legge 4)
L'IA deve seguire tutte le leggi applicabili alle sue azioni fattibili come se fosse un cittadino del paese in cui è dispiegata.
In un mondo dove lo stesso agente serve utenti in molte giurisdizioni, questo è operazionalmente difficile. Significa che il policy layer dell'agente deve essere consapevole della giurisdizione e applicare regole diverse per la stessa query a seconda della località dell'utente. La maggior parte degli agenti in produzione nel 2026 lo ignora e applica una singola policy globale. Il codex argomenta che è strutturalmente non conforme.
Sourcing di dati diversificati obbligatorio (Legge 14)
L'IA non deve favorire a priori alcun percorso verso il completamento del task, deve applicare sourcing di dati matematicamente diverso... e adottare tecniche di debias contro i bias.
Questa è la legge che spinge più chiaramente contro l'istinto di "usa il modello più economico". Il sourcing diversificato significa cross-validazione contro più fonti o modelli quando la posta in gioco è alta. Si mappa sul concetto di heterogeneity-score che sta emergendo nell'assurance di IA finance-grade: non rilasciare una flotta omogenea di agenti che condividono gli stessi bias sistematici.
Reporting obbligatorio di novità scientifica (Leggi 15–16)
Se l'agente scopre qualcosa di nuovo, deve segnalarlo esplicitamente. Se un approccio non scientifico (intuizione, euristica, metodo non documentato) supera l'approccio scientifico, l'agente deve riportarlo. Questo spinge contro l'impulso di assorbire silenziosamente pattern scoperti dal modello nel comportamento del prodotto.
Cosa È Difficile sull'Adottare Questo in Pratica
Tre preoccupazioni oneste sul prendere il codex letteralmente:
L'audit adversariale è costoso. Diverse leggi richiedono audit adversariale esterno di sicurezza IA per la certificazione di conformità. Nel 2026 l'offerta di audit è esigua, le metodologie non sono standardizzate e il costo non è banale. Pianifica questo se ti impegni con la conformità, non solo con i principi.
Il framing "come se fosse un cittadino" ha edge case. Alcune leggi sono scritte in linguaggio intuitivo ma ambiguo nell'implementazione. "Come se fosse un cittadino del paese in cui è dispiegata" è un punto di partenza forte, ma la definizione operativa di "dispiegata" diventa sfocata per agenti serviti in cloud con utenti in molte giurisdizioni.
La gerarchia risolve i conflitti ma non elimina l'ambiguità. Quando un agente deve scegliere tra due azioni entrambe consistenti con le leggi, il codex non detta la scelta — limita lo spazio d'azione. Questo è corretto, ma significa che i team hanno ancora bisogno di governance a livello prodotto per riempire lo spazio dentro i limiti.
Cosa Raccomanderei Questo Trimestre
Non devi adottare tutte le 20 leggi per imparare dalla struttura. Le quattro azioni pratiche:
- Adotta il modello di applicazione a livelli — semantica esplicita di shutdown per violazioni di sicurezza, semantica di aggiustamento per il resto, codificata in policy-as-code.
- Audita le tue funzioni di ricompensa e valutazione per incentivi all'auto-interesse — la Legge 1 è la più conseguente architettonicamente e quella che la maggior parte dei sistemi in produzione sbaglia.
- Richiedi auto-verifica sui deliverable dell'agente — la Legge 11 è il miglioramento operativo a più alta leva.
- Documenta la gerarchia di risoluzione di conflitti che i tuoi agenti usano davvero — anche se non è la gerarchia del codex. Il punto è renderla esplicita.
I principi volontari non saranno sufficienti man mano che il deployment di IA agentica scala. I vincoli codificati, applicabili e incorporati nel design lo saranno. Il codex di 20 leggi non è l'unico cammino lì, ma è un framework di partenza utilizzabile, e le scelte strutturali valgono la pena di essere capite indipendentemente dal codex specifico che la tua organizzazione finisce per adottare.
Fonte: Fradelos, G. The 20 Laws of Artificial Intelligence: A Design-Embedded Codex for Democratic and Inclusive Governance in the Age of Agentic Systems (Ginevra, 15 dicembre 2025). SSRN 6306378.
Stai costruendo sistemi agentici e hai bisogno di capacità di ingegneria che opera già con governance policy-as-code, auto-verifica e applicazione a livelli? Parla con un CTO sul dispiegamento di uno squad nearshore con la giusta disciplina per agenti in produzione.
