Un sistema di IA è classificato ad alto rischio in base alla destinazione d’uso e alle condizioni dell’articolo 6 dell’AI Act, non semplicemente perché tratta molti dati o utilizza un modello potente. Occorre verificare due percorsi: il collegamento con determinati prodotti regolati e gli usi elencati nell’Allegato III. Prima ancora, bisogna escludere che l’impiego rientri fra le pratiche vietate: la conformità come sistema ad alto rischio non rende lecito un uso proibito.
Il calendario originario è cambiato. Al 29 settembre 2026 è già entrato in vigore il regolamento (UE) 2026/1744, detto AI Omnibus. Questa guida considera le modifiche effettivamente adottate, comprese quelle su alfabetizzazione, classificazione dei componenti di sicurezza e registrazione. Si concentra sulle decisioni necessarie per classificare e governare un sistema; il quadro generale resta nella guida all’AI Act in Italia.
Le nuove scadenze: che cosa è stato rinviato
Il regolamento modificativo pubblicato nella Gazzetta ufficiale dell’Unione è dell’8 luglio 2026, è stato pubblicato il 24 luglio ed è entrato in vigore il 27 luglio 2026. Non si tratta più della sola proposta di semplificazione. La Commissione conferma l’entrata in vigore dell’AI Omnibus, ma per definire l’ambito delle singole modifiche occorre leggere le disposizioni operative.
L’articolo 113 modificato stabilisce l’applicazione del capitolo III, sezioni 1, 2 e 3, con l’eccezione dell’articolo 6, paragrafo 5, dal 2 dicembre 2027 per i sistemi classificati secondo articolo 6, paragrafo 2, e Allegato III, e dal 2 agosto 2028 per quelli classificati secondo articolo 6, paragrafo 1, e Allegato I. Le precedenti indicazioni generali «agosto 2026» e «agosto 2027» non rappresentano più correttamente questo calendario.
Il rinvio non riguarda indistintamente ogni articolo dell’AI Act, né sospende il GDPR o le norme settoriali. La disciplina delle pratiche vietate, gli obblighi di trasparenza e le disposizioni sui modelli per finalità generali hanno ambiti e regole temporali propri. Anche le disposizioni transitorie dell’articolo 111 richiedono di verificare quando il sistema è stato immesso sul mercato o messo in servizio e se successivamente subisce modifiche significative. Acquistare un prodotto prima di una scadenza non dimostra da solo un’esenzione permanente.
Per organizzare un progetto conviene quindi registrare, per ciascun obbligo, soggetto destinatario, articolo, condizione di applicazione e data pertinente. Le attività descritte nelle sezioni successive spiegano il regime sostanziale da preparare e applicare secondo queste condizioni; non significano che tutti gli adempimenti siano già esigibili per qualsiasi sistema oggi utilizzato.
Primo percorso: prodotti e componenti di sicurezza
L’articolo 6, paragrafo 1, del testo di base dell’AI Act richiede due condizioni cumulative. Il sistema deve essere destinato a fungere da componente di sicurezza di un prodotto coperto dalla legislazione dell’Allegato I, oppure essere esso stesso tale prodotto. Inoltre, il prodotto o il sistema deve essere soggetto a valutazione di conformità da parte di terzi secondo quella legislazione, per l’immissione sul mercato o la messa in servizio.
Non basta quindi trovare il nome di un settore nell’Allegato I. Per un software medico, per esempio, bisogna identificare destinazione d’uso, qualificazione del prodotto e percorso di conformità concretamente applicabile. Un programma amministrativo usato all’interno di un ospedale non diventa automaticamente un componente di sicurezza di un dispositivo medico.
L’AI Omnibus ha aggiunto precisazioni all’articolo 6: gli usi esclusivamente estranei alla sicurezza, quali determinate funzioni di comodità o efficienza, non costituiscono componenti di sicurezza. Resta però la qualificazione quando un guasto o malfunzionamento può mettere in pericolo salute e sicurezza. La modifica chiarisce anche che una valutazione di terzi richiesta soltanto per rischi diversi da salute e sicurezza non soddisfa la relativa condizione dell’articolo 6.
Va distinta la sezione A dalla sezione B dell’Allegato I, perché l’articolo 2 prevede per la seconda un’applicazione particolare e limitata delle disposizioni dell’AI Act. La riforma ha inoltre spostato il regolamento macchine nella sezione B. Non è corretto applicare a tutti i prodotti dell’Allegato I un identico elenco di obblighi senza esaminare questo coordinamento settoriale.
Secondo percorso: leggere l’uso preciso dell’Allegato III
L’Allegato III individua otto aree, ma non comprende qualsiasi programma impiegato in ciascuna area. Per l’occupazione include, fra l’altro, strumenti destinati alla selezione dei candidati, al filtraggio delle domande e a determinate decisioni o valutazioni sul rapporto di lavoro. Un sistema che assegna punteggi ai CV richiede quindi una verifica diversa da un calendario che propone orari per i colloqui. Anche la gestione GDPR delle risorse umane deve riflettere questa differenza.
Nell’istruzione rilevano specifici usi riguardanti accesso, ammissione, valutazione dell’apprendimento, livello formativo e controllo di comportamenti vietati durante gli esami. Nelle infrastrutture critiche il testo riguarda componenti di sicurezza per le attività indicate, incluse infrastrutture digitali critiche e determinate reti o servizi. Non ogni strumento di previsione commerciale di un’utility rientra automaticamente in questa voce.
Per i servizi essenziali sono previsti, tra gli altri, la valutazione del merito creditizio delle persone fisiche, con l’eccezione relativa alla rilevazione delle frodi finanziarie, e la valutazione dei rischi e determinazione dei prezzi nelle assicurazioni vita e salute. Il contesto dei dati personali nelle banche e quello delle assicurazioni aiutano a descrivere gli interessati e le conseguenze dell’output. Non tutte le assicurazioni né ogni analisi finanziaria sono incluse indistintamente.
La biometria comprende usi specifici, nei limiti in cui sono consentiti dal diritto applicabile. L’identificazione biometrica remota è distinta dalla verifica destinata soltanto a confermare l’identità dichiarata da una persona, esclusa da quella specifica voce. L’Allegato include anche determinate categorizzazioni e il riconoscimento delle emozioni. La semplice presenza di una telecamera non risolve la classificazione: occorre analizzare le funzioni effettive e le regole italiane sulla videosorveglianza.
Le altre aree riguardano specifici impieghi nell’attività di contrasto, nella migrazione e nelle frontiere, nell’amministrazione della giustizia e nei processi democratici. Un assistente destinato ad aiutare un’autorità giudiziaria nell’applicazione del diritto ai fatti non equivale a ogni motore di ricerca giuridica. L’esame deve citare il punto e la lettera pertinenti, anziché limitarsi a una categoria commerciale generica.
Quando è possibile l’esclusione dell’articolo 6, paragrafo 3
Per alcuni sistemi dell’Allegato III è possibile concludere che non siano ad alto rischio quando non presentano un rischio significativo di danno alla salute, sicurezza o diritti fondamentali, anche perché non influenzano sostanzialmente l’esito delle decisioni. Il testo individua quattro condizioni alternative: un compito procedurale ristretto; il miglioramento di un’attività umana già completata; la rilevazione di schemi o deviazioni nelle decisioni senza sostituire o influenzare la valutazione umana precedente in assenza di un adeguato riesame; oppure un compito preparatorio per una valutazione pertinente.
Queste condizioni devono essere lette insieme alla soglia sostanziale di rischio. Definire un prodotto «assistente» non è sufficiente. Se una graduatoria viene sistematicamente seguita per escludere candidati, la descrizione come supporto preparatorio può essere incompatibile con il funzionamento reale. I sistemi dell’Allegato III che effettuano profilazione di persone fisiche sono comunque considerati ad alto rischio secondo la clausola finale del paragrafo 3.
Il fornitore che invoca l’esclusione documenta la valutazione prima dell’immissione sul mercato o messa in servizio e la rende disponibile alle autorità competenti su richiesta. La registrazione prevista dall’articolo 49, paragrafo 2, rimane nel testo. L’AI Omnibus semplifica le informazioni dell’Allegato VIII, sezione B, eliminandone i punti 7 e 9; non cancella l’obbligo di registrazione né quello di motivare la classificazione. Una conclusione favorevole va riesaminata se cambia la destinazione d’uso.
Fornitore e deployer: il ruolo segue il sistema
Il fornitore sviluppa, o fa sviluppare, un sistema e lo immette sul mercato o mette in servizio con il proprio nome o marchio, alle condizioni della definizione normativa. Il deployer lo utilizza sotto la propria autorità nell’attività professionale. Il ruolo non coincide automaticamente con quello di titolare o responsabile del trattamento GDPR: le due classificazioni rispondono a domande diverse.
L’articolo 25 disciplina situazioni in cui un distributore, importatore, deployer o altro soggetto assume gli obblighi del fornitore. Rilevano, con le condizioni previste, il proprio marchio su un sistema ad alto rischio, una modifica sostanziale che ne conservi tale qualificazione e un cambiamento della destinazione d’uso che trasformi in alto rischio un sistema precedentemente diverso. Non ogni configurazione ordinaria è una modifica sostanziale, ma un nuovo uso decisionale può cambiare radicalmente il quadro.
Un esempio ipotetico è l’impiego di un modello generale per costruire un servizio che seleziona automaticamente i candidati. Il fatto che il modello originario non fosse commercializzato come strumento HR non determina da solo la classificazione del nuovo sistema. Occorre definire chi lo progetta, chi lo offre e chi decide la nuova finalità. I contratti devono permettere di ottenere documentazione e assistenza necessarie; l’articolo 25 modificato precisa anche gli obblighi di cooperazione del fornitore iniziale e le relative eccezioni.
Che cosa deve dimostrare il fornitore
Per il regime applicabile ai sistemi ad alto rischio, la gestione del rischio è un processo continuo lungo il ciclo di vita, con verifiche e aggiornamenti. Deve considerare uso previsto, uso improprio ragionevolmente prevedibile, rischi conosciuti e risultati del monitoraggio. Una matrice compilata soltanto prima del lancio non basta se l’esperienza successiva mostra nuove conseguenze per le persone.
I dati di addestramento, validazione e prova devono rispettare i criteri pertinenti di qualità, rappresentatività e adeguatezza alla finalità. Un risultato medio elevato può nascondere errori molto diversi per gruppi di utenti. Le prove devono quindi riflettere il contesto previsto, non soltanto un insieme di dati comodo da reperire. La documentazione tecnica collega versione, progetto, limiti, dati, verifiche e misure; le istruzioni devono consentire al deployer di comprendere e utilizzare correttamente gli output.
Registrazione automatica degli eventi, sorveglianza umana, accuratezza, robustezza e cibersicurezza rispondono a rischi differenti. La persona incaricata della supervisione deve poter comprendere limiti e anomalie e intervenire effettivamente, anche ignorando o interrompendo il sistema secondo il contesto. Un pulsante di approvazione premuto senza informazioni o tempo non dimostra un controllo adeguato.
La governance dei dati non attribuisce un permesso generale di raccogliere categorie particolari. Il nuovo articolo 4-bis disciplina eccezioni per rilevare e correggere distorsioni, con stretta necessità e garanzie cumulative. Fra queste figurano l’insufficienza di dati alternativi, limiti al riutilizzo, sicurezza e accessi controllati, divieto di accesso a terzi, cancellazione e documentazione delle ragioni. Va applicato al caso preciso; non è una base indifferenziata per addestrare qualsiasi sistema.
Conformità e registrazione non sono una certificazione universale
La valutazione di conformità segue il percorso previsto per la categoria pertinente. Per i sistemi dell’Allegato III, punti da 2 a 8, l’articolo 43 prevede il controllo interno dell’Allegato VI, senza partecipazione di un organismo notificato. La biometria del punto 1 ha regole specifiche, mentre i prodotti della sezione A dell’Allegato I richiedono il coordinamento con la legislazione settoriale, aggiornato dall’AI Omnibus. Non è corretto promettere che un unico certificato privato risolva ogni obbligo.
Quando richieste, dichiarazione UE, marcatura e registrazione devono corrispondere al sistema e alla versione effettivamente commercializzati. L’articolo 49 distingue inoltre registrazione del fornitore, registrazione di determinati deployer pubblici e regimi particolari: per le infrastrutture critiche del punto 2 è prevista registrazione nazionale; alcuni impieghi sensibili hanno sezioni non pubbliche. La descrizione generica «tutti i sistemi finiscono in un registro pubblico europeo» perde queste differenze.
Obblighi pratici del deployer
Il deployer deve organizzare l’uso conforme alle istruzioni, assegnare la sorveglianza a persone con competenza, formazione e autorità adeguate e controllare i dati di input nella misura in cui ne ha il controllo. Deve anche monitorare il funzionamento e gestire rischi e incidenti secondo le disposizioni pertinenti. Un contratto che attribuisce tutte le responsabilità al venditore non elimina questi compiti.
I log generati automaticamente, quando sono sotto il suo controllo, vanno conservati per un periodo appropriato alla finalità, di almeno sei mesi, salvo diversa previsione del diritto applicabile, in particolare quello sulla protezione dei dati. Non si tratta di un obbligo di conservare qualsiasi dato personale per sempre. Nell’impiego lavorativo l’articolo 26 prevede l’informazione dei rappresentanti dei lavoratori e dei lavoratori interessati prima della messa in servizio o dell’uso, secondo le condizioni previste.
L’articolo 4 modificato richiede misure a sostegno della promozione dell’alfabetizzazione in materia di IA, tenendo conto di conoscenze, esperienza, formazione e contesto. Specifica che non occorre garantire a ogni persona un determinato livello individuale. Ciò non cancella i requisiti specifici di competenza e autorità per la sorveglianza dei sistemi ad alto rischio. Una formazione pertinente deve aiutare a riconoscere errori concreti del sistema utilizzato.
FRIA e DPIA: individuare gli obblighi separatamente
La valutazione d’impatto sui diritti fondamentali dell’articolo 27 non riguarda automaticamente tutti i deployer. Per i sistemi dell’articolo 6, paragrafo 2, esclusa l’area delle infrastrutture critiche del punto 2, riguarda gli organismi di diritto pubblico, le entità private che forniscono servizi pubblici e i deployer degli usi dell’Allegato III, punto 5, lettere b) e c), relativi a credito e assicurazioni vita e salute.
La valutazione descrive processi, durata e frequenza, persone e gruppi coinvolti, rischi specifici, sorveglianza e misure di risposta, compresi i meccanismi di reclamo. Si riferisce al primo impiego, con aggiornamenti quando gli elementi cambiano, e prevede la notifica dei risultati all’autorità secondo il testo applicabile. Un documento del fornitore può contribuire all’analisi, ma deve corrispondere all’uso del deployer.
La DPIA ai sensi dell’articolo 35 GDPR dipende invece dal rischio elevato del trattamento di dati personali e dalle condizioni del GDPR. La classificazione AI Act non rende automaticamente obbligatorie entrambe le valutazioni per ogni impresa. L’articolo 27 modificato permette riferimenti incrociati o l’inclusione delle parti pertinenti della DPIA nella FRIA: gli obblighi restano distinti, senza imporre di duplicare materialmente tutta l’analisi.
Un modello di DPIA deve quindi essere adattato al flusso concreto dei dati. La privacy fin dalla progettazione aiuta a ridurre raccolta e accessi; la verifica delle decisioni unicamente automatizzate dell’articolo 22 GDPR resta autonoma. Una supervisione solo nominale non elimina il problema delle decisioni con effetti giuridici o analogamente significativi.
Autorità italiane e dossier della decisione
L’articolo 20 della legge italiana 132/2025 designa AgID e ACN, distinguendo funzioni di notifica e vigilanza del mercato e salvaguardando le competenze finanziarie indicate dalla norma. Restano le competenze del Garante sui dati personali e il coordinamento con le altre autorità. Una sanzione GDPR relativa a un chatbot non prova, da sola, che quel chatbot sia classificato ad alto rischio nell’AI Act.
Per una decisione rivedibile è utile raccogliere destinazione d’uso, versione, ruolo, punto normativo applicato, motivazione della classificazione, valutazioni necessarie, limiti operativi e responsabile dell’aggiornamento. Un software per la conformità all’AI Act può essere valutato in funzione della capacità di mantenere questi collegamenti e la cronologia delle decisioni. La classificazione deve comunque essere sostenuta da fatti verificabili e dal testo vigente, soprattutto quando un aggiornamento modifica il modo in cui il sistema incide sulle persone.