Quando si applica la documentazione tecnica e cosa fare dopo

La documentazione tecnica è un obbligo specifico dell'AI Act quando un'azienda è fornitore di un sistema ad alto rischio. L'articolo 11 impone di prepararla prima dell'immissione sul mercato o della messa in servizio, mantenerla aggiornata e renderla abbastanza chiara da consentire ad autorità e organismi notificati di valutare la conformità. L'allegato IV definisce il contenuto minimo.

Non ogni azienda SaaS che usa un'API di IA necessita quindi di un fascicolo completo. La risposta dipende dal confine del sistema, dal ruolo dell'azienda e dalla classificazione. Anche senza obbligo diretto, una documentazione proporzionata aiuta governance, controllo fornitori, richieste dei clienti, incidenti e successive rivalutazioni.

Confermare sistema, ruolo e classificazione

Descrivete l'intero sistema: finalità, utenti, persone interessate, input, output, integrazioni, contesto e influenza del risultato. Un modello di terzi può essere solo un componente del prodotto SaaS.

Stabilite poi il ruolo. Chi sviluppa e commercializza con il proprio nome un sistema ad alto rischio è normalmente fornitore; il cliente può essere deployer. Rebranding, modifica sostanziale o nuova finalità possono spostare le responsabilità. Valutate infine le due vie principali dell'articolo 6: prodotti regolamentati dell'allegato I e casi d'uso dell'allegato III. Consultate la guida per i fornitori SaaS.

Quando si applica l'articolo 11

Articolo 11 e allegato IV riguardano la documentazione dei sistemi ad alto rischio e pongono l'obbligo principale sul fornitore. Dopo il regolamento (UE) 2026/1744, le regole per i sistemi dell'allegato III si applicano dal 2 dicembre 2027 e quelle per i sistemi incorporati nei prodotti dell'allegato I dal 2 agosto 2028.

Non aspettate queste date. Diritto di settore, protezione dati, contratti, sicurezza e verifiche dei clienti possono già richiedere prove simili. Iniziare presto evita di ricostruire versioni, dati, test e decisioni.

Se il sistema non è ad alto rischio o l'azienda è solo deployer, il fascicolo completo potrebbe non essere dovuto. Registrate comunque decisione, fatti, revisore e trigger di riesame. Nuove finalità sensibili, modifiche sostanziali a modelli o dati, nuovi mercati o maggior impatto sulle persone impongono una nuova analisi.

Contenuto minimo

L'allegato IV richiede almeno:

1. Identità, finalità, versioni, utenti e condizioni operative.
2. Sviluppo, architettura, componenti e decisioni progettuali.
3. Provenienza dei dati, validazione, test e limiti prestazionali.
4. Rischi, controlli, sorveglianza umana, log ed escalation.
5. Robustezza, cybersicurezza ed esiti indesiderati prevedibili.
6. Cambiamenti, incidenti e monitoraggio post-commercializzazione.
7. Norme, percorso di conformità e approvazioni.
8. Tracciabilità di ogni affermazione a una fonte controllata.

Il fascicolo può essere un indice che rinvia ai registri controllati. Link stabili, permessi, versioni e conservazione contano più del numero di pagine.

Flusso operativo

1. Approvare l'ambito: registrare identificativo, finalità, confine, ruolo, classificazione e presupposti.
2. Creare l'indice dell'allegato IV: indicare fonte, proprietario, versione, stato, revisore e trigger.
3. Lasciare le prove ai veri proprietari: prodotto per la finalità, ingegneria per l'architettura, dati o ML per le valutazioni, sicurezza per i controlli, compliance per la mappatura.
4. Chiudere prima le lacune critiche: classificazione, prestazioni, rischi, supervisione e approvazione del rilascio.
5. Collegare i cambiamenti: finalità, modelli, dati, soglie, utenti, integrazioni o controlli devono attivare aggiornamenti e, se necessario, nuovi test.
6. Provare il reperimento: un revisore indipendente deve poter seguire un'affermazione prestazionale, un controllo, un percorso di supervisione e una release fino alle prove.

La checklist della documentazione tecnica offre una struttura dettagliata. Le risposte ai clienti devono inoltre coincidere con i controlli IA richiesti dagli acquirenti.

Errori comuni

• Partire da un modello prima di stabilire ambito e prove.
• Documentare il modello anziché l'intero sistema.
• Usare la documentazione del fornitore come prova della propria configurazione.
• Non riesaminare mai una conclusione di rischio basso.
• Tenere un fascicolo di audit scollegato da release e modifiche.

Esempio: selezione assistita dei candidati

Per una funzione che ordina candidature, il team deve definire finalità, fornitore, confine e analisi dell'allegato III. Se fornisce un sistema ad alto rischio, il fascicolo copre versioni in produzione, dati, flusso del cliente, valutazioni per gruppi, metriche, limiti, revisione umana, log, sicurezza e monitoraggio. Un cambio di modello o soglia deve riaprire i record collegati.

FAQ

Quando si applica ai team SaaS?

L'articolo 11 si applica ai fornitori di sistemi ad alto rischio. Confermate confine, ruolo e classificazione prima di considerare legalmente obbligatorio il fascicolo completo.

Cosa documentare per primo?

Finalità, confine, ruolo, classificazione, versione produttiva, architettura, rischi, valutazioni, controlli, istruzioni e proprietari.

Si possono riutilizzare i documenti di ingegneria?

Sì. Collegate fonti attuali e controllate e indicate nell'indice quale requisito e versione coprono.

Fonti

• Regolamento (UE) 2024/1689, articoli 6 e 11 e allegati I, III e IV.
• Regolamento (UE) 2026/1744 su documentazione e date applicative.
• Commissione europea, “AI Act”, calendario di attuazione vigente.