Governance agenti D365: 4 controlli prima dell'autonomia

Il sintomo: un agente che gira con accesso permanente

Nella maggior parte dei progetti che vedo, un agente viene attivato in demo con l'accesso della persona che lo ha configurato. Funziona, la demo convince, e quell'accesso resta lì. Il problema non emerge subito: emerge quando l'agente inizia ad agire su processi reali, e nessuno sa più con quali permessi sta operando né chi risponde delle sue azioni.

Su D365 F&SCM la posta in gioco è concreta. Un agente che ricalcola le scorte, propone un riordino o sposta una data di consegna tocca dati che finiscono in bilancio e in produzione. Se ha un accesso amministratore permanente ereditato da un utente, la superficie di rischio non è più il singolo errore, ma tutto ciò che quell'identità può fare, sempre, senza scadenza.

Il sintomo è quasi sempre lo stesso: un agente potente, utile, e completamente privo di paletti. Non è un problema di modello. È un problema di governance dell'identità, e va affrontato prima di passare dal pilota alla produzione.

Cosa cambia davvero con Agent 365

Fino a poco fa un agente agiva quasi sempre per delega: usava le credenziali di un utente e ne ereditava i permessi. Se io non potevo fare una cosa su D365, non poteva farla nemmeno l'agente. Era un limite, ma anche una rete di sicurezza implicita.

Con Agent 365, generalmente disponibile, cambia il modello: un agente può avere identità, credenziali e permessi propri. Non opera più necessariamente al posto di qualcuno, ma come entità a sé. È un salto di capacità reale, perché permette all'agente di lavorare in autonomia anche quando l'utente non c'è. Ma è anche un salto di responsabilità: un'identità che agisce da sola ha bisogno degli stessi controlli che daresti a un neoassunto, non di un badge valido per sempre.

Il punto pratico è questo: Microsoft ha esteso agli agenti gli strumenti di identity governance che già esistono per le persone. Pacchetti di accesso con permessi scoped e a termine tramite Entra ID Governance, un owner responsabile, audit delle azioni con Purview, esecuzione in ambienti isolati. Non serve inventare una governance nuova: serve applicare agli agenti quella che già usi per gli utenti, in modo esplicito.

Il framework in quattro controlli

Questi sono i quattro controlli che verifico prima di dare a un agente le chiavi di un processo F&SCM. Non sono opzionali: se anche uno solo manca, l'agente resta in pilota, non va in produzione.

• Identità propria o delega? Decidi consapevolmente se l'agente agisce per conto di un utente o con credenziali proprie. Sono due livelli di rischio diversi: la delega eredita e limita, l'identità propria libera ma espone. Scegliere per default l'identità propria perché è più comoda è l'errore più comune.
• Permessi a termine, non permanenti. Usa i pacchetti di accesso di Entra ID Governance per assegnare all'agente solo i permessi che gli servono, con una scadenza. Un agente che ricalcola le scorte non ha bisogno di toccare i pagamenti, e non ha bisogno di poterlo fare per sempre.
• Un owner con nome e cognome. Ogni agente deve avere un proprietario responsabile e identificabile, non un generico team. È la persona che risponde di cosa fa l'agente, che lo disattiva se qualcosa va storto e che rivede periodicamente i suoi permessi.
• Tracciabile e isolato. Le azioni dell'agente devono essere verificabili a posteriori con Purview, e l'esecuzione deve avvenire in ambienti isolati con traffico di rete controllato. Se non riesci a ricostruire cosa ha fatto un agente e in quale contesto, non hai un agente autonomo: hai un rischio non misurato.

Quando non dare autonomia a un agente

La governance corretta non significa dare autonomia a tutto. In diversi casi la risposta giusta è tenere l'agente in modalità suggerimento, con un umano che approva. Lo faccio quando l'azione ha effetti difficili da annullare, quando il processo a monte è disordinato, o quando manca ancora uno storico di comportamento affidabile.

Un agente che modifica in autonomia una data di consegna verso un cliente strategico, o che rilascia un ordine di produzione, tocca decisioni che è meglio far passare da un'approvazione umana finché la fiducia non è costruita. E se il processo sottostante è caotico, l'autonomia non lo sistema: lo espone solo più in fretta. L'agente amplifica il processo che trova, buono o cattivo che sia.

C'è anche un limite di maturità organizzativa. Se non hai ancora un owner chiaro, un audit funzionante e un modo per revocare i permessi in fretta, l'autonomia è prematura a prescindere da quanto è bravo il modello. In questi casi il controllo giusto è rallentare, non accelerare.

Da dove partire

Non serve una riorganizzazione. Serve applicare i quattro controlli al primo agente che stai per mettere in produzione, prima di attivarlo. Parti da un processo singolo, ben delimitato e a basso impatto, e usalo come banco di prova della tua governance, non solo delle capacità dell'agente.

In concreto: censisci gli agenti già attivi e verifica con quali permessi stanno girando oggi, assegna a ciascuno un owner nominale, sostituisci gli accessi permanenti con pacchetti di accesso a termine tramite Entra ID Governance, e attiva l'audit con Purview prima di allargare il perimetro. Solo dopo che questi quattro punti sono in piedi ha senso passare dal suggerimento all'azione autonoma.

La domanda da tenere sul tavolo è semplice: il tuo prossimo agente su D365 ha già un owner e un permesso a termine, o sta ancora girando con accesso permanente? Se la risposta è la seconda, il lavoro da fare non è sul modello. È sulla governance.