Gli agenti AI stanno passando dal rispondere a domande al compiere azioni.
Questo singolo cambiamento modifica completamente il modello di rischio.
I chatbot producono testo. Gli agenti operano sui sistemi.
Possono leggere email, chiamare API, aggiornare i record dei clienti, distribuire codice, creare ticket, approvare passaggi nei flussi di lavoro, coordinarsi con altri agenti e archiviare nuove conoscenze nella memoria a lungo termine.
Ciò significa che la domanda centrale non è più:
Questa risposta è corretta?
Bensì:
Questo agente dovrebbe essere autorizzato ad agire in questo momento?
È a questa domanda che un layer di governance esiste per rispondere.
1. La memoria è utile. Non è governance.
La memoria aiuta gli agenti a preservare il contesto tra le sessioni.
Li aiuta a ricordare le preferenze dell'utente, il lavoro passato, gli output degli strumenti e le decisioni precedenti. Questo è importante. Ma la memoria non decide:
- quali fatti possono entrare nella memoria
- quali ricordi sono obsoleti o avvelenati
- quali azioni richiedono approvazione
- quale passo del flusso di lavoro deve venire dopo
- quale prova è richiesta prima dell'esecuzione
- quale agente è autorizzato a utilizzare quali informazioni
Nei sistemi di agenti in produzione, il problema più difficile spesso non è il recupero delle informazioni. È l'autorità.
La memoria aiuta un agente a ricordare.
La governance lo aiuta a scegliere cosa gli è permesso fare.
È in questa distinzione che si colloca Marrow.
Marrow non è solo un layer di memoria. È un layer di giudizio per flotte di agenti AI.
2. L'osservabilità spiega il passato. Gli agenti hanno bisogno di controllo prima del futuro.
L'osservabilità è necessaria. I team hanno bisogno di tracce, log, valutazioni, annotazioni, avvisi e dashboard.
Ma la visibilità a posteriori non impedisce un'azione sbagliata prima che accada.
Se un agente distribuisce codice non sicuro, invia un'email sensibile, approva il pagamento sbagliato o salta un passaggio obbligatorio del flusso di lavoro, la dashboard potrebbe spiegare l'incidente in seguito. Non lo previene necessariamente.
Per i flussi di lavoro ad alto impatto, il segnale deve raggiungere l'agente prima dell'azione:
- livello di rischio
- prova richiesta
- vincoli delle policy
- approvazione del responsabile
- piano di rollback
- passo successivo esatto
- permetti, avvisa, rivedi o blocca
Questo è il divario tra osservabilità e governance.
I dashboard informano gli umani.
La governance informa gli agenti prima che agiscano.
3. La valutazione è un'istantanea. La produzione è un flusso.
La valutazione pre-distribuzione coglie molti fallimenti. Ma gli agenti in produzione vivono in ambienti che cambiano.
I prompt cambiano. Gli strumenti cambiano. Le API cambiano. I dati cambiano. Le policy cambiano. Altri agenti nella flotta cambiano.
Un benchmark può dire che un agente funziona bene in un certo insieme di condizioni. La produzione pone una domanda diversa:
Questo agente continuerà a prendere la decisione giusta man mano che l'ambiente cambia?
La ricerca sugli agenti che usano strumenti punta nella stessa direzione.
ToolEmu studia agenti basati su modelli linguistici che utilizzano strumenti ad alto rischio e mostra che i fallimenti degli agenti possono creare gravi conseguenze nel mondo reale. AgentHarm e CUAHarm si concentrano sul comportamento dannoso quando gli agenti possono usare strumenti o operare su computer. Altre ricerche mostrano che gli agenti possono comprendere il rischio in astratto ma fallire comunque nell'evitare azioni rischiose in traiettorie concrete.
La lezione è pratica:
La sicurezza non può risiedere solo nel modello o solo in un benchmark.
Gli agenti in produzione hanno bisogno di controllo in fase di esecuzione.
4. La governance sta diventando infrastruttura AI.
I principali framework di governance AI stanno convergendo sulla stessa idea: l'AI responsabile deve diventare operativa.
Non solo principi.
Non solo PDF di policy.
Non solo dashboard.
La governance operativa richiede:
- gestione documentata del rischio
- registrazione automatica
- supervisione umana per decisioni ad alto impatto
- gestione della qualità lungo l'intero ciclo di vita
- tracciabilità del comportamento del sistema
- monitoraggio post-commercializzazione
- responsabilità per risultati avversi
Questo è visibile in NIST AI RMF, NIST's Generative AI Profile, ISO/IEC 42001, i Principi OECD sull'AI, l'AI Act dell'UE, la tassonomia del rischio AI agentico di OWASP e la guida Five Eyes 2026 sui servizi AI agentici.
La direzione è chiara.
I sistemi AI aziendali necessitano di evidenza, controllo, tracciabilità e responsabilità durante la loro vita operativa.
Per gli agenti AI, ciò significa che la governance deve spostarsi nel runtime.
5. Cosa dovrebbe fare un layer di governance per agenti
Un layer di governance è un piano di controllo tra il runtime dell'agente e i sistemi su cui l'agente può agire.
Riceve l'azione intenzionale dell'agente, la valuta rispetto a policy, permessi, rischio, prova e risultati precedenti, quindi restituisce una decisione esecutiva:
permetti
avvisa
richiesta revisione
blocca
Un layer di governance serio necessita di nove funzioni.
- Identità e autorità con ambito definito
Ogni agente ha bisogno di un'identità chiara, permessi limitati e credenziali con ambito definito.
Una flotta non può essere governata se ogni agente condivide la stessa chiave API.
- Policy a runtime
Le policy devono diventare condizioni eseguibili in fase di runtime.
Quale passo viene prima?
Quale prova è richiesta?
Quale azione ha sempre bisogno di revisione?
Quale azione non dovrebbe mai essere eseguita automaticamente?
- Soglie di rischio
Il sistema dovrebbe classificare le azioni per impatto, reversibilità, sensibilità e contesto aziendale.
Il lavoro a basso rischio può essere eseguito automaticamente. Il lavoro ad alto rischio può richiedere prove, approvazione o blocco.
- Pacchetti di prova
Prima dell'azione, l'agente dovrebbe allegare le prove.
Esempi:
- copertura dei test
- piano di rollback
- clausola di policy
- verifica dell'identità
- approvazione clinica
- revisione della fattura
- autorizzazione del supervisore
- Instradamento delle approvazioni
La revisione umana non dovrebbe essere una coda manuale per tutto.
Dovrebbe essere un checkpoint condizionale per azioni in cui il costo dell'errore è alto.
- Audit e provenienza
Ogni decisione dovrebbe essere tracciabile.
Chi l'ha iniziata?
Perché è stata permessa o bloccata?
Quale policy è stata applicata?
Quale prova è stata allegata?
Chi l'ha approvata?
Cos'è successo dopo?
- Chiusura del risultato
La governance non finisce con permetti o blocca.
Il sistema deve chiudere il ciclo:
- l'azione ha avuto successo?
- è fallita?
- è stato necessario un rollback?
- chi l'ha approvata?
- quale lezione dovrebbe essere archiviata?
- Governance della scrittura in memoria
Non ogni log è conoscenza.
Non ogni pezzo di conoscenza dovrebbe influenzare ogni agente.
I risultati reali dovrebbero diventare memoria solo attraverso una scrittura controllata.
- Apprendimento a livello di flotta
Il layer di governance dovrebbe tracciare il comportamento in tutta la flotta:
- deriva dai flussi di lavoro di base
- cicli di ripetizione
- fallimenti ripetuti
- schemi che dovrebbero avvisare gli agenti futuri
Qui è dove la governance diventa più di una restrizione. Diventa apprendimento.
6. Marrow come caso studio di governance
Marrow è progettato attorno a un semplice ciclo operativo:
orienta−>pensa−>agisci−>controlla−>registraorient -> pensa -> agisci -> controlla -> registra
Ogni passo ha una funzione di governance.
Orienta presenta la storia rilevante, gli avvisi e i vincoli.
Pensa valuta l'azione intenzionale prima che accada.
Agisci esegue con contesto e protezioni allegate.
Controlla ispeziona se mancano prove o chiusura.
Registra archivia il risultato in modo che la prossima decisione migliori.
Questa è la differenza fondamentale tra memoria e giudizio.
La memoria chiede:
Cosa sa l'agente?
Marrow chiede:
L'agente dovrebbe agire e a quali condizioni?
Le sue superfici di prodotto si mappano direttamente sulla governance in fase di esecuzione:
- decisionBrief() fornisce all'agente il contesto pre-azione.
- workflowGate() restituisce permetti, avvisa, richiesta revisione o blocca.
- runGuarded() avvolge il lavoro rischioso con guida pre-azione e chiusura del risultato.
- agentRuntime() inietta lezioni e requisiti di prova nel contesto dell'agente.
- agentStatus() mostra se Marrow è attivo e sta raccogliendo segnali utili.
- valueReport() trasforma la governance in prova visibile al proprietario.
In altre parole:
Marrow trasforma i risultati passati in giudizio prima dell'azione.
7. Un esempio concreto: il deploy sbagliato
Immagina un agente CI/CD che sta per distribuire una modifica al webhook dei pagamenti.
Il build passa.
Il branch è pronto.
L'agente sta per fare il push in produzione.
Ma alla pull request mancano tre cose:
- copertura dei test
- piano di rollback
- test di fumoke
Senza governance, il deploy potrebbe procedere.
I fallimenti di pagamento compaiono ore dopo. I clienti sono colpiti. L'ingegnere di turno esegue il rollback manualmente. L'incidente diventa un'altra analisi post-mortem.
Con la governance, il gate del flusso di lavoro viene eseguito prima del deploy.
Restituisce:
livello di rischio: alto
pacchetto di prova mancante
distribuzione bloccata
L'agente non sta solo registrando di più. È costretto a fermarsi al punto giusto.
Questo è il valore della governance pre-azione.
8. Le metriche giuste per la governance degli agenti
Un layer di governance non dovrebbe solo contare i log.
Dovrebbe misurare se la flotta sta diventando più sicura, più coerente e più facile da controllare.
Le metriche utili includono:
- Copertura delle azioni: quante azioni ad alto impatto passano attraverso un gate
- Tasso di completamento delle prove: quante azioni includono la prova richiesta prima dell'esecuzione
- Tasso di chiusura dei risultati: quante decisioni vengono chiuse con un risultato reale
- Prevenzione di fallimenti ripetuti: quanto spesso vengono evitati schemi di fallimento noti
- Gravità della deriva: quanto gli agenti si allontanano dai flussi di lavoro approvati
- Tasso di falsi positivi: quanto spesso il gate blocca troppo
- Tasso di falsi negativi: quanto spesso azioni pericolose sfuggono
- Tempo di ricostruzione dell'audit: quanto tempo ci vuole per spiegare una decisione
- Precisione della revisione umana: se l'approvazione umana viene utilizzata per le azioni giuste
La governance è utile quando riduce i rollback, previene incidenti ripetuti, restringe le revisioni non necessarie e rende più facile dimostrare il comportamento dell'agente.
Altrimenti diventa teatro della conformità.
9. Anche il layer di governance ha dei rischi
Un layer di governance può anche fallire.
Può essere configurato male. Le policy possono diventare obsolete. Le prove possono essere incomplete. I gate possono bloccare troppo. Gli attaccanti possono prendere di mira il piano di controllo. Se memorizza troppi dati sensibili, diventa un punto di concentrazione del rischio.
Quindi il layer di governance stesso ha bisogno di disciplina:
- Privilegio minimo per impostazione predefinita Gli agenti dovrebbero ricevere solo i permessi di cui hanno bisogno, per il tempo in cui ne hanno bisogno.
- Fallimento chiuso per azioni ad alto impatto Se l'azione può causare danni gravi, la prova mancante dovrebbe fermare l'esecuzione.
- Fallimento morbido per automazione a basso rischio Non ogni azione merita lo stesso livello di attrito.
- Evidenza leggibile dall'umano, policy leggibile dalla macchina Gli operatori devono comprendere la decisione. I sistemi devono applicarla.
- Apprendimento dai risultati reali Senza chiusura del risultato, il sistema accumula log, non giudizio.
10. Conclusione
Gli agenti AI spingono il software verso un nuovo modello operativo.
Possono scegliere strumenti, coordinarsi con altri agenti, modificare sistemi e creare conseguenze.
In quel modello, la governance non è un layer aggiunto dopo la distribuzione. Appartiene al runtime.
Memoria, osservabilità, valutazione e revisione umana sono tutte importanti. Ma ognuna risolve solo una parte del problema.
Un layer di governance le collega in un ciclo di azione responsabile:
policy prima dell'azione prova prima dell'esecuzione autorità durante l'azione risultato dopo l'azione apprendimento in tutta la flotta
Questa è la tesi alla base di Marrow.
Le flotte di agenti AI non hanno semplicemente bisogno di ricordare di più.
Hanno bisogno di un giudizio migliore prima di agire.
Riferimenti
- NIST. AI Risk Management Framework
- NIST. Generative AI Profile, NIST AI 600-1
- OECD. OECD AI Principles
- European Commission AI Act Service Desk. Article 9: Risk management system
- European Commission AI Act Service Desk. Article 12: Record-keeping
- European Commission AI Act Service Desk. Article 14: Human oversight
- European Commission AI Act Service Desk. Article 17: Quality management system
