Guida alla valutazione dell'IA in ambito Finance

Panoramica

Introduzione

Un metodo ripetibile per decidere quali funzionalità integrare in un flusso di lavoro controllato, quali escludere e quali evidenze raccogliere prima di estenderne l'utilizzo.

Le funzionalità di intelligenza artificiale (IA) devono dimostrare di meritare un posto nei flussi di lavoro della funzione Finance. Questo toolkit offre un quadro pratico per individuare i casi d'uso concretamente realizzabili, verificare le dichiarazioni dei fornitori in condizioni operative reali e valutare tracciabilità, controlli e costi di esercizio. Si tratta quindi di una guida che mostra ai team Finance come arrivare a una decisione documentata - procedere, rivedere o interrompere (go/revise/stop) - basata su evidenze oggettive, chiara attribuzione delle responsabilità e valore misurabile dei flussi di lavoro. Ecco illustrati i sette step da seguire.

Passo 1

Partire dalla decisione, non dalla tecnologia

Una demo studiata ad arte punta a dimostrare che il software è in grado di produrre un risultato, non che quel risultato sia adatto a essere inserito in un processo di chiusura finanziaria, previsioni, riconciliazione o reporting per il CdA. Pertanto, la vera domanda da farsi è: "Ha senso inserire questa funzionalità in questo flusso di lavoro?".

Dalla risposta a questa domanda dipende il giudizio finale di chi è preposto alla valutazione. Per fare un esempio, una spiegazione degli scostamenti generata dall'IA può sembrare inappuntabile nella forma, ma continuerà a essere inutilizzabile se la funzione Finance non è in grado di ricollegare quei numeri ai conti e alle transazioni sottostanti. D’altro canto, invece, una proposta di corrispondenza ai fini della riconciliazione può sembrare meno spettacolare, ma generare valore. Perché? Perché può essere verificata in pochi secondi da un revisore, e in più il sistema è in grado di tracciare chi ha approvato la riconciliazione.

Al Chief Financial Officer (CFO) spetta definire i criteri di convalida delle evidenze e prendere la decisione finale di approvazione, revisione o interruzione per i casi d'uso rilevanti. La maggior parte dei test dovrebbe poi essere svolta da controller, Chief Accounting Officer, responsabili della pianificazione e analisi finanziarie (FP&A), funzioni di audit interno, IT, sicurezza e ufficio acquisti. Il CFO non è necessariamente chiamato a guidare il progetto pilota in prima persona, ma, prima del suo avvio, deve stabilire quali evidenze oggettive ne giustificheranno l'implementazione.

Adottare una catena del valore in tre fasi

Il valore dell'IA in ambito Finance va dimostrato seguendo quest'ordine:

L’ideale è non passare direttamente dai risultati del modello ai margini, ai ricavi o al valore aziendale. Sebbene possa fornire informazioni utili per prendere una decisione, il software non può eseguire autonomamente attività di determinazione dei prezzi, acquisto, assunzione o altre decisioni commerciali. Un business case che stabilisce un nesso diretto tra i risultati generati dall'IA e le performance finanziarie finirà per nascondere le ipotesi più importanti.

Passo 2

Creare un portafoglio di casi d'uso

L'IA per la funzione Finance si articola in una serie di decisioni circoscritte sui flussi di lavoro, ciascuna con caratteristiche economiche e rischi specifici. Spesso l'opportunità con il ritorno economico più elevato non coincide con quella caratterizzata dalla maggiore visibilità.

Ognuno dei casi presi in considerazione va valutato sulla base di cinque domande

La questione dei volumi è importante, perché "gravoso" e "costoso" sono due concetti distinti. Un'attività di 30 minuti eseguita 400 volte al mese equivale a 200 ore di lavoro. La stessa attività, eseguita sei volte a trimestre, equivale ad appena 3 ore. Se nel primo caso potrebbe essere giustificato un business case per l’automazione, nel secondo potrebbe bastare intervenire sul processo.

• 200 ore

  di lavoro al mese per un’attività di 30 minuti eseguita 400 volte al mese: può giustificare un business case per l’automazione

• 3 ore

  a trimestre per la stessa attività eseguita sei volte a trimestre: potrebbe bastare intervenire sul processo

Anche il costo delle verifiche è importante, perché può annullare il vantaggio apparente. Per verificare una proposta di riconciliazione, spesso basta confrontare due importi. Una relazione descrittiva generata dall’IA, invece, può richiedere l’intervento di un analista esperto che ne ricostruisca il ragionamento prima che possa essere utilizzata. Entrambe le attività possono figurare sotto l’etichetta "IA", ma hanno implicazioni economiche molto diverse.

Anche la complessità dei dati rappresenta un costo. Ogni ulteriore sistema sorgente, piano contabile, mappatura manuale e procedura di gestione delle eccezioni comporta attività di implementazione e manutenzione. Se la funzionalità è utilizzabile solo dopo che il team Finance ha predisposto manualmente l'ambiente, è necessario includere tale attività nel business case anziché considerarla come una configurazione iniziale a costo zero.

Dare priorità ai casi d'uso meno appariscenti

I commenti destinati al CdA, le sintesi per il management e le domande formulate con linguaggio naturale fanno una buona impressione nelle demo, perché i risultati sono comprensibili a tutti. Tuttavia, richiedono anche evidenze solide: i risultati sono visibili, il costo di un errore plausibile è elevato e la verifica è spesso onerosa.

I primi investimenti più efficaci tendono a essere i meno appariscenti:

• Corrispondenza delle riconciliazioni
• Classificazione delle eccezioni
• Rilevamento di anomalie
• Elenco dei casi da sottoporre a verifica

Lo stesso vale per qualsiasi altra attività ad alto volume per la quale siano già disponibili evidenze e un revisore possa scartare facilmente una proposta errata

Passo 3

Trasformare le promesse dei venditori in ipotesi verificabili

Una dichiarazione merita attenzione solo se la funzione Finance è in grado di verificarla e, se necessario, smentirla. Prima di prendere per buona una dichiarazione sui benefici, occorre chiedere informazioni su parametri quali processo operativo, quantità, unità di misura, situazione di riferimento, periodo, popolazione coinvolta e fonte delle evidenze.

Distinguere le metriche che spesso i fornitori tendono a confondere

Chiedi inoltre quale tecnologia esegua concretamente la fase mostrata nella demo. Le regole deterministiche, i modelli statistici e quelli generativi possono infatti generare errori di vario tipo, e pertanto richiedono evidenze diverse. Di fatto, un singolo prodotto può contenere tutte e tre queste tecnologie. La valutazione deve quindi concentrarsi sul comportamento della singola funzionalità, non sull’etichetta attribuita al prodotto.

Passo 4

Quattro test da eseguire prima di adottare la soluzione

Ogni progetto pilota dovrebbe rispondere a quattro domande. Prima di avviare i test, per ciascuna domanda va definita una condizione di esclusione.

1. Flusso di lavoro: Il flusso di lavoro è definito in modo chiaro?
2. Dati: Funziona sui nostri dati?
3. Risultati: I risultati sono giustificabili?
4. Controlli: L'azione può essere sottoposta a controlli adeguati?

Test 1: Flusso di lavoro: è definito e ha un responsabile?

Prima della demo, redigi una scheda sintetica che descriva il flusso di lavoro. Identifica l'attività, l'utente, il responsabile di prodotto, il risultato atteso, la decisione che ne consegue, il rischio in caso di errore e il sistema in cui viene svolta l'attività. "Riconciliazione interaziendale per le società del settore manifatturiero" descrive un flusso di lavoro. "Chiusura" no.

La descrizione del rischio in caso di errore determina il livello di evidenze e di controlli richiesto. La redazione di commenti interni non deve essere sottoposta agli stessi controlli previsti per una scrittura contabile rilevante; allo stesso modo, a una scrittura contabile rilevante non si possono applicare i criteri meno rigorosi previsti per la redazione dei commenti.

Test 2: Dati: la soluzione funziona nelle condizioni di produzione effettive?

Crea il set di dati per il test sulla base delle condizioni reali dell'azienda, non dell'ambiente di riferimento predisposto dal fornitore. Includi anche le complicazioni che normalmente ostacolano l'automazione:

• Svariati sistemi diversi
• Piani contabili differenti
• Periodi contabili aperti e chiusi
• Rettifiche di bilancio
• Valute diverse
• Record non mappati
• Documenti scansionati
• Record notoriamente errati

Quindi metti alla prova il fornitore omettendo le risposte corrette.

Conta le anomalie individuate, quelle non rilevate e i falsi positivi. Più che essere una metrica secondaria per valutare la qualità, i falsi positivi determinano se la funzionalità in questione riduce effettivamente il carico di lavoro oppure crea una nuova coda di attività da verificare. Registra tutte le mappature e le operazioni manuali preliminari effettuate dal fornitore. Non correggere i dati prima del test, a meno che tale operazione non sia prevista dal processo operativo.

Test 3: Risultati: la funzione Finance è in grado di giustificarli?

Non confondere risposta, spiegazione, evidenze, audit trail e riproducibilità. Un risultato destinato all’uso in produzione deve offrire un livello di documentazione adeguato alle conseguenze del suo utilizzo. Per i risultati rilevanti, la funzione Finance dovrebbe poter identificare:

• Record di origine
• Operazione eseguita
• Input rilevanti ed esclusioni
• Versione del modello o delle regole
• Storico delle revisioni
• Un numero di evidenze raccolte sufficiente a riprodurre o ricostruire il risultato a posteriori

Se le evidenze sono disponibili soltanto nell'ambiente del fornitore o solo per la versione corrente del modello, la tracciabilità ai fini dell’audit ha una durata limitata. Prima di firmare il contratto, negozia i diritti di conservazione e di esportazione dei dati.

Test 4: Controlli: il sistema è in grado di applicare il modello operativo previsto?

I controlli devono essere commisurati alle azioni che la funzionalità è in grado di eseguire. Per le scritture contabili rilevanti e i risultati di rendicontazione, la funzione Finance richiede in genere:

• Approvazione prima che l'azione diventi effettiva
• Controllo adeguato degli accessi
• Registrazioni sufficienti a ricostruire gli eventi
• Separazione dei ruoli tra chi propone/configura e chi approva

Queste raccomandazioni riguardano la governance, non i requisiti di legge. Spetta ai responsabili dei controlli interni definire nel dettaglio come strutturarli.

Verifica l'efficacia dei controlli chiedendo al sistema di eseguire un'operazione vietata. Se la persona che ha configurato il flusso di lavoro non è autorizzata ad approvare il risultato, prova comunque a farlo. Il rifiuto da parte del sistema costituisce un'evidenza concreta. La semplice esistenza di un documento che descrive le policy non è invece una prova sufficiente.

Passo 5

Tradurre i guadagni in termini di produttività in una decisione economica

L'errore più comune nei business case relativi all'IA in ambito Finance è considerare le ore risparmiate come costi effettivamente abbattuti. Un progetto pilota può liberare 200 ore al mese senza modificare in alcun modo la struttura dei costi. La tecnologia può aver funzionato alla perfezione, ma, semplicemente, la funzione Finance non ha mai deciso come utilizzare la capacità liberata.

Esamina ogni dichiarazione sulle ore risparmiate secondo quattro livelli

La capacità recuperata e destinata a un uso preciso può avere tre destinazioni giustificabili:

Alleggerire il carico di lavoro può essere una scelta legittima, in particolare per i team sovraccarichi, ma occorre classificarla correttamente. Dire "Abbiamo scelto di restituire capacità operativa al team" è diverso da sostenere di aver ottenuto un risparmio economico quantificabile.

Passo 6

Giungere a una decisione: procedere, rivedere o interrompere?

Ogni valutazione dovrebbe concludersi con una delle tre decisioni, formalizzata per iscritto e corredata dalle relative evidenze.

Il successo di un progetto pilota dimostra la validità della soluzione solo nell'ambito testato, non la sua idoneità a essere estesa a tutta l'azienda. La possibilità di trasferire la soluzione ad altre entità, sistemi, lingue o varianti di processo costituisce un’ipotesi distinta, da verificare separatamente. Prima di estendere l’implementazione, occorre testare la soluzione almeno in un secondo ambiente, scelto intenzionalmente per la sua complessità, e non nel team di volontari più collaborativo.

Utilizza un'unica scheda di valutazione per tutti i progetti pilota

È possibile che un progetto pilota ottenga un buon punteggio complessivo ma, al contempo, presenti qualche aspetto che ne rende inaccettabile l'implementazione. Utilizza la griglia di valutazione sottostante per mettere a confronto i casi candidati sulla base di criteri coerenti, ma valuta separatamente i requisiti indispensabili per la messa in produzione. Il punteggio indica la solidità relativa della funzionalità; ma sono i requisiti di implementazione a determinare se quest'ultima è effettivamente pronta per la messa in produzione. Valuta ogni dimensione con un punteggio da 0 a 3:

• 0 = nessuna evidenza
• 1 = dichiarazione del fornitore
• 2 = evidenze raccolte dal progetto pilota
• 3 = evidenze verificabili da un revisore indipendente senza l’intervento del fornitore

Un punteggio elevato, da solo, non è sufficiente. Prima che una funzionalità possa passare alla fase di messa in produzione, è necessario che soddisfi determinati requisiti. Utilizza il punteggio ponderato per confrontare i casi considerati e i requisiti di implementazione per stabilire se una funzionalità è pronta per essere adottata.

Passo 7

Comunicare la decisione in modo efficace

I CdA e i comitati di audit valutano la qualità del giudizio del management:

• Che cosa fa la funzionalità e quali sono i suoi limiti
• Che cosa è cambiato nel sistema dei controlli
• Chi è responsabile del risultato
• Quale valore è stato effettivamente dimostrato
• Che cosa potrebbe indurre il management a restringere o interrompere l’implementazione

In caso di decisione di procedere, rispondi a quattro domande

• Ambito di applicazione: che cosa fa e che cosa non fa la funzionalità?
• Controlli: in quali fasi è necessaria l’approvazione umana e quali operazioni impedisce il sistema?
• Valore: qual è il beneficio netto nell’ambito effettivamente testato (non la stima del fornitore né il risparmio lordo di ore)?
• Monitoraggio: che cosa è stato definito relativamente a responsabile, frequenza dei controlli, rischio residuo e condizioni di interruzione o ripristino concordate in anticipo?

In caso di decisione di interrompere, parti dal motivo che l'ha determinata

Esplicita la decisione (senza ripercorrere l'intero progetto pilota), le evidenze che hanno reso inaccettabile l'implementazione, l’eventuale possibilità di mantenere un’attività più circoscritta e il costo sostenuto per la valutazione. Un progetto pilota interrotto non dimostra il fallimento del programma di IA: dimostra che i criteri di valutazione funzionano.

In caso di implementazione parziale, spiega con precisione il perimetro

Specifica che cosa è incluso e che cosa è escluso, perché è stato definito quel perimetro e quali evidenze sarebbero necessarie per ampliarlo. Evita, però, di ampliare il perimetro durante la riunione. Così facendo, infatti, c'è il rischio che un progetto pilota controllato si trasformi in una dipendenza priva di adeguata governance.

Conclusione

Conclusione

Questo toolkit è basato su un principio semplice: l'IA deve essere valutata con gli stessi criteri che la funzione Finance applica a qualsiasi altro investimento.

Più che chiederti se una funzionalità sia di un certo livello, occorre valutare se migliora uno specifico flusso di lavoro, produce risultati affidabili per la funzione Finance e genera valore misurabile. Le decisioni valide si basano sulle evidenze, non sulle demo. Occorre capire in quali contesti una funzionalità può fare la differenza, dove non è adatta e quali controlli sono necessari prima di metterla in produzione.

L'esito della valutazione deve essere chiaro. Alcuni casi d'uso giustificheranno un’implementazione più ampia; altri richiederanno un perimetro più ristretto, ulteriori test oppure non giustificheranno altri investimenti. Questo approccio rigoroso è un punto di forza, non un limite. In definitiva, la funzione Finance deve applicare gli stessi criteri a ogni progetto pilota, così da concentrare le risorse sulle funzionalità più appropriate. Quelle, cioè, che risolvono problemi concreti, favoriscono decisioni migliori e superano rigorosi controlli anche a distanza di tempo, dopo che si è spento l’entusiasmo per la demo iniziale.