AI, A2A e il divario di governance
Negli ultimi sei mesi, si è osservato un modello ripetuto nei team di intelligenza artificiale aziendale. A2A e ACP illuminano la stanza durante le revisioni architettoniche: i protocolli sono eleganti e le dimostrazioni impressionanti. Tre settimane dopo il lancio, qualcuno chiede: “Aspetta, quale agente ha autorizzato quel pagamento di $50.000 a un fornitore alle 2 del mattino?” L’eccitazione si trasforma in preoccupazione.
Ecco il paradosso: Agent2Agent (A2A) e il Protocollo di Comunicazione degli Agenti (ACP) sono così efficaci nell’eliminare l’attrito dell’integrazione che hanno rimosso i “freni” naturali che in passato forzavano le conversazioni sulla governance. Abbiamo brillantemente risolto il problema dell’infrastruttura, ma abbiamo creato una nuova classe di debito di integrazione, in cui le organizzazioni prendono in prestito velocità oggi a costo della responsabilità domani.
I protocolli tecnici sono solidi. Tuttavia, i protocolli organizzativi mancano. Ci stiamo rapidamente spostando dalla fase “Possono questi sistemi connettersi?” alla fase “Chi ha autorizzato questo agente a liquidare una posizione alle 3 del mattino?”. In pratica, questo crea un divario di governance: la nostra capacità di connettere agenti supera la nostra capacità di controllare ciò a cui ci impegnano.
Evoluzione della struttura degli agenti
Per comprendere perché questo cambiamento stia avvenendo così rapidamente, è utile esaminare come si sta evolvendo la “stack” degli agenti. Stiamo assistendo all’emergere di una struttura a tre livelli che sostituisce silenziosamente la connettività tradizionale basata su API:
- Livello: Tooling
Esempi di protocollo: MCP (Model Context Protocol)
Scopo: Collega gli agenti a dati locali e strumenti specifici
Analogico “umano”: La cassetta degli attrezzi di un lavoratore - Livello: Contesto
Esempi di protocollo: ACP (Agent Communication Protocol)
Scopo: Standardizza come obiettivi, storia dell’utente e stato si spostano tra gli agenti
Analogico “umano”: La memoria e il briefing di un lavoratore - Livello: Coordinamento
Esempi di protocollo: A2A (Agent2Agent)
Scopo: Gestisce la scoperta, la negoziazione e la delega oltre i confini
Analogico “umano”: Un contratto o una stretta di mano
Questa stack rende i flussi di lavoro multi-agente un problema di configurazione piuttosto che un progetto di ingegneria personalizzata. Questo è esattamente il motivo per cui la superficie del rischio si sta espandendo più rapidamente di quanto la maggior parte dei CISO realizzi.
In passato, le persone inviavano ticket per attivare azioni di sistema. Nell’era A2A, gli agenti utilizzano “Agent Cards” per scoprire l’uno dell’altro e negoziare sopra quei sistemi. ACP consente a questi agenti di scambiare contesti ricchi, il che significa che una conversazione iniziata nel supporto clienti può fluire nella logistica di adempimento e partner senza passaggi umani. Ciò che un tempo era la dispersione delle API sta diventando dozzine di processi semiautonomi che agiscono per conto della tua azienda attraverso infrastrutture che non controlli completamente. L’attrito dell’integrazione manuale fungeva da freno naturale al rischio; A2A ha rimosso quel freno.
Il divario di governance
Questo divario di governance non si manifesta solitamente come un singolo fallimento catastrofico. Si presenta come una serie di piccoli incidenti confusi in cui tutto sembra “verde” nei dashboard, ma il risultato aziendale è errato. La documentazione del protocollo si concentra sulla crittografia e sulle strette di mano, ma ignora le modalità di fallimento emergenti della collaborazione autonoma. Questi non sono bug nei protocolli; sono segnali che l’architettura circostante non è ancora allineata con il livello di autonomia che i protocolli abilitano.
Modi di fallimento comuni
Deriva delle politiche: Una politica di rimborso codificata in un agente di servizio può tecnicamente interoperare con l’agente di riscossione di un partner tramite A2A, ma la loro logica aziendale può essere diametralmente opposta. Quando qualcosa va storto, nessuno possiede il comportamento end-to-end.
Condivisione eccessiva del contesto: Un team potrebbe ampliare uno schema ACP per includere “Sentimento dell’utente” per una migliore personalizzazione, ignaro che questi dati ora si propagano a ogni agente terzo a valle nella catena. Ciò che è iniziato come arricchimento locale diventa esposizione distribuita.
Trappola del determinismo: A differenza delle API REST, gli agenti sono nondeterministici. La logica della politica di rimborso di un agente potrebbe cambiare quando il suo modello sottostante viene aggiornato, anche se la “Agent Card” A2A dichiara capacità identiche. Il flusso di lavoro “funziona” fino a quando non funziona più, e non c’è traccia di versione per il debug. Questo crea quelli che chiamo “ghost breaks”: fallimenti che non si manifestano nella tradizionale osservabilità perché il contratto dell’interfaccia sembra invariato.
Questi modi di fallimento non sono casi limite. Sono il risultato di aver dato agli agenti maggiore autonomia senza aggiornare le regole di ingaggio tra di loro. Questi modi di fallimento hanno una causa comune: la capacità tecnica di collaborare tra agenti ha superato la capacità dell’organizzazione di stabilire dove quella collaborazione è appropriata e sotto quali vincoli.
Costruire un livello di trattato per gli agenti
È quindi necessario qualcosa oltre i protocolli stessi: un esplicito “livello di trattato per agenti”. Se il protocollo è la lingua, il trattato è la costituzione. La governance deve spostarsi dalla “documentazione secondaria” a “politiche come codice”. La governance tradizionale considera le violazioni delle politiche come fallimenti da prevenire. Un approccio antifragile le considera come segnali da sfruttare.
Quando un agente fa un impegno che viola un vincolo aziendale, il sistema dovrebbe catturare quell’evento, tracciare la catena causale e restituirlo sia all’addestramento dell’agente che al set di regole del trattato. Nel tempo, il livello di governance diventa più intelligente, non solo più rigoroso.
Definire vincoli a livello di trattato: Non autorizzare solo una connessione; autorizza un campo di applicazione. Quali campi ACP un agente è autorizzato a condividere? Quali operazioni A2A sono “solamente lettura” rispetto a “legalmente vincolanti”? Quali categorie di decisioni richiedono l’escalation umana?
Versionare il comportamento, non solo lo schema: Trattare le “Agent Cards” come superfici di prodotto di prima classe. Se il modello sottostante cambia, la versione deve aumentare, innescando una revisione del trattato. Questo non è un overhead burocratico; è l’unico modo per mantenere la responsabilità in un sistema in cui agenti autonomi prendono impegni per conto della tua organizzazione.
Tracciabilità inter-organizzativa: Abbiamo bisogno di tracciabilità osservabile che non mostri solo la latenza, ma l’intento: Quale agente ha fatto questo impegno, sotto quale politica? E chi è il proprietario umano? Questo è particolarmente critico quando i flussi di lavoro attraversano confini organizzativi e ecosistemi di partner.
Conclusione
Progettare quel livello di trattato non è solo un problema di strumenti. Cambia chi deve essere presente nella stanza e come pensano al sistema. Il vincolo più difficile non è il codice; è il personale. Stiamo entrando in un mondo in cui gli ingegneri devono ragionare sulla teoria dei giochi multi-agente e le interazioni politiche, non solo sull’integrazione SDK. I team di rischio devono audire gli “impegni macchina a macchina” che potrebbero non essere mai resi in linguaggio umano. I product manager devono possedere ecosistemi agenti in cui un cambiamento nella funzione di ricompensa o nello schema di contesto di un agente influisce sul comportamento di un intero network di partner. Le funzioni di conformità e audit hanno bisogno di nuovi strumenti e modelli mentali per rivedere flussi di lavoro autonomi che si eseguono a velocità macchina. In molte organizzazioni, queste competenze si trovano in silos diversi, e l’adozione di A2A/ACP sta procedendo più rapidamente delle strutture cross-funzionali necessarie per gestirle.
Tre tendenze convergenti stanno rendendo questo urgente: La maturità dei protocolli significa che le specifiche A2A, ACP e MCP si sono stabilizzate a tal punto che le aziende stanno passando oltre i progetti pilota a implementazioni in produzione. L’orchestrazione multi-agente sta cambiando da agenti singoli a ecosistemi di agenti e flussi di lavoro che attraversano team, dipartimenti e organizzazioni. E l’autonomia silenziosa sta sfumando la linea tra “assistenza agli strumenti” e “decisioni autonome”, spesso senza un riconoscimento esplicito dell’organizzazione.
Ci stiamo spostando dall’integrazione (far parlare le cose) all’orchestrazione (far agire le cose), ma i nostri strumenti di monitoraggio misurano ancora solo il dialogo. I prossimi 18 mesi determineranno se le aziende riusciranno a prendere l’iniziativa o se assisteremo a una ondata di fallimenti di alto profilo che costringerà a una governance retroattiva.
Il rischio non è che A2A e ACP siano insicuri; è che siano troppo efficaci. Per i team che sperimentano questi protocolli, smettere di concentrarsi sul “percorso felice” della connettività. Invece, scegliere un flusso di lavoro multi-agente e strumentarlo come prodotto critico:
Mappare il flusso del contesto: Ogni campo ACP deve avere un’etichetta di “limitazione di scopo”. Documentare quali agenti vedono quali campi, e quali requisiti aziendali o normativi giustificano quella visibilità. Non è un esercizio di inventario; è un modo per far emergere dipendenze nascoste dei dati.
Audire gli impegni: Identificare ogni interazione A2A che rappresenta un impegno finanziario o legale, specialmente quelle che non passano attraverso l’approvazione umana. Chiedere: “Se il comportamento di questo agente cambiasse da un giorno all’altro, chi se ne accorgerebbe? Chi è responsabile?”
Codificare il trattato: Prototipare un agente “gatekeeper” che applica vincoli aziendali sopra il traffico del protocollo grezzo. Non si tratta di bloccare gli agenti; si tratta di rendere visibile e applicabile la politica in tempo reale. Iniziare in modo minimale: una politica, un flusso di lavoro, una metrica di successo.
Strumentare per l’apprendimento: Catturare quali agenti collaborano, quali politiche invocano e quali contesti condividono. Trattare questo come telemetria, non solo come registri di audit. Alimentare i modelli nelle revisioni di governance trimestrali.
Se questo funziona, ora hai un modello ripetibile per scalare le distribuzioni degli agenti senza sacrificare la responsabilità. Se si interrompe, hai appreso qualcosa di cruciale sulla tua architettura prima che si interrompa in produzione. Se riesci a far comportare un flusso di lavoro in questo modo—governato, osservabile e adattabile—hai un modello per il resto del tuo ecosistema di agenti.
Se l’ultimo decennio è stato dedicato a trattare le API come prodotti, il prossimo sarà dedicato a trattare i flussi di lavoro autonomi come politiche codificate nel traffico tra agenti. I protocolli sono pronti. La tua struttura organizzativa non lo è. Il ponte tra i due è il Trattato degli Agenti: inizia a costruirlo prima che i tuoi agenti inizino a firmare accordi senza di te. La buona notizia: non è necessario ridisegnare l’intera organizzazione. Devi aggiungere un solo livello cruciale—il Trattato degli Agenti—che rende la politica applicabile dalle macchine, osservabile e apprendibile. Devi avere ingegneri che pensano alla composizione e alla teoria dei giochi, non solo alla connessione. E devi trattare le distribuzioni degli agenti come prodotti, non come infrastrutture. Più in fretta inizi, più rapidamente si chiude il divario di governance.
