Molte aziende che stanno portando gli agenti di coding in produzione hanno gia' un AI governance framework, o lo stanno per finire. C'e' una sezione sui modelli approvati, una sulla gestione dei dati, una sul rischio fornitori. Legal l'ha firmato. Risponde, per iscritto, alla maggior parte delle domande che un board o un cliente farebbero su come l'azienda usa l'AI.
Non risponde alla domanda che arriva al delivery owner quando un cliente contesta una modifica specifica: chi l'ha approvata, cosa e' stato controllato prima che partisse. Quella domanda si trova un livello sotto a dove si ferma la maggior parte dei framework di governance.
Cosa copre di solito un AI governance framework
I framework che le aziende adottano davvero, il NIST AI Risk Management Framework con le sue quattro funzioni Govern, Map, Measure, Manage, oppure ISO/IEC 42001, il primo standard certificabile per un sistema di gestione dell'AI, sono costruiti attorno allo stesso oggetto: il sistema AI in se'. Quali modelli sono approvati, quali dati possono essere inviati loro, quale valutazione del rischio deve superare un nuovo caso d'uso prima di essere ammesso, chi risponde se un modello si comporta male. E' un perimetro reale e necessario. Ed e' anche, per costruzione, una policy su strumenti e dati, non sui singoli pezzi di lavoro che quegli strumenti producono.
La parte che si ferma al confine del modello
Un framework di governance costruito cosi' risponde a domande a livello di sistema: questo modello e' approvato, questo fornitore e' verificato, questo caso d'uso rientra in una categoria di rischio accettabile. Non e' stato progettato per rispondere a domande a livello di singola modifica: quale sessione ha prodotto questo diff, cosa era autorizzato a toccare l'agente quando l'ha scritto, qualcuno ha guardato il risultato prima che arrivasse in produzione. Sono due granularita' diverse, e una policy scritta per la prima non si estende automaticamente alla seconda, qualunque cosa suggerisca l'organigramma.
Questo scarto contava poco quando quasi ogni riga era scritta da una persona. Una policy di governance poteva fermarsi al livello dello strumento perche' la responsabilita' di ogni modifica restava comunque in capo a chi l'aveva committata, e si poteva chiedere direttamente a lei. Gli agenti di coding cambiano chi, o cosa, sta a monte di un commit, senza cambiare dove atterra la domanda di un cliente.
Il codice e' l'output che nessuno ha messo nella policy
Un AI governance framework costruito attorno a modelli e dati tratta il codice come tratta qualsiasi altro output: come qualcosa prodotto dal sistema approvato, dentro il suo perimetro approvato. Quello che non tratta come oggetto di primo livello e' la singola modifica, il diff specifico che un cliente, un revisore o un nuovo responsabile tecnico potrebbero chiedere di vedere tra sei mesi. L'auto mode diventato il default in Claude Code e' una versione concreta di questo scarto: un classifier decide, in tempo reale, se un'azione ha bisogno che una persona la guardi prima che parta. E' un livello di sicurezza reale, e sta interamente dentro lo strumento. Risponde a "questo e' stato bloccato a meta' sessione", non a "qualcuno puo' mostrare, dopo il fatto, chi ha firmato cosa e' arrivato in produzione".
Lo stesso scarto si vede sul lato supply chain. Un SBOM elenca cosa c'e' dentro una build, con precisione, fino alla dipendenza e all'hash. Non e' mai stato pensato per registrare perche' esiste un certo pezzo di codice, quale task lo ha prodotto, o chi lo ha revisionato prima del rilascio. Un framework di governance che si ferma a "quali modelli sono approvati" e una distinta base che si ferma a "cosa c'e' nella build" sono entrambi corretti nel proprio perimetro, ed entrambi silenziosi sulla stessa domanda: cosa e' successo a questa modifica specifica, tra il momento in cui un agente ha iniziato e il momento in cui e' arrivata a un cliente.
Quattro domande a cui una policy sui modelli non risponde
Sono le domande che arrivano per prime, di solito da un cliente, a volte da un revisore, occasionalmente da una persona appena assunta che cerca di capire perche' le cose funzionano cosi':
- Quale sessione dell'agente ha prodotto questa modifica, e con quale autorizzazione stava operando in quel momento?
- Che contesto e quali vincoli aveva davvero l'agente quando ha preso questa decisione specifica, non quello che dice la policy che avrebbe dovuto avere?
- Una persona ha revisionato questa modifica prima che entrasse, ed esiste una traccia di quella revisione che sopravvive a chi l'ha fatta se lascia l'azienda?
- Se un cliente contesta questa modifica tra sei mesi, cosa gli consegnate: un file di log che chiunque avrebbe potuto modificare, o qualcosa di firmato?
Una policy su modelli e dati, per quanto scritta bene, non produce da sola una risposta a nessuna di queste. Non era pensata per farlo. L'errore e' assumere che, siccome il framework governa l'AI, copra gia' anche cosa deve restare come prova quando a fare la modifica e' stato un agente, non la policy.
Estendere la governance alla modifica, non solo allo strumento
Niente di tutto questo dice di non avere un framework di governance su modelli e dati. Dice che il framework che la maggior parte delle aziende ha oggi copre il lato input del problema, quali strumenti sono affidabili, e si ferma prima del lato output, quali modifiche quegli strumenti hanno prodotto e chi risponde di ciascuna. Il livello che manca sta in mezzo ai due: lega un intento specifico, il contesto che l'agente era davvero autorizzato a usare, l'esecuzione che ne e' seguita e una firma umana, come un'unica catena che un delivery owner puo' consegnare senza doverla ricostruire a memoria.
Non e' un sostituto della governance sui modelli. E' la parte di governance che oggi finisce al confine del modello, estesa fino alla modifica di cui il cliente ha davvero chiesto conto.