Sistemi AI ad alto rischio: come si legge l'articolo 6 dell'AI Act

In sintesi. Un sistema AI diventa ad alto rischio per due strade: come componente di sicurezza di un prodotto regolato dall'Allegato I, oppure perché il suo scopo previsto rientra in uno degli otto ambiti dell'Allegato III. Il Digital Omnibus ha spostato gli obblighi al 2 dicembre 2027 e al 2 agosto 2028, ma la classificazione va fatta adesso, perché decide costi, contratti e architetture dei progetti già in corso.

Il 19 maggio 2026 la Commissione europea ha pubblicato la bozza delle linee guida sulla classificazione dei sistemi di intelligenza artificiale ad alto rischio, previste dall'articolo 6, paragrafo 5, del Regolamento (UE) 2024/1689. Dovevano arrivare entro il 2 febbraio, sono arrivate con più di tre mesi di ritardo, la consultazione con gli stakeholder si è chiusa in estate e la versione definitiva è attesa entro la fine del 2026. Nel frattempo il Digital Omnibus, pubblicato come Regolamento (UE) 2026/1744 il 24 luglio, ha spostato il calendario: gli obblighi per i sistemi elencati nell'Allegato III si applicano dal 2 dicembre 2027, quelli per l'AI integrata nei prodotti regolati dell'Allegato I dal 2 agosto 2028.

In queste settimane il tema è ovunque, tra webinar, post e checklist, e la reazione che osserviamo più spesso nelle aziende è una specie di sollievo, perché quattordici mesi sembrano tanti. Secondo me è una lettura pericolosa.

La classificazione di un sistema AI decide quanto costa svilupparlo, come va scritto il contratto con il fornitore, quale documentazione va prodotta mentre il progetto nasce, chi in azienda deve firmare. L'Osservatorio Artificial Intelligence del Politecnico di Milano, nella ricerca presentata a febbraio 2026, rileva che il 71% delle grandi imprese italiane ha progetti AI attivi e solo il 9% ha una governance strutturata: in quello scarto ci sono sistemi che nessuno ha ancora classificato, e che tra un anno qualcuno dovrà classificare in fretta.

Le due strade dell'articolo 6

L'articolo 6 apre due porte distinte verso l'alto rischio, e confonderle è l'errore più comune.

La prima, al paragrafo 1, riguarda i sistemi AI che sono essi stessi un prodotto, o un componente di sicurezza di un prodotto, coperto dalla normativa europea di armonizzazione elencata nell'Allegato I, a condizione che quel prodotto debba passare da una valutazione di conformità di terza parte. La seconda, al paragrafo 2, riguarda i sistemi il cui scopo previsto rientra in uno dei casi d'uso dell'Allegato III, indipendentemente dal prodotto in cui girano.

Sono due logiche diverse. La prima ragiona sul prodotto e sulla sicurezza fisica, eredita il linguaggio del New Legislative Framework e si innesta su processi di certificazione che i produttori di macchinari o dispositivi medici conoscono da anni. La seconda ragiona sull'uso e sui diritti fondamentali, e colpisce aziende che non si sono mai considerate "regolate", come chi seleziona personale o valuta il merito creditizio.

In entrambi i casi la variabile decisiva è lo scopo previsto, cioè l'uso che il fornitore dichiara nella documentazione, nelle istruzioni, nel materiale commerciale. La bozza di linee guida insiste molto su questo punto: lo scopo va descritto in modo coerente in tutti i documenti, e un sistema presentato come generico nella scheda tecnica ma venduto per lo screening dei candidati sul sito verrà letto per quello che fa.

I prodotti regolati dell'Allegato I

Per l'AI integrata nei prodotti, la domanda da farsi è tecnica prima che giuridica. L'Allegato I elenca la normativa di prodotto rilevante: macchine, giocattoli, apparecchiature radio, dispositivi medici e diagnostici in vitro, ascensori, attrezzature a pressione, veicoli, aviazione civile e altro ancora. Se il prodotto rientra in una di queste discipline e richiede l'intervento di un organismo notificato, bisogna capire se il sistema AI svolge una funzione di sicurezza o se un suo malfunzionamento può mettere a rischio la salute o la sicurezza delle persone, secondo la definizione di componente di sicurezza dell'articolo 3, punto 14.

Le linee guida chiariscono che conta la funzione, non il modo in cui l'AI viene distribuita: un modulo di visione che ferma una pressa quando rileva una mano nella zona di lavoro è un componente di sicurezza sia che giri a bordo macchina sia che arrivi come servizio cloud. Per chi produce in Italia, e il nostro manifatturiero è pieno di macchine sempre più intelligenti, significa che la classificazione va fatta dentro il fascicolo tecnico del prodotto, con le stesse persone che oggi gestiscono la marcatura CE.

Gli otto ambiti dell'Allegato III

L'Allegato III è l'elenco che interessa la maggior parte delle aziende di servizi. Gli ambiti sono otto:

• biometria, inclusa l'identificazione a distanza e il riconoscimento delle emozioni dove consentito;
• infrastrutture critiche, come la gestione di reti idriche, gas, elettricità e traffico;
• istruzione e formazione professionale, dall'ammissione alla valutazione degli apprendimenti;
• occupazione e gestione dei lavoratori, dalla selezione alle decisioni su promozioni, cessazioni e assegnazione dei compiti;
• accesso a servizi essenziali pubblici e privati, tra cui il merito creditizio e la determinazione del premio nelle assicurazioni vita e salute;
• attività di contrasto;
• migrazione, asilo e controllo delle frontiere;
• amministrazione della giustizia e processi democratici.

Chi lavora in banca, in assicurazione o in una direzione HR si trova dentro questo elenco anche senza sviluppare nulla in casa, perché gli obblighi seguono il sistema lungo la catena e ricadono in parte su chi lo usa. La bozza della Commissione aggiunge un chiarimento che molte aziende non avevano messo in conto: un sistema che orienta in modo rilevante una decisione sul lavoro resta ad alto rischio anche se l'ultima parola spetta a una persona, perché la supervisione umana è un obbligo dell'articolo 14 e non una via d'uscita dalla classificazione.

Le eccezioni dell'articolo 6, paragrafo 3

In questo spazio si concentreranno le discussioni più accese con le autorità di vigilanza. Un sistema che rientra nell'Allegato III può non essere considerato ad alto rischio se non influenza in modo sostanziale l'esito delle decisioni, e l'articolo 6, paragrafo 3, individua quattro condizioni alternative, per cui ne basta una:

• il sistema esegue un compito procedurale limitato, come classificare documenti in entrata;
• migliora il risultato di un'attività umana già completata, ad esempio rivedendo la forma di un testo scritto da una persona;
• rileva schemi decisionali o scostamenti rispetto a decisioni precedenti, senza sostituire la valutazione umana;
• svolge un compito preparatorio rispetto a una valutazione che resta umana.

Con un limite che non ammette interpretazioni: se il sistema effettua profilazione di persone fisiche, nessuna delle quattro condizioni lo salva.

Chi si avvale dell'eccezione deve documentare la propria valutazione prima dell'immissione sul mercato e metterla a disposizione delle autorità che la chiedono, per cui la deroga è una scelta attiva, firmata, che qualcuno deve poter difendere. Le linee guida chiudono anche la scorciatoia architetturale: se più componenti, magari agenti distinti, concorrono insieme a una decisione che rientra nell'Allegato III, la configurazione complessiva viene trattata come un unico sistema, e spezzare il flusso in pezzi che singolarmente sembrano innocui non cambia l'esito.

Gli obblighi per fornitori e deployer

Una volta classificato il sistema come ad alto rischio, il fornitore si fa carico del grosso. Deve istituire un sistema di gestione dei rischi lungo tutto il ciclo di vita, governare la qualità dei dati di addestramento, validazione e test, produrre la documentazione tecnica, garantire la registrazione automatica degli eventi, fornire istruzioni d'uso comprensibili, progettare la supervisione umana, assicurare livelli adeguati di accuratezza, robustezza e cybersicurezza. A questo si aggiungono un sistema di gestione della qualità, la valutazione della conformità con marcatura CE, la registrazione nella banca dati europea, il monitoraggio successivo all'immissione sul mercato e la segnalazione degli incidenti gravi.

Il deployer, cioè l'azienda che usa il sistema nella propria attività, ha obblighi più leggeri ma tutt'altro che formali. L'articolo 26 gli chiede di usare il sistema secondo le istruzioni, di affidare la supervisione a persone con competenza e autorità adeguate, di verificare la pertinenza dei dati di input che controlla, di monitorare il funzionamento, di conservare i log generati automaticamente per almeno sei mesi e di informare i lavoratori quando il sistema viene impiegato sul luogo di lavoro. Per gli enti pubblici, per i privati che erogano servizi pubblici e per chi usa sistemi di valutazione del merito creditizio o di pricing nelle assicurazioni vita e salute, l'articolo 27 aggiunge la valutazione d'impatto sui diritti fondamentali.

L'articolo 25 prevede che un deployer diventi fornitore, con tutti i relativi obblighi, se modifica in modo sostanziale un sistema ad alto rischio, se ne cambia lo scopo previsto facendolo diventare ad alto rischio, o se lo mette in commercio con il proprio nome. Chi prende un modello generico e lo configura per lo screening dei curriculum dei propri clienti sta attraversando questa linea, spesso senza accorgersene.

La classificazione come decisione di governance

Davanti a questo elenco molte aziende sono tentate di trattare tutto come un problema legale da delegare. È comprensibile, e un parere legale su un caso limite serve davvero, ma la classificazione nasce prima, nel momento in cui qualcuno in azienda decide lo scopo di un sistema, sceglie un fornitore, disegna un flusso di lavoro. Chi arriva dal legale con un inventario vuoto riceverà un parere su un'ipotesi.

Il lavoro che vediamo mancare quasi ovunque è a monte: un registro dei sistemi AI in uso e in sviluppo, con per ciascuno lo scopo previsto dichiarato, il ruolo dell'azienda (fornitore, deployer, o entrambi), la strada dell'articolo 6 che potrebbe applicarsi e, se si invoca un'eccezione, la motivazione scritta e il nome di chi l'ha approvata. È lo stesso tipo di disciplina che chiede la ISO/IEC 42001 per un sistema di gestione dell'AI, ed è quello che nel nostro AI Rating misuriamo nella dimensione Risk, con un gate che non si compensa con punteggi alti altrove: un'azienda che non sa quali sistemi ha non può essere matura sull'AI, qualunque sia la qualità dei suoi modelli.

Il calendario del Digital Omnibus dà tempo per costruire documentazione, test, contratti e processi di supervisione, a condizione che la classificazione sia fatta adesso. Chi la rimanda al 2027 si troverà a classificare sistemi già in produzione, con contratti già firmati e architetture già decise, e a quel punto ogni risposta scomoda costa il doppio. La bozza della Commissione verrà rivista, gli esempi cambieranno, alcune interpretazioni si sposteranno. Un registro cominciato oggi sarà pronto ad accogliere la versione finale, e dirà all'azienda quanti dei suoi "strumenti di supporto" sono in realtà sistemi che orientano decisioni sulle persone.