AI Act EU

Cosa va storto nella pratica

Si ripete che l'IA non cambia nulla per il revisore legale. Una parte è vera (gli ISA e gli OIC restano gli stessi), una parte no.

Cosa si vede nei fascicoli 2024-2025: lo studio adotta un tool di anomaly detection (Cegid Audit IA, MindBridge, Indigo) per il campionamento sostantivo. Il software gira sui dati del cliente. Restituisce un elenco di transazioni anomale. Il senior tickа l'output. Il manager firma. Il fascicolo non contiene la valutazione del tool ai sensi dell'AI Act, non contiene la classificazione del rischio del modello, non contiene la valutazione di impatto richiesta dall'art. 27 per i deployer di sistemi ad alto rischio.

Le carte sono leggere proprio sul punto che il MEF guarderà per primo nei controlli 2026.

L'art. 6 e l'Allegato III dell'AI Act definiscono i sistemi ad alto rischio per categoria d'uso. La revisione legale non è elencata nell'Allegato III come settore (il legislatore europeo ha guardato a sanità, istruzione, occupazione, giustizia, infrastrutture critiche). Qui inizia la zona grigia.

Cosa significa nella pratica: se il tool IA che si usa rientra in una delle categorie dell'Allegato III, gli obblighi del Capitolo III (artt. 8-22) si applicano integralmente. Se non vi rientra, restano gli obblighi di trasparenza dell'art. 50 e gli obblighi del fornitore sui modelli general-purpose (artt. 51-55) qualora il tool sia costruito su un foundation model.

Il dibattito che divide gli studi

C'è un disaccordo legittimo tra revisori esperti su come classificare i tool IA usati negli incarichi.

Il Partner A sostiene che un sistema di anomaly detection che incide sulla selezione del campione sostantivo è ad alto rischio. La motivazione: l'output del modello determina quali transazioni vengano testate e quali no. Una falla nel modello (bias sui ricavi di fine anno, sotto-rappresentazione di una controllata estera) si traduce in un campione non rappresentativo, in evidenze probatorie insufficienti, in violazione di ISA Italia 500. Il fatto che l'Allegato III non menzioni la revisione non esclude l'applicazione: l'art. 6, paragrafo 2, prevede che la Commissione possa estendere l'elenco, e il considerando 50 indica che i sistemi che incidono sull'integrità di processi decisionali rilevanti meritano scrutinio.

Il Partner B replica che il tool è meramente assistivo. Il revisore mantiene la responsabilità professionale, sceglie il campione finale, firma la relazione. L'AI Act, secondo questa lettura, regola sistemi che decidono autonomamente o sostituiscono il giudizio umano (selezione del personale, valutazione del merito creditizio, sistemi biometrici). Un tool di analytics che propone un elenco di anomalie e attende che il revisore decida non rientra nello scopo dell'art. 6.

Chi ha ragione? Probabilmente entrambi, in parti diverse del processo. Il drafting dei memo con ChatGPT è chiaramente assistivo (Partner B). Un modello che produce direttamente la stima del fair value senza challenge sostanziale è in zona alto rischio (Partner A). Il problema è che pochi studi hanno fatto questa distinzione formalmente nel proprio sistema ISQM 1.

Cosa richiede la norma

L'art. 14 (supervisione umana) è la disposizione che il revisore legale italiano dovrebbe leggere per primo. Richiede che il deployer di un sistema ad alto rischio garantisca che la decisione finale sia presa da una persona fisica che (a) comprenda capacità e limiti del sistema, (b) sia consapevole del rischio di automation bias, (c) possa interpretare correttamente l'output, (d) possa decidere di non usarlo o di sovrascriverlo. Affinché si possa dimostrare conformità, queste quattro condizioni devono essere documentate nel fascicolo.

L'art. 50 (trasparenza) impone disclosure quando un contenuto è generato o manipolato da IA. Per il cliente che produce la nota integrativa con un tool generativo, qualora il documento sottoposto a revisione sia stato generato da IA senza intervento umano sostanziale, l'obbligo di disclosure scatta a carico del cliente, non del revisore. Il revisore (ISA Italia 240, ISA Italia 540) deve però considerare il rischio: una stima generata da ChatGPT su prompt generico non ha la stessa affidabilità di una stima costruita dal CFO su evidenze specifiche.

L'art. 27 richiede la valutazione di impatto sui diritti fondamentali per alcuni deployer di sistemi ad alto rischio. Lo studio di revisione non rientra tra i soggetti obbligati (l'articolo elenca enti di diritto pubblico, banche, assicurazioni). Resta però il principio: chi usa un sistema ad alto rischio deve sapere cosa il sistema fa.

In termini concreti: ISQM 1 paragrafo 32 richiede che lo studio identifichi e valuti i rischi di qualità connessi alle risorse tecnologiche. Prima dell'AI Act questo era un requisito generico. Dal 2026 ha contenuto specifico: classificazione del tool, valutazione delle limitazioni del modello, definizione del livello di supervisione umana, documentazione del processo di challenge.

I tre soggetti e perché contano

L'AI Act distingue tre soggetti: fornitore (chi sviluppa il sistema), deployer (chi lo usa professionalmente), utente finale. Per il revisore legale la distinzione non è teorica.

Quando lo studio adotta MindBridge o Cegid Audit IA, lo studio è deployer. Il fornitore (la software house) ha gli obblighi del Capitolo III sulla qualità del modello. Lo studio ha gli obblighi sull'uso (art. 26): istruzioni del fornitore seguite, log conservati, supervisione umana garantita, monitoraggio del funzionamento.

Quando il cliente revisionato usa un sistema IA per produrre stime contabili (impairment IAS 36, fair value IFRS 13, accantonamenti IAS 37), il cliente è deployer e il revisore non ha obblighi diretti ai sensi dell'AI Act. Gli obblighi del revisore restano quelli di ISA Italia 540 (revisione delle stime contabili): comprensione del processo, valutazione delle assunzioni, verifica della ragionevolezza dell'output. Qualora il revisore tickasse l'output IA del cliente senza challenge, il rilievo che ne deriverebbe sarebbe una violazione dell'ISA Italia 540, non dell'AI Act.

Quando lo studio costruisce in-house un modello (alcuni studi medio-grandi italiani lo stanno facendo per il sampling settoriale), lo studio diventa fornitore E deployer simultaneamente. Gli obblighi raddoppiano.

L'incentivo perverso

Si adottano i tool IA per ragioni di tempo. La busy season è già impossibile da chiudere con i compensi attuali; un software che riduce le ore di campionamento sostantivo del 30% si paga in due incarichi. Il problema è che il tempo risparmiato sul campionamento non viene reinvestito nella mappatura formale ISQM 1 del tool, perché quella mappatura non è fatturabile a nessun cliente.

Risultato: lo studio adotta IA per liberare tempo. Il tempo liberato non va in conformità AI Act. La prima ispezione MEF post-2026 chiederà la classificazione del tool e troverà il vuoto. La sanzione (o il rilievo) compenserà il risparmio di una busy season intera.

I compensi irrisori che spingono all'automazione sono gli stessi compensi che impediscono la documentazione corretta dell'automazione. Il regolamento non ha pensato a questa dinamica.

Esempio pratico: studio con tool di anomaly detection

Cliente: Manifatture Ceramiche Venete S.r.l., fatturato 28 milioni di euro, revisione legale del bilancio IFRS, esercizio 2025.

Circostanza: Lo studio ha adottato a settembre 2025 un software di analytics con modello di machine learning per il sampling sostantivo sui ricavi. Il software flagga le transazioni anomale; il revisore decide la composizione finale del campione.

Fase 1: classificazione del sistema (luglio 2025). Il senior manager richiede al fornitore la classificazione AI Act del prodotto. Il fornitore conferma che il modello è general-purpose AI ai sensi dell'art. 51 e fornisce la documentazione tecnica (artt. 11-13). Lo studio classifica internamente l'uso come potenzialmente alto rischio (l'output incide sulla selezione del campione sostantivo, quindi su ISA Italia 500). La classificazione viene documentata nel sistema ISQM 1.

Documentazione nel fascicolo: scheda di classificazione del tool con riferimento al considerando 50 e all'art. 6, paragrafo 2.

Fase 2: valutazione e supervisione umana (settembre 2025). Lo studio testa il software su tre bilanci di esercizi precedenti. Verifica i tassi di falsi positivi (15% sul primo test) e di mancati rilievi (3 transazioni materialmente significative non flaggate su 12.000). Definisce il protocollo di challenge: il senior incaricato non si limita a tickare l'output ma documenta perché il modello ha identificato ogni transazione e cosa avrebbe potuto perdere.

Documentazione nel fascicolo: protocollo di supervisione ai sensi dell'art. 14 con i quattro requisiti (comprensione, consapevolezza del bias, interpretazione, override).

Fase 3: esecuzione (gennaio 2026). Il software analizza 28.000 transazioni di ricavi del 2025. Flagga 1.400 transazioni anomale. Il senior esamina i parametri del modello, identifica un cluster di 47 fatture di dicembre da tre clienti nuovi sopra 85.000 euro. Verifica i contratti, le spedizioni, l'incasso. Confronta con il pattern storico: i tre clienti non avevano relazione con la società prima di ottobre 2025. Si pone la domanda se il modello abbia perso qualcosa: aggiunge alla popolazione 12 fatture di clienti storici sopra soglia per coprire l'intera base ricavi.

Documentazione nel fascicolo: nota di carta di lavoro con il ragionamento, non solo il tick.

Fase 4: monitoraggio e tracciabilità. Lo studio mantiene il log delle esecuzioni, dei parametri di input, del numero di transazioni flaggate, della composizione del campione finale, della motivazione di ogni deviazione. Il log resta nel fascicolo per dieci anni dalla data della relazione (D.Lgs. 39/2010 art. 11 sulla tenuta del fascicolo, allineato con la conservazione AI Act).

Esito atteso del controllo MEF: se l'ispettore esamina il fascicolo, trova la classificazione del tool, la valutazione di impatto, il protocollo di supervisione, il log di esecuzione, le note di challenge. La supervisione umana è documentata, non solo dichiarata. Il rischio di rilievo si riduce alla qualità del giudizio professionale, che è dove il revisore può difendersi.

Cosa gli ispettori e i professionisti fraintendono

Tier 1 (rilievo MEF/CONSOB): Nel campione MEF 2025, gli studi che usano tool IA non hanno documentato la valutazione del tool ai sensi del proprio sistema ISQM 1. Le carte sono leggere proprio sul punto che l'AI Act ha reso obbligatorio. Il rilievo non è "lo studio ha violato l'AI Act"; è "lo studio non ha aggiornato la propria gestione della qualità per riflettere l'uso di tecnologia ad alto impatto." La distinzione è importante perché la sanzione segue la seconda strada (D.Lgs. 39/2010), non la prima.

Tier 2 (errore standard-referenziato): Diversi professionisti ritengono che la supervisione umana ai sensi dell'art. 14 si riduca all'approvazione finale del partner. Non è così. Il paragrafo 4, lettera (a), dell'art. 14 richiede che la persona possa "comprendere correttamente le capacità e i limiti pertinenti del sistema." Una firma sul fascicolo senza comprensione del modello non integra il requisito. La differenza tra ticking e supervisione è il challenge documentato.

Tier 3 (gap pratico): Lo studio acquista il tool, segue il manuale del fornitore, documenta che il tool è in uso. Ritiene di essere conforme. Manca però la classificazione del rischio nel proprio ISQM 1, la valutazione di impatto sull'incarico tipo, la formazione documentata del team sui limiti del modello. La conformità apparente non è conformità reale; il fascicolo deve raccontare la storia del giudizio, non solo il fatto che si è usato il software.

Confronto: AI Act EU vs. ISA Italia e ISQM 1

L'AI Act è un regolamento UE direttamente applicabile dal 2024 (con efficacia scaglionata fino al 2027). Impone obblighi orizzontali sull'uso di sistemi IA, indipendentemente dal settore. Le sanzioni vanno fino a 15 milioni di euro o al 3% del fatturato annuo (art. 99). Gli ISA Italia (in particolare 230, 240, 315, 500, 540) sono principi professionali emanati in Italia con il sistema MEF-CONSOB. Disciplinano il giudizio del revisore. Non parlano di IA, ma il giudizio su evidenze prodotte da IA ricade nei loro requisiti di scetticismo professionale e sufficienza delle prove.

ISQM 1 (per gli studi che svolgono revisioni) richiede al sistema di gestione della qualità di identificare e rispondere ai rischi connessi alle risorse tecnologiche. Dal 2026, l'AI Act riempie quel requisito di contenuto specifico: classificazione, valutazione, supervisione, monitoraggio. Senza l'AI Act, ISQM 1 paragrafo 32 era un riquadro semi-vuoto. Con l'AI Act, è il punto di ispezione più probabile.

In pratica: lo studio deve conformarsi sia al Regolamento UE 2024/1689 (per la legalità dell'uso del tool), sia agli ISA Italia (per la qualità delle evidenze prodotte con il tool), sia all'ISQM 1 (per la gestione del rischio tecnologico a livello di studio). I tre piani non si sovrappongono perfettamente, e i punti di frizione sono dove vivono i rilievi MEF.

Termini correlati

- Classificazione del rischio nell'AI Act - Come l'AI Act categorizza i sistemi IA in base al rischio. - Tracciabilità e documentazione tecnica - Requisiti dell'AI Act per la conservazione dei registri. - Supervisione umana significativa - Il requisito dell'art. 14 di mantenere il controllo finale sulla decisione. - ISA Italia 315 e l'integrazione della tecnologia - Come la valutazione del rischio considera le risorse tecnologiche del cliente. - Data analytics nella revisione contabile - L'applicazione di algoritmi al campionamento sostantivo. - ISA Italia 240 Revised e il rilevamento della frode tramite IA - Come i sistemi IA possono supportare (ma non sostituire) il giudizio del revisore.

---