Documentazione tecnica dell’IA: che cos’è, che cosa deve contenere e come prepararla prima che sia obbligatoria

L’AI Act richiede che ogni sistema di IA ad alto rischio disponga di una documentazione tecnica completa. Ti spieghiamo le 16 sezioni che deve contenere, come si collega alla FRIA e alla DPIA, e una strategia pratica per iniziare a documentare i tuoi sistemi oggi

Quando si parla di AI Act, la conversazione si concentra di solito sulla classificazione dei rischi o sulle sanzioni. Ma c’è un obbligo meno visibile che richiederà alle aziende uno sforzo operativo enorme: la documentazione tecnica.

La documentazione tecnica è la descrizione completa di un sistema di IA. Non è una sintesi per la direzione né una scheda di prodotto. È un dossier esaustivo che descrive che cosa fa il sistema, come funziona, quali dati usa, come viene valutato, chi lo supervisiona, come viene messo in sicurezza e che cosa succede quando si guasta. Per i sistemi ad alto rischio, tenerla aggiornata non è una buona pratica: è un obbligo di legge.

Il problema è che la maggior parte delle aziende non documenta i propri sistemi di IA con questo livello di dettaglio. Ha codice nei repository, modelli in produzione, configurazioni sparse e conoscenza distribuita nella testa dei suoi ingegneri. Trasformare tutto questo in una documentazione tecnica strutturata richiede tempo, processo e un modello chiaro.

In questo articolo ti spieghiamo che cos’è la documentazione tecnica, perché l’AI Act la richiede, quali sezioni deve contenere e come iniziare a costruirla anche se i tuoi sistemi sono già in produzione.

Che cos’è la documentazione tecnica e perché ti serve

La documentazione tecnica è il documento centrale della compliance di un sistema di IA. L’AI Act la richiede per tutti i sistemi ad alto rischio (sia per i fornitori sia per i deployer) e deve essere disponibile per le autorità di vigilanza se la richiedono.

Il suo obiettivo è triplice:

• Tracciabilità: Permette di ricostruire come funziona il sistema, con quali dati è stato addestrato o configurato, quali metriche si usano per valutarlo e chi prende le decisioni sul suo rilascio.
• Responsabilità: Documenta le decisioni tecniche e organizzative: perché è stato scelto quel modello, perché sono state fissate quelle soglie, chi ha approvato il passaggio in produzione.
• Continuità operativa: Se il responsabile del sistema cambia ruolo o azienda, la documentazione permette a qualsiasi persona con il profilo adeguato di capire, mantenere e verificare il sistema.

La documentazione tecnica non è una formalità. È la memoria istituzionale del tuo sistema di IA.

Le 16 sezioni della documentazione tecnica

Sulla base dei requisiti dell’AI Act e delle migliori pratiche di governance dell’IA, una documentazione tecnica completa comprende le sezioni seguenti:

Blocco 1: Identificazione e contesto (sezioni 0-2)

1. Copertina e metadati. Nome del sistema, versione, data, product owner, responsabile del rilascio, fornitore, DPO, CISO. Stato del sistema (progettazione, pilota, produzione, ritirato). Normativa applicabile: GDPR, AI Act, DSA, DMA, NIS2.
2. Finalità e limiti. Scopo del sistema, processi supportati, popolazione e canali inclusi ed esclusi, casi di astensione. Uso previsto secondo le istruzioni del fornitore. Modifiche sostanziali che richiedono una nuova valutazione.
3. Classificazione e ruolo ai sensi dell’AI Act. Ruolo dell’organizzazione (fornitore, deployer, importatore, distributore). Classificazione del sistema (vietato, alto rischio Allegato III, alto rischio incorporato Allegato I, limitato, minimo). Valutazioni richieste: DPIA sì/no, FRIA sì/no.

Blocco 2: Architettura e dati (sezioni 3-5)

1. Architettura e ambienti. Diagramma end-to-end del sistema. Descrizione dei componenti, delle dipendenze esterne e dei punti di controllo. Endpoint per ambiente (sviluppo, staging, produzione). Modalità degradata e continuità: RTO, RPO, evidenza del test.
2. Dati e governance. Inventario dei dataset: origine, presenza di dati personali o sensibili, base giuridica del trattamento, rappresentatività, conservazione, trasferimenti, data owner. Collegamenti alla DPIA e agli accordi sul trattamento dei dati (DPA).
3. Metodo e configurazione del sistema. Tecnica utilizzata (modello supervisionato, RAG, agente, ecc.), fornitore, ID/versione del modello, parametri chiave, guardrail e policy. Per i sistemi RAG: top-k, reranking, finestre contestuali, template di prompt.

Blocco 3: Valutazione e supervisione (sezioni 6-8)

1. Valutazione, metriche e soglie. Metriche con formula, dataset di valutazione, obiettivo, soglia e trigger operativo (revisione o rollback). Frequenza della valutazione e responsabile. Questo è il cuore tecnico della documentazione.
2. Supervisione umana. Punti di controllo in cui interviene una persona. Per ciascuno: condizione di attivazione, azione umana, livello di autorità, evidenza generata, SLA.
3. Logging e tracciabilità. Che cosa viene registrato a ogni interazione: input, contesto, passaggi citati (se è RAG), output, punteggi, decisione, utente/agente. Conservazione, accessi e collocazione dei log.

Blocco 4: Sicurezza e trasparenza (sezioni 9-10)

1. Sicurezza e continuità (NIS2/DR-BCP). Controlli di sicurezza con evidenze, periodicità, responsabile e stato. RTO, RPO, risultati dei test di ripristino, modalità degradata.
2. Trasparenza e informazione all’utente. Testi dell’avviso di IA, rilevabilità dei contenuti sintetici, pagine esplicative. Screenshot e versioni degli avvisi.

Blocco 5: Rischi e modifiche (sezioni 11-14)

1. Rischi e salvaguardie (sintesi FRIA/DPIA). Sintesi dei rischi individuati nella FRIA e nella DPIA: rischio, diritto coinvolto, gravità × probabilità, misure, rischio residuo, evidenza.
2. Gestione delle modifiche. Changelog con ogni modifica rilevante: ID, data, oggetto della modifica, impatto atteso, evidenze dei test, decisione.
3. Ruoli e responsabilità (RACI). Matrice RACI per le attività critiche: DPIA/FRIA, metriche, logging, sicurezza, trasparenza, changelog, deploy.
4. Incidenti e post-market monitoring. Registro degli incidenti con data, descrizione, gravità, azione correttiva, chiusura. Collegamento ai post-mortem.

Blocco 6: Chiusura (sezioni 15-16)

1. Allegati e collegamenti. Inventario dei documenti collegati: metriche, checklist, evidenze RAG, changelog, runbook degli incidenti, DPA, DPIA, FRIA.
2. Approvazioni. Firme del product owner, del data owner/ML, di legale/DPO, di sicurezza/CISO e della direzione. Data di approvazione e trigger di revisione.

Punto chiave: La documentazione deve essere completata prima del Gate 2 (pre-rilascio) del sistema di governance dell’IA. E deve essere aggiornata in caso di modifiche sostanziali o dopo la finestra di stabilizzazione successiva al go-live.

Esempio: che cosa conterrebbe la documentazione di un chatbot RAG di assistenza clienti

Per renderlo concreto, vediamo come si applicherebbe la documentazione a un chatbot RAG di assistenza clienti in un ecommerce. Questo sistema usa l’IA generativa per rispondere alle domande dei clienti su ordini, resi e prodotti, basandosi su una base di conoscenza interna.

• Classificazione: Rischio limitato (non è nell’Allegato III, ma interagisce direttamente con i consumatori). Richiede trasparenza: l’utente deve sapere che sta parlando con un’IA.
• Architettura: Base di conoscenza indicizzata (documenti di policy, FAQ, catalogo prodotti) → ricerca vettoriale (top-k=5) → reranking → LLM con prompt di sistema che include istruzioni di grounding → risposta all’utente.
• Metriche chiave: Faithfulness (fedeltà al contesto) ≥ 90%, tasso di allucinazioni < 5%, soddisfazione dell’utente (CSAT) ≥ 4,0/5, tasso di escalation a un agente umano < 15%.
• Supervisione umana: Escalation automatica quando il chatbot rileva l’intenzione di presentare un reclamo formale, una richiesta di rimborso superiore a 200€ o tre domande consecutive senza una risposta soddisfacente.
• Trasparenza: Banner visibile: «Questo assistente usa l’intelligenza artificiale. Per parlare con un agente, scrivi AGENTE». Rilevabilità dei contenuti sintetici se vengono generate immagini o sintesi.
• Sicurezza: Test periodici di prompt injection, guardrail contro la generazione di informazioni su temi non legati al business, filtraggio dei dati personali nei log.

Anche se questo sistema non è ad alto rischio, documentarlo con la documentazione tecnica è una buona pratica che facilita la manutenzione, l’audit interno e la dimostrazione della diligenza se sorge un problema.

Gli errori che vediamo più spesso quando si documentano i sistemi di IA

• Documentazione retrospettiva: Il sistema è in produzione da mesi e nessuno ha documentato nulla. Ricostruire il dossier da zero è possibile, ma costoso in tempo e fatica.
• Documentazione statica: Il dossier viene creato una volta e non si aggiorna. Una documentazione non aggiornata è peggio che non averla, perché genera una falsa sensazione di conformità.
• Focus solo sul modello: La documentazione non è solo la scheda del modello di IA. Comprende dati, sicurezza, supervisione umana, trasparenza, incidenti e governance organizzativa.
• Senza metriche né soglie: Una documentazione senza metriche valutabili è un documento descrittivo, non uno strumento di controllo. Devi sapere quando il sistema funziona bene e quando no.
• Scollegata dalla FRIA: La documentazione tecnica e la FRIA devono essere collegate. I rischi individuati nella FRIA devono comparire nella sezione 11 del dossier con le relative salvaguardie.

Strategia pratica: come cominciare senza bloccarti

Non devi documentare tutto in una volta. La strategia più efficace è progressiva:

1. Settimane 1-2: Inventario. Elenca tutti i sistemi di IA in uso o in sviluppo. Per ciascuno individua: nome, responsabile, stato (progettazione/pilota/produzione), classificazione preliminare ai sensi dell’AI Act.
2. Settimane 3-4: Prioritizzazione. Classifica ogni sistema secondo l’AI Act. Quelli ad alto rischio (Allegato III) hanno bisogno di una documentazione completa. Quelli a rischio limitato, di una documentazione proporzionata.
3. Mese 2: Copertina + Classificazione + Architettura. Completa le sezioni 0-3 dei sistemi prioritari. Sono le più semplici perché l’informazione esiste già, va solo strutturata.
4. Mese 3: Dati + Metodo + Metriche. Completa le sezioni 4-6. Questa è la parte tecnica densa: richiede il coordinamento con i team di dati e di ingegneria.
5. Mese 4: Supervisione + Sicurezza + Trasparenza. Sezioni 7-10. Qui entrano in gioco i team di operations, sicurezza e legale.
6. Mese 5: Rischi + Governance + Approvazioni. Sezioni 11-16. Collega alla FRIA e alla DPIA, definisci la RACI e ottieni le approvazioni.

Se cominci oggi con questa cadenza, in 5 mesi avrai completa la documentazione dei tuoi sistemi critici. Questo ti lascia margine prima di agosto 2026.

La documentazione dentro il quadro di governance dell’IA

La documentazione tecnica non vive isolata. Nel modello dei 5 Pilastri della AI Transformation è un pezzo centrale del Pilastro di Compliance e si collega a tutto l’ecosistema di governance:

• Gate (porte di controllo): La documentazione si avvia al Gate 1 (approvazione del progetto) e deve essere completa per il Gate 2 (pre-rilascio). Al Gate 3 (post-rilascio) si verifica che sia aggiornata.
• FRIA e DPIA: La documentazione le integra nella sezione 11 e le richiama negli allegati. Non le sostituisce: le completa con la dimensione tecnica.
• AI Steering Committee: Il comitato IA esamina la documentazione come parte della decisione GO/FIX/KILL. Una documentazione incompleta è un argomento a favore di un FIX.
• Policy IA Lite: I principi di osservabilità e reversibilità della policy si concretizzano nelle sezioni di logging (8) e modalità degradata (9) della documentazione.

Chi deve partecipare alla stesura della documentazione

Un errore frequente è dare per scontato che la documentazione tecnica sia responsabilità esclusiva del team dati o di ingegneria. In realtà richiede la partecipazione coordinata di più profili:

• Product Owner / responsabile di business: Definisce la finalità, i limiti d’uso e i criteri di successo del sistema. Responsabile delle sezioni 1 e 2.
• Data Engineer / ML Engineer: Documenta l’architettura, i dati, il metodo, le metriche e il logging. Sezioni 3-6 e 8.
• Legale / DPO: Valida la classificazione ai sensi dell’AI Act, la FRIA, la DPIA e i requisiti di trasparenza. Sezioni 2, 10 e 11.
• Sicurezza / CISO: Documenta i controlli di sicurezza, la continuità e i test di ripristino. Sezione 9.
• Operations: Definisce e documenta i punti di supervisione umana, il runbook degli incidenti e la modalità degradata. Sezioni 7 e 14.

La matrice RACI (sezione 13) formalizza queste responsabilità ed è decisiva perché la documentazione resti viva dopo la sua creazione iniziale.

Conclusione: documenta oggi ciò che domani sarà obbligatorio

La documentazione tecnica è probabilmente l’obbligo dell’AI Act che richiede il maggiore sforzo operativo. Non si risolve con un documento generico: ogni sistema ha bisogno del proprio dossier, con dati specifici, metriche reali e decisioni documentate.

La buona notizia è che gran parte delle informazioni esiste già nella tua organizzazione. La sfida è strutturarle, centralizzarle e mantenerle aggiornate. Con il modello a 16 sezioni e una cadenza progressiva, puoi avere i tuoi dossier pronti prima che l’obbligo entri in vigore.

Se hai bisogno di aiuto per costruire la documentazione tecnica dei tuoi sistemi di IA, definire le metriche di valutazione o integrare la documentazione nel tuo quadro di governance, in Impulsa3 abbiamo il modello, la metodologia e l’esperienza per accompagnarti.

impulsa3.com · Trasformazione Digitale e IA per PMI ed ecommerce · servicios@impulsa3.com