Un “no” che non si può difendere
Un’ispezione, un audit interno, una richiesta dell’autorità.
Il momento critico arriva quando qualcuno pone una domanda semplice solo in apparenza: “Perché avete concluso che questo sistema dell’Allegato III non è ad alto rischio?”
Nell’organizzazione c’è un file, in un repository, con una tabella. In una cella c’è scritto “no”.
Nessuno ricorda chi l’abbia scritto, quale versione del sistema descrivesse, quali documenti fossero stati letti.
Quella cella è il problema.
Se quel “no” poggia sulla deroga dell’articolo 6, paragrafo 3, l’articolo 80 dell’AI Act consente all’autorità di vigilanza del mercato di riesaminare proprio quella conclusione; negli altri casi valgono i suoi poteri generali di vigilanza.
In entrambe le situazioni, una conclusione senza motivazione non si può difendere.
Dalla risposta alla prova
Una buona classificazione non si limita alla conclusione. Scrivere “sistema non ad alto rischio” senza spiegare perché produce un’informazione difficile da verificare, difficile da aggiornare e debole in caso di controllo.
La governance chiede qualcosa di diverso: una traccia sintetica ma completa del ragionamento seguito.
Deve essere possibile capire quali fatti sono stati considerati, quali norme applicate, chi ha partecipato alla valutazione, quali documenti sono stati esaminati e quali condizioni imporrebbero un nuovo esame.
Per questo la scheda di classificazione dovrebbe diventare un documento stabile del sistema di governance dell’AI. Vediamo come costruirla, sezione per sezione.
Prima sezione: chi, che cosa, e se l’AI Act si applica
Si parte dagli elementi di base:
- nome e versione del sistema;
- descrizione sintetica delle funzionalità;
- organizzazione che lo sviluppa o lo fa sviluppare;
- soggetto che lo immette sul mercato o lo mette in servizio con il proprio nome o marchio; ruolo dell’organizzazione ai sensi dell’AI Act (fornitore, deployer, importatore, distributore, fornitore a valle di un modello per finalità generali);
- eventuali altri operatori rilevanti; eventuali circostanze dell’articolo 25 che abbiano trasferito il ruolo di fornitore.
Poi la domanda che nel secondo articolo di questa esalogia abbiamo chiamato “zero”: il Regolamento si applica (articolo 2)? Il sistema rientra in un’esclusione, per esempio quella per la sicurezza nazionale o quella per la ricerca? È un componente di sicurezza di un prodotto della sezione B dell’Allegato I, con il regime speciale dell’articolo 2, paragrafo 2?
Sembra semplice ma evita un errore frequente: discutere della classificazione senza aver chiarito se il Regolamento si applichi, chi sia davvero il fornitore e chi assuma gli obblighi.
Seconda sezione: la finalità prevista, scritta per chi non c’era
La sezione successiva contiene la finalità prevista, in forma abbastanza precisa da essere capita da chi non ha partecipato allo sviluppo.
Quale compito svolge il sistema? Quale output produce? In quale processo entra? Chi lo utilizza? Su quali persone o situazioni possono incidere gli output? Quanto pesa sul processo decisionale? Quali sono le condizioni e i limiti di utilizzo? È presentato come strumento specifico o come piattaforma applicabile a tutto?
Questa descrizione va confrontata con istruzioni, documentazione tecnica, materiali commerciali e configurazioni del prodotto.
Le incoerenze si risolvono prima della classificazione, non dopo.
Terza sezione: il percorso normativo, domanda dopo domanda
Qui la scheda ripercorre il cammino del secondo articolo della nostra esalogia, con una breve motivazione e la fonte per ogni risposta:
- Zero: l’AI Act si applica al sistema, al soggetto e all’uso (articolo 2)?
- Prima: il sistema rientra nella definizione dell’articolo 3, punto 1, letta con le linee guida della Commissione del 6 febbraio 2025?
- Seconda: la finalità prevista descritta nella seconda sezione è coerente con istruzioni per l’uso, documentazione tecnica e materiale promozionale (articolo 3, punto 12)?
- Terza: l’uso previsto rientra in una pratica vietata dall’articolo 5, comprese le due introdotte dal Regolamento (UE) 2026/1744?
- Quarta, percorso dei prodotti: ricorrono le due condizioni dell’articolo 6, paragrafo 1, rispetto ai prodotti dell’Allegato I, tenuto conto dei paragrafi 1 bis, 1 ter e 1 quater e della distinzione tra sezione A e sezione B?
- Quarta, percorso dei casi d’uso: il sistema ricade in una delle otto aree dell’Allegato III (articolo 6, paragrafo 2)? Se sì, effettua profilazione di persone fisiche? Se la effettua, la deroga è preclusa; se non la effettua, ricorrono i presupposti dell’articolo 6, paragrafo 3?
- Quinta: si applicano gli obblighi di trasparenza dell’articolo 50, e quali gravano sul fornitore e quali sul deployer?
- Sesta: l’organizzazione è fornitore di un modello per finalità generali, oppure integra un modello altrui? Nel primo caso, quali obblighi del Capo V si applicano; nel secondo, quali informazioni riceve ai sensi dell’articolo 53, paragrafo 1, lettera b), e il sistema è un sistema per finalità generali ai sensi dell’articolo 3, punto 66?
- Settima: da quando si applicano gli obblighi individuati, e il sistema rientra nel regime transitorio dell’articolo 111, compreso il termine del 2 agosto 2030 per i sistemi destinati alle autorità pubbliche?
Quarta sezione: le eccezioni si motivano di più, non di meno
Le conclusioni che alleggeriscono gli obblighi meritano più attenzione, non meno.
Il caso più evidente è l’articolo 6, paragrafo 3 dell’AI Act.
Se il fornitore ritiene che un sistema dell’Allegato III non sia ad alto rischio, la motivazione non può ridursi a una formula come “impatto limitato”.
Occorre anzitutto escludere la profilazione.
Occorre poi spiegare, seguendo la lettura delle linee guida della Commissione europea in bozza del 19 maggio 2026, perché il sistema non presenti un rischio significativo di danno per salute, sicurezza o diritti fondamentali, anche nel senso di non influenzare materialmente il risultato del processo decisionale, e quale delle quattro condizioni ricorra, con elementi che dimostrino, in particolare, che il sistema non ordina, non attribuisce punteggi e non formula raccomandazioni o valutazioni specifiche, che la bozza delle linee guida considera incompatibili con le condizioni della deroga.
L’articolo 6, paragrafo 4, fa di questa documentazione un passaggio esplicito e vi aggiunge la registrazione nella banca dati dell’Unione ai sensi dell’articolo 49, paragrafo 2, i cui estremi vanno riportati nella scheda.
L’articolo 80 ricorda che la conclusione può essere riesaminata dall’autorità di vigilanza e, se elusiva, sanzionata.
Più una conclusione si allontana dalla regola generale, più la motivazione deve essere solida.
Quinta sezione: firma, data e i motivi per riaprire il file
La scheda si chiude con una qualificazione espressa, con gli obblighi principali che ne derivano e con la data dalla quale si applicano.
Ma contiene anche data, versione del sistema, chi ha partecipato alla valutazione, chi l’ha approvata e quando è previsto il riesame.
Soprattutto, elenca gli eventi che impongono una nuova classificazione:
- cambio della finalità prevista, introduzione di nuove funzionalità, modifica sostanziale, nuovi contesti d’uso;
- cambio di ruolo ai sensi dell’articolo 25 dell’AI Act;
- modifiche legislative, come quelle introdotte dal Regolamento (UE) 2026/1744;
- aggiornamenti degli Allegati con atti delegati (articolo 7) e delle condizioni della deroga (articolo 6, paragrafi 6 e 7);
- adozione definitiva delle linee guida della Commissione previste dall’articolo 6, paragrafo 5, o pubblicazione di nuove linee guida;
- risultati del monitoraggio successivo all’immissione sul mercato ed evidenze di uso improprio ragionevolmente prevedibile;
- esiti della FRIA o della DPIA che rivelino un uso diverso da quello previsto;
- entrata in vigore di norme nazionali di adeguamento, in Italia i decreti legislativi attuativi della legge n. 132/2025.
La classificazione non deve diventare una fotografia dimenticata in un repository. Deve seguire il sistema.
Due livelli: il registro e la scheda
In un’organizzazione strutturata proporrei due livelli documentali.
Il primo è il registro dei sistemi di AI
Censisce sistemi, ruoli, finalità, stato della classificazione, owner, date di applicazione e scadenze.
Per i deployer pubblici dialoga con la banca dati dell’Unione (articolo 26, paragrafo 8).
Il secondo è la scheda di classificazione del singolo sistema, che contiene il ragionamento giuridico completo.
Per i sistemi ad alto rischio si collegano poi gli altri documenti richiesti dal Regolamento:
- per il fornitore il sistema di gestione dei rischi, la documentazione tecnica, il sistema di gestione della qualità e la valutazione della conformità;
- per il deployer le misure dell’articolo 26 e, dove dovuta, la FRIA dell’articolo 27. Per i sistemi che trattano dati personali, la scheda viene richiamata nella DPIA, senza confondere la qualificazione AI Act con la valutazione del rischio GDPR.
Per le organizzazioni italiane, infine, la scheda tiene conto della legge 23 settembre 2025, n. 132, che ha:
- designato l’Agenzia per l’Italia digitale (AGID) come autorità di notifica e l’Agenzia per la cybersicurezza nazionale (ACN) come autorità di vigilanza del mercato, ferme le competenze delle autorità di settore;
- introdotto obblighi propri, a cominciare dall’informazione ai lavoratori dell’articolo 11.
Per i sistemi biometrici usati a fini di contrasto, gestione delle frontiere, giustizia e processi democratici e per quelli dei punti 6, 7 e 8 dell’Allegato III, l’articolo 74, paragrafo 8, dell’AI Act rimette agli Stati membri la scelta tra le autorità di protezione dei dati e altre autorità indipendenti; Va considerato anche il decreto legislativo 9 settembre 2026, n. 160, in vigore dal 30 settembre 2026, sull’uso dei sistemi di IA nelle attività di polizia e sulla responsabilità civile e penale.
La documentazione deve quindi essere leggibile da queste autorità nazionali, che sono le prime a poterla chiedere.
Questa architettura evita duplicazioni e, soprattutto, permette di capire quale documento risponde a quale domanda.
Conclusioni
La classificazione AI Act dovrebbe concludersi con una decisione motivata, documentata, registrata dove la legge lo richiede, e riesaminabile.
È il passaggio che trasforma una lettura teorica del Regolamento in governance reale.
Il fornitore qualifica il sistema applicando la legge alla finalità prevista e alle caratteristiche concrete.
Il deployer verifica il perimetro in cui lo usa e adempie ai propri obblighi.
Il risk management governa i rischi concreti.
La FRIA, per chi vi è tenuto, valuta l’impatto dell’uso sui diritti fondamentali.
La DPIA, quando necessaria, valuta il trattamento di dati personali e i rischi per i diritti e le libertà.
L’esalogia si chiude dove dovrebbe cominciare ogni progetto operativo: non con una piramide colorata, ma con una domanda documentata.
“Quale norma si applica a questo sistema, per questa finalità, in questo contesto, e da quando?”
