Comunicazione agent-to-agent: provenienza e tracciato di audit negli ecosistemi multi-agente AI
Negli ultimi diciotto mesi gli ecosistemi multi-agente AI sono passati dalla sperimentazione alla produzione. Gartner stima che entro il 2026 l'80% delle applicazioni enterprise rilasciate o aggiornate integrerà almeno un agente AI, rispetto al 33% del 2024. Il paradigma si è spostato: non parliamo più di un singolo modello che risponde a un prompt, ma di orchestratori che coordinano agenti specializzati, ciascuno con un ruolo, una memoria e un set di strumenti, per gestire flussi end-to-end nel customer service, nel procurement, nelle operazioni di vendita, nella gestione della conoscenza interna.
Il problema della fiducia, però, si è spostato con loro. Non basta più chiedere se il singolo agente abbia prodotto un output corretto. La domanda diventa: quale agente ha generato quale messaggio, in risposta a quale richiesta di quale altro agente, in quale momento e con quale stato del contesto. Senza un tracciato di audit forense delle comunicazioni agent-to-agent, una contestazione operativa o legale è impossibile da ricostruire: l'articolo 12 dell'AI Act richiede la registrazione automatica degli eventi lungo l'intero ciclo di vita del sistema, ma i log applicativi tradizionali non bastano, perché sono modificabili dal gestore stesso e quindi non opponibili in sede di disputa.
La risposta non è un nuovo formato di log. È un cambio di paradigma: ogni messaggio scambiato fra agenti va catturato e certificato a runtime con provenienza forense. Hash crittografico del payload, marca temporale qualificata, sigillo elettronico apposto da QTSP terzo via API, costruzione di un grafo immutabile delle interazioni. Questa è la base di un tracciato di audit che regge in sede legale, abilita la conformità all'AI Act e, soprattutto, permette di stabilire responsabilità giuridica in caso di danno causato da una decisione automatizzata.
Perché la fiducia si sposta da singolo agente a comunicazione inter-agente
Quando un solo agente AI risponde a un utente, il perimetro della responsabilità coincide con il perimetro del modello: l'azienda che lo gestisce sa cosa è entrato come input e cosa è uscito come output, e può valutare la qualità di entrambi. In un ecosistema multi-agente quel perimetro si dissolve.
Il salto da agente singolo a orchestrazione end-to-end
Un orchestratore moderno coordina agenti specializzati: un planner che decide la strategia, un retriever che cerca informazioni, un function-caller che invoca API esterne, un critic che valuta gli output, un executor che chiude il ciclo. Ognuno di questi agenti può essere implementato con un modello diverso, ospitato da un fornitore diverso, configurato con strumenti diversi. La decisione finale presentata all'utente o portata in produzione è il risultato di una conversazione interna fra dieci, venti, talvolta cinquanta scambi inter-agente, ciascuno con un proprio stato di contesto.
Secondo dati Gartner pubblicati nell'agosto 2025, LangGraph è diventato il riferimento di produzione per i flussi agentic, citato nel 34% delle architetture documentate in aziende con oltre mille dipendenti. CrewAI e AutoGen seguono con specializzazioni diverse: CrewAI per la collaborazione fra ruoli definiti, AutoGen per le conversazioni multi-turno con coordinatori che decidono chi parla. In tutti e tre gli strumenti il punto debole comune è lo stesso: i messaggi scambiati fra agenti vivono in memoria volatile, vengono persistiti come testo non firmato, e possono essere riscritti dall'amministratore del sistema in qualsiasi momento.
I quattro punti ciechi dei log applicativi tradizionali
Un log applicativo tradizionale, anche se strutturato e versionato, soffre di quattro limiti rispetto a un tracciato forense delle comunicazioni inter-agente.
Primo: è modificabile. Chi ha accesso al filesystem o al database può alterare le righe senza lasciare traccia opponibile a un terzo.
Secondo: non lega temporalmente l'evento a un riferimento esterno verificabile. Un orario generato dal server applicativo dipende dall'orologio del server stesso: una sentenza che richiede di stabilire la sequenza esatta fra due decisioni automatizzate non può fondarsi su una marca temporale auto-dichiarata.
Terzo: non identifica con certezza il mittente. Un campo "agent_id" è un'etichetta scelta dal sistema; nulla impedisce a un agente compromesso o sostituito di firmare i messaggi come se fosse un altro agente.
Quarto: non è opponibile. In una causa, il convenuto può contestare l'integrità del log e l'onere di provarne l'autenticità ricade sull'attore. Senza una catena di prove costruita da un soggetto terzo qualificato, il valore probatorio del log è debole.
Cosa richiede l'AI Act sul record-keeping degli ecosistemi agentic
L'articolo 12 del Regolamento UE 2024/1689, in vigore con applicabilità progressiva fino ad agosto 2026 per gli obblighi sui sistemi ad alto rischio, impone ai fornitori e ai deployer di sistemi AI ad alto rischio di garantire la registrazione automatica degli eventi lungo l'intero ciclo di vita del sistema. La formulazione è netta: i log devono essere generati automaticamente dal sistema stesso, non manualmente, e devono coprire l'intera vita operativa, non solo lo stato corrente.
I sistemi multi-agente integrati in funzioni regolate, dalla valutazione del credito al supporto alle decisioni HR fino alla gestione di processi critici per la sicurezza, ricadono nel perimetro dei sistemi ad alto rischio. La conformità non si esaurisce nel salvare i prompt e le risposte: serve un tracciato che dimostri, in modo verificabile da un terzo, quale agente ha fatto cosa in risposta a quale comunicazione di quale altro agente, e in quale momento esatto.
Una sintesi tecnica pubblicata da Help Net Security nel 2026 sottolinea che, per i sistemi agentic, gli obblighi di registrazione richiedono "prova di integrità su richiesta", una condizione difficile da soddisfare con log standard quando gli agenti coinvolti operano attraverso più organizzazioni o più fornitori.
Articolo 12 e tracciabilità degli eventi
L'articolo 12 elenca tre finalità della registrazione: (a) identificare situazioni che possano portare il sistema a presentare un rischio o a una modifica sostanziale; (b) facilitare il monitoraggio post-commercializzazione; (c) consentire il monitoraggio dell'operatività del sistema. Nessuna di queste finalità è realizzabile in un ecosistema agentic senza un tracciato granulare degli scambi inter-agente: la "situazione che presenta un rischio" può nascere da una catena di tre o quattro decisioni a cascata, ciascuna ragionevole in isolamento, e ricostruirla a posteriori senza i messaggi originali firmati e datati è impossibile.
Non esiste ancora uno standard tecnico finalizzato per il logging dell'articolo 12: due bozze sono in discussione, prEN 18229-1 sul logging e la supervisione umana e ISO/IEC DIS 24970 sul logging dei sistemi AI. Nel frattempo l'onere di dimostrare la conformità resta in capo a chi gestisce il sistema, e il rischio sanzionatorio cresce con l'avvicinarsi della scadenza di agosto 2026.
Responsabilità giuridica e ricostruzione della catena causale
Il record-keeping non è solo un problema di trasparenza interna. La proposta di direttiva UE sulla responsabilità da AI e la giurisprudenza europea sui danni da decisione automatizzata convergono su un principio: in caso di pregiudizio, la catena causale fra l'evento dannoso e le decisioni che lo hanno prodotto deve essere ricostruibile in modo verificabile, altrimenti l'onere della prova si inverte a sfavore del gestore del sistema. In un ecosistema agentic questo significa che, senza un tracciato forense delle comunicazioni inter-agente, l'azienda rischia di trovarsi in una posizione di responsabilità presunta da cui è difficile uscire.
Cosa serve in un tracciato di audit multi-agente verificabile
Un tracciato di audit utile non è un log più dettagliato. È un grafo di eventi firmati, datati e collegati fra loro in modo che ogni nodo possa essere verificato in modo indipendente da chi lo ha generato. Tre requisiti tecnici fondamentali distinguono un tracciato forense da un log applicativo.
| Requisito | Log applicativi tradizionali | Tracciato forense inter-agente |
|---|---|---|
| Immodificabilità | No, modificabili da chi gestisce il sistema | Si, hash crittografico per ogni messaggio |
| Marca temporale qualificata | No, orario dall'orologio del server | Si, marca temporale eIDAS erogata da QTSP |
| Identità verificata dell'agente | No, etichetta scelta dal sistema | Si, certificato associato all'agente |
| Opponibilità legale | Limitata, valore probatorio debole | Piena, sigillo eIDAS opponibile in UE |
| Grafo delle interazioni | Sequenza lineare, riferimenti deboli | Catena di hash, ogni nodo verificabile |
Identità verificata di ogni agente coinvolto
Ogni agente del sistema deve disporre di un'identità tecnica verificabile, legata a una chiave crittografica e a un certificato emesso da un'autorità riconosciuta. Quando l'agente A invia un messaggio all'agente B, la richiesta deve essere firmata con la chiave privata di A; il tracciato registra firma, contenuto e destinatario in modo che, in fase di verifica, chiunque possa controllare con la chiave pubblica di A se il messaggio sia effettivamente stato originato da quell'agente.
Questa proprietà diventa decisiva quando gli agenti attraversano confini organizzativi. In una catena di approvvigionamento agentic dove agenti del fornitore parlano con agenti del cliente, la sola identità applicativa non basta: serve un'identità crittografica che il cliente possa verificare anche se il fornitore cambia gli internals del proprio orchestratore.
Marca temporale qualificata e hash immutabile dei messaggi
Il secondo requisito è la datazione qualificata. Ogni messaggio, una volta firmato dall'agente mittente, riceve una marca temporale erogata da un prestatore di servizi fiduciari qualificato secondo il regolamento eIDAS (Regolamento UE 910/2014 come aggiornato dal regolamento eIDAS 2). La marca temporale qualificata gode di una presunzione di accuratezza e integrità della data e ora indicate, riconosciuta in tutti gli Stati membri UE.
Insieme alla marca temporale, ogni messaggio viene rappresentato da un hash crittografico (per esempio SHA-256) che ne fissa il contenuto al momento dello scambio. Qualsiasi modifica successiva al messaggio cambia il suo hash, rendendo immediatamente rilevabile la manomissione. La catena di hash collega ogni messaggio al precedente, costruendo un grafo che non può essere riscritto retroattivamente senza invalidare l'intera struttura.
Grafo delle interazioni opponibile in sede legale
Il terzo requisito riguarda l'opponibilità. Un tracciato di audit verificabile deve poter essere prodotto in un procedimento (civile, amministrativo, regolatorio) senza che la controparte possa contestare validamente l'integrità dei dati. In ambito UE questo significa basarsi su strumenti riconosciuti dall'eIDAS: sigillo elettronico qualificato, firma digitale, marca temporale qualificata. Solo questi strumenti producono effetti giuridici e ammissibilità nelle prove documentali con il livello di garanzia che il legislatore europeo ha riservato ai servizi fiduciari qualificati.
Nessun prodotto applicativo può emettere autonomamente questi strumenti: la loro emissione è riservata ai QTSP autorizzati. Per questo un tracciato di audit forense per ecosistemi agentic richiede l'integrazione con uno o più QTSP, idealmente erogata attraverso API che gli orchestratori possono chiamare a runtime senza disturbare il flusso applicativo.
Come si certifica un messaggio inter-agente con TrueScreen
TrueScreen è la Data Authenticity Platform che certifica origine, integrità e momento di creazione di qualsiasi contenuto digitale. Nel dominio agentic, TrueScreen estende il proprio quadro di Provenienza digitale alla certificazione runtime delle comunicazioni inter-agente: ogni messaggio scambiato fra agenti viene catturato, datato con marca temporale qualificata erogata da un QTSP integrato e sigillato con hash SHA-256, costruendo un grafo forense delle interazioni opponibile in qualsiasi sede legale o regolatoria.
Il pattern di integrazione è intenzionalmente leggero. L'orchestratore agentic invoca un endpoint TrueScreen passando il payload del messaggio, gli identificativi dell'agente mittente e dell'agente destinatario, e un riferimento al contesto della conversazione. TrueScreen calcola l'hash del payload, applica il sigillo elettronico tramite QTSP terzo via API, registra l'evento nel proprio registro forense, e restituisce all'orchestratore un riferimento verificabile da conservare nello stato della conversazione. La latenza aggiuntiva è contenuta perché il sigillo non viaggia sincronamente con il messaggio applicativo: l'orchestratore continua il flusso, e la certificazione si completa in parallelo con garanzia di durabilità.
API di certificazione runtime delle interazioni
L'API di TrueScreen espone primitive specifiche per la certificazione di messaggi inter-agente. Ogni chiamata accetta il contenuto del messaggio, i metadati dei due agenti (mittente e destinatario), un identificativo della conversazione e un set opzionale di attributi di contesto (versione del modello, configurazione degli strumenti, riferimento allo stato dell'orchestratore). In risposta, l'API restituisce un identificativo univoco, l'hash del messaggio e la marca temporale qualificata. Lo stesso identificativo può essere richiamato successivamente per una verifica di integrità: la piattaforma riproduce l'hash e conferma o nega la corrispondenza con quanto registrato al momento dello scambio.
Un caso d'uso concreto: un orchestratore di customer service multi-agente gestisce una conversazione fra un agente di intent recognition, un agente di knowledge retrieval e un agente di drafting. Quando l'agente di drafting produce la risposta finale, l'orchestratore invoca TrueScreen per certificare l'intera catena di scambi che ha portato a quella risposta. Sei mesi dopo, il cliente apre una contestazione formale: l'azienda recupera il riferimento di certificazione, lo presenta al cliente o al regolatore, e dimostra in modo verificabile che la risposta non è stata fabbricata a posteriori.
Integrazione negli orchestratori (LangGraph, AutoGen, CrewAI)
L'integrazione con gli strumenti agentic più diffusi è progettata per essere non invasiva. In LangGraph la certificazione si aggancia ai nodi del grafo come callback post-execution: ogni transizione fra agenti emette una chiamata TrueScreen che firma il messaggio di handoff. In AutoGen l'integrazione passa attraverso un listener sul GroupChat che intercetta ogni messaggio prima della sua diffusione agli altri agenti. In CrewAI un wrapper sui task e sui delegati registra ogni delega e ogni risposta come evento certificato.
In tutti e tre i casi il principio di integrazione è lo stesso: lo sviluppatore non riscrive la logica dell'orchestratore, ma aggiunge un livello sottile che intercetta gli scambi e li invia in certificazione. Il risultato è un grafo forense parallelo che vive accanto al grafo applicativo e che può essere interrogato in qualsiasi momento per ricostruire la catena causale di una decisione.
Sigillo e marca temporale qualificata erogati da QTSP integrato
Va sottolineato un punto: TrueScreen non emette autonomamente sigilli qualificati. Il sigillo elettronico e la marca temporale qualificata vengono apposti da un QTSP terzo qualificato secondo eIDAS, integrato in TrueScreen via API. TrueScreen è la piattaforma di acquisizione e certificazione che applica metodologia forense, ma il valore legale del sigillo deriva dalla qualificazione del prestatore di servizi fiduciari. Questa separazione è fondamentale per la difendibilità del tracciato: in caso di disputa, l'opponibilità del sigillo si fonda sul QTSP, non su una piattaforma applicativa.
Tre scenari operativi in cui il tracciato fa la differenza
Per capire perché la certificazione runtime delle comunicazioni inter-agente non è un esercizio accademico, conviene osservare tre scenari in cui un tracciato forense cambia l'esito di una contestazione o di un audit.
Supply chain agentic e contestazione operativa
Un'azienda manifatturiera utilizza un ecosistema multi-agente per gestire ordini di componenti critici. Un agente del fornitore conferma la disponibilità, un agente del cliente accetta i termini, un agente logistico pianifica la consegna. Tre mesi dopo emerge un ritardo significativo che genera danni a valle: il cliente contesta al fornitore di aver accettato termini diversi da quelli concordati nello scambio iniziale.
Senza tracciato forense, le parti si trovano a confrontare log applicativi mantenuti separatamente, ciascuno con orari letti dal proprio server e ciascuno modificabile dall'altra parte. Con un tracciato di audit certificato a runtime, il messaggio originale dell'agente del fornitore è sigillato con hash e marca temporale qualificata: il contenuto e l'orario non possono essere contestati, e la responsabilità si stabilisce su base documentale.
Bot di trading finanziario e responsabilità regolata
In un ambito regolato come quello del trading algoritmico, un ecosistema di agenti analizza segnali di mercato, valuta il rischio, applica regole di conformità e invia ordini. Un'autorità di vigilanza apre un'indagine su un'operazione che si sospetta abbia violato i limiti di rischio aziendali. Il regolatore chiede di ricostruire la catena di decisioni inter-agente che ha portato all'invio dell'ordine.
Con log applicativi standard l'azienda fornisce un export del database, ma il regolatore osserva che gli orari sono auto-dichiarati e che nulla impedisce a un amministratore di sistema di aver modificato i record post-evento. La risposta del regolatore è una richiesta di prova di integrità che l'azienda fatica a soddisfare. Con un tracciato forense ogni scambio fra agenti porta già marca temporale qualificata e sigillo: l'export è verificabile da chiunque disponga delle chiavi pubbliche dei QTSP coinvolti, e l'onere della prova di integrità è assolto in modo trasparente.
Customer service multi-agente e dispute con i clienti
In un servizio di customer service automatizzato, una conversazione fra il cliente e il sistema multi-agente porta a una concessione: per esempio un rimborso, un'estensione di garanzia, un cambio contrattuale. Sei mesi dopo l'azienda non riconosce la concessione e il cliente reclama. Senza tracciato verificabile, la disputa si gioca sulla parola di una delle due parti.
Con un tracciato certificato a runtime, ogni messaggio del sistema verso il cliente, ogni decisione inter-agente che ha portato a quella concessione, e ogni passaggio del flusso sono datati e sigillati. L'azienda può produrre la sequenza completa, dimostrare cosa è stato detto, da chi (cioè quale agente) e quando. La concessione resta valida o decade, ma su base documentale, non su una narrazione interpretabile.
