Quando un sistema di IA è ad alto rischio?

Un’azienda sviluppa un sistema che analizza i CV e produce un ranking dei candidati: si tratta di un sistema considerato ad alto rischio. La stessa azienda sviluppa un sistema che, dopo la selezione, organizza i colloqui nel calendario del responsabile HR: in questo caso no. 

La differenza non è tecnica. Dipende interamente dalla classificazione normativa e le conseguenze pratiche delle due ipotesi, in termini di documentazione tecnica, valutazione della conformità e obblighi di trasparenza, sono molto diverse.

Il 19 maggio 2026, la Commissione europea ha pubblicato le bozze delle linee guida sull’articolo 6 dell’AI Act, aperte alla consultazione pubblica fino al 23 giugno 2026. Si tratta di documenti non vincolanti e non definitivi, ma di peso interpretativo considerevole: forniscono moltissimi esempi pratici su quando un sistema rientra o meno nell’alto rischio e rappresentano la lettura ufficiale della Commissione sui concetti giuridici che le autorità nazionali di vigilanza applicheranno.

Il rinvio delle scadenze introdotto dal Digital Omnibus (trattato nel numero 79 della newsletter) sposta al 2 dicembre 2027 l’applicazione per i sistemi dell’Allegato III e al 2 agosto 2028 per quelli dell’Allegato I. Ma il lavoro di classificazione non può aspettare quelle date: progettare un sistema ad alto rischio richiede scelte architetturali e documentali che, se non incorporate fin dall’inizio, diventano molto costose da recuperare.

 

I due binari dell’articolo 6

L’AI Act prevede due percorsi distinti attraverso i quali un sistema di IA può essere classificato ad alto rischio.

Il primo riguarda i sistemi che sono essi stessi prodotti regolamentati dalla normativa europea di armonizzazione settoriale o che operano come componenti di sicurezza di tali prodotti, a condizione che il prodotto richieda una valutazione di conformità da parte di un organismo notificato. Il riferimento è all’Allegato I: dispositivi medici, macchinari, giocattoli, ascensori e categorie analoghe.

Il secondo binario riguarda i sistemi di IA utilizzati in uno degli otto ambiti previsti dall’Allegato III: biometria, infrastrutture critiche, istruzione e formazione professionale, occupazione e gestione del personale, accesso a servizi essenziali, applicazione della legge, gestione della migrazione e delle frontiere, amministrazione della giustizia.

In entrambi i casi, la classificazione si compie prima dell’immissione sul mercato, sulla base dello scopo previsto dal provider. Non rileva l’uso effettivo che il deployer farà del sistema: conta la destinazione d’uso dichiarata nella documentazione tecnica, nelle istruzioni per l’uso e nei materiali promozionali.

Il nodo della componente di sicurezza

Nel primo binario, il concetto di componente di sicurezza è quello che genera più incertezza classificatoria e le linee guida vi dedicano un’elaborazione autonoma rispetto alle singole normative settoriali. 

Non occorre che la legislazione di prodotto qualifichi esplicitamente il sistema di IA come componente di sicurezza: l’AI Act usa una propria definizione, articolata in due scenari alternativi.

Il primo scenario è basato sull’intenzione del provider: il sistema ha lo scopo dichiarato di prevenire o mitigare rischi per la salute, la sicurezza o la proprietà. Un sistema di visione artificiale che arresta un macchinario quando rileva la presenza di una persona rientra qui.

Il secondo scenario è più delicato e nelle linee guida viene definito “consequence-based“: un sistema non nasce con funzioni di sicurezza, ma un suo guasto o malfunzionamento metterebbe attivamente in pericolo persone o beni. L’esempio proposto dalle linee guida è un sistema che ottimizza il funzionamento di un elettrodomestico a gas: progettato per l’efficienza, ma capace di produrre esiti gravi se genera output errati. In questo caso il sistema è componente di sicurezza indipendentemente dall’intenzione originaria del provider.

Questa distinzione ha implicazioni concrete per chi sviluppa software embedded in prodotti regolamentati: l’analisi classificatoria non può limitarsi a verificare se la funzione dichiarata è di sicurezza, ma deve includere uno scenario di problematicità o crisi e valutarne le conseguenze sulla salute e sulla sicurezza delle persone.

 

Il filtro del paragrafo 3

Per i sistemi che ricadono nell’Allegato III, l’articolo 6, paragrafo 3, introduce un meccanismo di esenzione: il sistema non è ad alto rischio se non influenza materialmente l’esito del processo decisionale. 

Le linee guida identificano quattro condizioni alternative che consentono di accedere a questa esenzione, da interpretare in modo restrittivo.

La prima è svolgere un compito procedurale ristretto: convertire dati non strutturati in strutturati, smistare documenti per categoria, rilevare duplicati. Nessun giudizio di valore sull’oggetto trattato.

La seconda è migliorare il risultato di un’attività umana già completata: verificare la coerenza formale di un documento già redatto, segnalare incongruenze interne. Il sistema interviene su qualcosa di concluso senza alterarne la sostanza.

La terza condizione riguarda il rilevamento di schemi decisionali passati: analisi ex-post comparative per supportare la revisione umana della qualità, senza che il sistema si sostituisca alla valutazione sul caso in esame.

La quarta è svolgere un compito puramente preparatorio rispetto alla valutazione vera e propria: ricercare informazioni, indicizzare documenti, fornire riferimenti generali di contesto.

Le linee guida precisano che chi tenta di costruire architetture modulari che parcellizzano funzioni ad alto rischio in sottosistemi teoricamente esenti si espone alla riqualificazione da parte delle autorità di vigilanza: il sistema viene valutato nel suo funzionamento complessivo, non componente per componente.

Dove il filtro non arriva

Tre limiti hanno carattere assoluto e non ammettono eccezioni.

Il primo: aggiungere supervisione umana non modifica la classificazione. Un sistema che produce un ranking di candidati rimane ad alto rischio anche se il responsabile HR lo revisiona prima di decidere. Il concetto di “human in the loop” non è una via di uscita dall’alto rischio quando la finalità del sistema ricade nell’Allegato III.

Il secondo limite è il più netto: se il sistema effettua profilazione di persone fisiche, il filtro non si applica. La profilazione è definita in coerenza con il GDPR (elaborazione automatizzata di dati personali per valutare, analizzare o prevedere aspetti come il comportamento, l’affidabilità, la salute, il rendimento lavorativo). Qualsiasi sistema che svolga questa funzione nell’ambito degli otto settori dell’Allegato III è ad alto rischio senza possibilità di esenzione.

Il terzo limite riguarda la responsabilità dell’autovalutazione: il provider che ritiene di beneficiare dell’esenzione ex art. 6(3) deve documentare e registrare questa valutazione nella banca dati UE. L’autorità di vigilanza può riqualificare il sistema in qualsiasi momento, e la sanzione per classificazione elusiva non è meno severa di quella per mancata conformità.

 

Il punto sul processo

Chi deve classificare un sistema nell’ambito dell’Allegato III si trova davanti a una sequenza logica:

•  verificare se il caso d’uso rientra in uno degli otto settori, 
• stabilire se il sistema influenza materialmente l’esito decisionale, 
• verificare se ricorre una delle quattro condizioni di esenzione, 
• controllare che nessuno dei tre limiti assoluti sia applicabile. 

Se il percorso conduce alla classificazione ad alto rischio, gli obblighi dell’AI Act si attivano in pieno: documentazione tecnica ex Allegato IV, registrazione, valutazione della conformità, trasparenza verso gli utilizzatori, monitoraggio post-mercato.

Le scadenze del 2027 e del 2028 lasciano margine. La progettazione dei sistemi, però, non altrettanto.

 

👾 👾 👾

Alla prossima!