Documentazione dei sistemi di IA: cosa richiede l’AI Act

In sintesi

• La documentazione di un sistema di IA è l’insieme di prove che dimostra come un sistema sia stato progettato, testato e monitorato in modo responsabile. Non coincide con l’uso dell’IA per redigere documentazione.
• Ai sensi dell’AI Act, la documentazione tecnica è obbligatoria per i sistemi di IA ad alto rischio. L’articolo 11 la richiede prima dell’immissione sul mercato e impone di mantenerla aggiornata.
• L’allegato IV definisce nove sezioni che tale documentazione deve contenere, dalla descrizione generale del sistema al piano di monitoraggio successivo all’immissione sul mercato.
• Artefatti già noti (model card, schede dei set di dati, registri) rispondono direttamente a questi obblighi: gran parte del lavoro consiste nell’organizzare prove che dovreste comunque produrre.
• Una base di prove ben strutturata soddisfa contemporaneamente l’AI Act, la ISO/IEC 42001 e il NIST AI RMF, ed è per questo che la documentazione appartiene a un processo di governance e non a una cartella dell’ultimo minuto.

Documentazione IA e documentazione dei sistemi di IA: due cose diverse

Chi cerca «artificial intelligence documentation» trova soprattutto software: strumenti che leggono documenti (Document AI, elaborazione intelligente dei documenti) o strumenti che redigono la documentazione al posto vostro. Questo significato esiste, ma non è ciò di cui ha bisogno un team di conformità o di gestione del rischio. Questa guida tratta l’altro significato: la documentazione dei sistemi di IA, ossia il fascicolo strutturato che descrive come funziona un determinato sistema di IA, con quali dati è stato addestrato, come è stato testato, quali rischi comporta e come viene sorvegliato. È la traccia scritta (sempre più digitale) che consente a un revisore, a un’autorità o al vostro stesso consiglio di amministrazione di confermare che il sistema fa ciò che dichiarate senza causare danni. La distinzione conta, perché i destinatari sono diversi. Un redattore tecnico vuole produrre più in fretta un manuale. Il fornitore di un sistema di IA ad alto rischio deve dimostrare, su richiesta, che il sistema rispetta requisiti di legge. L’autorità statunitense NTIA lo afferma con chiarezza: la documentazione è un elemento essenziale per la trasparenza e la valutazione, sia interna sia esterna, volontaria o imposta. Chi è coinvolto? Ai sensi dell’AI Act, i fornitori e i deployer di sistemi ad alto rischio sostengono gli obblighi più gravosi, e i fornitori di modelli di IA per finalità generali (GPAI) hanno propri doveri documentali. Se progettate, vendete o utilizzate IA in un settore regolamentato, il tema vi riguarda, e la piattaforma AI Sigil è concepita per strutturare esattamente queste prove.

Perché la documentazione dei sistemi di IA è ora un obbligo di legge

Per anni documentare l’IA è stata una buona prassi. L’AI Act l’ha trasformata in obbligo. L’articolo 11 impone che la documentazione tecnica di un sistema ad alto rischio sia redatta prima dell’immissione sul mercato o della messa in servizio e sia mantenuta aggiornata. Deve fornire alle autorità nazionali e agli organismi notificati informazioni sufficienti, in forma chiara e completa, per valutare la conformità. Quest’ultimo punto ridefinisce l’intero esercizio. La documentazione non è scritta per i vostri utenti, ma perché un terzo possa verificare la conformità. Se un valutatore non riesce a seguire le vostre prove, il sistema non è dimostrabilmente conforme, per quanto ben progettato. Due fattori rendono il tema urgente. Il primo è il calendario: gli obblighi documentali dei sistemi ad alto rischio elencati nell’allegato III si applicano dal 2 agosto 2026, quindi le prove devono esistere prima del lancio, non dopo un incidente. Il secondo è la responsabilità: come sostiene il rapporto della NTIA, una tenuta dei registri integrata nella valutazione costituisce la base di una responsabilità end-to-end. La documentazione è ciò che collega una scelta di progettazione a un risultato di test e poi a un comportamento in produzione. AI Sigil è stato costruito per questa disciplina di tracciabilità.

Cosa richiede l’allegato IV dell’AI Act (le nove sezioni)

L’allegato IV è la lista di riferimento. Definisce, come minimo, nove ambiti che la documentazione tecnica deve coprire per un sistema ad alto rischio.

1. Descrizione generale. La finalità prevista del sistema, il fornitore, le versioni, l’interazione con hardware e software e le istruzioni per l’uso.
2. Processo di sviluppo ed elementi. Specifiche di progettazione, architettura del sistema, requisiti sui dati, metodologia di addestramento, valutazione della sorveglianza umana, procedure di validazione e test.
3. Monitoraggio, funzionamento e controllo. Capacità e limiti del sistema, accuratezza attesa per gruppi specifici, esiti indesiderati prevedibili e misure tecniche di sorveglianza umana.
4. Metriche di prestazione. Perché gli indicatori scelti sono adeguati per questo sistema.
5. Sistema di gestione dei rischi. Il processo di gestione dei rischi previsto dall’articolo 9, con i rischi individuati e le misure di mitigazione.
6. Modifiche nel ciclo di vita. Un registro delle modifiche apportate al sistema durante la sua vita.
7. Norme applicate. Le norme armonizzate applicate o, in assenza, le soluzioni adottate per soddisfare i requisiti.
8. Dichiarazione di conformità UE. La dichiarazione formale di cui all’articolo 47.
9. Piano di monitoraggio successivo all’immissione sul mercato. Il sistema di monitoraggio delle prestazioni dopo l’implementazione, ai sensi dell’articolo 72.

I fornitori più piccoli godono di un alleggerimento. L’AI Act consente a PMI e start-up di fornire gli elementi dell’allegato IV in forma semplificata, e la Commissione deve pubblicare un modello semplificato destinato alle micro e piccole imprese. L’alleggerimento riguarda la forma, non la sostanza: le stesse domande esigono comunque risposta, e questo rende il collegamento di ciascuna sezione a un controllo riutilizzabile particolarmente conveniente.

La catena di dipendenze documentali

L’allegato IV sembra composto da nove risultati separati. In pratica, ogni sezione è alimentata da un altro obbligo che dovete comunque soddisfare. Riconoscere questa catena evita di scrivere due volte la stessa documentazione.

• La governance dei dati (articolo 10) alimenta la sezione 2. Le descrizioni dei set di dati, i registri di provenienza e i controlli di qualità diventano la parte «dati» del fascicolo di sviluppo.
• La gestione dei rischi (articolo 9) alimenta la sezione 5. Il registro dei rischi e le prove di mitigazione costituiscono la sezione sulla gestione dei rischi, non una nota separata.
• La tenuta dei registri (articolo 12) alimenta la sezione 3. L’articolo 12 impone ai sistemi ad alto rischio di conservare registri automatici per tutta la loro vita; tali registri sono la prova operativa di monitoraggio e controllo.
• La trasparenza (articolo 13) alimenta la sezione 1. L’articolo 13 richiede istruzioni per l’uso chiare, e lo stesso contenuto àncora la descrizione generale.
• La sorveglianza umana (articolo 14) alimenta le sezioni 2 e 3. Il modo in cui una persona può intervenire, ignorare o arrestare il sistema appartiene sia al fascicolo di progettazione sia alla descrizione del controllo.

La lezione è semplice: la documentazione è un sottoprodotto di una buona governance. Se gli articoli 9, 10, 12, 13 e 14 sono gestiti correttamente, l’allegato IV è soprattutto assemblaggio più che stesura.

Gli artefatti documentali principali

Non serve inventare formati. Il settore dispone già di artefatti collaudati, e ciascuno risponde agli obblighi sopra descritti.

• Model card. Introdotte da Mitchell e colleghi nel 2019, una model card riassume l’uso previsto di un modello, le prestazioni tra i gruppi, i limiti e le considerazioni etiche. Sostiene le sezioni 1, 3 e 4 dell’allegato IV.
• Schede dei set di dati (datasheet). Proposte da Gebru e colleghi nel 2018, una scheda documenta motivazione, composizione, processo di raccolta e usi consigliati di un set di dati. Sostiene la sezione 2 e la governance dei dati sottostante.
• System card. Una vista a livello di sistema che descrive come si combinano i componenti, usata da diversi grandi fornitori. Sostiene le sezioni 1 e 3.
• Valutazioni d’impatto sulla protezione dei dati. Quando sono coinvolti dati personali, la DPIA collega la documentazione dell’IA agli obblighi esistenti del GDPR.
• Registri e tracciamenti delle modifiche. I registri automatici (articolo 12) e un log delle modifiche versionato sostengono le sezioni 3 e 6.

Per l’IA per finalità generali, il codice di buone pratiche GPAI dell’Ufficio per l’IA prevede un impegno di documentazione e un modulo di documentazione del modello, offrendo ai fornitori GPAI un modello pronto per le informazioni che i deployer a valle richiederanno. Il rapporto della NTIA raggruppa questi strumenti e raccomanda che model card, schede dei dati e system card diventino prassi standard come elementi di responsabilità.

Una sola base di prove, tre quadri

Le stesse prove rispondono a più di un quadro normativo. È l’idea più utile per un team di conformità sotto pressione. La ISO/IEC 42001, la norma sui sistemi di gestione dell’IA, presenta requisiti pervasivi di «informazioni documentate» al punto 7.5 e una serie di controlli nell’allegato A (valutazioni d’impatto, politiche, registri). Il NIST AI RMF richiede profili documentati che catturino contesto, misurazione e monitoraggio. L’AI Act richiede l’allegato IV. Messi a confronto, questi testi si sovrappongono ampiamente. Una scheda dei dati soddisfa insieme una parte della sezione 2 dell’allegato IV, una parte dei controlli di gestione dei dati della ISO 42001 e una parte della funzione «Map» del NIST. Costruite la prova una volta, associatela a ciascun quadro e riutilizzatela. Duplicare la documentazione per ogni quadro è lo spreco più comune e più evitabile nella governance dell’IA; AI Sigil associa un unico insieme di controlli a più quadri affinché la prova sia inserita una sola volta.

Mantenere la documentazione pronta all’audit

Produrre la documentazione una volta non è l’obiettivo. Mantenerla veritiera lo è. L’allegato IV impone di tenere aggiornato il fascicolo, e gli obblighi di conservazione proseguono per anni dopo il ritiro di un sistema. Alcune pratiche distinguono i team pronti all’audit dagli altri.

• Trattare la documentazione come prova viva. Aggiornarla quando cambiano il modello, i dati o il profilo di rischio, non con cadenza annuale.
• Versionare tutto. Un valutatore deve vedere quale versione del modello corrisponde a quale risultato di test e a quale implementazione.
• Tenere una matrice di tracciabilità. Associare ogni sezione dell’allegato IV (e ogni controllo ISO o NIST) all’artefatto preciso che la soddisfa, così che le lacune emergano prima che le trovi un audit.
• Assegnare la responsabilità. Ogni artefatto ha bisogno di un titolare designato, altrimenti si disallinea.
• Pianificare la conservazione. Conservare i registri per il periodo richiesto dalla legge, che può superare di molto la vita attiva del sistema.

È qui che una cartella di PDF mostra i suoi limiti e una piattaforma di governance trova il suo posto. Quando la documentazione vive nello stesso sistema che gestisce controlli, rischi e prove, tenerla aggiornata diventa un flusso di lavoro anziché una corsa. Scoprite come la piattaforma AI Sigil se ne occupa.

Domande frequenti

Che cos’è la documentazione di un sistema di IA? È il fascicolo strutturato che descrive come un sistema di IA è stato progettato, addestrato, testato e monitorato e quali rischi comporta. Ai sensi dell’AI Act si chiama documentazione tecnica ed è obbligatoria per i sistemi ad alto rischio. Il suo scopo è permettere a un’autorità o a un revisore di confermare la conformità, cosa diversa da un manuale d’uso e dagli strumenti di IA che redigono documentazione. La documentazione dell’IA è obbligatoria per legge? Per i sistemi di IA ad alto rischio ai sensi dell’AI Act, sì. L’articolo 11 richiede documentazione tecnica prima dell’immissione sul mercato, mantenuta aggiornata. Anche i fornitori di modelli di IA per finalità generali hanno doveri documentali. I sistemi al di fuori delle categorie ad alto rischio possono richiedere documentazione più leggera o volontaria, ma la direzione di normative e standard va verso più requisiti, non meno. Cosa deve contenere la documentazione tecnica dell’AI Act? Almeno i nove ambiti dell’allegato IV: descrizione generale, processo di sviluppo ed elementi, monitoraggio e controllo, giustificazione delle metriche, sistema di gestione dei rischi, modifiche nel ciclo di vita, norme applicate, dichiarazione di conformità UE e piano di monitoraggio successivo all’immissione sul mercato. Qual è la differenza tra una model card e la documentazione tecnica? Una model card riassume finalità, prestazioni e limiti di un singolo modello. La documentazione tecnica dell’AI Act è più ampia: copre l’intero sistema, i suoi dati, la sua gestione dei rischi e le sue prove di conformità. La model card è un componente utile della documentazione, non un sostituto. Quando si applicano questi obblighi documentali? Gli obblighi documentali dei sistemi ad alto rischio elencati nell’allegato III si applicano dal 2 agosto 2026. Poiché la documentazione deve esistere prima dell’immissione sul mercato, i team devono costruirla durante lo sviluppo, non dopo il lancio. Le piccole imprese possono documentare in modo più semplice? Sì. L’AI Act consente a PMI e start-up di fornire gli elementi dell’allegato IV in forma semplificata, e la Commissione deve pubblicare un modello semplificato per le micro e piccole imprese. La semplificazione riguarda forma e impegno, non l’omissione delle domande di sostanza.

Conclusione

La documentazione di un sistema di IA non è un compito di scrittura aggiunto alla fine. È la prova che trasforma le affermazioni su un sistema in qualcosa che un’autorità, un revisore o un consiglio di amministrazione può verificare. L’AI Act lo rende esplicito con l’articolo 11 e le nove sezioni dell’allegato IV, ma gli stessi registri rispondono anche alla ISO/IEC 42001 e al NIST AI RMF. I team che costruiscono la documentazione come sottoprodotto di una buona governance, versionata, assegnata e riutilizzata, sono pronti quando arriva una valutazione. Quelli che la trattano come burocrazia non lo sono. Scoprite come AI Sigil trasforma la documentazione dell’IA in un flusso di governance.