La maggior parte dei programmi di conformità fallisce perché resta troppo a lungo sul piano concettuale. Questa checklist traduce gli obblighi dell'Articolo 17 in flussi di lavoro implementativi che i team di prodotto, ingegneria e conformità possono eseguire concretamente. Utilizzatela come baseline di programma, adattandola poi per settore e profilo di rischio.
Fase 1: Definire il perimetro e classificare
Iniziate determinando esattamente quali sistemi e release rientrano nel perimetro degli obblighi per l'alto rischio. Non costruite controlli per un ambito non definito.
La chiarezza dei ruoli è essenziale. Gli obblighi del fornitore differiscono da quelli del deployer e la confusione tra ruoli rimane una delle fonti di rilavorazione più costose.
- Inventariare i sistemi di IA e classificare lo status di alto rischio in base alla finalità prevista
- Confermare i confini fornitore/deployer per ogni prodotto e scenario cliente
- Gestire il regime transitorio per i sistemi già immessi sul mercato e le relative modifiche
Fase 2: Costruire la mappatura requisiti-controlli
Create una matrice dei requisiti per gli Articoli 9-15 e le famiglie di controllo dell'Articolo 17. Ogni requisito deve avere un responsabile, una procedura operativa e una definizione degli artefatti di evidenza.
Laddove le norme armonizzate non siano disponibili o non coprano integralmente i requisiti, documentate in modo esplicito le misure tecniche alternative e le relative motivazioni.
- Gestione del rischio (Articolo 9) integrata con i controlli di rilascio e gestione delle modifiche
- Governance dei dati (Articolo 10) con logiche di rappresentatività e gestione dei bias
- Documentazione tecnica e predisposizione alla conservazione delle registrazioni (Articoli 11-12)
- Trasparenza, sorveglianza umana e soglie di qualità (Articoli 13-15)
Fase 3: Rendere operativi i controlli sul ciclo di vita
Le procedure documentate sono necessarie ma non sufficienti. I controlli devono essere attivi nelle fasi di progettazione, test, deployment, monitoraggio post-commercializzazione e gestione degli incidenti.
Un punto debole ricorrente è la governance delle modifiche: i team tracciano le variazioni di versione ma non valutano l'impatto sulla conformità applicando la logica di modifica sostanziale di cui all'Articolo 3, paragrafo 23.
- Verifica pre-deployment con evidenze di test riproducibili
- Governance dei fornitori e dei componenti esterni con controlli proporzionati al rischio
- Gate di gestione delle modifiche che attivano la rivalutazione quando necessario
- Tracciabilità che colleghi le versioni in produzione alla documentazione e alle evidenze
Fase 4: Costruire la capacità operativa post-commercializzazione e di gestione degli incidenti
Il monitoraggio post-commercializzazione e la prontezza operativa per gli incidenti gravi sono gli ambiti in cui i programmi puramente documentali falliscono nelle condizioni reali. Costruite i flussi di lavoro ora, non dopo il lancio.
I team operativi dovrebbero condurre esercitazioni simulate almeno trimestralmente, affinché i percorsi di escalation e le responsabilità di segnalazione non restino teorici.
- Definire indicatori di prestazione e di rischio monitorati per ciascun sistema di IA
- Stabilire soglie, responsabilità e SLA di risposta per gli eventi avversi
- Implementare triage degli incidenti, segnalazione alle autorità e cicli di azione correttiva
- Conservare le evidenze in un formato utilizzabile per audit e richieste delle autorità
Fase 5: Governance, formazione e qualità delle evidenze
L'efficacia del sistema di gestione della qualità dipende dalla competenza e dalla responsabilizzazione, non solo dai template. Assicuratevi che i team responsabili siano formati sugli obblighi specifici del loro ruolo e sull'autorità decisionale.
Per accelerare la preparazione, utilizzate la guida alla documentazione dell'Allegato IV e la baseline dei requisiti del Regolamento UE sull'IA insieme a questa checklist.
- Definire i responsabili e la governance di escalation a livello dirigenziale
- Condurre formazione basata sui ruoli per i team di ingegneria, prodotto, legale e operations
- Effettuare audit interni periodici con azioni correttive ed evidenze di chiusura
- Mantenere aggiornato e consultabile un indice delle evidenze destinato alle autorità di regolamentazione
Domande frequenti
Qual è la prima cosa da fare per la conformità all'Articolo 17?
Definire il perimetro di applicazione e i confini di responsabilità. Senza un ambito chiaro dei sistemi ad alto rischio e delle responsabilità del fornitore, ogni piano di controllo a valle diventa instabile.
È necessario che tutte le norme armonizzate siano finalizzate per essere conformi?
No. È necessaria un'implementazione conforme agli obblighi di legge. Le norme armonizzate facilitano i percorsi di presunzione di conformità, ma il lavoro di adeguamento non può attendere la pubblicazione completa di tutte le norme.
Quali evidenze richiedono per prime gli auditor?
Tipicamente la titolarità dei controlli, le procedure operative, gli artefatti di evidenza collegati alle versioni, le registrazioni del monitoraggio post-commercializzazione, i log di gestione degli incidenti e la prova che le decisioni di governance vengano effettivamente eseguite.
Punti chiave
La conformità all'Articolo 17 è una disciplina di sistema di gestione, non una singola milestone di progetto. I team che tratteranno questa checklist come un modello operativo vivo saranno meglio preparati sia per l'applicabilità di agosto 2026 sia per il controllo continuativo delle autorità di vigilanza.