L’ascesa degli strumenti di sviluppo agentico, che affidano ad agenti di IA la preparazione delle modifiche al codice, solleva la questione dell’auditabilità dei workflow. Nei settori regolamentati, sapere chi ha approvato una modifica non basta più: occorre poter ricostruire il contesto, i controlli e le decisioni che l’hanno prodotta.
All’interno di una grande istituzione finanziaria che utilizza un agente nel proprio workflow di sviluppo, il team di audit interno e di conformità si è posto una domanda precisa. Per una merge request (una richiesta di fusione del codice) aperta da un agente per aggiornare una dipendenza di un servizio di pagamento, si poteva indicare chi l’avesse approvata, quali dati di input e quali prompt l’agente avesse utilizzato, quali controlli di policy fossero stati valutati e come riprodurre o annullare tale attività? Il team non aveva risposta. Il sistema di delivery non considerava il lavoro dell’agente come una transazione delimitata e auditabile.
Un diff validato dalla CI (l’integrazione continua, che testa automaticamente il codice) e approvato prova che una modifica è avvenuta. Non prova, tuttavia, il contesto utilizzato dall’agente, le decisioni di policy valutate prima della creazione della merge request, né la possibilità di riprodurre il risultato in un’esecuzione successiva. Eppure, negli ambienti regolamentati, il « come » e il « perché » sono essenziali. Questa situazione si riscontra sull’intero panorama delle piattaforme e nelle organizzazioni DevSecOps: il budget per gli strumenti agentici viene validato in poche settimane, mentre quello per i registri di esecuzione, il collegamento delle identità e gli strumenti di replay non compare mai o viene trattato come un semplice costo di conformità.
Quattro eccezioni ricorrenti
Non appena gli agenti aprono merge request in un ambiente CI/CD regolamentato, emergono quattro tipi di eccezioni di conformità. La prima è la provenienza mancante: nessuno può dire quali dati l’agente abbia utilizzato, siano essi specifiche, contesto recuperato, chiamate a strumenti o stato del repository. La seconda è l’attribuzione d’identità incerta, poiché l’agente ha agito sotto un token di servizio condiviso, senza un responsabile umano designato. La terza è una catena decisionale non ricostruibile, il ragionamento essendo stato catturato solo in modo effimero. La quarta è il rollback non delimitato: le modifiche dell’agente essendo accoppiate, ogni annullamento diventa un lavoro manuale attraverso commit e repository.
La ricostruzione a posteriori consiste nell’esaminare i log di conversazione, gli output parziali della CI e le tracce dell’agente ancora disponibili. Nella maggior parte delle organizzazioni, nessuno conteggia le ore dedicate ogni settimana a questo compito, il che spiega perché il suo costo rimanga invisibile. La fonte propone un semplice test: un team è in grado di produrre in meno di un’ora un dossier di prove che riunisca le specifiche del compito, lo stato del repository, i controlli valutati e il responsabile umano all’origine dell’azione?
« Consegnare prima » e i suoi limiti
La strategia « Consegna prima, governa dopo » può funzionare quando gli agenti sono confinati a perimetri ristretti, come la generazione di test, piccole refactoring o l’aggiornamento della documentazione, con una solida revisione umana. Si incrina invece quando i team se ne affrancano, quando le librerie di prompt si moltiplicano con una registrazione incoerente e quando token condivisi rendono l’attribuzione impossibile a livello di portafoglio. L’articolo cita anche il caso di una grande azienda che ha voluto costruire una base di workflow prima di generalizzare gli agenti: il progetto di piattaforma si è protratto per diversi trimestri, e i team hanno finito per aggirarlo.
L’articolo sottolinea che « la pressione competitiva premia la velocità, mentre i regolatori premiano la capacità di ricostruzione ». Descrive il costo di questo divario: prove mancanti scoperte durante un controllo, rimedio di diverse settimane e raggio d’impatto che si allarga con ogni azione dell’agente mal registrata. Cita a tal proposito Crédit Agricole CIB, che pilota, secondo il testo, una delivery che riunisce migliaia di sviluppatori distribuiti in decine di paesi su un’unica piattaforma DevSecOps, condizione necessaria per auditare il lavoro agentico.
Nominare e misurare il lavoro
La fonte raccomanda di trattare questo progetto come un prodotto a sé stante, battezzato « Esecuzione registrata per il CI/CD agentico », con risorse che riuniscono ingegneria di piattaforma, sicurezza, audit ed esperienza sviluppatore. I suoi deliverable coprono uno schema di registrazione che cattura dati di input, output, chiamate a strumenti e versione del modello, un collegamento d’identità che associa ogni azione a un responsabile umano, log delle decisioni di policy, oltre a meccanismi di replay e di rollback. Il monitoraggio può basarsi sulla profondità della coda delle eccezioni, il tempo mediano per ottenere le prove, il tasso di successo dei replay e il tasso di riapertura delle eccezioni.
Se un solo passo deve essere compiuto, il testo consiglia di iniziare dai casi più a rischio, come i cambiamenti delle dipendenze, le modifiche dell’Infrastructure as Code e la configurazione della sicurezza. L’ultimo test proposto consiste nel chiedere a un team di annullare in modo pulito una modifica unita scritta da un agente, basandosi esclusivamente su artefatti registrati.
