AI Act dell’UE: classificare i casi d’uso e pianificare le evidenze

La governance dell’IA inizia dal sapere quali sistemi l’organizzazione fornisce, utilizza o rende comunque disponibili. Un elenco di nomi di modelli non basta: sono la finalità prevista, il contesto di utilizzo e il vostro ruolo a determinare gli obblighi da esaminare.

Per il vertice aziendale, la classificazione è una decisione di allocazione delle risorse oltre che una valutazione giuridica. Stabilisce quali progetti richiedono una revisione specialistica, che cosa devono dimostrare i fornitori e quali evidenze devono esistere prima del rilascio. Uno strumento di selezione del personale e un assistente di scrittura interno possono usare lo stesso modello e richiedere tuttavia valutazioni molto diverse.

Il risultato utile è un registro dei casi d’uso revisionato e collegato a responsabili, requisiti, evidenze e decisioni di modifica, non un’etichetta aziendale generica che dichiari «IA a basso rischio».

Definire ambito e responsabilità prima di attribuire il rischio

Il regolamento UE sull’intelligenza artificiale (AI Act) è un regolamento i cui obblighi dipendono dall’attività, dal sistema e dall’operatore. Il suo ambito territoriale comprende i fornitori che immettono sistemi sul mercato dell’UE o li mettono in servizio, i deployer stabiliti o situati nell’UE e alcuni fornitori e deployer extra UE quando gli output dei sistemi sono utilizzati nell’UE. La cittadinanza, da sola, non è il criterio.

Fate stabilire a revisori giuridici e tecnici se l’applicazione rientra nella definizione di sistema di IA del regolamento e se si applicano esclusioni dall’ambito pertinenti. Non date per scontato che ogni script di automazione sia IA, né che un servizio ospitato esternamente esuli dalle vostre responsabilità.

Registrate poi il vostro ruolo:

• Fornitore: sviluppa un sistema, o lo fa sviluppare, e lo immette sul mercato o lo mette in servizio con il proprio nome o marchio.
• Deployer: utilizza un sistema sotto la propria autorità in un contesto professionale.
• Importatore o distributore: immette sistemi pertinenti sul mercato dell’UE o li mette a disposizione lungo la catena di approvvigionamento, con i relativi obblighi di verifica.
• Fabbricante del prodotto o rappresentante autorizzato: ha responsabilità derivanti dallo specifico assetto del prodotto o da un mandato scritto.

Un’organizzazione può ricoprire ruoli diversi all’interno del proprio portafoglio. Acquistare un’API non stabilisce il ruolo relativo all’applicazione finita. Un cambio di marchio, una modifica sostanziale o la modifica della finalità prevista possono far scattare responsabilità da fornitore alle condizioni applicabili. Il fine-tuning è quindi un elemento che attiva una revisione, non una conclusione giuridica automatica.

Distinguete il modello di IA per finalità generali dal sistema costruito attorno a esso. Gli obblighi del fornitore del modello e quelli relativi al sistema a valle sono correlati ma non intercambiabili.

Costruire un inventario dei casi d’uso che supporti le decisioni

Inventariate le funzioni aziendali, non solo i fornitori. Intervistate acquisti, risorse umane, prodotto, operations e IT: l’IA può arrivare tramite una nuova funzionalità di un fornitore esistente anziché tramite un acquisto dedicato.

Per ogni caso d’uso, registrate:

Registrate i flussi di lavoro effettivi accanto alla finalità prevista. Uno strumento descritto come «supporto ai recruiter» può di fatto escludere candidati se il personale esamina solo la sua rosa ristretta. Una policy scritta che richiede la revisione umana non dimostra che la revisione avvenga.

Il risultato è un record versionato per ciascun caso d’uso. Le classificazioni non risolte devono restare visibilmente aperte, con un responsabile e una scadenza per la decisione, invece di ricadere per impostazione predefinita nella categoria meno impegnativa.

Valutare separatamente divieti, percorsi verso l’alto rischio e trasparenza

La nota descrizione a quattro livelli (vietato, alto rischio, obblighi di trasparenza e rischio minore) è un’introduzione utile. Non è un albero decisionale completo. Gli obblighi di trasparenza possono sovrapporsi a quelli per l’alto rischio, e gli obblighi di alfabetizzazione in materia di IA non riguardano solo i sistemi ad alto rischio.

Verificare per prime le pratiche vietate

L’articolo 5 vieta pratiche specifiche, fatte salve le condizioni e le eccezioni dettagliate della disposizione. Domande di screening pertinenti sono se un sistema utilizza tecniche manipolative dannose o sfrutta vulnerabilità, effettua un punteggio sociale vietato, crea banche dati di riconoscimento facciale mediante scraping non mirato o esegue una categorizzazione biometrica vietata.

È inoltre vietato inferire le emozioni tramite IA sulla base di dati biometrici nei luoghi di lavoro e negli istituti di istruzione, salvo per specifici motivi medici o di sicurezza. L’analisi del sentiment basata solo su testo non rientra in questo divieto per il solo fatto di valutare il tono emotivo. Alcuni usi biometrici a fini di contrasto sono soggetti a regole strettamente delimitate; «tutto il riconoscimento facciale è vietato» non è un sostituto accurato della valutazione.

Sottoponete a escalation una possibile pratica vietata prima dell’acquisto o dell’utilizzo. Le evidenze devono descrivere la funzionalità e il ragionamento giuridico, non limitarsi a ripetere la dichiarazione di «IA etica» di un fornitore.

Verificare entrambi i percorsi verso la classificazione ad alto rischio

Il percorso dei prodotti regolamentati, articolo 6, paragrafo 1: esaminate se l’IA è essa stessa un prodotto, o un componente di sicurezza di un prodotto, disciplinato dalla normativa pertinente dell’allegato I, e se tale prodotto richiede una valutazione della conformità da parte di terzi. Entrambe le condizioni contano. Usate il testo giuridico modificato per lo specifico regime di prodotto; integrare l’IA non basta di per sé a stabilire lo status di alto rischio.

Il percorso dell’allegato III, articolo 6, paragrafo 2: esaminate se la funzione prevista corrisponde a un caso d’uso elencato. Le otto aree sono titoli ampi, non regole che rendono ad alto rischio ogni applicazione di un settore.

Leggete le voci dettagliate e le esclusioni. Per esempio, il rilevamento delle frodi finanziarie è distinto dall’uso elencato relativo all’affidabilità creditizia, e la verifica dei documenti di viaggio è esclusa dalla pertinente voce di identificazione in materia di migrazione. L’organizzazione amministrativa di una campagna non equivale a influenzare gli elettori.

Valutare la trasparenza anche quando non si applicano le regole sull’alto rischio

L’articolo 50 riguarda interazioni e output specifici. A seconda del ruolo e delle circostanze, gli obblighi riguardano l’informazione alle persone che stanno interagendo con un’IA, la marcatura in formato leggibile da una macchina degli output sintetici, le comunicazioni relative ai deepfake e specifici testi generati dall’IA pubblicati su questioni di interesse pubblico. Anche gli usi di riconoscimento delle emozioni e di categorizzazione biometrica, ove consentiti, prevedono obblighi di informazione.

Non riducete tutto questo a «etichettare ogni documento redatto con l’ausilio dell’IA». Stabilite quale disposizione si applica, chi deve agire e se un’eccezione è pertinente. Conservate come evidenza la formulazione delle informative, il loro posizionamento, le modalità di marcatura degli output e i risultati dei test.

Trattare l’eccezione dell’articolo 6, paragrafo 3, come una valutazione documentata

Alcuni sistemi dell’allegato III possono non rientrare nella classificazione ad alto rischio ai sensi dell’articolo 6, paragrafo 3. Non si tratta di un’esenzione generale per gli strumenti che prevedono un essere umano da qualche parte nel processo.

La valutazione deve stabilire se il sistema presenta un rischio significativo di danno per la salute, la sicurezza o i diritti fondamentali, anche influenzando materialmente il risultato del processo decisionale. La disposizione individua circostanze relative a compiti procedurali limitati, al miglioramento del risultato di un’attività umana precedentemente completata, al rilevamento di schemi decisionali o deviazioni a determinate condizioni di revisione e a compiti preparatori. Avvalersi dell’eccezione richiede di soddisfare almeno una di queste condizioni e di stabilire che il sistema non presenta il rischio significativo specificato.

Un fornitore che si avvale di questa eccezione deve documentare la valutazione prima di immettere il sistema sul mercato o di metterlo in servizio, e adempiere all’obbligo di registrazione applicabile. Elemento cruciale: un sistema dell’allegato III che effettua la profilazione di persone fisiche resta ad alto rischio; ciò non significa che ogni sistema di profilazione in ogni contesto diventi automaticamente ad alto rischio.

Le evidenze devono spiegare quali informazioni usa il sistema, come gli output influenzano i revisori e se il compito presentato come preparatorio determina chi riceve una valutazione nel merito. Includete osservazioni sul flusso di lavoro e output rappresentativi. Una frase come «la decisione finale spetta a una persona» è insufficiente se classificazioni, filtri o raccomandazioni determinano di fatto quella decisione.

Pianificare in base alle date di applicazione attuali

Alla verifica del 7 ottobre 2026, la panoramica e la cronologia aggiornate della Commissione europea sull’AI Act indicano le seguenti scadenze:

Verificate il testo giuridico modificato e le disposizioni transitorie che vi riguardano. Sistemi esistenti, date di immissione sul mercato dei modelli, modifiche e specifici assetti degli operatori possono richiedere analisi aggiuntive. Guide meno recenti potrebbero ancora riportare date precedenti per l’alto rischio.

Non interpretate il calendario aggiornato per l’alto rischio come un rinvio dell’intero regolamento. Prevedete budget separati per gli obblighi già applicabili e per la preparazione al regime dell’alto rischio pertinente. Il vostro registro deve indicare la scadenza applicabile e la fonte usata per stabilirla.

Trasformare la classificazione in un piano delle evidenze

Le responsabilità del fornitore e quelle del deployer sono diverse. Il vertice aziendale deve richiedere un piano specifico per ruolo invece di assegnare ogni obbligo a ogni team.

Se fornite un sistema ad alto rischio

I requisiti per l’alto rischio e gli obblighi del fornitore comprendono gestione dei rischi, governance dei dati, documentazione tecnica, conservazione delle registrazioni, informazioni per i deployer, sorveglianza umana, accuratezza, robustezza, cybersicurezza e gestione della qualità. Vanno pianificati anche la valutazione della conformità applicabile, la dichiarazione, la marcatura, la registrazione, il monitoraggio successivo all’immissione sul mercato e i processi relativi agli incidenti.

Traducete questi elementi in deliverable:

• Una valutazione dei rischi lungo il ciclo di vita, con misure di attenuazione, rischi residui e decisioni di approvazione.
• Registrazioni sulla provenienza, l’idoneità e la qualità dei dati, ove pertinenti per il sistema.
• Documentazione tecnica che indichi finalità, progettazione, dipendenze, limiti e metodi di valutazione.
• Risultati dei test collegati a criteri di accettazione e al contesto di utilizzo.
• Istruzioni per la sorveglianza che spieghino intervento, override ed escalation.
• Specifiche di logging, modalità di monitoraggio e procedure per gli incidenti.
• Un piano di lavoro per la conformità che individui il percorso applicabile e le registrazioni richieste.

Non tutti i sistemi ad alto rischio seguono lo stesso percorso di valutazione. Non mettete a budget un audit di terza parte universale e non considerate una certificazione di sicurezza come prova di conformità all’AI Act.

Se utilizzate un sistema ad alto rischio come deployer

Concentratevi sull’utilizzo del sistema conformemente alle istruzioni, sull’affidamento della sorveglianza a persone competenti, sul monitoraggio del suo uso e sulla conservazione delle registrazioni richieste. Occupatevi dell’idoneità dei dati di input quando li controllate voi e dei requisiti applicabili di informazione ai lavoratori o alle persone interessate.

Chiedete ai fornitori istruzioni, limiti, requisiti di sorveglianza e informazioni sulla conformità pertinenti. Individuate ciò che non sono in grado di fornire e chi colmerà la lacuna. Una dichiarazione di garanzia del fornitore non dimostra che la vostra configurazione locale sia adeguata.

Valutate se per la vostra categoria di deployer e il vostro caso d’uso sia richiesta una valutazione d’impatto sui diritti fondamentali. Non è obbligatoria per tutti gli utilizzi. Quando sono coinvolti dati personali, valutate separatamente i requisiti del GDPR; una valutazione d’impatto sulla protezione dei dati e una valutazione ai sensi dell’AI Act hanno finalità giuridiche diverse, anche quando le evidenze si sovrappongono.

Per ogni deliverable, indicate responsabile, revisore, scadenza, posizione della fonte e criterio di accettazione. «Policy caricata» non equivale a «controllo dimostrato».

Esempio pratico: un modello, due decisioni di business

Ipotesi illustrative: un datore di lavoro dell’UE utilizza un modello linguistico di terzi per un assistente di scrittura interno e per un’applicazione di selezione del personale separata. L’applicazione di selezione assegna ai candidati un punteggio rispetto ai criteri del ruolo e presenta una rosa ristretta in ordine di classifica. Il datore di lavoro usa entrambe internamente; i suoi ruoli precisi come operatore richiedono una revisione.

Per l’assistente di scrittura, registrate le attività di redazione consentite, le restrizioni sui dati, la revisione degli output e gli eventuali requisiti di trasparenza applicabili. La normale redazione interna non diventa ad alto rischio solo perché usa l’IA. Un’estensione alla valutazione in ambito lavorativo attiverebbe una nuova valutazione.

Per la selezione del personale, la voce dell’allegato III relativa all’occupazione è direttamente pertinente. Esaminate l’attribuzione di punteggi e la profilazione dei candidati, non solo la descrizione dell’interfaccia. Se i recruiter considerano solo i candidati della rosa ristretta, il sistema condiziona in modo sostanziale l’accesso all’occupazione. L’approvazione umana dell’assunzione finale non elimina tale influenza.

La decisione del vertice è quindi diversa per ciascuna applicazione. L’assistente di scrittura può procedere con controlli proporzionati dopo la revisione. Il progetto di selezione del personale richiede un piano di preparazione all’alto rischio, evidenze dei fornitori, una sorveglianza formata, la valutazione dell’uso locale e una decisione di rilascio documentata.

Se il team propone di trasformare la funzione di selezione in una pianificazione dei colloqui in calendario, valutate ex novo la nuova finalità e il nuovo flusso di lavoro. La pianificazione può essere un compito procedurale limitato, ma mantenere dietro le quinte l’attribuzione di punteggi ai candidati vanificherebbe la nuova motivazione. Versionate la decisione invece di sovrascrivere il record originale.

Rendere visibile la responsabilità nelle decisioni operative

Nominate un responsabile di business in grado di spiegare la finalità e approvare le risorse, un responsabile tecnico in grado di dimostrare il comportamento del sistema e un revisore legale o di compliance in grado di contestare la classificazione. L’approvazione del vertice deve risolvere questioni di finanziamento, restrizioni al rilascio e rischi aperti, non sostituire l’analisi specialistica.

Come raccomandazione pratica, rivedete la classificazione quando cambiano finalità, utenti, dati, integrazioni, autonomia o influenza su decisioni con conseguenze rilevanti. Collegate questa revisione ai rinnovi degli acquisti e ai rilasci di prodotto. Un aggiornamento del modello, da solo, può non modificare la classificazione, ma può invalidare le evidenze di valutazione o le ipotesi operative.

Errori comuni sono accettare classificazioni valide per l’intero fornitore, presumere che la revisione umana crei automaticamente un’esenzione, trascurare gli obblighi di alfabetizzazione e trasparenza già applicabili e raccogliere documenti senza verificare il funzionamento locale. Un sistema di gestione ISO/IEC 42001 può supportare la governance, ma la certificazione non stabilisce automaticamente la conformità all’AI Act.

Secani può supportare il flusso delle evidenze collegando requisiti, controlli, materiale di riferimento, responsabili, attività e decisioni revisionate. Iniziate da un processo, collegate le evidenze a ciò che dimostrano e mantenete commenti, approvazioni e marcature temporali insieme alle conclusioni rilevanti. Trattate i suggerimenti supportati dall’IA come bozze da sottoporre a revisione umana, non come determinazioni giuridiche. La nostra guida alla governance degli agenti di IA offre controlli pratici per permessi e revisione.

Il passo successivo utile è un workshop di classificazione mirato: selezionate i casi d’uso attivi con le conseguenze più rilevanti, coinvolgete i rispettivi responsabili di business e tecnici e producete record revisionati con le questioni aperte e le attività sulle evidenze. Questo fornisce al vertice una base difendibile per decidere che cosa può procedere, che cosa richiede condizioni e che cosa necessita di ulteriori valutazioni.