Lo stesso motore, due destini
Prendiamo un modello linguistico e mettiamolo dentro due prodotti diversi.
Nel primo, il sistema suggerisce correzioni grammaticali e stilistiche mentre una persona scrive.
Nel secondo, legge curriculum e lettere di presentazione, assegna a ogni candidato un indicatore di compatibilità con la posizione e propone al selezionatore un ordine di priorità.
Il motore è lo stesso ma il destino giuridico no.
Il correttore non rientra in alcuna area dell’Allegato III, perché la sua finalità prevista non corrisponde a nessuno dei casi d’uso elencati.
E pur generando testo, svolge una funzione di assistenza per l’editing standard, che l’articolo 50, paragrafo 2, dell’AI Act esclude dall’obbligo di marcatura, come confermano le linee guida definitive sulla trasparenza del 20 luglio 2026.
Il sistema per la selezione, invece, ricade nell’Allegato III, punto 4, lettera a): sistemi destinati all’assunzione o alla selezione di persone fisiche, in particolare per analizzare e filtrare le candidature e valutare i candidati; e poiché, nella configurazione descritta, valuta aspetti personali dei candidati per prevederne l’idoneità, effettua profilazione ai sensi dell’articolo 4, punto 4, GDPR: nemmeno la deroga dell’articolo 6, paragrafo 3 dell’AI Act è disponibile in questo caso.
Questo esempio spiega perché parlare di “rischio dell’algoritmo” serve a poco.
Il Regolamento disciplina sistemi immessi sul mercato o messi in servizio per svolgere determinate funzioni; non disciplina l’algoritmo in isolamento.
Perché la tecnologia non basta
Quando si parla di intelligenza artificiale l’istinto è guardare alla tecnologia: il modello, le capacità, l’accuratezza, il grado di autonomia, il volume di dati, la capacità generativa.
Sono certamente elementi importanti che, però, non bastano a classificare un sistema ai sensi dell’AI Act.
Il Regolamento guarda continuamente a ciò per cui il sistema è destinato a essere usato; è la “finalità prevista”, definita dall’articolo 3, punto 12.
Questo concetto evita un errore frequente che consiste nel classificare un sistema in base alla sua sofisticazione tecnica.
In verità, un sistema molto potente può non essere ad alto rischio mentre un sistema tecnologicamente modesto può esserlo, se è destinato a una funzione compresa nell’Allegato III.
Che cosa deve dire una finalità prevista seria
La finalità prevista non è uno slogan commerciale.
Deve consentire a un terzo di capire quale funzione il sistema svolge e, secondo la definizione, emerge da quattro luoghi che il Regolamento mette sullo stesso piano:
- le istruzioni per l’uso;
- il materiale promozionale o di vendita;
- le dichiarazioni del fornitore;
- la documentazione tecnica.
Una descrizione efficace chiarisce almeno:
- quale attività svolge il sistema e quale output produce;
- in quale processo viene utilizzato e da chi;
- quali persone possono essere interessate dagli output;
- quali decisioni il sistema supporta o influenza;
- quali sono le condizioni essenziali di utilizzo.
“Assistente intelligente per le risorse umane” non dice quasi nulla mentre “Sistema destinato a classificare le candidature ricevute per una posizione lavorativa e a proporre al recruiter un ordinamento dei candidati sulla base dei requisiti professionali indicati” dice l’essenziale: chi legge capisce subito di trovarsi nell’Allegato III.
La qualità della finalità prevista è la qualità della classificazione.
Le capacità rientrano dalla finestra
Sarebbe però un errore concludere che la tecnologia non conti.
In almeno quattro punti il Regolamento guarda a ciò che il sistema è capace di fare, non solo a ciò per cui è destinato.
I due nuovi divieti dell’articolo 5 introdotti dal Regolamento (UE) 2026/1744 colpiscono l’immissione sul mercato di sistemi che generano immagini intime non consensuali o materiale pedopornografico non solo quando questa è la loro finalità prevista, ma anche quando la generazione è ragionevolmente prevedibile senza modifiche tecniche significative e mancano garanzie adeguate: è la capacità del sistema, non la destinazione dichiarata, a far scattare il divieto.
L’articolo 50 si applica a chi genera contenuti sintetici o interagisce con le persone, qualunque sia lo scopo commerciale del prodotto.
Il Capo V classifica i modelli per finalità generali anche in base alla potenza di calcolo usata per addestrarli.
Il quarto punto è il più insidioso.
La bozza delle linee guida della Commissione europea sulla classificazione dei sistemi ad alto rischio, pubblicata il 19 maggio 2026 per la consultazione degli stakeholder, propone infatti un criterio che riconduce le capacità del sistema alla sua finalità prevista.
In pratica, quando un sistema per finalità generali viene presentato come ampiamente applicabile, occorre prestare particolare attenzione a come il fornitore descrive i possibili impieghi.
Se gli usi ad alto rischio non vengono esclusi in modo chiaro, concreto e coerente in tutti i materiali informativi e contrattuali, tali usi possono essere considerati ricompresi nella finalità prevista del sistema.
Ciò vale quando tali impieghi risultano tecnicamente fattibili e ragionevolmente prevedibili alla luce delle funzionalità offerte dal sistema.
Pertanto, una clausola nei termini di servizio che “esclude gli usi ad alto rischio” non basta, se il posizionamento complessivo del prodotto dice il contrario.
In altre parole: la finalità prevista decide, ma il fornitore non può usarla per nascondere ciò che il sistema sa fare e che il mercato si aspetta che faccia.
Non si può spezzare il sistema per farlo sembrare innocuo
La stessa bozza di linee guida della Commissione europea del 19 maggio 2026 (documento n.3, paragrafo 75) chiude un’altra scappatoia.
Quando più sistemi di AI fanno parte di un sistema di AI più complesso e la loro finalità combinata o i loro risultati congiunti influenzano in modo significativo una decisione relativa a una persona, la configurazione complessiva viene considerata come un unico sistema di AI ai fini della classificazione ad alto rischio.
Per evitare che le regole sulla classificazione dei sistemi ad alto rischio vengano aggirate attraverso particolari scelte progettuali, le architetture suddivise in più componenti vengono valutate nel loro insieme.
L’esempio del modello incorporato in due prodotti va letto anche così: ciò che conta è la funzione del sistema finale, non la neutralità del modulo.
Sei uffici, una sola descrizione
La finalità prevista deve emergere in modo coerente dall’intero ecosistema documentale e commerciale del sistema.
Non ha senso scrivere nella documentazione tecnica che il sistema “organizza documenti” e poi promuoverlo sul sito come strumento capace di valutare l’affidabilità dei candidati.
Le dichiarazioni del fornitore contribuiscono, per espressa previsione dell’articolo 3, punto 12, a definire il perimetro reale del sistema.
Per questo motivo, classificazione e governance di prodotto devono parlarsi.
Legale, sviluppo, prodotto, marketing, vendite e compliance non possono descrivere lo stesso sistema in sei modi incompatibili e la classificazione non dovrebbe arrivare a valle, a prodotto finito.
Dovrebbe, invece, accompagnare la progettazione e consolidarsi mano a mano che finalità e funzionalità prendono forma.
Quando il deployer cambia il gioco
La finalità prevista resta centrale anche dopo, quando il sistema passa dal fornitore al deployer.
Per i sistemi ad alto rischio, l’articolo 26, paragrafo 1, impone ai deployer di adottare misure tecniche e organizzative idonee a utilizzarli conformemente alle istruzioni per l’uso.
Per gli altri sistemi un obbligo analogo non esiste nell’AI Act, ma la questione si ripresenta da un’altra porta: se il deployer impiega il sistema per una funzione diversa, non cambia soltanto il proprio profilo di rischio.
Può cambiare ruolo.
L’articolo 25, paragrafo 1, prevede tre casi in cui un distributore, un importatore, un deployer o un altro terzo è considerato fornitore di un sistema ad alto rischio, con tutti gli obblighi dell’articolo 16:
- quando appone il proprio nome o marchio su un sistema ad alto rischio già immesso sul mercato o messo in servizio;
- quando apporta una modifica sostanziale a un sistema ad alto rischio, che resta tale;
- quando modifica la finalità prevista di un sistema, compreso un sistema per finalità generali, non classificato come ad alto rischio, in modo tale che lo diventi.
In questi casi il fornitore iniziale cessa di essere considerato tale per quel sistema, ma deve cooperare strettamente con il nuovo fornitore.
Dopo il Regolamento (UE) 2026/1744 deve mettergli a disposizione la documentazione tecnica necessaria a valutare la conformità, informarlo dei limiti noti e delle modalità di guasto e consentirgli un accesso tecnico mirato, anche per prove e convalida (paragrafo 2); la violazione di questi obblighi è ora sanzionata dall’articolo 99.
L’obbligo non sussiste, però, se il fornitore iniziale ha chiaramente specificato che il suo sistema non deve essere trasformato in un sistema ad alto rischio (paragrafo 2, ultimo comma).
Per i sistemi multiuso la bozza delle linee guida della Commissione europea del 19 maggio 2026 (documento 1, paragrafo 21) distingue due situazioni.
Se il fornitore presenta il sistema come applicabile a tutto e non esclude in modo chiaro e coerente gli usi ad alto rischio, quegli usi si considerano compresi nella finalità prevista e gli obblighi restano suoi.
Se invece li ha esclusi, il deployer che sceglie comunque di impiegare il sistema per un uso dell’Allegato III ne modifica la finalità prevista e diventa fornitore ai sensi dell’articolo 25, paragrafo 1, lettera c), con gli obblighi dell’articolo 16.
In questo secondo caso il fornitore iniziale, avendo escluso espressamente la trasformazione, non è tenuto a cooperare né a consegnare la documentazione.
L’esclusione degli usi ad alto rischio, dunque, non è una clausola di stile: sposta la responsabilità.
Il rilievo operativo è evidente.
Un’organizzazione che acquista un sistema e lo riutilizza per uno scopo diverso non può presumere che la classificazione originaria continui a valere.
Deve riesaminare il quadro e capire se il nuovo uso cambi la qualificazione del sistema, o il proprio ruolo.
La finalità prevista come presidio di governance
La finalità prevista, quindi, non è la frase introduttiva della documentazione ma è un presidio di governance.
Consente al fornitore di delimitare il sistema e consente al deployer di capire entro quale perimetro può utilizzarlo.
Consente, inoltre, alle funzioni di compliance di verificare la classificazione e alle autorità di confrontare ciò che il fornitore dichiara con ciò che il prodotto fa effettivamente e con il modo in cui viene proposto sul mercato.
Da questa prospettiva, una finalità prevista troppo ampia è pericolosa quanto una artificiosamente stretta.
La prima rende impossibile classificare.
La seconda nasconde usi che il prodotto è chiaramente progettato e venduto per svolgere, e che la bozza delle linee guida della Commissione europea riporta dentro la finalità prevista.
La buona finalità prevista è precisa abbastanza da descrivere l’uso reale e stabile abbastanza da governare il ciclo di vita del sistema.
Conclusioni
La classificazione AI Act non deriva dal nome della tecnologia ma dall’incontro tra ciò che il sistema è, ciò che il fornitore dichiara che deve fare, ciò che il mercato è indotto ad aspettarsi e le fattispecie del Regolamento.
Per questo motivo, la finalità prevista è uno snodo decisivo.
Se è confusa, la classificazione diventa confusa.
Se è artificiosamente stretta, le capacità del sistema la riaprono.
Se cambia, può cambiare il regime giuridico e perfino il soggetto che ne risponde.
Nel prossimo articolo affronteremo l’equivoco successivo: un sistema ad alto rischio non è tale perché qualcuno ha calcolato un rischio alto.
Vedremo perché la classificazione dell’articolo 6 dell’AI Act e la gestione dei rischi dell’articolo 9 devono restare separate, e perché l’alto rischio è un regime intero, non un singolo articolo.
