Che cos'è un sistema AI ad alto rischio ai sensi dell'AI Act UE?

L'AI Act applica una classificazione basata sul caso d'uso. Un sistema AI è alto-rischio se è destinato a essere usato come componente di sicurezza di un prodotto coperto dalla legislazione di armonizzazione UE elencata nell'Allegato I, OPPURE se il suo uso destinato ricade in una delle categorie elencate nell'Allegato III: biometria, infrastrutture critiche, istruzione e formazione professionale, lavoro, accesso a servizi essenziali, law enforcement, migrazione/asilo/controllo frontiere, amministrazione della giustizia.

Per la cybersecurity: un sistema AI che "è destinato a essere usato come componente di sicurezza nella gestione e operazione di infrastruttura digitale critica" ricade nell'Allegato III(2) ed è quindi alto-rischio per default. Questo include il tooling offensivo autonomo deployato su operatori di infrastrutture critiche.

Un sistema alto-rischio richiede:

• Art. 9 sistema di gestione del rischio — continuo, documentato, copertura intero lifecycle.
• Art. 10 governance dei dati — qualità dati training/validation/test, valutazione bias, tracciabilità.
• Art. 11 documentazione tecnica — descrizione capability, architettura sistema, metodologia training, metriche performance, limitazioni note.
• Art. 12 logging — logging automatico di eventi rilevanti per il rischio e per il monitoraggio post-market.
• Art. 13 trasparenza — istruzioni operative sufficienti perché il deployer usi il sistema in modo responsabile.
• Art. 14 supervisione umana — human-in-the-loop significativo, kill-switch, capacità di override.
• Art. 15 accuratezza, robustezza, cybersecurity — dichiarata, misurabile, testata.
• Art. 17 sistema di gestione qualità — per il provider.
• Art. 72 monitoraggio post-market — reporting incidenti, tracking performance.

In pratica, tutto questo dev'essere presente come artefatti scritti, non come pratiche informali.

L'Atto distingue tra provider (chi immette il sistema sul mercato) e deployer (chi lo usa sotto la propria autorità).

• Il provider porta il grosso del carico di documentazione tecnica, gestione del rischio e valutazione di conformità.
• Il deployer è responsabile di usare il sistema in linea con le istruzioni, mantenere supervisione umana significativa, monitorarne l'operazione e segnalare incidenti gravi.

Se fai procurement di un tool security AI, ne diventi deployer. La due-diligence di procurement dovrebbe ora includere la review della documentazione tecnica art. 11 del provider, dei meccanismi di supervisione art. 14, e delle dichiarazioni di accuratezza/robustezza/cybersecurity art. 15.

Due shift pratici:

1. Il procurement chiede la documentazione tecnica AI Act come baseline. I vendor che non riescono a produrla vengono sempre più squalificati prima della valutazione commerciale.

1. I controlli interni lato deployer devono dimostrare supervisione umana significativa (kill-switch, audit trail degli eventi di override) e capacità di reporting di incidenti gravi. È documentazione-pesante e tipicamente emerge al primo ciclo di internal audit.

L'implicazione pratica: il tooling security AI che espone evidenze firmate per ogni azione, un kill-switch su ogni campagna, e hook di telemetria post-market è procurement-friendly. Il tooling opaco è sempre più difficile da deployare in un'org AI Act-aware.