AI Act nel 2026: come decidere se un sistema di IA attiva obblighi, quali evidenze raccogliere e quando interviene una persona

Ambito di questa guida: una decisione tracciabile, non un parere legale

Questa guida è destinata ai team di prodotto, sicurezza, compliance, acquisti e tecnologia che sviluppano, integrano, distribuiscono o utilizzano sistemi di IA collegati al mercato dell'Unione europea. Il suo obiettivo è trasformare un caso d'uso in una scheda verificabile: cosa fa il sistema, chi interviene nella catena di fornitura, dove viene usato, quale categoria potrebbe essere rilevante, quali obblighi sono già applicabili e quali evidenze esistono.

Non intende risolvere in modo definitivo la classificazione giuridica di un prodotto specifico. L'applicazione del regolamento sull'IA dipende dai fatti, dalla destinazione d'uso prevista, dalla configurazione effettiva, dagli attori che prendono decisioni e, in alcuni settori, da norme ulteriori. Privacy, lavoro, credito, dispositivi medici, aviazione, biometria e prestazione di servizi pubblici possono richiedere valutazioni nell'ambito di quadri distinti.

Le date sono importanti, ma non esiste un'unica data di applicazione per l'intero regolamento. La Commissione europea presenta un calendario scaglionato: alcune norme, incluse quelle sulle pratiche vietate e sull'alfabetizzazione in materia di IA, hanno iniziato ad applicarsi prima del regime generale. Inoltre, una successiva modifica legislativa cambia il calendario di determinati obblighi per i sistemi ad alto rischio.

Usa questo contenuto come procedura di governance. Per approfondire i controlli operativi, consulta la sezione Sicurezza; per valutare alternative tecniche e fornitori, la sezione Confronta; per contestualizzare capacità e casi d'uso, la sezione Scopri.

Passo 1: delimita il caso d'uso prima di valutare il rischio

L'unità di analisi non dovrebbe essere soltanto il nome commerciale di uno strumento. Può essere una funzionalità specifica, una versione di modello, un flusso automatizzato o un'integrazione. Uno stesso prodotto può avere funzioni con livelli di esposizione diversi: riassumere documenti interni non equivale a dare priorità a persone per una prestazione, né a eseguire modifiche in un account esterno.

Documenta la destinazione d'uso prevista dichiarata da chi offre il sistema e la finalità effettiva che la tua organizzazione configura o consente. Includi i territori di immissione sul mercato, utilizzo o disponibilità dei risultati; i gruppi potenzialmente interessati; il contesto d'uso; la fase del ciclo di vita; le interfacce; e le azioni successive abilitate. Conserva schermate di configurazione, contratti, istruzioni, valutazioni e versioni.

Identifica inoltre se si tratta di un modello di IA per finalità generali, di un sistema costruito su tale modello o di entrambi. Le linee guida della Commissione sui modelli per finalità generali sono interpretative e aiutano a distinguere gli obblighi del fornitore del modello da quelli dell'attore che offre o utilizza un sistema a valle. Non sostituiscono la norma né un'interpretazione giudiziaria.

Passo 2: identifica il ruolo in base all'attività, non al nome del contratto

Un'organizzazione può ricoprire più di un ruolo rispetto a prodotti o componenti diversi. Il titolo di un contratto — per esempio «cliente», «partner» o «rivenditore» — non determina da solo l'esito. Per l'analisi conta ciò che l'attore sviluppa, fa sviluppare, commercializza, mette in servizio, importa, distribuisce, modifica o utilizza sotto la propria autorità.

Come quadro operativo, considera possibile fornitore l'attore che sviluppa un sistema o un modello, oppure ne commissiona lo sviluppo, e lo commercializza o lo mette in servizio con il proprio nome o marchio. Considera possibile deployer l'attore che utilizza un sistema sotto la propria autorità, salvo gli usi personali non professionali. Importatore e distributore sono ruoli della catena commerciale che richiedono di verificare come il sistema sia introdotto o messo a disposizione nell'Unione. La figura del rappresentante autorizzato richiede una designazione e un mandato verificabili.

Una modifica sostanziale, un cambiamento della finalità o la commercializzazione con marchio proprio sono segnali per interrompere il flusso automatico e chiedere una revisione specialistica. Le linee guida disponibili sull'ambito degli obblighi dei fornitori di modelli per finalità generali affrontano, tra l'altro, l'identificazione del fornitore, l'immissione sul mercato e le modifiche; il loro carattere di guida interpretativa deve essere annotato nel fascicolo.

Passo 3: classifica l'uso e separa categorie che non sono intercambiabili

Inizia escludendo se il caso possa essere collegato a una pratica vietata. Le pratiche vietate seguono un regime di applicazione precedente al calendario generale. La Commissione ha pubblicato linee guida su tali pratiche; sono utili per strutturare domande ed esempi, ma l'interpretazione autorevole finale spetta ai tribunali competenti dell'Unione.

Valuta poi, senza presumere l'esito, quattro piani distinti: se il sistema potrebbe rientrare nell'alto rischio perché componente di sicurezza di un prodotto regolamentato o per un altro caso disciplinato; se il caso d'uso potrebbe rientrare in categorie ad alto rischio; se attiva obblighi di trasparenza; e se interviene un modello di IA per finalità generali. Un sistema può richiedere trasparenza senza essere ad alto rischio. Un modello per finalità generali non equivale automaticamente a un sistema ad alto rischio utilizzato da un terzo.

Non trasformare un elenco di settori in una diagnosi. La finalità specifica, l'effetto sulle persone, l'autonomia operativa, il contesto di implementazione e le eccezioni applicabili possono cambiare la conclusione. Se il sistema incide su lavoro, istruzione, accesso a servizi essenziali, credito, salute, biometria, amministrazione della giustizia o servizi pubblici, stabilisci una revisione giuridica e settoriale come condizione di uscita.

Passo 4: costruisci una cronologia per obbligo e condizione

La pianificazione deve associare ogni obbligo a una condizione di attivazione, non limitarsi a una data complessiva. Il quadro della Commissione indica che le pratiche vietate e gli obblighi di alfabetizzazione in materia di IA si applicano dal 2 febbraio 2025. Gli obblighi relativi ai modelli per finalità generali e determinate disposizioni di governance hanno iniziato ad applicarsi prima del regime generale, il 2 agosto 2025. Il regime generale ha come riferimento il 2 agosto 2026, fatte salve le eccezioni previste.

Per l'alto rischio, non riutilizzare automaticamente le date precedenti. La modifica legislativa pubblicata nel 2026 rinvia l'applicazione collegata ai sistemi dell'allegato III e ai sistemi relativi all'allegato I secondo un calendario differenziato: il 2 dicembre 2027 per un gruppo e il 2 agosto 2028 per l'altro. La corrispondenza concreta deve essere verificata rispetto al testo consolidato e alla situazione del sistema.

Le linee guida sulla trasparenza pubblicate dalla Commissione nel 2026 sono presentate come orientamento sull'ambito pratico degli obblighi applicabili dal 2 agosto 2026. Usale per progettare controlli ed evidenze, non per sostituire l'analisi del testo legislativo o di atti successivi.

Passo 5: traduci i requisiti in evidenze operative

Un obbligo è gestibile solo se è associato a un responsabile, una fonte, una data, una versione e una prova di esecuzione. Il fascicolo non deve consistere in una dichiarazione commerciale generica. Deve consentire di ricostruire quale sistema è stato valutato, per quale finalità, con quale configurazione, quali controlli sono stati applicati e quale decisione è stata presa.

Per un caso potenzialmente ad alto rischio, gli ambiti abitualmente rilevanti includono gestione dei rischi, governance e qualità dei dati quando pertinenti, documentazione tecnica, registrazioni, informazioni per i deployer, supervisione umana, accuratezza, robustezza e cibersicurezza. L'applicabilità concreta dipende dalla classificazione e dal ruolo. Non dichiarare che un controllo soddisfa un requisito se non ne sono stati verificati ambito, prova ed evidenza.

Anche la supervisione umana non si dimostra con la frase «c'è una persona nel circuito». Descrivi cosa può vedere la persona, quando interviene, quale autorità ha per ignorare o fermare un output, quale formazione riceve, come sono gestiti gli avvisi e cosa accade in caso di automazione eccessiva. Se non può intervenire in modo sostanziale prima di una conseguenza rilevante, documenta tale limite.

Passo 6: applica l'analisi agli acquisti e all'integrazione di terzi

L'acquisto di un sistema o di un'API non elimina le responsabilità di chi lo configura e utilizza. L'organizzazione acquirente deve distinguere la documentazione ricevuta dal fornitore dall'evidenza generata sulla propria implementazione. Per esempio, il fornitore può fornire istruzioni, caratteristiche dichiarate e documentazione di conformità ove pertinente; il deployer deve poter spiegare la finalità locale, gli utenti autorizzati, i dati connessi, le autorizzazioni e le decisioni prese dopo un output.

Inserisci domande di compliance nella selezione, nel contratto, nell'accettazione tecnica e nella revisione periodica. Richiedi informazioni con un livello di dettaglio proporzionato all'uso previsto. Se il fornitore rifiuta di identificare versione, modifiche rilevanti, limiti noti, condizioni d'uso o meccanismo per gli incidenti, considera la mancanza di informazioni un rischio di acquisizione, non una questione amministrativa secondaria.

Il codice di buone pratiche per l'IA per finalità generali, pubblicato nel 2025 e considerato dalla Commissione uno strumento volontario adeguato, può essere un utile segnale documentale in alcuni casi. Non equivale di per sé a dimostrare la conformità legale né sostituisce l'evidenza specifica del sistema integrato.

Tre scenari: quali fatti cambiano l'analisi

Scenario uno: un assistente interno redige bozze a partire da documenti caricati manualmente dal team. Se non decide su persone, non esegue azioni esterne ed è utilizzato con una revisione umana sostanziale, il fascicolo può concentrarsi inizialmente su finalità, dati, informazioni agli utenti, autorizzazioni, fornitori e formazione. Tuttavia, la classificazione cambia se le bozze sono usate per decisioni in materia di lavoro, credito, salute o accesso a servizi senza una revisione effettiva.

Scenario due: un sistema dà priorità alle richieste dei clienti. Il nome «prioritizzazione» non risolve nulla. Conta se ordina soltanto una coda operativa oppure se determina di fatto chi riceve un servizio, con quale tempistica, a quali condizioni e con quale possibilità di correzione. Devono essere documentate variabili, regole, metriche, distorsioni note, responsabili dell'annullamento ed effetti dei falsi positivi e negativi.

Scenario tre: un agente può inviare email, modificare registri o attivare azioni in strumenti esterni. Il fatto decisivo non è l'uso del linguaggio naturale, ma l'ampiezza delle autorizzazioni, la reversibilità delle azioni, le soglie di autorizzazione, l'identità che esegue l'azione e i controlli prima e dopo. Un'ampia capacità di esecuzione può richiedere una valutazione di sicurezza più intensa anche quando la classificazione normativa rimane incerta.

Modello testuale di scheda di applicabilità

Mantieni una scheda per ogni caso d'uso e aggiornala quando cambiano finalità, modello, integrazione, fornitore, dati o popolazione interessata. La scheda deve poter essere letta da prodotto, sicurezza, acquisti e compliance senza obbligarli a ricostruire decisioni da messaggi o riunioni isolate.

È preferibile registrare esplicitamente l'incertezza piuttosto che chiudere una classificazione senza una base sufficiente. Indica quale conclusione è un fatto documentato, quale elemento è un'analisi interna e quale questione attende una conferma legale, tecnica o contrattuale.

Errori frequenti e quando fermarsi per effettuare escalation

Un errore comune è presumere che il fornitore assorba ogni responsabilità. Un altro è accettare un'affermazione commerciale di conformità senza verificare quale prodotto, versione, finalità e attore copra. È inoltre frequente usare un'unica data per l'intero regolamento, oppure trasformare la valutazione del rischio in una casella che non viene riesaminata dopo una modifica tecnica o di contesto.

Interrompi il deployment o l'ampliamento ed effettua escalation a consulenza legale quando vi sia una possibile pratica vietata; un'incertezza ragionevole sull'alto rischio; trattamento sensibile o decisioni con effetti significativi sulle persone; biometria; lavoro; credito; salute; istruzione; servizi pubblici; attività di polizia o giudiziarie; commercializzazione transfrontaliera complessa; modifica sostanziale; oppure conflitto tra finalità dichiarata e uso effettivo.

Effettuare escalation non equivale a bloccare definitivamente il prodotto. Significa formulare una domanda concreta, allegare fatti ed evidenze, identificare la decisione in sospeso e conservare una versione del sistema valutato. Questa disciplina permette che la revisione legale, di privacy, sicurezza o diritti fondamentali sia più rapida e verificabile.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.