Checklist sistemi AI ad alto rischio per founder e compliance lead

I sistemi AI ad alto rischio hanno bisogno di checklist perche il problema non e capire il termine. Il problema e dimostrare che il caso d'uso corretto e stato rivisto, gli owner sono stati assegnati, i controlli attivati e l'evidenza conservata per clienti, board, auditor o regulator.

Secondo l'EU AI Act, la classificazione high-risk puo derivare da prodotti regolati o da casi d'uso dell'Annex III. Le draft guidelines della Commissione di maggio 2026 aiutano ad applicare Article 6, ma il regolamento resta la fonte giuridica.

1. Conferma il caso d'uso AI

Conferma se il workflow usa davvero un sistema AI. Label come automation, intelligence, insight, scoring, recommendation, assistant o optimization non bastano.

Registra nome sistema, area prodotto, finalita, modello o vendor, output, chi usa l'output e se la funzione e customer-facing, employee-facing, interna o embedded. Se non c'e sistema AI, documenta e chiudi la checklist.

2. Identifica il ruolo AI Act

Il ruolo conta perche gli obblighi cambiano tra provider, deployer, importer, distributor, product manufacturer e altri attori. Una SaaS company puo avere ruoli diversi per workflow.

Documenta chi sviluppa, chi controlla finalita e configurazione, chi mette il sistema sul mercato UE e quali istruzioni o role statement fornisce il vendor.

3. Rivedi la route prodotto regolato

Chiedi se il sistema puo essere componente di sicurezza di un prodotto regolato o un prodotto regolato. Questo puo contare per dispositivi medici, macchinari, trasporti, aviazione, radio equipment, giocattoli, ascensori o ambienti industriali.

Verifica se l'AI supporta comportamento di sicurezza, diagnosi, monitoring, controllo, alert o failure detection e se puo servire conformity assessment di terza parte.

4. Rivedi l'Annex III

L'Annex III e spesso piu rilevante per SaaS. Controlla biometria, infrastrutture critiche, education, recruiting, employment, worker management, accesso a servizi essenziali, credito, assicurazioni, giustizia, migrazione e processi democratici.

La classificazione segue finalita e uso concreto. Lo stesso modello puo essere low risk come assistente interno e high risk in un workflow di recruiting.

5. Valuta la configurazione cliente

SaaS e spesso configurabile. Una funzione ordinaria puo diventare sensibile se i clienti la usano per classificare candidati, valutare lavoratori, misurare studenti o influenzare accesso a servizi importanti.

Verifica se i clienti possono scegliere campi, criteri, soglie o label, se sono possibili workflow sensibili e se esiste un gate di review prima dell'abilitazione.

6. Assegna owner e gate

Assegna product owner, engineering owner, legal o compliance owner, security o risk owner e owner customer-facing per dichiarazioni approvate.

Una classificazione mancante dovrebbe bloccare il lancio in domini sensibili. Una classificazione probabilmente high-risk dovrebbe attivare review approfondita e condizioni di lancio.

7. Definisci evidenza minima

Conserva intake, descrizione sistema, role analysis, screen prodotto regolato, screen Annex III, finalita, analisi persone interessate, data flow, documenti vendor, decisione di classificazione, reviewer, data, razionale, fonti, decisione di lancio, controlli e prossimo trigger.

Per sistemi probabilmente high-risk aggiungi risk records, decisioni data governance, owner documentazione tecnica, testing, human oversight, logging, monitoring, incident path e route di conformita.

8. Trasforma controlli in lavoro prodotto

Risk management diventa record di rischio feature. Data governance diventa regole per dati training, test, input, cliente e feedback. Documentazione tecnica diventa cartella evidenze. Trasparenza diventa istruzioni cliente. Human oversight diventa processo reale di review. Monitoring diventa metriche con owner e cadenza.

9. Riapri la decisione

Riapri la checklist se cambiano finalita, modello, vendor, versione, review umana, configurazione cliente, mercato, categorie dati, monitoring, linee guida, standard o risk appetite.

FAQ

Cosa devono capire i team?

Quando i sistemi AI ad alto rischio possono applicarsi, quali cambiamenti operativi attivano e quale evidenza dimostra che il lavoro avviene.

Perche conta in pratica?

Perche puo influenzare design prodotto, gate di lancio, documentazione cliente, vendor review, monitoring, incident response ed evidenza audit.

Qual e l'errore principale?

Trattare high-risk AI come interpretazione legale unica invece che come workflow ripetibile con owner, trigger, evidenza ed escalation.

Fonti

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission draft guidelines on the classification of high-risk AI systems.
• European Commission AI Act FAQ on high-risk AI systems.
• European Commission guidance on AI Act standardisation.