AI Act: conformità senza l'astrazione.

Classifica il sistema prima di fare qualsiasi altra cosa

Ogni decisione legata all'AI Act parte da una domanda: in quale livello rientra questo sistema. Sbaglia la classificazione e finirai o per sovra-ingegnerizzare un chatbot oppure per sotto-proteggere uno strumento di screening dei CV che un regolatore tratterà come ad alto rischio. I quattro livelli non sono uno spettro su cui scorrere; sono compartimenti distinti con conseguenze giuridiche diverse, e un singolo prodotto può collocarsi in più di uno se raggruppa diverse funzioni.

La classificazione è funzione della finalità prevista, non della sofisticazione tecnica. Una semplice regressione logistica che decide chi ottiene un prestito è ad alto rischio. Un grande modello multimodale che consiglia ricette non lo è. L'Act guarda a cosa serve il sistema e chi colpisce, quindi il lavoro di classificazione spetta congiuntamente a prodotto e conformità, non solo al team di data science.

La maggior parte delle controversie nella sala di audit non riguarda il minimo contro l'alto; riguarda l'alto contro il limitato al confine. Se non riesci a difendere la classificazione per iscritto, trattala come il livello superiore finché non ci riesci. Il corso AI Risk Manager illustra la logica di classificazione e le prove di cui hai bisogno per sostenere una decisione.

Cosa significa davvero "alto rischio" sul piano operativo

Il TL;DR elenca le sette aree di obbligo. La realtà operativa è che ciascuna è un processo ricorrente, non un documento che scrivi una volta sola. La conformità per l'alto rischio è un sistema che gestisci per tutta la vita del prodotto, e l'Act si aspetta che tu dimostri che il sistema è attivo, non che esisteva il giorno del lancio.

1. La gestione del rischio è continua. Identifichi l'uso improprio e i danni prevedibili, li mitighi, testi il rischio residuo e ripeti a ogni modifica sostanziale. Un registro dei rischi congelato al lancio è un rilievo, non un controllo.
2. La governance dei dati copre i set di addestramento, validazione e test: rappresentatività, esame dei bias, lacune e provenienza dei dati. Devi mostrare cosa hai verificato e cosa hai riscontrato, non limitarti ad affermare che i dati erano "buoni".
3. La documentazione tecnica è la spina dorsale del fascicolo. Descrive il sistema, la sua finalità, le sue scelte progettuali, le sue metriche di prestazione e i suoi limiti con un livello di dettaglio sufficiente affinché un terzo possa valutarne la conformità.
4. La conservazione delle registrazioni significa logging automatico per tutta la vita del sistema, così che gli eventi siano tracciabili. Se qualcosa va storto, devi essere in grado di ricostruire cosa ha fatto il sistema.
5. La sorveglianza umana deve essere progettata sin dall'inizio, non aggiunta a posteriori: le persone che supervisionano il sistema devono poter comprendere, intervenire e annullare, e l'interfaccia deve renderlo possibile.
6. Accuratezza, robustezza e cybersecurity devono essere misurate e dichiarate, poi mantenute in condizioni reali, comprese quelle avversariali. "Funziona nella demo" non è un'affermazione di robustezza.

Questi obblighi si mappano in modo pulito su un sistema di gestione, ed è per questo che i team abbinano l'Act alla ISO/IEC 42001. Il corso ISO 42001 Lead Implementer costruisce il modello operativo che trasforma queste sette aree in processi ripetibili con responsabili, prove e cicli di revisione.

Il flusso di lavoro della valutazione di conformità

La valutazione di conformità è il vincolo che un sistema ad alto rischio supera prima di essere immesso sul mercato europeo. Per la maggior parte delle categorie ad alto rischio si tratta di una valutazione basata sul controllo interno, condotta dal fornitore rispetto ai requisiti dell'Act; alcune categorie, in particolare certe applicazioni biometriche, passano attraverso un organismo notificato. In entrambi i casi la sequenza è la stessa, e conviene trattarla come un piano di progetto anziché come una checklist.

1. Conferma la classificazione e i requisiti applicabili per il tuo specifico caso d'uso e categoria.
2. Avvia i processi di gestione del rischio e di governance dei dati e mettili in atto, generando prove reali anziché segnaposto.
3. Assembla la documentazione tecnica in modo che sia completa e internamente coerente con i log, i risultati dei test e il registro dei rischi.
4. Esegui la valutazione di conformità (interna, oppure tramite un organismo notificato ove richiesto) e risolvi le lacune che emergono.
5. Redigi la dichiarazione di conformità dell'Unione, apponi la marcatura CE e registra il sistema nella banca dati dell'Unione prima di andare sul mercato.
6. Passa al monitoraggio post-commercializzazione dal primo giorno, perché l'obbligo non finisce con il lancio.

Monitoraggio post-commercializzazione e la tempistica a fasi

Immettere un sistema sul mercato è il punto intermedio dell'obbligo, non la fine. I fornitori devono attuare un piano di monitoraggio post-commercializzazione che raccolga attivamente dati su prestazioni e incidenti per tutta la vita di esercizio del sistema, e gli incidenti gravi devono essere segnalati alle autorità entro finestre temporali definite. Le modifiche sostanziali possono far scattare nuovamente la valutazione di conformità, quindi il tuo processo di change management e il tuo processo AI Act devono essere collegati tra loro.

La tempistica è a fasi, cosa che mette in difficoltà i team che leggono "agosto 2027" e presumono di avere fino ad allora per tutto. I divieti sulle pratiche inaccettabili si applicano già. Gli obblighi GPAI e diverse disposizioni di governance si collocano prima nel calendario, e gli obblighi per l'alto rischio entrano in vigore progressivamente nel periodo fino ad agosto 2027 a seconda della categoria. L'atteggiamento corretto è mappare ciascuno dei tuoi sistemi alla sua data applicabile, anziché pianificare verso un'unica scadenza limite.

Gestire il ciclo di monitoraggio e segnalazione degli incidenti è il punto in cui i ruoli di auditor e risk manager dell'IA si dimostrano preziosi. Il corso AI auditor (AAIA) tratta come auditare un sistema di gestione dell'IA rispetto a queste prove, e il corso advanced AI auditor (AAIR) approfondisce il lavoro di testing e assurance dietro un fascicolo post-commercializzazione difendibile.

IA per finalità generali: un obbligo separato che puoi ereditare

Le regole sui modelli GPAI si collocano accanto ai livelli di rischio, non al loro interno. Se costruisci o fai fine-tuning di un modello per finalità generali, ti assumi gli obblighi del fornitore: documentazione tecnica del modello, informazioni per i deployer a valle, una politica sul diritto d'autore e una sintesi pubblica dei contenuti di addestramento. I modelli giudicati portatori di rischio sistemico assumono doveri più stringenti, tra cui valutazione del modello, testing avversariale e segnalazione degli incidenti.

La trappola per la maggior parte dei team è l'altro lato di quella relazione. Se integri un modello fondativo di terze parti nel tuo sistema ad alto rischio, non sfuggi all'Act puntando il dito verso il fornitore del modello. Erediti il rischio di integrazione e resti responsabile del raggiungimento della conformità del tuo sistema. Tratta la documentazione del fornitore del modello come un input al tuo fascicolo, non come un sostituto, e metti in atto i flow-down contrattuali prima di andare in produzione.

Errori comuni e la decisione che hai davanti

• Trattare la classificazione come un fatto isolato. Una funzionalità nata come motore di raccomandazione diventa ad alto rischio nel momento in cui condiziona una decisione di assunzione o di credito. Riclassifica a ogni cambiamento sostanziale di finalità.
• Scrivere la documentazione come un artefatto di lancio. Il fascicolo deve restare sincronizzato con il sistema in esercizio; un fascicolo obsoleto è peggio di uno incompleto, perché induce attivamente in errore.
• Confondere il sistema di gestione con la regolamentazione. La ISO 42001 organizza le tue prove, ma di per sé non rende un sistema conforme all'AI Act. Devi comunque classificare, valutare e registrare rispetto all'Act.
• Presumere che gli obblighi del fornitore GPAI coprano la tua integrazione. Non è così. Il tuo sistema ad alto rischio ha bisogno di una propria storia di conformità.
• Pianificare verso un'unica scadenza. Le date a fasi fanno sì che alcuni obblighi siano già attivi mentre altri sono lontani anni; pianifica per sistema, per categoria.

La decisione che la maggior parte dei team ha davanti non è se conformarsi, ma come costruire la capacità di conformarsi ripetutamente. Se parti da zero, il corso ISO 42001 Foundation dà al team un vocabolario condiviso, e il corso AI security management (AAISM) collega gli obblighi di cybersecurity e robustezza dell'Act al programma di sicurezza che già gestisci. Scegli il ruolo più vicino alla tua lacuna e costruisci da lì verso l'esterno.