La qualità del bilancio dipende sempre più da sistemi capaci di selezionare dati, costruire stime e suggerire classificazioni. La stessa tecnologia che rende più efficiente il controllo può diventare il punto di ingresso di una frode capace di alterare l’informazione finanziaria senza lasciare le tracce tipiche della manipolazione contabile tradizionale.
Indice degli argomenti
Il bilancio entra nell’era dei sistemi intelligenti
La digitalizzazione della contabilità ha attraversato fasi diverse. La prima ha riguardato la sostituzione dei registri manuali con applicativi gestionali. La seconda ha integrato i flussi amministrativi all’interno degli ERP, rendendo possibile la riconciliazione automatica tra acquisti, vendite, magazzino, tesoreria e fiscalità. La fase attuale introduce sistemi capaci di apprendere dai dati e di intervenire su passaggi che richiedono valutazioni, assunzioni e giudizi professionali. Modelli predittivi stimano la probabilità di insolvenza, individuano anomalie nelle registrazioni, classificano documenti, suggeriscono accantonamenti, supportano il calcolo delle perdite attese, elaborano scenari di fair value e producono parti dell’informativa di bilancio.
Il cambiamento investe la natura stessa del dato contabile. Una registrazione tradizionale può essere ricondotta a un documento, a un’autorizzazione e a una sequenza di operazioni. Un output algoritmico deriva invece da una catena più ampia: fonti informative, trasformazioni, criteri di pulizia, variabili selezionate, versione del modello, parametri, soglie, regole di aggiornamento e interventi umani. La correttezza del risultato dipende dalla tenuta dell’intera catena e il documento finale può essere formalmente regolare anche quando uno degli elementi a monte è stato alterato.
Per questa ragione la cybersecurity applicata all’informazione finanziaria non può limitarsi alla riservatezza e alla disponibilità. Data breach e ransomware restano rischi rilevanti, ma l’integrità assume un peso specifico crescente, un sistema contabile indisponibile genera un’interruzione evidente mentre un sistema disponibile che elabora dati contaminati continua a funzionare e produce risultati credibili. La frode diventa più difficile da riconoscere proprio perché sfrutta l’affidabilità attribuita all’automazione.
Il problema riguarda imprese industriali, banche, assicurazioni, società quotate, pubbliche amministrazioni e operatori che forniscono software o servizi contabili in cloud. Coinvolge anche revisori, sindaci, organismi di vigilanza, funzioni di internal audit e autorità di controllo. Ogni soggetto che fonda una decisione su una stima prodotta da un modello deve poter rispondere a una domanda semplice solo in apparenza, ovvero quali dati e quali trasformazioni hanno determinato quel risultato.
Quando la frode si sposta a monte
La frode contabile classica modifica direttamente la rappresentazione economica dell’impresa. Può ricorrere a fatture inesistenti, ricavi anticipati, passività occultate, valutazioni irragionevoli, operazioni con parti correlate non correttamente rappresentate o registrazioni di assestamento prive di giustificazione. La traccia documentale può essere falsa, incompleta o costruita ex post, ma resta individuabile attraverso il confronto tra scritture, documenti, conferme esterne e flussi finanziari.
L’impiego dell’intelligenza artificiale consente una diversa modalità di intervento. L’autore della manipolazione può agire sui dati utilizzati per addestrare il sistema, sui dati che alimentano il modello durante l’esercizio, sulle etichette impiegate per distinguere operazioni lecite e anomale, sulle regole di selezione delle variabili oppure sui meccanismi di aggiornamento. Il modello conserva una struttura tecnicamente funzionante e continua a produrre output coerenti con i dati che riceve. La falsificazione viene incorporata nel processo di calcolo, prima che il risultato raggiunga il libro giornale, il prospetto di valutazione o la nota integrativa.
La letteratura sull’adversarial machine learning definisce il data poisoning come l’alterazione intenzionale dei dati di addestramento o del processo di apprendimento al fine di modificare il comportamento del modello (Biggio, Nelson e Laskov, 2012; Jagielski et al., 2018; NIST, 2024). L’attacco può degradare in modo generalizzato le prestazioni, orientare una specifica classe di decisioni o inserire una backdoor che si attiva soltanto in presenza di determinate caratteristiche. Nel dominio contabile, l’obiettivo potrebbe consistere nel ridurre la sensibilità di un sistema antifrode verso un particolare schema di pagamento, abbassare la probabilità di default attribuita a una categoria di clienti, spostare la soglia che determina un accantonamento o rendere statisticamente ordinarie registrazioni create per occultare un’operazione.
Una tecnica particolarmente insidiosa consiste nell’introdurre modifiche graduali. Piccole variazioni ripetute nel tempo possono influenzare un modello senza generare scostamenti immediatamente incompatibili con l’andamento storico. L’effetto emerge nella somma di molte decisioni: minori svalutazioni, eccezioni approvate con maggiore frequenza, anomalie escluse dalla revisione, fondi rischi alimentati con intensità insufficiente. La rappresentazione contabile si allontana dalla realtà economica attraverso passaggi individualmente plausibili.
Il data poisoning applicato alla materia contabile
Il data poisoning viene spesso descritto come un problema dei laboratori di machine learning. La sua applicazione ai processi finanziari richiede invece attenzione perché numerose grandezze di bilancio derivano da modelli di classificazione o regressione. Le perdite attese sui crediti, le previsioni di cash flow, la valutazione di strumenti complessi, il calcolo di impairment, la stima di resi e garanzie, la rilevazione di frodi e la selezione delle journal entries da sottoporre a verifica sono esempi nei quali il dato storico influenza direttamente una decisione corrente.
Nel credit scoring, un dataset contaminato può indurre una sottostima sistematica del rischio associato a determinati profili. L’effetto contabile non coincide soltanto con una decisione di finanziamento errata. Può propagarsi alla classificazione delle esposizioni, alla determinazione delle rettifiche, alla misurazione del rischio e alla comunicazione agli organi aziendali. Nei modelli antifrode, l’inserimento di operazioni fraudolente etichettate come lecite può aumentare i falsi negativi e ridurre la probabilità che transazioni analoghe vengano esaminate. Nei sistemi di anomaly detection applicati alle scritture contabili, la manipolazione può modificare ciò che il modello considera “normale”.
La ricerca ha già mostrato che reti neurali e autoencoder possono essere utilizzati per individuare registrazioni anomale e, sul versante opposto, per generare scritture capaci di eludere sistemi automatici di controllo. Gli studi sui cosiddetti accounting deepfakes non dimostrano l’esistenza di una diffusione generalizzata di questa pratica nelle imprese, ma offrono una prova di fattibilità tecnica: è possibile creare journal entries sintetiche che conservano caratteristiche compatibili con i dati reali e risultano meno visibili ai controlli automatizzati (Schreyer et al., 2019a; Schreyer et al., 2019b).
Il punto giuridico è molto rilevante e gli articoli 2621 e 2622 del codice civile sanzionano le false comunicazioni sociali quando la rappresentazione non corrisponde al vero nei termini previsti dalla norma. La tecnologia utilizzata per produrre l’informazione non modifica l’esigenza di accertare materialità, consapevolezza, finalità e responsabilità. Modifica però il percorso probatorio. La condotta può consistere nella manipolazione di un parametro, nell’omissione intenzionale di una fonte, nell’alterazione di un set di training o nell’approvazione consapevole di un modello privo di controlli adeguati. Il falso può nascere prima della registrazione e propagarsi in modo automatico su migliaia di operazioni.
Anche la responsabilità civilistica degli amministratori e degli organi di controllo deve essere letta alla luce di questa trasformazione. Gli obblighi di diligenza e di adeguatezza degli assetti organizzativi richiedono che i sistemi utilizzati per produrre informazioni rilevanti siano governati, documentati e sottoposti a verifiche proporzionate. L’affidamento su un modello non esonera dall’obbligo di comprenderne la funzione, i limiti e le dipendenze informative. Quando una stima incide in modo significativo sul bilancio, la provenienza dei dati e la robustezza del processo diventano elementi della qualità dell’assetto amministrativo e contabile.
Dalle stime di bilancio ai sistemi antifrode
Le aree più esposte condividono una caratteristica, l’output non deriva semplicemente da una regola deterministica facilmente verificabile, ma da una valutazione probabilistica. L’ISA Italia 540 impone al revisore di affrontare il rischio connesso alle stime contabili e alla relativa informativa, considerando metodi, assunzioni, dati e incertezza. Quando il metodo incorpora machine learning, la verifica non può fermarsi alla ragionevolezza del risultato finale. Occorre esaminare la qualità dei dati, la logica con cui sono stati selezionati, la stabilità del modello e le modifiche intervenute nel periodo.
Un secondo ambito riguarda il management override of controls. L’ISA Italia 240 identifica la possibilità che la direzione eluda i controlli come un rischio presente in ogni revisione. Nei sistemi intelligenti l’override può assumere una forma meno visibile dell’inserimento manuale di una scrittura. Un amministratore o un insider con accessi adeguati può modificare una soglia, escludere una variabile, approvare un aggiornamento non testato, alterare il campione utilizzato per la validazione o intervenire sul processo che attribuisce le etichette. La modifica tecnica può essere presentata come ottimizzazione del modello, mentre produce un effetto contabile favorevole e prevedibile.
Le operazioni con parti correlate richiedono un’attenzione distinta, disciplinata dall’ISA Italia 550. Un sistema di analisi delle relazioni societarie o dei pagamenti può essere addestrato a riconoscere collegamenti noti, ma fallire quando le relazioni sono indirette, recenti o intenzionalmente schermate. Se i dati anagrafici sono incompleti o la logica di entity resolution viene indebolita, l’algoritmo può non collegare transazioni che avrebbero richiesto una valutazione specifica. La contaminazione può quindi colpire anche il processo di identificazione del perimetro, non soltanto il calcolo di una grandezza.
La stessa dinamica riguarda antiriciclaggio, monitoraggio delle transazioni e sistemi di rilevazione delle frodi. Un modello che apprende dai casi confermati può essere influenzato dalla qualità delle segnalazioni, dalle decisioni degli analisti e dai feedback successivi. Se l’attaccante riesce a condizionare il circuito di apprendimento, il sistema può ridurre progressivamente l’attenzione verso comportamenti di interesse. La manipolazione del dato e la manipolazione del controllo finiscono per coincidere.
Perché l’audit tradizionale fatica a vedere la manipolazione
I principi di revisione offrono una metodologia solida e già richiedono comprensione dell’ambiente informatico, valutazione dei rischi, scetticismo professionale e acquisizione di elementi probativi sufficienti e appropriati. Il problema riguarda l’ampiezza delle competenze e degli oggetti da verificare. Le procedure costruite attorno a documenti, autorizzazioni e campioni di transazioni devono essere estese a dataset, pipeline, versioni di codice, registri di modifica e dipendenze da fornitori esterni.
La campionatura conserva utilità quando il rischio è distribuito in modo ragionevolmente omogeneo e la popolazione è stabile. Un attacco algoritmico può essere progettato per colpire una sottopopolazione molto specifica o attivarsi solo al verificarsi di una combinazione rara. L’analisi di un campione tradizionale può non intercettare il comportamento. Gli strumenti di audit data analytics consentono di testare l’intera popolazione e di ricostruire sequenze, eccezioni e cluster, ma la capacità di elaborare il 100 per cento delle registrazioni non garantisce da sola l’affidabilità. Se il modello di controllo è stato addestrato su dati contaminati, l’analisi completa può replicare il medesimo errore su tutta la popolazione.
Il revisore deve quindi distinguere tra l’uso della tecnologia per svolgere procedure di audit e l’audit della tecnologia che produce l’informazione finanziaria. Nel primo caso gli strumenti automatizzati aumentano copertura e profondità. Nel secondo occorre verificare un sistema socio-tecnico composto da dati, software, persone, autorizzazioni e processi decisionali. L’IAASB ha pubblicato materiali di supporto sull’impiego di automated tools and techniques, riconoscendo il valore dell’analisi di grandi volumi di dati e l’esigenza di documentare procedure, eccezioni e giudizi. Il passaggio successivo consiste nel definire con maggiore precisione le procedure da applicare quando il modello sottoposto a revisione è esposto ad attacchi adversarial o a manipolazioni interne.
La black box non deve essere trattata come un alibi tecnico. Molti modelli possono essere sottoposti a test di robustezza, analisi di sensibilità, confronto tra versioni e verifica delle fonti. Per i modelli più complessi, l’assenza di una spiegazione completa di ogni parametro non impedisce di valutare governance, provenienza dei dati, segregazione degli accessi, qualità della validazione e coerenza degli output. L’obiettivo dell’audit non è ricostruire ogni operazione matematica, ma ottenere evidenze sufficienti sulla capacità del sistema di produrre risultati affidabili e sulla possibilità di rilevare deviazioni intenzionali.
Norme europee: responsabilità distribuite e ambiti da distinguere
Il quadro europeo offre riferimenti utili, purché venga applicato con precisione. Il regolamento (UE) 2024/1689, noto come AI Act, introduce obblighi di gestione del rischio, data governance, documentazione tecnica, registrazione, supervisione umana, accuratezza, robustezza e cybersecurity per i sistemi qualificati ad alto rischio. L’allegato III include, tra gli altri, i sistemi utilizzati per valutare l’affidabilità creditizia delle persone fisiche, salvo specifiche eccezioni, e alcune applicazioni assicurative. Un software contabile o un modello di stima di bilancio non rientra automaticamente nella categoria high-risk per il solo fatto di utilizzare intelligenza artificiale. La qualificazione dipende dalla funzione, dal settore, dall’impatto e dalle condizioni previste dal regolamento.
Questa distinzione evita due errori opposti. Il primo consiste nell’estendere senza base giuridica gli obblighi dei sistemi ad alto rischio a ogni applicazione amministrativa. Il secondo consiste nel ritenere irrilevanti i requisiti dell’AI Act quando il sistema non ricade nell’allegato III. Anche in assenza della classificazione high-risk, la governance del dato, la sicurezza, la trasparenza contrattuale e la responsabilità degli organi aziendali restano disciplinate da norme settoriali, obblighi organizzativi e principi professionali.
Il calendario di applicazione è stato oggetto di revisione. Il Digital Omnibus on AI, approvato dal Parlamento europeo in prima lettura il 16 giugno 2026 e avviato verso il completamento formale dell’iter, ha previsto il rinvio degli obblighi relativi ai sistemi ad alto rischio al 2 dicembre 2027 per i sistemi standalone dell’allegato III e al 2 agosto 2028 per quelli incorporati in prodotti disciplinati dalla normativa europea di sicurezza. Il rinvio non sospende l’esigenza di preparazione. Inventario dei modelli, classificazione, data lineage, gestione dei fornitori e processi di validazione richiedono tempi incompatibili con un adeguamento avviato a ridosso della scadenza.
Per il settore finanziario, DORA assume un rilievo diretto. Il regolamento (UE) 2022/2554 richiede un quadro documentato di gestione del rischio ICT, attribuisce responsabilità all’organo di gestione e impone protezione di disponibilità, autenticità, integrità e riservatezza dei dati. Prevede inoltre mappatura degli asset, gestione del rischio delle terze parti e test di resilienza operativa. Un modello utilizzato per decisioni contabili o di rischio rientra nell’insieme degli asset e dei processi che devono essere identificati e governati.
La direttiva NIS2, recepita in Italia con il decreto legislativo 4 settembre 2024, n. 138, opera invece in relazione ai soggetti compresi nel proprio ambito. Non ogni impresa e non ogni software contabile ricadono nella disciplina. Per i soggetti essenziali e importanti, le misure di gestione del rischio cyber comprendono sicurezza della supply chain, gestione delle vulnerabilità, controllo degli accessi, continuità operativa e valutazione dell’efficacia delle misure. La legge italiana 23 settembre 2025, n. 132, completa il quadro nazionale sull’intelligenza artificiale e richiama un impiego corretto, trasparente e responsabile dei sistemi, in coerenza con il regolamento europeo.
Il verificatore algoritmico come funzione di garanzia
La risposta organizzativa può essere sintetizzata nella figura del verificatore algoritmico. L’espressione non indica necessariamente una nuova professione regolamentata da istituire in tempi brevi. Descrive una funzione indipendente, esercitata da un professionista o da un gruppo multidisciplinare, incaricata di verificare i sistemi algoritmici che incidono sulla formazione del bilancio, sui controlli finanziari e sulle decisioni suscettibili di produrre effetti economici rilevanti.
Il verificatore algoritmico deve collegare quattro linguaggi che oggi tendono a rimanere separati. Il primo è quello contabile, necessario per comprendere materialità, stime, principi di valutazione, processi di chiusura e rappresentazione dell’informazione. Il secondo è quello giuridico, indispensabile per qualificare responsabilità, obblighi di governance, rilevanza penale delle condotte e requisiti della prova. Il terzo è quello informatico-forense, che consente di acquisire log, immagini di sistema, configurazioni, versioni e metadati preservandone autenticità e integrità. Il quarto è quello del machine learning, utile per valutare dataset, feature engineering, metriche, drift, robustezza, backdoor e possibili attacchi di poisoning.
La funzione dovrebbe partire dall’inventario. Un’impresa deve sapere quali modelli utilizza, quale processo supportano, chi li ha sviluppati, dove sono eseguiti, quali dati ricevono e quali decisioni influenzano. A questa mappa deve seguire la classificazione della rilevanza contabile e regolatoria. Un algoritmo che ordina le fatture per agevolare il lavoro dell’ufficio amministrativo presenta un rischio diverso da un modello che determina le perdite attese su un portafoglio crediti o blocca le transazioni considerate anomale.
Il secondo oggetto di verifica è la provenienza del dato. Devono essere ricostruiti origine, titolarità, trasformazioni, controlli di qualità, criteri di esclusione, versioni e autorizzazioni. Un dataset privo di lineage non consente di stabilire chi abbia introdotto un’anomalia e in quale momento. Il terzo oggetto riguarda il modello: architettura, versione, parametri, soglie, ambiente di esecuzione, risultati dei test e modifiche intervenute. Il quarto riguarda l’uso umano: chi può approvare un aggiornamento, chi può sovrascrivere un risultato, chi gestisce le eccezioni e come viene documentata una decisione difforme dall’output.
La verifica deve includere test adversarial proporzionati. Non occorre trasformare ogni revisione in un’attività di penetration testing. È però necessario valutare se piccole alterazioni dei dati, modifiche delle etichette, esclusione di variabili o cambiamenti delle soglie possano produrre effetti materiali. La riproducibilità rappresenta un requisito essenziale: a parità di dati, versione e configurazione, il sistema deve consentire di ricostruire il risultato oppure spiegare con precisione le cause della variazione.
La prova digitale e la ricostruzione del nesso causale
La manipolazione algoritmica pone un problema probatorio più complesso della semplice individuazione di un output errato. Occorre ricostruire il rapporto tra condotta, modifica tecnica, effetto sul modello e conseguenza contabile. Un bilancio inesatto può dipendere da un errore di progettazione, da dati incompleti, da un cambiamento del fenomeno osservato, da negligenza nella validazione o da un intervento intenzionale. La qualificazione giuridica richiede di distinguere queste ipotesi.
La prova deve essere costruita lungo la catena di produzione dell’informazione. Sono rilevanti i log di accesso e amministrazione, la cronologia delle versioni, i repository di codice, i dataset utilizzati, gli hash dei file, le autorizzazioni, i ticket di modifica, i verbali di approvazione, i risultati dei test, le comunicazioni tra sviluppatori e funzioni aziendali e le evidenze relative alle eccezioni. Nei sistemi forniti come servizio, assumono rilievo i contratti, gli accordi sui livelli di servizio, le responsabilità per gli aggiornamenti e la possibilità di ottenere dati tecnici dal provider.
La legge 18 marzo 2008, n. 48, che ha ratificato la Convenzione di Budapest, ha rafforzato nel sistema italiano l’attenzione alle modalità di acquisizione e conservazione della prova informatica. Nei procedimenti che riguardano modelli di intelligenza artificiale, la corretta preservazione deve essere accompagnata dalla capacità di rendere comprensibile il significato dell’evidenza tecnica. Un log dimostra un accesso; non dimostra da solo la finalità della modifica. Un cambiamento di soglia può essere legittimo; diventa rilevante quando è collegato alla consapevolezza dell’effetto contabile e all’assenza di una motivazione tecnica coerente.
Il verificatore algoritmico svolge quindi anche una funzione di traduzione probatoria. Deve trasformare elementi come feature, pesi, drift e metriche in proposizioni verificabili: quale popolazione è stata interessata, quale grandezza è cambiata, con quale intensità, in quale periodo e attraverso quale intervento. La qualità dell’accertamento dipende dalla capacità di collegare il livello informatico al livello economico e a quello soggettivo.
Governance aziendale e controllo interno
L’introduzione di sistemi intelligenti nei processi contabili richiede un aggiornamento dei modelli di governance. Il rischio algoritmico deve essere inserito nel sistema di controllo interno e nella valutazione dei rischi aziendali, con responsabilità definite tra organo amministrativo, funzione finanziaria, IT, cybersecurity, risk management, compliance, internal audit e revisione esterna. La frammentazione delle responsabilità rappresenta uno dei principali fattori di debolezza: la funzione finance conosce l’effetto sul bilancio ma non sempre il modello; la funzione IT conosce l’architettura ma può non valutare la materialità contabile; il fornitore conosce il codice ma non il processo decisionale dell’impresa.
I modelli di organizzazione, gestione e controllo adottati ai sensi del decreto legislativo 8 giugno 2001, n. 231, dovrebbero considerare i processi nei quali un sistema algoritmico può facilitare, occultare o amplificare condotte rilevanti. L’aggiornamento non richiede una sezione generica dedicata all’intelligenza artificiale. Richiede l’analisi dei processi concreti: autorizzazione dei pagamenti, gestione dei crediti, fiscalità, rapporti con parti correlate, valutazioni, segnalazioni e reporting. Per ciascun processo occorre identificare dati, modello, soggetti autorizzati, controlli preventivi e modalità di escalation.
L’Organismo di Vigilanza deve poter ottenere informazioni sui sistemi che incidono sulle aree di rischio, mentre il collegio sindacale e il comitato controllo e rischi devono ricevere una rappresentazione comprensibile dell’esposizione algoritmica. Il revisore legale deve valutare l’impatto dei modelli sulla strategia di audit e la necessità di coinvolgere specialisti. L’indipendenza del controllo richiede inoltre che chi valida il modello non coincida integralmente con chi lo sviluppa o ne beneficia operativamente.
Un programma maturo comprende inventario e classificazione dei modelli, controllo degli accessi, segregazione dei compiti, tracciabilità delle modifiche, test periodici di robustezza, monitoraggio del drift, procedure di rollback, gestione delle terze parti e conservazione delle evidenze. La documentazione deve essere sufficiente a spiegare come una decisione sia stata prodotta e chi ne abbia autorizzato l’impiego. L’obiettivo è ridurre la distanza tra affidabilità tecnica e responsabilità giuridica.
Formazione e capacità istituzionale
Le competenze richieste non possono essere concentrate in una sola disciplina. Il revisore che ignora il funzionamento dei dati rischia di considerare affidabile un output soltanto perché proviene da un sistema complesso. Il tecnico che non conosce principi contabili e materialità può individuare un’anomalia senza comprenderne l’effetto sul bilancio. Il giurista privo di alfabetizzazione algoritmica può incontrare difficoltà nel formulare correttamente il quesito tecnico e nel valutare il nesso causale.
Servono percorsi post-laurea e programmi di formazione avanzata che integrino revisione legale, diritto penale dell’economia, diritto societario, cybersecurity, digital forensics, data analytics e machine learning auditing. La parte teorica deve essere affiancata da laboratori su dataset contabili, ricostruzione di pipeline, analisi di log, test di poisoning, valutazione della qualità del dato e redazione di relazioni tecniche utilizzabili in sede giudiziaria o ispettiva.
La formazione riguarda anche magistratura, autorità di vigilanza, amministrazioni di controllo e polizia economico-finanziaria. Le indagini future potranno richiedere unità miste nelle quali competenze contabili, investigative e informatiche operino secondo un metodo comune. La capacità istituzionale non dipende soltanto dall’acquisto di strumenti. Dipende dalla disponibilità di protocolli, tassonomie, standard di acquisizione e criteri condivisi per valutare l’affidabilità di un modello.
Una certificazione del verificatore algoritmico potrà essere discussa quando requisiti, responsabilità e metodologie avranno raggiunto una sufficiente stabilità. Nell’immediato, la priorità consiste nel definire la funzione, rendere espliciti gli oggetti del controllo e costruire équipe in grado di operare con indipendenza. La regolamentazione professionale può seguire; la necessità operativa è già presente.
Interrogare l’algoritmo prima che diventi prova di se stesso
L’intelligenza artificiale può migliorare qualità, tempestività e profondità del controllo contabile. Può analizzare popolazioni complete, riconoscere pattern invisibili alle procedure manuali e assistere i professionisti nelle aree caratterizzate da elevata complessità. La stessa capacità produce una nuova esposizione: quando il modello viene manipolato, l’errore acquista velocità, scala e apparente oggettività.
Il data poisoning applicato alla contabilità sposta l’attenzione dalla singola registrazione alla catena che genera la registrazione. La verifica deve risalire alle fonti, ai criteri di trasformazione, alle versioni del modello, alle autorizzazioni e ai feedback utilizzati per l’apprendimento. La conformità formale del documento finale perde valore quando non è possibile dimostrare l’integrità del processo che lo ha prodotto.
Il verificatore algoritmico risponde a questa esigenza. La sua funzione consiste nel rendere auditabile il sistema intelligente, collegando robustezza tecnica, correttezza contabile e responsabilità giuridica. Non sostituisce il revisore, il forensic accountant, il data scientist o l’esperto di cybersecurity. Organizza la loro cooperazione attorno a un oggetto comune: l’affidabilità della decisione automatizzata che entra nel bilancio o nel sistema dei controlli.
Bilanci e mercati si fondano sulla possibilità di verificare le informazioni, nell’era dell’intelligenza artificiale, tale possibilità richiede qualcosa in più della lettura del documento e della riconciliazione della scrittura. Richiede la capacità di interrogare l’algoritmo, ricostruirne la memoria, misurarne le deviazioni e attribuire le responsabilità e solo così l’automazione potrà diventare uno strumento di fiducia anziché un nuovo spazio di opacità.
Bibliografia e riferimenti normativi
Biggio, B., Nelson, B., Laskov, P. (2012), “Poisoning Attacks against Support Vector Machines”, Proceedings of the 29th International Conference on Machine Learning (ICML).
ENISA (2021), Securing Machine Learning Algorithms, European Union Agency for Cybersecurity, 14 dicembre 2021.
European Parliament (2026), Digital Omnibus on AI, posizione in prima lettura approvata il 16 giugno 2026, procedura 2025/0359(COD).
IAASB (2020), Non-Authoritative Support Materials: Using Automated Tools & Techniques in Performing Audit Procedures, International Auditing and Assurance Standards Board.
IAASB (2020), Audit Documentation when Using Automated Tools and Techniques, International Auditing and Assurance Standards Board.
IAASB (2021), Audit Planning When Using Automated Tools and Techniques, International Auditing and Assurance Standards Board.
Jagielski, M., Oprea, A., Biggio, B., Liu, C., Nita-Rotaru, C., Li, B. (2018), “Manipulating Machine Learning: Poisoning Attacks and Countermeasures for Regression Learning”, 2018 IEEE Symposium on Security and Privacy, pp. 19-35, DOI: 10.1109/SP.2018.00057.
NIST (2023), Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, National Institute of Standards and Technology, DOI: 10.6028/NIST.AI.100-1.
Vassilev, A., Oprea, A., Fordyce, A., Andersen, H. (2024), Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, NIST AI 100-2e2023, DOI: 10.6028/NIST.AI.100-2e2023.
Schreyer, M., Sattarov, T., Schulze, C., Reimer, B., Borth, D. (2019a), “Detection of Accounting Anomalies in the Latent Space using Adversarial Autoencoder Neural Networks”, arXiv:1908.00734.
Schreyer, M., Sattarov, T., Reimer, B., Borth, D. (2019b), “Adversarial Learning of Deepfakes in Accounting”, arXiv:1910.03810.
Schultz, M., Tropmann-Frick, M. (2020), “Autoencoder Neural Networks versus External Auditors: Detecting Unusual Journal Entries in Financial Statement Audits”, Proceedings of the 53rd Hawaii International Conference on System Sciences, DOI: 10.24251/HICSS.2020.666.
International Standards on Auditing – ISA Italia: ISA 200, ISA 230, ISA 240, ISA 315, ISA 500, ISA 540, ISA 550 e ISA 520, nelle versioni vigenti.
Regolamento (UE) 2024/1689 del Parlamento europeo e del Consiglio, del 13 giugno 2024, che stabilisce regole armonizzate sull’intelligenza artificiale (AI Act).
Regolamento (UE) 2022/2554 del Parlamento europeo e del Consiglio, del 14 dicembre 2022, relativo alla resilienza operativa digitale per il settore finanziario (DORA).
Direttiva (UE) 2022/2555 del Parlamento europeo e del Consiglio, del 14 dicembre 2022, relativa a misure per un livello comune elevato di cibersicurezza nell’Unione (NIS2).
Decreto legislativo 4 settembre 2024, n. 138, recante recepimento della direttiva (UE) 2022/2555.
Legge 23 settembre 2025, n. 132, Disposizioni e deleghe al Governo in materia di intelligenza artificiale.
Codice civile, artt. 2086, 2392-2394, 2621 e 2622.
Partecipa alla community