Come operazionalizzare i sistemi AI ad alto rischio senza rallentare il delivery prodotto

I sistemi AI ad alto rischio devono diventare un workflow di delivery, non una domanda legale che arriva alla fine. Il punto e identificare presto il caso d'uso, capire se puo applicarsi la route high-risk, assegnare owner, attivare controlli e conservare evidenza dove prodotto, security, privacy, compliance e team customer possono usarla.

Secondo l'EU AI Act, un sistema puo essere high-risk se e collegato alla sicurezza di un prodotto regolato o se e destinato a un caso d'uso sensibile dell'Annex III. Le draft guidelines della Commissione di maggio 2026 aiutano l'interpretazione, ma non sostituiscono il regolamento. Per i team SaaS la risposta operativa e inserire la review prima di vendita, configurazione o lancio.

Perche conta in pratica

La classificazione high-risk cambia cio che il team deve sapere prima del go-live: finalita prevista, persone interessate, categorie dati, modello o vendor, ruolo dell'azienda, human oversight, istruzioni d'uso, logging, monitoring, incident process, configurazione cliente ed evidenza.

Gli obblighi possono includere risk management, data governance, documentazione tecnica, record keeping, trasparenza, human oversight, accuratezza, robustezza, cybersecurity, quality management, conformity assessment, registrazione, monitoring e azioni correttive. Senza workflow questi temi emergono troppo tardi, spesso durante una customer review, un audit o una domanda regolatoria.

Partire da un intake high-risk

L'intake deve essere breve. Non deve chiedere una conclusione legale finale, ma raccogliere fatti: nome sistema, owner, scopo business, user journey, persone interessate, geografia, dati, modello o vendor, ruolo provider o deployer, output, uso umano dell'output e configurazioni cliente.

Poi servono due domande. Il sistema potrebbe essere componente di sicurezza di un prodotto regolato, o essere esso stesso un prodotto regolato? Questo conta per dispositivi medici, macchinari, trasporti, aviazione, radio equipment, giocattoli, ascensori e ambienti simili. Il caso d'uso potrebbe rientrare nell'Annex III, ad esempio employment, education, servizi essenziali, credito, assicurazioni, biometria, infrastrutture critiche, migrazione, giustizia o processi democratici?

Se nessuna route e plausibile, documenta la ragione e continua con review ordinaria AI, privacy, security e vendor. Se una route e plausibile, il caso richiede analisi piu profonda prima del lancio o dell'abilitazione cliente.

Definire trigger e lane

La review deve essere attivata da eventi che gia contano per il delivery: nuova feature AI, nuovo scopo, nuovo modello o vendor, dati cliente collegati al workflow, output che influenza persone, riduzione della review umana, configurazione cliente sensibile, ingresso nel mercato UE o domande buyer non coperte dall'evidenza.

Usa tre lane. Lane uno: nessun segnale high-risk, con breve giustificazione e trigger di nuova review. Lane due: incerto o sensibile, con reviewer nominato, deadline e blocco del lancio fino alla decisione. Lane tre: probabilmente high-risk, con lavoro approfondito di legal, prodotto, security, privacy e compliance.

Owner e controlli

Il product owner gestisce finalita, configurazione, scope e promesse al cliente. Engineering gestisce architettura, log, versioning, fallback e controlli tecnici. Legal o compliance gestisce razionale di classificazione, fonti, dichiarazioni ai clienti e trigger di review. Security o risk gestisce evidenza vendor, monitoring, incident escalation, accessi e resilienza.

Gli obblighi devono diventare controlli prodotto. Il risk management diventa un risk record della feature. La data governance diventa regole su dati di training, test, input, cliente e feedback. La documentazione tecnica diventa una cartella evidenze mantenuta. La trasparenza diventa istruzioni interne e customer-facing. Human oversight diventa un processo reale con potere di intervento. Monitoring diventa metriche, owner e cadenza.

Tenere l'evidenza vicino al delivery

L'evidenza non deve vivere in un archivio separato. Usa ticket prodotto per intake, record architetturali per design tecnico, vendor record per terze parti, privacy review per dati e persone interessate, security review per controlli e release checklist per gate.

Mantieni almeno intake, decisione di classificazione, role analysis, fonti, reviewer, data, razionale, controlli attivati, questioni aperte, approval, limiti cliente, owner monitoring, percorso incident e prossimo trigger di review.

FAQ

Cosa devono capire i team?

Che i sistemi AI ad alto rischio sono una questione operativa oltre che legale. Il workflow identifica il caso d'uso, lo instrada, attiva controlli e mantiene evidenza aggiornata.

Ogni feature AI SaaS e high-risk?

No. Molte feature AI-assisted non lo saranno. Il team deve comunque documentare perche la route high-risk non si applica.

Quando bisogna fermare un lancio?

Quando il caso d'uso puo influenzare persone in un'area Annex III, essere legato alla sicurezza di prodotto, non avere owner, mancare di evidenza o dipendere da una configurazione cliente non rivista.

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.
• European Commission May 2026 update on AI Act implementation timing.
• European Commission report on the review of prohibitions and high-risk AI.