Risposta sintetica
Il Regolamento (UE) 2024/1689 (AI Act) qualifica come sistemi ad alto rischio, ai sensi dell'art. 6(2) e dell'Allegato III, punto 5(b), la maggior parte degli strumenti di revisione che influenzano le conclusioni del revisore (ML-based journal entry scoring, anomaly detection, client risk scoring). Gli studi che li adoperano sono «deployer» ai sensi dell'art. 26 e, dal 2 agosto 2026, rispondono di documentazione d'uso, log di funzionamento e oversight umano, indipendentemente da cosa affermi il fornitore nel contratto.
Quello che imparerete
> - Come distinguere le responsabilita del fornitore da quelle del deployer secondo gli artt. 16 e 26 > - Quali strumenti del vostro stack rientrano probabilmente nell'Allegato III e quali no > - Come assorbire l'oversight IA dentro il sistema ISQM 1 invece di costruire un sistema parallelo > - Cosa chiedere al vendor prima del 2 agosto 2026 senza aspettare che sia lui a muoversi
Indice
- Il problema del deployer: la responsabilita ricade a valle - Cosa tocca davvero l'Allegato III nello stack dello studio - Obblighi operativi dal 2 agosto 2026 - ISQM 1 come tessuto connettivo, non come sistema parallelo - Esempio pratico: il software di anomaly detection sulle journal entries - Dove i professionisti ragionevolmente non concordano - Checklist di conformita - Errori comuni nella valutazione - Contenuti correlati
Il problema del deployer: la responsabilita ricade a valle
L'argomento che gira negli studi italiani da fine 2025 e questo: «la conformita all'AI Act se la vede il vendor, lo strumento lo abbiamo comprato certificato». Dal nostro punto di vista, e una lettura che non tiene. L'art. 2 del Regolamento distingue fornitori (provider), distributori e deployer. Lo studio che adopera il sistema negli incarichi e deployer. Il fornitore certifica il prodotto. Il deployer risponde dell'uso.
L'art. 26 e esplicito. Il deployer deve usare il sistema secondo le istruzioni d'uso, monitorarne il funzionamento, conservare i log che il sistema genera, segnalare malfunzionamenti gravi e garantire la supervisione umana prevista all'art. 14. Qualora la CONSOB, in sede di controllo qualita, rilevi che l'output del modello ha guidato una selezione campionaria senza che in fascicolo risulti una valutazione umana tracciabile, il rilievo non sara contro il vendor. Sara contro lo studio.
Cosa succede davvero: il contratto con il vendor contiene quasi sempre una clausola che scarica sul deployer ogni obbligo ex art. 26. Il vendor fornisce la documentazione dell'Allegato IV, la dichiarazione di conformita ex art. 47 e il marchio CE. Finisce li. Se nello studio non esiste una procedura scritta che spieghi come il revisore rilegge l'output, cosa fa quando non e d'accordo, e dove annota la propria valutazione, il fascicolo non regge al controllo. La scorciatoia del «ci pensa il vendor» nasce dalla pressione economica: mappare lo stack richiede tempo non fatturabile, e in tempi di compensi irrisori quel tempo nessuno lo trova.
Cosa tocca davvero l'Allegato III nello stack dello studio
L'Allegato III, punto 5(b), include fra i sistemi ad alto rischio quelli «destinati a essere utilizzati per valutare l'affidabilita creditizia» e, per estensione interpretativa adottata dalla maggior parte dei commentari italiani (CNDCEC, nota operativa di gennaio 2026; AgID, Linee guida 2026/01), i sistemi IA che supportano giudizi professionali in servizi finanziari critici. La revisione legale, ai sensi del D.Lgs. 39/2010, vi rientra.
Quali strumenti dello stack medio di uno studio italiano ricadono probabilmente nell'Allegato III:
- ML-based journal entry scoring (ISA Italia 240) quando il modello produce un ranking che guida la selezione dei test - Anomaly detection su popolazioni contabili (ISA Italia 330) quando l'output influenza l'estensione delle procedure - Client risk scoring in fase di accettazione e continuazione incarico (ISA Italia 220) - Sampling IA-driven che calcola dimensioni campionarie oltre al campionamento statistico puro dell'ISA Italia 530 - Strumenti di analisi documentale che classificano contratti o stime della direzione in categorie di rischio
Quali strumenti probabilmente non ricadono:
- Fogli di calcolo Excel senza modelli di machine learning, anche se complessi - Database di ricerca normativa e archivi documentali senza logica decisionale automatica - OCR semplice senza classificazione automatica del contenuto estratto - Strumenti di elaborazione testo standard e software di redazione
La zona grigia vera e la seconda categoria quando pero lo strumento viene adoperato per scopi diversi da quelli dichiarati. Se lo studio usa un motore di ricerca normativa con componenti IA per generare automaticamente bozze di carte di lavoro, quello che nasceva come strumento informativo puo essere riqualificato come sistema ad alto rischio. L'uso effettivo conta piu dell'etichetta del vendor.
Obblighi operativi dal 2 agosto 2026
L'art. 16 elenca gli obblighi del provider. L'art. 26 elenca quelli del deployer. La lettura congiunta dei due articoli, con l'art. 17 sul sistema di gestione della qualita e l'art. 20 sulla tenuta dei log, definisce il perimetro pratico. Per lo studio questo si traduce in quattro cose concrete.
Documentazione tecnica ex Allegato IV (a carico del fornitore, da archiviare). Il fornitore deve consegnare la descrizione generale del sistema, la documentazione sui dati di addestramento, le metriche di accuratezza su dataset rappresentativi, la descrizione del sistema di monitoraggio post-market. Lo studio archivia questa documentazione e la aggiorna quando il fornitore rilascia nuove versioni. Il file dello strumento, insieme al contratto e alle istruzioni d'uso, deve essere reperibile in qualsiasi momento.
Istruzioni d'uso e oversight umano ex art. 14 (a carico del deployer, da scrivere). Il fornitore non conosce il vostro processo. Lo studio deve scrivere, in procedura interna, come l'output del sistema entra nel giudizio del revisore, chi lo rilegge, quando lo si puo ignorare, e dove si documenta la valutazione umana. Nella nostra esperienza questa e la parte che gli studi saltano piu spesso: si assume che l'oversight umano sia implicito perche «il senior guarda sempre tutto». Senza procedura scritta, nel fascicolo non c'e prova.
Log di funzionamento ex art. 20 (generati dal sistema, conservati dal deployer). Il sistema genera log automatici. Lo studio deve assicurarsi che siano effettivamente abilitati (non e automatico in tutti i prodotti), che vengano esportati periodicamente dalla piattaforma del vendor alla conservazione interna dello studio, e che la retention policy sia documentata. La CONSOB ha gia chiesto in alcuni controlli del 2025, in relazione ad altri strumenti digitali, la tracciabilita delle elaborazioni.
Segnalazione di malfunzionamenti gravi (a carico del deployer). Qualora il sistema produca un output che, se seguito, avrebbe portato a un errore significativo nel bilancio, scatta l'obbligo di segnalazione. Non solo al fornitore: anche all'autorita competente quando il malfunzionamento integri gli estremi dell'art. 73.
ISQM 1 come tessuto connettivo, non come sistema parallelo
Il riflesso iniziale di molti studi e costruire un sistema di governance IA separato. E la strada piu costosa e, a nostro avviso, la meno difendibile nel tempo. L'ISQM 1 prevede gia otto componenti di sistema di gestione della qualita, fra cui la valutazione dei rischi dello studio, le risorse (incluse quelle tecnologiche) e il processo di monitoraggio e remediation. L'oversight IA si innesta su queste componenti esistenti, non accanto.
In pratica: il rischio «uso improprio di un sistema IA ad alto rischio che influenza il giudizio» si aggiunge alla mappa dei rischi ISQM 1. Le risorse tecnologiche gia documentate nel sistema qualita si arricchiscono della classificazione AI Act e della documentazione ex Allegato IV. Il processo di monitoraggio ISQM 1 copre anche il controllo periodico sui log e sulle istruzioni d'uso. La policy di accettazione e continuazione clienti include la verifica che lo stack IA utilizzato sia conforme per quell'incarico specifico.
Il vantaggio e che il sistema qualita viene verificato dal MEF e dalla CONSOB in sede di controllo qualita: se l'oversight IA vive dentro ISQM 1, viene coperto dallo stesso controllo. Se vive in un sistema parallelo, ogni controllo diventa il doppio del lavoro. Questa e l'unica configurazione che scala su uno studio mid-tier con venti engagement high-risk in contemporanea.
Esempio pratico: il software di anomaly detection sulle journal entries
Scenario. Studio Bianchi & Associati S.r.l., venti professionisti, revisione legale su quindici clienti mid-market. Da dicembre 2025 usa uno strumento di anomaly detection basato su machine learning che analizza le journal entries del cliente, assegna uno score di rischio a ciascuna, e suggerisce al revisore quali testare in modo approfondito ai sensi dell'ISA Italia 240.A23.
Quando il partner affida l'engagement al senior, il senior importa il general ledger dell'esercizio in chiusura (tipicamente ottocentomila-un milione di scritture per un cliente da EUR 40M di fatturato). Il modello genera lo score. Tipicamente il 2% circa delle scritture, circa sedicimila righe, riceve score alto.
Passo 1: classificazione. Il sistema rientra nella definizione di sistema IA ex art. 3(1) perche l'output influenza la selezione dei test del revisore. Secondo l'Allegato III, punto 5(b), letto con le linee guida CNDCEC 2026/01, si tratta di un sistema ad alto rischio. Si documenti la classificazione nel registro dei sistemi IA dello studio, con riferimento normativo specifico e data di classificazione.
Nota di documentazione: il registro dei sistemi IA diventa parte integrante della documentazione ISQM 1 — componente «risorse tecnologiche». Non una cartella a parte.
Passo 2: documentazione del fornitore. Bianchi & Associati richiede al fornitore la documentazione completa ex Allegato IV, la dichiarazione di conformita ex art. 47, la descrizione dei dataset di addestramento con analisi dei bias potenziali, le metriche di performance su popolazioni rappresentative. Il fornitore consegna tutto. Lo studio archivia.
Passo 3: la complicazione. A marzo 2026, durante un incarico su un cliente manifatturiero, il senior riceve dallo strumento una lista di duemila scritture ad alto rischio. Rivedendo manualmente un campione di cento, il senior nota che l'80% delle scritture flaggate sono rigiri fisiologici di fine mese sui conti infragruppo della societa controllante estera, privi di rilevanza di frode. Il modello ha imparato su un dataset senza controllate estere e non distingue i rigiri legittimi dalle anomalie sostanziali.
Nota di documentazione: questa e la situazione che espone lo studio al rischio deployer. Se il senior ignorasse lo score del modello senza documentazione, nel fascicolo ci sarebbe solo l'output del modello, senza tracciabilita del giudizio umano.
Cosa fa il senior. Apre la procedura interna scritta dallo studio a dicembre 2025, segue il protocollo di «override dell'output IA»: documenta nel memo di audit perche il modello sta sovrastimando il rischio su quel sottoinsieme, quali procedure alternative applica (test di completezza dei rigiri infragruppo secondo ISA Italia 550 e verifica dei saldi reciproci), e sottopone la valutazione al partner prima di procedere.
Passo 4: il log finisce nel fascicolo. I log del sistema registrano lo score generato, le scritture effettivamente testate dopo l'override, e le procedure alternative eseguite. Il file dell'incarico contiene: output originale dello strumento, memo di override con motivazione, log di funzionamento esportati, documentazione dell'approvazione del partner. La catena decisionale e tracciabile dall'input del modello al giudizio finale.
Risultato. Qualora la CONSOB nel 2027 selezionasse l'incarico per controllo qualita, il fascicolo risponde a tutte le domande: il sistema era classificato, il fornitore era documentato, il deployer aveva istruzioni d'uso scritte, l'oversight umano era tracciato, l'override era motivato. Nessuno dice che e piacevole produrre questa documentazione. La si produce perche la mancata produzione e il rilievo.
Dove i professionisti ragionevolmente non concordano
Su un punto specifico, dentro il nostro team e fra colleghi sul mercato, la discussione e aperta. L'anomaly detection sulle journal entries rientra o no nell'Allegato III?
Il Partner A sostiene di si. La lettura e quella del punto 5(b) combinato con l'art. 6(2): il sistema influenza un giudizio professionale in un servizio finanziario critico, quindi e alto rischio, indipendentemente dal fatto che l'output sia solo una «raccomandazione» al revisore. La prudenza, in un contesto dove la CONSOB ha margini ampi nel controllo qualita, suggerisce di trattare tutti questi strumenti come alto rischio e produrre la documentazione completa.
Il Partner B sostiene di no. La tesi e che l'Allegato III, punto 5(b), si riferisce letteralmente a sistemi destinati all'uso in servizi finanziari erogati al pubblico (valutazione creditizia, pricing assicurativo) e non a strumenti interni dell'auditor che non producono effetti sul mercato. Secondo questa lettura, il ML-based journal entry scoring sarebbe al di fuori dell'Allegato III; i relativi obblighi discenderebbero solo dall'ISA Italia 240 e dall'ISQM 1. La documentazione si farebbe comunque, ma non secondo l'architettura dell'AI Act.
La nostra posizione: sul piano testuale, il Partner B ha un argomento. Sul piano pratico, prima che il primo chiarimento interpretativo dell'AgID o dell'AI Office europeo arrivi, conviene il Partner A. Documentare come alto rischio costa tempo una volta. Riscoprire a controllo in corso che la lettura ristretta non e stata accolta costa il rilievo.
Checklist di conformita
1. Inventario dello stack. Elencare tutti gli strumenti usati negli incarichi che contengono componenti ML o logica decisionale automatica. Classificarli secondo le categorie AI Act. Data obiettivo: 30 giugno 2026.
2. Documentazione del fornitore. Per ogni sistema classificato ad alto rischio, richiedere al fornitore la documentazione ex Allegato IV, la dichiarazione di conformita ex art. 47, e la descrizione dei log generati. Archiviare nel sistema qualita.
3. Istruzioni d'uso scritte dallo studio. Redigere una procedura interna per ciascun sistema ad alto rischio che descriva come l'output entra nel giudizio, chi lo rilegge, come si documenta l'override, dove si conserva il log. Non affidarsi alle istruzioni del vendor: sono generiche.
4. Oversight umano ex art. 14. Verificare che la supervisione umana sia tracciata nei fascicoli in modo indipendente dall'output del sistema. Il fascicolo deve poter essere letto senza aprire il tool.
5. Gestione dei log. Assicurarsi che i log siano abilitati (non sempre lo sono per default), esportati periodicamente, conservati secondo la retention policy dello studio.
6. Integrazione ISQM 1. Innestare la mappa dei sistemi IA nella valutazione dei rischi dello studio e nelle componenti «risorse» e «monitoraggio» dell'ISQM 1. Non costruire un sistema parallelo.
7. Formazione del team. Formare senior e manager sul protocollo di override, sulla distinzione provider/deployer, e sui casi in cui l'output del modello puo essere ignorato con documentazione.
Errori comuni nella valutazione
- Delega totale al vendor. Affidarsi alle dichiarazioni di conformita del fornitore senza scrivere le istruzioni d'uso interne. La certificazione CE del sistema non copre l'uso che lo studio ne fa.
- Sottovalutazione dello stack. Considerare solo i tool piu visibili e tralasciare strumenti apparentemente semplici (motori di analisi documentale, scoring di rischio cliente) che contengono componenti ML.
- Sistema parallelo invece di integrazione ISQM 1. Costruire una governance IA separata che richiede controllo separato, formazione separata, documentazione separata. Il costo si moltiplica per ogni controllo qualita futuro.
- Assenza di tracciabilita dell'override. Ignorare l'output del modello senza documentare il perche. Nel fascicolo resta solo l'input del sistema, senza traccia del giudizio umano. E la fattispecie che la CONSOB punisce piu severamente.
- Aspettare i chiarimenti. Rimandare la classificazione dello stack aspettando le linee guida definitive di AgID, Garante Privacy o AI Office. Il 2 agosto 2026 e una data del Regolamento, non una proposta.
Contenuti correlati
- Glossario IA nella revisione - Definizioni tecniche dei sistemi IA utilizzati negli studi di revisione - Checklist Quality Control ISA Italia 220 - Include sezioni specifiche per la governance dei sistemi IA dentro l'ISQM 1 - Gestione del rischio tecnologico - Come integrare la governance IA nel risk management dello studio