Il 19 maggio 2026 la Commissione europea ha pubblicato le bozze di Linee guida sulla classificazione dei sistemi di IA ad alto rischio ai sensi dell’art. 6 del Regolamento (UE) 2024/1689 (AI Act), aprendole alla consultazione degli stakeholder fino al 23 giugno 2026.
Si tratta di circa 150 pagine articolate in tre documenti — principi generali, classificazione ex art. 6, par. 1, e Allegato I (sicurezza dei prodotti), classificazione ex art. 6, par. 2, e Allegato III (gli otto ambiti d’uso) — adottate ai sensi dell’art. 6, par. 5, AI Act.
Si tratta di una bozza, non ancora adottata in via definitiva: anche una volta finalizzate, le linee guida non saranno comunque vincolanti. Ciò non toglie che si tratti del primo documento in cui la Commissione prende posizione, con questo livello di dettaglio e con centinaia di esempi concreti, sulla domanda più pratica e più temuta dell’intero Regolamento: quando un sistema entra nel regime ad alto rischio e quando ne resta fuori.
La tempistica poi non è casuale.
Le date di applicazione dell’AI ACT per i sistemi ad Alto Rischio sono state infatti spostate in avanti dal pacchetto Digital Omnibus: come ricordano le stesse Linee guida (par. 448), gli obblighi per i sistemi dell’Allegato III ex art. 6, par. 2, si applicheranno dal 2 dicembre 2027 (in luogo del 2 agosto 2026) e quelli per i sistemi dell’Allegato I ex art. 6, par. 1, dal 2 agosto 2028 (in luogo del 2 agosto 2027).
È comunque una finestra di respiro, non un condono: la classificazione del sistema resta l’adempimento principale e, per chi opera nel settore, va impostata ora.
Vediamo allora i nodi che più interessano chi lavora su software medicali, digital health, gestione del personale e servizi pubblici essenziali.
Indice degli argomenti
I sistemi di AI in allegato I e la nozione autonoma di “componente di sicurezza”
La prima porta verso la qualificazione di IA ad alto rischio è quella dell’art. 6, par. 1, AI Act: vi rientrano i sistemi di IA che sono essi stessi un prodotto, oppure i componenti di sicurezza di un prodotto, a condizione che ricorrano due presupposti cumulativi: il prodotto deve essere disciplinato dalla normativa di armonizzazione dell’Unione elencata nell’Allegato I e deve essere altresì sottoposto, secondo tale disciplina, a valutazione di conformità da parte di terzi (par. 27).
L’Allegato I include, tra gli altri, il Regolamento (UE) 2017/745 (MDR) e il Regolamento (UE) 2017/746 (IVDR).
Definizione autonoma e i due scenari alternativi
Il cuore dell’analisi relativamente ai sistemi di IA ad alto rischio in Allegato I è la definizione di “componente di sicurezza” dell’art. 3, punto 14, AI Act.
La definizione stabilisce il componente è di sicurezza quando « svolge una funzione di sicurezza » per il prodotto o il sistema, « o il cui guasto o malfunzionamento mette in pericolo la salute e la sicurezza di persone o cose ».
Il primo punto su cui le Linee guida insistono è l’autonomia della nozione.
In altre parole le Linee guida affermano (par. 33) che si tratta appunto di una definizione autonoma dell’AI Act, che ha significato proprio e indipendente dalle definizioni di “componente di sicurezza” contenute nelle singole normative settoriali dell’Allegato I. In altri termini, nel valutare se un sistema di IA è componente di sicurezza ai fini dell’art. 6, par. 1, rileva solo l’art. 3, punto 14, AI Act, non la nozione di safety component eventualmente presente nell’MDR o altrove.
Da quella definizione la Commissione ricava (par. 34) due scenari alternativi.
Il primo è quello della funzione di sicurezza: la componente è di sicurezza quando, nelle intenzioni del fornitore, ha lo scopo di prevenire o mitigare rischi per la salute e la sicurezza di persone o cose (par. 35-37). È un criterio intent based, ancorato alla destinazione d’uso che il fornitore dichiara nelle istruzioni, nella documentazione tecnica e nei materiali promozionali (art. 3, punto 12, AI Act).
Il secondo scenario è quello del guasto o malfunzionamento: più esattamente anche se la componente non è destinata a svolgere una funzione di sicurezza, la stessa rientra in tale nozione quando il suo guasto o malfunzionamento metterebbe in pericolo la salute e la sicurezza (par. 38). Qui il criterio è consequence based: non conta cosa il sistema “dovrebbe fare”, ma cosa accade se sbaglia.
La distinzione non è teorica. Nel primo scenario il fornitore ha un controllo elevato — è lui a definire la destinazione d’uso — e la prova si trova nella documentazione (istruzioni, technical file, materiali di vendita). Nel secondo, il controllo è minore: la valutazione dipende dall’architettura del sistema, dai modi di guasto e dai loro effetti, a prescindere da come il prodotto sia stato “venduto” (la Commissione lo riassume nella Tabella 1, par. 44). A parere di chi scrive, è proprio il secondo scenario il più insidioso in sede di compliance: un fornitore può essere convinto di aver immesso sul mercato un sistema di mera ottimizzazione e ritrovarsi, in caso di malfunzionamento dagli effetti lesivi, dentro il perimetro dell’alto rischio.
Gli esempi aiutano.
Rientrano nello scenario “funzione di sicurezza” (par. 45) il sistema di computer vision che rileva la presenza umana in una cella robotizzata e attiva l’arresto di sicurezza, o il sistema che monitora la concentrazione di gas in atmosfera potenzialmente esplosiva e comanda lo spegnimento. Rientrano invece nello scenario “malfunzionamento” (par. 46) sistemi nati per altro: l’IA che gestisce tempi di chiusura e rilevamento ostacoli di un ascensore (destinazione: efficienza; ma un malfunzionamento può ferire), o l’assistenza al mantenimento di corsia di un veicolo (destinazione: comfort; ma uno sterzo errato può causare collisioni).
L’esempio dell’elettrodomestico a gas (par. 43) è il più didattico: un’IA che ottimizza la combustione ha destinazione “efficienza energetica” — che non è funzione di sicurezza — ma se un suo malfunzionamento può generare monossido di carbonio, esplosione o incendio, diventa componente di sicurezza per la via del guasto.
Il crinale per la digital health: software-dispositivo e valutazione di conformità
Per quanto riguarda i software medicali, un sistema di IA che sia esso stesso un dispositivo medico o un dispositivo IVD ai sensi di MDR/IVDR, e che richieda l’intervento di un Organismo Notificato per la valutazione di conformità, sarà ad alto rischio ex art. 6, par. 1. Le Linee guida ribadiscono (par. 57-58) che la classificazione non dipende dal modulo di conformità prescelto: la possibilità — ove esista — di ricorrere al controllo interno con applicazione di norme armonizzate non sottrae il sistema all’alto rischio, perché ciò che conta è che il prodotto sia comunque assoggettato a un controllo regolatorio rafforzato prima dell’immissione sul mercato. È una precisazione che chiude, correttamente, ogni tentazione di arbitraggio sul modulo per uscire dal regime.
Da segnalare anche la disciplina dei meccanismi di riduzione dell’onere di conformità (par. 60-62): per i sistemi ad alto rischio coperti dalla Sezione A dell’Allegato I si applicano i requisiti della Sezione 2 del Capo III AI Act, ma gli artt. 8, par. 2, 9, par. 10, e 17, par. 3, AI Act consentono di integrare la valutazione dei rischi specifici dell’IA nei sistemi di gestione del rischio e della qualità già esistenti — leggasi: nel sistema MDR/IVDR già in piedi — evitando duplicazioni.
Per le aziende medtech è l’indicazione operativa più utile dell’intero capitolo.
I sistemi IA ad alto rischio per finalità d’uso e le possibili deroghe dell’Allegato III
La seconda porta verso l’alto rischio è quella dell’art. 6, par. 2, AI Act: i sistemi AI che per finalità d’uso ricadono in uno degli otto ambiti dell’Allegato III — biometria, infrastrutture critiche, istruzione, lavoro, accesso a servizi essenziali, contrasto, migrazione e asilo, amministrazione della giustizia e processi democratici.
Qui infatti entra in gioco anche un possibile meccanismo di deroga che condiziona l’intera architettura: il par. 3 dell’art. 6 consente infatti di sottrarre alla qualificazione ad alto rischio quei sistemi che, pur ricadendo in un caso d’uso, non presentano rischi significativi perché non incidono materialmente sull’esito del processo decisionale.
Quattro condizioni alternative, da interpretare in modo restrittivo
Le condizioni della deroga (art. 6, par. 3, e par. 86 delle Linee guida) sono quattro, esaustive ma alternative (cioè ne basta una). Più esattamente il sistema non rientra nell’alto rischio quando:
(a) svolge un compito procedurale ristretto;
(b) è destinato a migliorare il risultato di un’attività umana già completata;
(c) è destinato a rilevare schemi decisionali o scostamenti da schemi pregressi, senza sostituire o influenzare la valutazione umana senza adeguato riesame;
(d) svolge un compito preparatorio rispetto a una valutazione rilevante per i casi d’uso dell’Allegato III.
Trattandosi poi di deroga a regole poste anche a tutela dei diritti fondamentali, le condizioni vanno interpretate restrittivamente (par. 88) e alla luce del principio che il sistema non deve incidere materialmente sull’esito della decisione. Conseguenza pratica chiarita ai par. 70-71: il solo inserimento di un controllo umano (“human in the loop”) non basta a far uscire il sistema dall’alto rischio. La sorveglianza umana è un requisito di conformità ex art. 14 AI Act, non una scorciatoia di classificazione. Il fornitore non può declassare un sistema a “basso rischio” semplicemente aggiungendovi un requisito di intervento umano.
Le quattro condizioni sono poi chiarite e dettagliate con cura.
- Il compito procedurale ristretto (par. 91-93) copre operazioni come trasformare dati non strutturati in strutturati, classificare documenti in categorie, rilevare duplicati; ma non i sistemi che esprimono un giudizio di valore sui dati — attribuire un punteggio, un ranking, etichettare un input come “più o meno utile” — perché ciò incide già sull’istruttoria.
- Il miglioramento di un’attività già completata (par. 94-96) richiede che l’attività umana sia conclusa e abbia prodotto un risultato, che l’IA si limita ad affinare: il legislatore ha scelto “migliorare” e non “rivedere”, sicché un sistema che fornisce una soluzione sostanzialmente diversa da quella umana non rientra nella deroga.
- La rilevazione di schemi (par. 97-102) ammette un ruolo più sostanziale, ma solo ex post e con riesame umano “adeguato”, ossia significativo e completo.
- Il compito preparatorio (par. 103-108) riguarda attività a monte della valutazione — indicizzare, cercare, processare, collegare — con impatto “molto basso” sull’esito.
Nessuna deroga se c’è profilazione e le clausole anti-elusione
Vi è poi un limite invalicabile: la deroga non opera mai se il sistema effettua profilazione di persone fisiche (art. 6, par. 3, ultimo comma, e par. 89, 109-112).
La nozione di profilazione è, in questo caso, quella dell’art. 4, punto 4, GDPR, richiamato dall’art. 3, punto 52, AI Act, e poggia su tre elementi cumulativi: trattamento automatizzato; su dati personali; con l’obiettivo di valutare aspetti personali di una persona fisica. Se c’è profilazione, il sistema resta ad alto rischio anche se, in astratto, ricadrebbe in una delle quattro condizioni di esclusione. È un crinale che, nel lavoro e nei servizi sanitari, sposta moltissimi sistemi dentro il regime (come si vedrà in seguito).
La Commissione blinda poi il filtro contro l’elusione per via di system design (par. 75, 90): quando più sistemi di IA compongono un sistema più complesso e i loro output congiunti incidono materialmente su una decisione individuale, l’insieme è valutato come un unico sistema; le architetture “spezzettate” e i sistemi agentici interconnessi si guardano nel loro funzionamento complessivo. Un modulo che, isolato, sarebbe esente non può beneficiare della deroga se, dentro la configurazione complessiva, contribuisce a un fine ad alto rischio. È — a parere di chi scrive — una delle scelte più lungimiranti dell’intero documento, perché anticipa la tentazione di frammentare i sistemi per farli scivolare sotto la soglia.
Sul piano operativo, l’applicazione della deroga è una autovalutazione del fornitore (par. 113-116): l’art. 6, par. 4, AI Act impone di documentare la valutazione prima dell’immissione sul mercato o messa in servizio e di registrare il sistema nella banca dati UE ex art. 71 AI Act.
La documentazione deve indicare destinazione d’uso, ragioni dell’astratta classificazione ad alto rischio, condizione di esenzione invocata e perché non vi è profilazione.
Ai sensi dell’art. 80 AI Act le autorità di vigilanza del mercato possono poi riqualificare il sistema e, se accertano un’elusione, irrogare sanzioni ex art. 99 AI Act (par. 117).
I sistemi ad alto rischio per finalità d’uso: casistica
Chiarite le regole generali analizziamo ora alcune casistiche di ampia applicazione e rilievo.
Lavoro e gestione dei lavoratori: il perimetro più ampio e i confini del filtro
Il punto 4 dell’Allegato III classifica ad alto rischio i sistemi di IA destinati al reclutamento e selezione (punto 4, lett. a) e quelli destinati alla gestione del rapporto di lavoro (punto 4, lett. b). La ratio è nel Considerando 57 AI Act: questi sistemi possono incidere in modo apprezzabile sulle prospettive di carriera, sui mezzi di sostentamento e sui diritti dei lavoratori, in un contesto di asimmetria di potere strutturale, e rischiano di perpetuare discriminazioni storiche — contro le donne, certe fasce d’età, le persone con disabilità, persone di determinata origine razziale o etnica o orientamento sessuale.
In relazione a tali attività vanno tenuti presenti in particolare i seguenti aspetti:
Ampiezza dell’ambito soggettivo
Un elemento che chi gestisce HR deve metabolizzare è l’ampiezza applicativa (par. 238-241). Non si parla solo di lavoratori subordinati: la Commissione, traendo ispirazione dalla nozione autonoma di “lavoratore” elaborata dalla CGUE (a partire da Lawrie-Blum, causa 66/85), ricomprende il lavoro autonomo, i prestatori di servizi tramite piattaforma e i lavoratori solo formalmente autonomi ma in posizione comparabile a quella dei subordinati. Freelance, professionisti, prestatori di servizi e platform worker rientrano nel perimetro ogni volta che un sistema di IA media o condiziona il loro accesso alle opportunità di lavoro. Si aggiunga l’intreccio con la pratica vietata dell’art. 5, par. 1, lett. f), AI Act sul riconoscimento delle emozioni sul luogo di lavoro: se un sistema vi ricade, la classificazione ad alto rischio non si pone neppure, perché la pratica è a monte vietata.
Reclutamento e selezione: cosa entra, cosa esce, cosa è esente
Rientrano nel punto 4, lett. a) gli annunci di lavoro mirati, l’analisi e il filtraggio delle candidature, la valutazione dei candidati. La Commissione adotta una lettura funzionale: l’“analisi” che incide sull’accesso alle fasi successive opera di fatto come “filtraggio” (par. 253). Tra gli esempi che ricadono nell’alto rischio (par. 254): il job matching che genera punteggi e ranking di candidati; il sourcing automatico di candidati su piattaforme e database; il sistema che ordina i prestatori di servizi autonomi presentati ai potenziali clienti; il sistema di vision che valuta le capacità visive dei candidati piloti determinandone l’idoneità; il background check che produce punteggi di rischio (e che, basandosi su profilazione, non può mai beneficiare del filtro).
Restano invece fuori i sistemi non destinati al reclutamento o selezione di persone (par. 254): il tool che individua linguaggio discriminatorio negli annunci, l’employer branding non legato a una posizione specifica, il monitoraggio reputazionale anonimizzato, e — dato di rilievo — il tool che il candidato usa di propria iniziativa per adattare il CV o trovare la posizione migliore, perché sfugge al controllo del datore. Beneficiano del filtro, infine, alcuni casi-limite (par. 254): la verifica di un’accreditazione professionale presso registri ufficiali (compito procedurale ristretto, art. 6, par. 3, lett. a); la mera organizzazione delle informazioni dei CV in un database interrogabile; la pianificazione dei colloqui; l’audit retrospettivo su dati anonimizzati per rilevare bias nelle decisioni passate (lett. c).
Gestione del rapporto: la soglia di significatività
Il punto 4, lett. b) copre poi le decisioni che incidono sui termini del rapporto, su promozione e cessazione, l’assegnazione di compiti basata su comportamento o tratti personali, il monitoraggio e la valutazione di prestazioni e comportamento. La nozione di “decisione” deve essere intesa come funzionale (par. 258): rileva anche quando l’output dell’IA influenza in modo significativo una decisione formalmente umana. Ma non ogni microdecisione organizzativa quotidiana entra nel perimetro: la Commissione fissa una soglia di significatività (par. 262), escludendo gli aggiustamenti operativi che non alterano in sostanza i diritti e gli obblighi nascenti dal rapporto.
Tra gli esempi ad alto rischio (par. 254, lett. b): lo scheduler che assegna turni e priorità in base a punteggi di performance, incidendo su retribuzione variabile e progressione; la piattaforma di tutoring che disattiva automaticamente l’account del docente autonomo al di sotto di una certa valutazione (disattivazione che equivale, funzionalmente, a una cessazione del rapporto); il sistema che alloca il carico di lavoro tra associate di uno studio legale; il sistema che fissa dinamicamente il compenso nel platform work.
Restano fuori (par. 254) il tracking delle spedizioni che si limita a segnalare errori all’addetto, il booking delle postazioni, la pianificazione delle trasferte, e i suggerimenti di zona ai rider quando sono facoltativi e privi di penalità o registrazione.
Biometria e AI Act: una definizione “larga” e i risvolti sanitari
Per quanto attiene alla biometria, il punto 1 dell’Allegato III contempla tre casi d’uso — identificazione biometrica remota (RBI, lett. a), categorizzazione biometrica secondo attributi sensibili o protetti (lett. b), riconoscimento delle emozioni (lett. c) — « nella misura in cui il loro uso sia consentito dal pertinente diritto dell’Unione o nazionale ».
Tale ultimo chiarimento merita attenzione: le linee guida precisano infatti (par. 82) che la classificazione ad alto rischio non significa che l’uso sia di per sé lecito, dovendo comunque rispettare la Carta dei diritti fondamentali, il GDPR e le altre norme applicabili.
Il punto più rilevante — e spesso frainteso — è che la definizione di “dato biometrico” dell’art. 3, punto 34, AI Act è più ampia di quella del GDPR (par. 125).
La Commissione chiarisce infatti che la definizione di dato biometrico del GDPR contiene l’inciso « che ne consentono o confermano l’identificazione univoca »; tale inciso al contrario non si ritrova nella definizione di dato biometrico dell’AI ACT: ciò comporta che l’AI copre i sistemi che usano dati biometrici anche al di fuori dell’identificazione. Conseguenza: dati come l’andatura (gait), la voce, la dinamica di battitura (keystroke), perfino EEG ed ECG, rientrano nel perimetro biometrico dell’AI Act anche quando non servono a identificare nessuno. È un disallineamento concettuale che chi opera in queste materie deve conoscere, per non sovrapporre meccanicamente le due nozioni.
Sul caso RBI (art. 3, punto 41), la Commissione richiede tre condizioni (par. 129): finalità di identificazione biometrica; assenza di coinvolgimento attivo dell’interessato (la “remotezza”); confronto con un database di riferimento. Sono esclusi i sistemi di mera verifica/autenticazione “uno a uno” (par. 136) — sbloccare uno smartphone, confrontare il volto del viaggiatore con la foto del passaporto — perché confermano soltanto che la persona è chi dichiara di essere.
Dove la biometria incrocia la salute
Per il settore life science il punto più interessante è la categorizzazione biometrica (lett. b).
È infatti un sistema AI ad alto rischio solo quando inferisce e classifica le persone secondo attributi sensibili o protetti ai sensi dell’art. 9, par. 1, GDPR (par. 169-170): tra questi, i dati relativi alla salute.
L’esempio della Commissione è calzante (par. 170): un sistema che cattura l’andatura del paziente, ne inferisce dati sulla salute e lo assegna a categorie predefinite (stadio precoce o avanzato di una malattia che si manifesta con problemi di mobilità) è ad alto rischio, perché categorizza secondo un attributo sanitario. Per converso, un sistema che inferisce età o genere — attributi non protetti ex art. 9, par. 1, GDPR — non vi rientra (par. 170), salvo che l’età/genere siano usati per valutare il rischio di un soggetto in ingresso (punto 7, lett. b, dell’Allegato III).
Quanto al riconoscimento delle emozioni (lett. c), la Commissione perimetra con precisione utile alla sanità digitale: gli stati fisici come dolore e fatica non sono “emozioni o intenzioni” ex Considerando 18 (par. 177), sicché il sistema che rileva la sonnolenza del conducente per prevenire incidenti non è emotion recognition; lo è invece lo smartwatch che inferisce stati emotivi (tristezza, noia, felicità) dalla voce o dalla frequenza cardiaca per suggerire “miglioramenti emotivi” (par. 176). Si tenga presente l’intreccio con i divieti dell’art. 5 (par. 126): il riconoscimento delle emozioni fuori da lavoro e istruzione, o al loro interno ma per ragioni mediche o di sicurezza, non è vietato ma resta ad alto rischio.
Accesso in sicurezza alle prestazioni sanitarie: eligibilità, triage e MDR
Il punto 5 dell’Allegato III tocca da vicino il settore sanitario, perché vi rientrano espressamente i servizi sanitari.
Conviene distinguere due profili:
• l’accesso alle prestazioni assistenziali pubbliche (lett. a) e i sistemi di gestione delle emergenze e di triage (lett. d).
• la valutazione del rischio e tariffazione nelle assicurazioni sanitarie e sulla vita (lett. c).
Eligibilità alle prestazioni assistenziali, servizi sanitari inclusi
Il punto 5, lett. a) classifica ad alto rischio i sistemi destinati ad essere usati da o per conto di autorità pubbliche per valutare l’ammissibilità delle persone fisiche alle prestazioni e ai servizi essenziali di assistenza pubblica — servizi sanitari inclusi — nonché per concedere, ridurre, revocare o recuperare tali prestazioni.
Il Considerando 58 e le Linee guida (par. 288) ricomprendono tra i servizi essenziali alcuni servizi sanitari (ad esempio l’assistenza a lungo termine) e numerose prestazioni di sicurezza sociale. Bastano la sola valutazione di ammissibilità del paziente oppure la sola decisione di concessione/diniego di un servizio: non occorre che il sistema svolga entrambe (par. 292).
Gli esempi ad alto rischio (par. 293) sono molto concreti: il sistema che valuta l’ammissibilità a un sussidio o ne raccomanda concessione/diniego; quello che prioritizza l’allocazione di ore di assistenza domiciliare tra aventi diritto; il sistema che valuta le domande di prestazioni sanitarie per decidere se attivare un esame approfondito; e perfino l’invito personalizzato a uno screening preventivo (es. mammografia) quando incorpori una valutazione di ammissibilità.
Sono invece esenti, come compiti procedurali o preparatori (par. 293), il chatbot che risponde a domande fattuali del funzionario (es. l’età dell’interessato), il sistema che si limita a sintetizzare referti medici che il funzionario deve comunque rileggere, e la traduzione delle domande presentate in lingua straniera.
Emergenza e triage sanitario: il bivio con l’MDR
Il punto 5, lett. d) classifica poi ad alto rischio i sistemi destinati a valutare e classificare le chiamate di emergenza, a inviare o stabilire le priorità nell’invio dei servizi di primo soccorso (polizia, vigili del fuoco, soccorso medico) e i sistemi di triage sanitario d’emergenza dei pazienti. È qui che si colloca, in senso proprio, l’“accesso in sicurezza alle prestazioni sanitarie”: un errore di classificazione di una chiamata o di un triage incide su situazioni critiche per la vita e la salute.
Il passaggio decisivo per chi opera nel medtech è il rapporto con la disciplina dei dispositivi medici (par. 331, 334-335).
Se infatti il sistema di triage sanitario d’emergenza si qualifica come dispositivo medico ai sensi dell’art. 2, punto 1, del Regolamento (UE) 2017/745 (MDR) e soddisfa le condizioni dell’art. 6, par. 1, AI Act, allora sarà ad alto rischio per la via dell’art. 6, par. 1, e dell’Allegato I, con compliance settoriale coordinata. Se invece il sistema di triage non costituisce dispositivo medico, sarà ad alto rischio ex art. 6, par. 2, e punto 5, lett. d), dell’Allegato III. È il classico bivio tra le due porte dell’art. 6: la qualificazione MDR a monte determina il binario di conformità a valle. Una lettura, a parere di chi scrive, coerente e da accogliere con favore, perché evita duplicazioni e ancora la valutazione alla natura del prodotto.
Tra gli esempi ad alto rischio (par. 335): il sistema in pronto soccorso che prioritizza i pazienti senza compiere atti clinici o diagnostici; il chatbot di triage in crisi di salute mentale che valuta gravità e urgenza dei contatti.
Restano fuori (par. 335) i sistemi di mera previsione/disaster monitoring non collegati alla decisione su quando e dove inviare i soccorsi, la stima dei tempi di guarigione per la gestione dei posti letto, la mera schedulazione di appuntamenti medici.
Un cenno alle assicurazioni salute e vita
Per completezza, il punto 5, lett. c) classifica ad alto rischio i sistemi di valutazione del rischio e tariffazione per le persone fisiche nelle assicurazioni sulla vita e sulla salute (par. 310-320).
A differenza della lett. b) sul credit scoring, qui non opera l’eccezione per il rilevamento delle frodi (par. 321): un sistema usato per risk assessment o pricing in materia di assicurazione vita/salute resta ad alto rischio anche se incorpora una funzione antifrode, salvo che quest’ultima costituisca un sistema distinto a sé stante.
Le Linee guida vi ricomprendono anche l’assistenza a lungo termine privata e, a certe condizioni, i prodotti pensionistici individuali e le polizze vita a copertura di un finanziamento.
Conclusioni operative: perché il cantiere va aperto adesso
Il 2 dicembre 2027 è la data c per i sistemi dell’Allegato III; il 2 agosto 2028 per quelli dell’Allegato I.
Realizzare un sistema di IA ad alto rischio non è un’attività di qualche settimana: è un progetto strutturato, con requisiti di processo e di prodotto che devono essere progettati — non aggiunti a posteriori — e con una conformità che deve essere dimostrata.
Queste linee guida saranno un grande aiuto in consultazione, con tutti i loro limiti — non vincolanti, ancora parziali, soggette a revisione — sono il segnale più chiaro che quella disciplina sta diventando concreta. Chi ha deciso di entrare nel modo AI deve partire ora.
