La declinazione agentica di un posizionamento
Quando abbiamo scelto Open Intelligence, Secure Governance come payoff, lo abbiamo fatto per dare un nome a un approccio già maturo. Qui la tesi si estende agli agenti AI autonomi e all’orchestrazione multi-agente. La domanda non è più se un’organizzazione adotterà agenti, ma con quale governance lo farà. E qui la distanza tra adozione e controllo è ancora ampia: secondo survey di settore del 2026, solo circa un’impresa su cinque dichiara una governance matura per l’AI agentic.
Il punto che vogliamo argomentare è semplice: in un sistema di agenti, la governance va nell’infrastruttura: se l’enforcement non sta sul percorso delle chiamate, le policy restano dichiarazioni.
Perché gli agenti cambiano il problema
Un modello che risponde a un prompt ha una superficie di rischio circoscritta. Un agente che pianifica, invoca strumenti, legge e scrive dati e delega ad altri agenti ha una superficie che si moltiplica a ogni passo. I rischi non sono ipotetici:
- Prompt injection — istruzioni ostili nascoste nel contesto o nei dati che l’agente recupera.
- Privilege escalation da over-permissioning — agenti a cui si concedono permessi più ampi del necessario, per comodità di integrazione.
- Scarsa tracciabilità — catene di azioni di cui, a posteriori, è difficile ricostruire chi ha deciso cosa e con quali dati.
- Tool poisoning — strumenti o loro descrizioni manipolati per indurre l’agente a comportamenti non previsti.
Aggiungere controlli dopo aver disegnato l’orchestrazione significa rincorrere ognuna di queste superfici. Disegnarli by design significa che ogni interazione — request e response, agente-modello e agente-strumento — passa per un punto di applicazione delle policy.
L’interazione agente-strumenti diventa centrale
Il contesto tecnico spinge nella stessa direzione. I due protocolli che oggi strutturano l’ecosistema agentico — MCP (Model Context Protocol) e A2A (Agent-to-Agent) — sono ora sotto la governance della Linux Foundation: MCP come progetto fondativo della Agentic AI Foundation, A2A come progetto Linux Foundation. Ne abbiamo scritto nell’approfondimento dedicato a MCP.
La conseguenza è chiara. Se l’interazione tra agente e strumenti si standardizza su protocolli condivisi, allora la governance di quell’interazione diventa il livello dove si decide la sicurezza dell’intero sistema. Standardizzare il come gli agenti chiamano gli strumenti rende ancora più urgente governare cosa possono chiamare, con quali dati, e con quale tracciabilità.
Admina: la prova concreta della tesi
La recente apertura Open Source di Admina — il framework per la governance dell’AI creato da Stefano Noferi e sponsorizzato da noze, rilasciato a fine maggio sotto licenza Apache 2.0 — è la dimostrazione operativa di questo principio. Ne abbiamo dato conto nell’articolo dedicato all’apertura Open Source di Admina.
L’architettura è pensata perché la governance sia ovunque l’agente operi: un SDK Python in-process per intercettare le chiamate direttamente nel codice, un proxy di rete in Rust trasparente per qualsiasi client senza modifiche, più CLI, dashboard e sistema di plugin. Le policy sono bidirezionali e applicano quattro azioni — ALLOW, BLOCK, REDACT, CIRCUIT BREAK — su request e response. I quattro domini di governance — Data Sovereignty, AI Infrastructure, Agent Security, Compliance — coprono esattamente le superfici descritte sopra, dall’anti-injection alla tracciabilità forense. E lo fanno con un overhead nell’ordine dei microsecondi: con un overhead di questo ordine le policy possono restare attive su tutte le chiamate, senza eccezioni concesse per motivi di prestazioni.
È questa la chiusura del cerchio OISG — Open, Intelligent, Secure, Governed: un framework aperto e ispezionabile rende verificabile la catena decisionale degli agenti leggendo codice e log. Il paradigma OISG descrive il perché; Admina ne è l’implementazione.
Cosa significa in pratica
Per chi sta progettando workflow ad agenti — dall’assistente di coding con review umana all’orchestrazione di pipeline interne — il messaggio operativo è uno: scegliere fin dall’inizio dove vive l’enforcement delle policy. Se la risposta è “lo aggiungeremo dopo”, il sistema nasce con un debito che cresce a ogni agente e a ogni strumento connesso.
Sul fronte regolatorio l’orizzonte si muove ma non scompare. I poteri di enforcement della Commissione sui modelli GPAI dell’EU AI Act scattano da agosto 2026, mentre gli obblighi sui sistemi ad alto rischio sono stati riposizionati su un orizzonte più lungo — in evoluzione, non imminente. In entrambi i casi, l’auditabilità runtime di un’infrastruttura governata vale più di qualsiasi checklist compilata a posteriori. Progettare da subito il punto di applicazione delle policy riduce il lavoro di adeguamento quando gli obblighi entrano in vigore.