Per i CFO che stanno iniziando a introdurre gli agenti AI nei processi finanziari, la priorità non dovrebbe essere dimostrare immediatamente quanto denaro è possibile risparmiare, ma verificare quanto bene l’organizzazione riesca a controllare ciò che questi sistemi fanno. È questa la prospettiva indicata da Gartner attraverso le analisi di Alex Levine, Director Analyst della Finance practice, secondo cui il primo progetto con un agente AI dovrebbe essere considerato soprattutto un pilota di governance.

La ragione sta nella differenza sostanziale fra gli agenti e le precedenti generazioni di automazione. Un processo RPA, per esempio, esegue una sequenza predefinita di istruzioni, mentre un sistema di GenAI tradizionale produce invece un contenuto sulla base di una richiesta. Un agente AI opera invece a un livello diverso, visto che interpreta un obiettivo, decide quali passaggi compiere, interagisce con più applicazioni e può arrivare a eseguire autonomamente determinate azioni.

Nel dipartimento finanziario questo cambio di paradigma modifica radicalmente il profilo di rischio. Se infatti un errore commesso da un’automazione rigidamente configurata tende a essere circoscritto al perimetro delle regole definite, un agente può adattare il proprio comportamento in funzione del contesto e prendere decisioni che non sono state esplicitamente programmate come una sequenza fissa. Se dispone inoltre di accesso a ERP, sistemi contabili, database, strumenti di reporting o piattaforme di procurement, un singolo errore può propagarsi rapidamente attraverso più sistemi.

Per questo motivo il controllo non deve essere applicato esclusivamente al risultato finale. La governance deve riguardare l’intero processo decisionale dell’agente, compresi i dati consultati, le azioni intraprese, gli strumenti utilizzati e i passaggi intermedi. La tracciabilità diventa quindi una caratteristica fondamentale dell’architettura, soprattutto quando l’agente opera in aree soggette a controlli finanziari, audit o obblighi normativi.

Gartner suggerisce di evitare, almeno nelle prime fasi, i processi caratterizzati dalle conseguenze più elevate. Un primo progetto dovrebbe essere confinato a un’attività con limiti ben definiti, procedure ripetibili e risultati facilmente verificabili. Ancora più importante, eventuali errori devono poter essere individuati rapidamente e soprattutto corretti o annullati senza conseguenze operative significative.

IA Garante Privacy

Crediti: Shutterstock

Questo criterio esclude inizialmente attività nelle quali un errore dell’agente potrebbe generare una rettifica contabile, un problema di compliance o conseguenze sul reporting regolamentare. Il valore del primo progetto non viene quindi misurato dalla quantità di autonomia concessa al sistema, ma dalla capacità dell’azienda di capire come si comporta quando gli vengono affidati obiettivi reali.

I confini operativi dovrebbero essere stabiliti prima ancora dello sviluppo. Il CFO infatti deve sapere quali dati l’agente può leggere, quali sistemi può interrogare, quali operazioni è autorizzato a eseguire e in quali circostanze deve necessariamente intervenire una persona. Questo significa definire policy di accesso, livelli di autorizzazione, punti di revisione umana e condizioni di escalation come parte integrante del progetto, anziché aggiungerli successivamente.

La responsabilità, inoltre, non può rimanere confinata al reparto IT. Un agente che opera su processi finanziari coinvolge direttamente finance, tecnologia, audit e risk management. Servono quindi responsabilità chiaramente assegnate e un modello di controllo condiviso, capace di stabilire chi autorizza l’agente, chi monitora il suo comportamento e chi interviene quando qualcosa non funziona.

Anche l’ambiente di esecuzione assume un’importanza decisiva. Gartner raccomanda di utilizzare inizialmente un ambiente sandbox separato dai sistemi produttivi, nel quale osservare il comportamento dell’agente senza esporre l’azienda a conseguenze operative. Il sandbox diventa una sorta di laboratorio di governance, permettendo di verificare quali informazioni vengono consultate, quali decisioni vengono prese e come il sistema reagisce alle anomalie prima di concedergli privilegi più ampi.

La misurazione del progetto dovrebbe seguire la stessa logica. ROI e autonomia possono essere indicatori interessanti, ma non rappresentano necessariamente il criterio più utile per valutare un primo deployment. Un pilota riuscito dovrebbe dimostrare soprattutto che ogni azione dell’agente è ricostruibile, che i controlli vengono applicati in maniera coerente e che esistono punti di revisione chiaramente identificati.

Particolarmente importante è mantenere un registro completo degli errori. Il team finanziario deve poter ricostruire, per ogni esecuzione, cosa l’agente aveva pianificato, quali dati aveva consultato, quali strumenti aveva utilizzato, quali azioni aveva compiuto e quale risultato aveva prodotto. Il failure log non serve soltanto a documentare i problemi, ma diventa una base concreta per correggere configurazioni, affinare i controlli e migliorare le procedure.