Conformità all'AI Act dell'UE: documentazione tecnica, registrazione degli eventi, sorveglianza umana e governance dei dati

Quasi tutto ciò che è stato scritto sul regolamento europeo sull'intelligenza artificiale riguarda l'ambito di applicazione: in quale livello di rischio ricadete, se siete fornitore o deployer, se il vostro sistema rientra nell'allegato III. A quelle domande rispondono i vostri consulenti legali.

Quello che quasi nessuno affronta è ciò che succede dopo la risposta. Se il vostro sistema è ad alto rischio, il regolamento chiede un sistema di gestione dei rischi che attraversi l'intero ciclo di vita, una governance dei dati dimostrabile, la registrazione automatica degli eventi con una conservazione definita, una documentazione tecnica con una struttura prescritta, una sorveglianza umana progettata e non semplicemente dichiarata, e un monitoraggio successivo all'immissione sul mercato che raccolga davvero qualcosa. Sono tutti deliverable di ingegneria. È questa la parte che costruiamo noi.

A che punto sono le scadenze

L'AI Act (regolamento (UE) 2024/1689) è entrato in vigore ad agosto 2024 e si applica per fasi. Le fasi sono cambiate nel 2026 e conviene essere precisi, perché quel cambiamento ha spostato soldi e attenzione.

• 2 febbraio 2025: si applicano le pratiche vietate e gli obblighi di alfabetizzazione in materia di IA.
• 2 agosto 2025: si applicano gli obblighi per i modelli di IA per finalità generali.
• 2 agosto 2026: si applicano gli obblighi di trasparenza dell'articolo 50: informare l'utente che sta interagendo con un sistema di IA, marcare i contenuti sintetici, dichiarare il riconoscimento delle emozioni e la categorizzazione biometrica, etichettare i deep fake.
• 2 dicembre 2027: obblighi per i sistemi ad alto rischio autonomi, a seguito del Digital Omnibus. Consiglio e Parlamento hanno concordato il rinvio a maggio 2026 e l'approvazione definitiva è arrivata a giugno 2026.
• 2 agosto 2028: obblighi per i sistemi di IA ad alto rischio incorporati in prodotti già regolamentati.

Se siete fornitori di un sistema ad alto rischio, il rinvio vi ha comprato circa sedici mesi. Non ha ridotto il lavoro, e non ha spostato i due obblighi già in vigore: la trasparenza dell'articolo 50 e l'alfabetizzazione in materia di IA per il personale che usa questi sistemi.

Che cosa realizziamo

La documentazione tecnica come artefatto generato

L'allegato IV stabilisce che cosa la documentazione tecnica deve contenere: descrizione del sistema, scelte di progettazione, architettura, requisiti sui dati, metodologia di addestramento ove pertinente, procedure di convalida e di prova, metriche, misure di gestione del rischio e le modifiche apportate lungo il ciclo di vita.

Scritto a mano, quel documento è già superato la settimana dopo la firma. Noi lo costruiamo come qualcosa che la vostra pipeline produce: model card e schede dei dati generate dalle esecuzioni di addestramento e valutazione, descrizioni di architettura e flussi di dati mantenute accanto al codice, risultati delle valutazioni agganciati alla versione che descrivono, e una cronologia delle modifiche che nasce dal controllo di versione e non dalla memoria di qualcuno. Il documento diventa un output della build.

Registrazione automatica degli eventi conforme all'articolo 12

I sistemi ad alto rischio devono registrare automaticamente gli eventi per tutta la loro durata di vita, a un livello che consenta di tracciarne il funzionamento e di alimentare il monitoraggio successivo all'immissione sul mercato, con una conservazione adeguata alla finalità e, in alcuni casi, di almeno sei mesi.

Nella pratica significa decidere che cosa sia un "evento" per il vostro sistema, catturare input, output, versione del modello, percorso decisionale e identità della persona coinvolta, conservarli in una forma interrogabile anche a distanza di anni, e farlo senza accumulare dati personali che non avete titolo per tenere. Quella tensione (registrare abbastanza per l'AI Act, conservare abbastanza poco per il GDPR) è il vero problema di progettazione, e lo affrontiamo esplicitamente insieme alle vostre persone della protezione dati.

Governance dei dati secondo l'articolo 10

I set di dati di addestramento, convalida e prova devono essere pertinenti, sufficientemente rappresentativi e, nella misura del possibile, privi di errori e completi, con un esame delle possibili distorsioni. Rispettare quel requisito significa poter mostrare la tracciabilità del dato, documentare la provenienza, disporre di una metodologia di valutazione delle distorsioni con i relativi risultati, ed essere in grado di ricostruire quali dati abbiano prodotto quale versione del modello.

Costruiamo la pipeline che rende verificabili quelle affermazioni anziché velleitarie: set di dati versionati, suddivisioni riproducibili, controlli automatici di qualità del dato e valutazione delle distorsioni sulle caratteristiche protette rilevanti per il vostro caso d'uso.

Sorveglianza umana costruita, non dichiarata

L'articolo 14 richiede che i sistemi ad alto rischio siano progettati in modo che una persona possa comprendere l'output, restare consapevole del rischio di eccessiva fiducia nell'automazione, interpretare correttamente il risultato, decidere di non utilizzarlo e intervenire o arrestare il sistema.

È una specifica di interfaccia. La sorveglianza la costruiamo dentro il prodotto: confidenza e incertezza esposte con onestà, fattori alla base di un output resi visibili, un comando di override facile da usare quanto l'accettazione, un controllo di arresto che funziona, e la registrazione di ogni override, così che il monitoraggio successivo all'immissione sul mercato abbia qualcosa da cui imparare.

Monitoraggio post-commercializzazione e segnalazione degli incidenti

Il piano di monitoraggio è obbligatorio, così come la segnalazione degli incidenti gravi all'autorità competente. Costruiamo la telemetria che lo alimenta: prestazioni misurate rispetto alle metriche indicate nella documentazione, rilevamento della deriva su input e output, un canale attraverso cui i problemi segnalati dagli utenti arrivino davvero all'ingegneria, e un flusso di gestione degli incidenti con i tempi previsti già incorporati, invece di scoprirli durante il primo incidente.

Obblighi di trasparenza dell'articolo 50

Già in vigore. Informare l'utente che sta interagendo con un sistema di IA, marcare in formato leggibile da una macchina audio, immagini, video e testi sintetici, etichettare i deep fake e dichiarare il riconoscimento delle emozioni. Implementiamo le interfacce di informativa e la marcatura di provenienza dei contenuti (con le content credentials C2PA dove è il meccanismo adatto), e facciamo in modo che sopravvivano ai percorsi di esportazione e ricodifica che di solito le cancellano.

Supporto alla registrazione e alla conformità

I sistemi ad alto rischio che ricadono negli ambiti dell'allegato III devono essere registrati nella banca dati dell'UE prima di essere immessi sul mercato, e i fornitori devono svolgere una valutazione della conformità. Prepariamo gli elementi tecnici (documentazione, dossier di evidenze, gli artefatti del sistema di gestione della qualità sul lato ingegneristico), e lavoriamo insieme al vostro organismo notificato o al vostro processo interno di valutazione.

Che cosa non facciamo

Non forniamo consulenza legale e non vi diciamo in quale livello di rischio ricada il vostro sistema. Quella determinazione è giuridica, ha conseguenze concrete e spetta ai legali o a un consulente qualificato in materia di conformità.

Non vendiamo nemmeno una piattaforma di AI governance. Ne esistono molte e, se ciò che vi serve è un registro dei sistemi di IA e un flusso di approvazione delle policy, una di quelle vi servirà meglio di noi. Noi facciamo l'ingegneria dentro i sistemi.

A chi ci rivolgiamo

Fornitori di sistemi di IA ad alto rischio ai sensi dell'allegato III (selezione del personale e gestione dei lavoratori, valutazione del merito creditizio, tariffazione assicurativa, valutazione nell'istruzione, accesso a servizi essenziali, sistemi biometrici), che ora hanno tempo fino a dicembre 2027 e parecchio da costruire.

Fabbricanti che incorporano l'IA in prodotti regolamentati (dispositivi medici, macchinari, veicoli), dove l'AI Act si sovrappone a un regime di conformità già esistente e le due serie di documenti devono coincidere.

Aziende che utilizzano sistemi ad alto rischio acquistati da terzi, che hanno obblighi propri: sorveglianza umana, pertinenza dei dati di input, monitoraggio e conservazione dei log.

Chiunque rilasci funzionalità generative a utenti dell'UE, dove la trasparenza dell'articolo 50 si applica già oggi a prescindere dal livello di rischio.

Come si svolgono i progetti

Valutazione tecnica dei gap, dalle due alle quattro settimane. Partiamo dalla classificazione a cui è arrivato il vostro team legale e valutiamo i vostri sistemi rispetto agli obblighi ingegneristici che ne derivano. Il risultato è un registro dei gap (obbligo, stato attuale, che cosa va costruito, impegno stimato), su cui possono lavorare sia i responsabili della conformità sia quelli tecnici.

Realizzazione, per fasi, di norma a partire dai log e dalla generazione della documentazione, perché tutto il resto produce evidenze che devono pur atterrare da qualche parte.

Revisione di prontezza prima della valutazione della conformità, con il dossier di evidenze assemblato e i gap residui indicati con onestà.

Standard e riferimenti

Regolamento (UE) 2024/1689 con gli allegati III e IV; le norme armonizzate in arrivo dal CEN/CENELEC JTC 21; ISO/IEC 42001 per i sistemi di gestione dell'IA e ISO/IEC 23894 per la gestione del rischio; il NIST AI Risk Management Framework dove una capogruppo statunitense chiede allineamento; e il GDPR, che non sparisce e che condiziona la maggior parte delle scelte sui log.

Domande frequenti

L'AI Act è stato rinviato?

In parte. Il Digital Omnibus ha differito gli obblighi per i sistemi ad alto rischio al 2 dicembre 2027 per i sistemi autonomi e al 2 agosto 2028 per l'IA incorporata in prodotti regolamentati. Pratiche vietate, alfabetizzazione in materia di IA, obblighi sui modelli di IA per finalità generali e regole di trasparenza dell'articolo 50 non sono stati rinviati e sono in vigore adesso.

Usiamo solo sistemi di IA costruiti da altri. Abbiamo comunque degli obblighi?

Sì, in qualità di deployer. Tra questi: utilizzare il sistema secondo le istruzioni per l'uso, affidare la sorveglianza umana a persone con la competenza e l'autorità per esercitarla, assicurarsi che i dati di input siano pertinenti alla finalità prevista, monitorare il funzionamento e conservare i log. Sono obblighi più leggeri di quelli del fornitore, ma reali, e va notato che modificare sostanzialmente un sistema o apporvi il proprio nome può rendervi fornitori.

Il nostro sistema non è ad alto rischio. C'è comunque qualcosa da fare?

Probabilmente due cose. La trasparenza dell'articolo 50 si applica a determinati sistemi indipendentemente dal livello di rischio, chatbot e generazione di contenuti sintetici compresi. E l'alfabetizzazione in materia di IA prevista dall'articolo 4 riguarda in generale fornitori e deployer. Oltre a questo, poter dimostrare come siete arrivati alla classificazione è utile se un'autorità dovesse chiedervelo.

La documentazione tecnica può davvero essere generata?

In gran parte sì. Architettura, descrizione dei set di dati, risultati delle valutazioni, metriche, versioni dei modelli e cronologia delle modifiche esistono già nei vostri sistemi; il lavoro sta nel catturarli in una struttura stabile al momento della build. Le sezioni davvero narrative (finalità prevista, analisi dei rischi, motivazioni progettuali) le scrivono delle persone, e poi restano nello stesso repository così da essere versionate insieme a tutto il resto.

Come si combinano AI Act e GDPR?

Si sovrappongono e ogni tanto tirano in direzioni opposte, in particolare sui log. L'AI Act vuole tracciabilità, il GDPR vuole minimizzazione e cancellazione. La soluzione passa di solito da pseudonimizzazione, perimetrazione attenta di ciò che si registra e tempi di conservazione definiti e legati a una finalità documentata. È una decisione di progettazione, presa una volta e presa con cognizione.

Usare un modello di terzi ci rende fornitori di quel modello?

No, ma costruirci sopra un sistema di IA può rendervi fornitori di quel sistema, con gli obblighi che ne discendono. Dove cada esattamente la linea dipende da che cosa costruite e da come lo presentate, ed è una questione giuridica: la conseguenza ingegneristica, però, è che dovete dare per scontato che vi servirà una documentazione del vostro sistema in ogni caso.

Iniziamo

Raccontateci che cosa fanno i vostri sistemi e a quali conclusioni sono arrivati i vostri consulenti legali sulla classificazione. Valuteremo che cosa significano gli obblighi in termini di codice e vi consegneremo un registro dei gap con l'impegno stimato riga per riga.

Contattateci per fissare una valutazione tecnica dei gap sull'AI Act.

Servizi correlati

• Sviluppo di agenti AI e integrazione MCP: costruire i sistemi che questo regime disciplina
• Sviluppo per Ingresso nel Mercato UE: il più ampio stack di conformità digitale dell'UE
• Rimedio per l'accessibilità web: l'altro obbligo europeo che si rivela un progetto di ingegneria