Sfide

La legislazione europea sull'IA è in vigore. Puoi rispondere a queste cinque domande?

Di Marc Molas·31 maggio 2026·8 min di lettura

Il regolamento europeo sull'IA è in vigore dall'agosto 2024. Le pratiche vietate sono scadute nell'agosto 2025. Gli obblighi per l'IA ad alto rischio entrano in vigore nell'agosto 2026. Se distribuisci sistemi di IA in Europa — o elabori dati appartenenti a europei — il conto alla rovescia è già partito.

La maggior parte delle organizzazioni tratta ancora l'AI Act come un documento di conformità da leggere e firmare. Lo hanno affidato al legale, segnato come "in revisione" e sono andati avanti. Questo è l'approccio sbagliato.

L'AI Act non è principalmente un testo giuridico. È un insieme di obblighi operativi. E il modo più rapido per capire se sei davvero conforme — non sulla carta, ma operativamente — è rispondere a cinque domande concrete su ogni sistema di IA che gestisci.

Se non riesci a rispondere a tutte e cinque, hai lavoro da fare prima di agosto.

Perché queste cinque domande

Il regolamento ha più di 180 articoli. Ma sepolto nelle disposizioni di gestione dei rischi, negli obblighi di trasparenza, nei requisiti di supervisione umana e nel quadro di responsabilità c'è una struttura sottostante coerente: i sistemi di IA devono essere governabili. Non solo sicuri in astratto — attivamente governabili da persone identificabili, con processi definiti, comportamento auditabile e una chiara catena di responsabilità.

Quella struttura si riduce a cinque domande. Non sono mie — sono quelle che qualsiasi regolatore, revisore o avvocato farà per prime quando qualcosa va storto. Dovresti potervi rispondere prima che qualcosa vada storto.

Domanda 1: A quali dati accede e quali dati può modificare?

Sembra ovvio. Raramente lo è.

In pratica, la maggior parte dei team che distribuisce sistemi di IA ha una risposta ragionevole per "quali dati legge?" (dati di addestramento, dati di input, forse un corpus di recupero), ma una risposta molto più vaga per "quali dati può scrivere, modificare o causare cambiamenti?"

I sistemi agentici peggiorano questo. Un agente che invia e-mail, aggiorna record CRM, chiama API o modifica configurazioni ha accesso in scrittura a sistemi reali. Le disposizioni di governance dei dati dell'AI Act (articoli 10 e 13) richiedono di documentare la provenienza dei dati di addestramento, l'ambito dei dati di input e — soprattutto — quale stato del sistema può essere modificato dagli output del sistema di IA.

Cosa significa la conformità: una mappa dei dati mantenuta per ogni distribuzione di IA. Fonti di input (con controlli di accesso documentati), destinazioni di output (con autorizzazioni di scrittura documentate) e una distinzione chiara tra percorsi di lettura e scrittura.

Il gap più comune: sono stati documentati gli input ma non ciò che accade a valle degli output dell'IA. Se il tuo sistema di IA raccomanda qualcosa e un essere umano clicca su approva, il clic dell'umano conta come la scrittura? Legalmente: a volte sì, a volte no. Devi sapere qual è il tuo caso.

Domanda 2: Chi lo supervisiona?

L'AI Act richiede la supervisione umana per i sistemi di IA ad alto rischio (articolo 14). Non "gli esseri umani possono rivedere gli output se vogliono." Supervisione umana definita — un ruolo nominato con la responsabilità di monitorare il comportamento del sistema, rivedere le decisioni segnalate e l'autorità per ignorare o fermare.

Questa domanda ha due livelli:

Supervisione operativa: chi monitora il sistema quotidianamente? Chi riceve l'avviso quando il tasso di errore aumenta? Nella maggior parte delle organizzazioni, questa è una funzione di guardia dell'ingegneria. Va bene, ma deve essere esplicita. "Il team lo monitora" non è sufficiente — il team non è un'entità legale e non ha autorità.

Supervisione di governance: chi ha l'autorità di modificare i parametri del sistema, riaddestrare il modello o spegnerlo? Per le industrie regolamentate questo si mappa sulle strutture di governance esistenti. Per le startup spesso non si mappa su nessuno, il che è un problema.

Cosa significa la conformità: per ogni sistema di IA, un individuo nominato o un ruolo con responsabilità di supervisione documentate e l'autorità reale (accesso, strumenti, processo) per esercitarle. Non un RACI che punta a "Ingegneria" — una persona, o un ruolo chiaramente definito, con responsabilità reale.

L'Ufficio IA e le autorità nazionali di sorveglianza del mercato sono lo strato di supervisione sopra la tua governance interna. Non sono astratte. Stanno costruendo attivamente capacità di enforcement.

Domanda 3: Dove conserva le informazioni?

Il GDPR e l'AI Act si sovrappongono significativamente qui. Gli obblighi di trasparenza e i requisiti di governance dei dati dell'AI Act presuppongono che tu possa rispondere a dove vengono persistiti gli input del modello, gli output e gli stati intermedi.

Questo si complica rapidamente per i sistemi che utilizzano fornitori di modelli di terze parti, la generazione aumentata dal recupero con database vettoriali esterni, modelli affinati ospitati da fornitori cloud, o architetture multi-agente dove un agente passa il contesto a un altro.

Cosa significa la conformità: residenza dei dati documentata per ogni archivio persistente che il sistema di IA tocca. Questo include: dati di input, dati di output, cronologia delle conversazioni o stato della sessione se conservati, embeddings in un database vettoriale, dati di addestramento di fine-tuning, log di audit.

Per l'IA ad alto rischio, i dati devono essere conservati in modo da consentire audit post-hoc. Devi essere in grado di ricostruire cosa ha fatto il sistema con quali dati, per una decisione specifica, in una data specifica.

La domanda sul fornitore cloud: se stai usando un fornitore LLM con sede negli USA senza residenza dei dati nell'UE, la questione di dove vanno i dati in transito è aperta. La maggior parte dei team di ingegneria non ha mai letto gli addenda sul trattamento dei dati dei propri contratti.

Domanda 4: Chi è responsabile se sbaglia?

Il quadro di responsabilità dell'AI Act, combinato con la pendente Direttiva sulla Responsabilità dell'IA, è progettato per rispondere a questo a livello macro. Ma la domanda pratica è interna: prima che il regolatore chieda, la tua organizzazione lo sa?

Ci sono tre ruoli di responsabilità nella struttura dell'AI Act:

Fornitore: l'organizzazione che sviluppa o immette sul mercato un sistema di IA. Se affini un modello, costruisci un prodotto su un modello o sviluppi uno strumento di IA per l'uso altrui, probabilmente sei un fornitore.

Deployer: l'organizzazione che mette in uso un sistema di IA in un contesto specifico. Se stai usando il prodotto di un fornitore di IA nelle tue operazioni aziendali, sei un deployer.

La maggior parte delle organizzazioni è sia fornitore (dei propri strumenti di IA) che deployer (di IA di terze parti). La divisione degli obblighi tra loro è importante: i fornitori sono responsabili della sicurezza di progettazione fondamentale del sistema; i deployer sono responsabili del contesto di distribuzione appropriato e della supervisione.

Cosa significa la conformità: allocazione documentata degli obblighi tra la tua organizzazione e i tuoi fornitori di IA. I tuoi contratti enterprise dovrebbero specificare chi è il fornitore di riferimento per ogni sistema.

Il gap reale: la maggior parte delle organizzazioni non ha ancora avuto la conversazione sulla responsabilità con i propri fornitori di IA. Il contratto è stato firmato, la chiave API è in produzione e nessuno ha formalmente allocato chi risponde al regolatore.

Domanda 5: Come si spegne se inizia a funzionare male?

Questa è la domanda che la maggior parte dei team trova più difficile da rispondere, non perché il meccanismo non esista, ma perché non è mai stato progettato esplicitamente.

L'articolo 9 (gestione dei rischi) e l'articolo 14 (supervisione umana) insieme richiedono che i sistemi di IA ad alto rischio abbiano procedure definite per interrompere l'operazione quando vengono superati i limiti di sicurezza o accuratezza. Non è "puoi spegnere il server." Significa:

Rilevamento: come sai che si sta comportando male? Quale metrica, avviso o processo di revisione fa emergere il problema?
Classificazione: cosa costituisce "funzionare male" per questo sistema specifico? Deriva del modello? Disparità demografica negli output? Tasso di errore che supera la soglia?
Autorizzazione: chi ha l'autorità di decidere di fermare?
Esecuzione: cosa significa fermare? Terminare l'API? Tornare a una versione precedente? Passare a un processo manuale di riserva?
Comunicazione: chi viene notificato quando si verifica un arresto? Per i sistemi ad alto rischio in alcune categorie, la segnalazione degli incidenti all'Ufficio IA è obbligatoria.

Cosa significa la conformità: un runbook — non un interruttore di spegnimento teorico, ma una procedura documentata testata almeno una volta, con proprietari nominati ad ogni passo.

Perché la maggior parte dei team fallisce qui: il sistema è stato distribuito in modo incrementale. Non c'è mai stata una sessione di progettazione su "qual è il piano di spegnimento?". L'interruttore esiste in linea di principio (spegnere il server) ma i livelli di rilevamento e autorizzazione non esistono.

Il pattern dietro le cinque domande

Leggile insieme: accesso/modifica dei dati, supervisione, archiviazione, responsabilità, spegnimento. Non sono cinque requisiti indipendenti. Sono cinque facce di un'unica domanda: questo sistema di IA è governabile?

La governance richiede che qualcuno possa osservare il sistema (domande 1, 3), che qualcuno abbia autorità su di esso (domande 2, 4) e che tale autorità possa essere esercitata nella pratica (domanda 5). Se manca una delle cinque, il ciclo di governance è rotto.

L'AI Act europeo sta operativizzando questo nella legge perché l'approccio volontario non ha funzionato. I principi senza applicazione non cambiano il comportamento. L'Atto è applicazione.

Cosa farei questo trimestre

Se stai distribuendo sistemi di IA in Europa, o qualsiasi cosa che tocchi dati europei, la sequenza pratica:

Fai un inventario delle tue distribuzioni di IA. Non solo i prodotti di IA che vendi — tutta l'IA che usi internamente. Strumenti di selezione HR, bot del servizio clienti, rilevamento delle frodi, motori di raccomandazione.
Per ogni sistema, rispondi alle cinque domande. Scrivile. "Non abbiamo ancora deciso" è una risposta — significa che hai un gap.
Per qualsiasi cosa nelle categorie ad alto rischio (Allegato III dell'Atto) — dai priorità. Agosto 2026 è la scadenza definitiva.
Metti in ordine i contratti con i fornitori. Chi è il fornitore di riferimento? Quali capacità di audit fornisce il fornitore?
Costruisci il runbook per la domanda 5. Delle cinque, è la più operativa e la meno probabile che esista. Costruiscila prima di averne bisogno.

L'AI Act non è una regolamentazione perfetta. Ma le cinque domande sono un'ingegneria responsabile indipendentemente dalla regolamentazione — è ciò che il deployment responsabile di sistemi con conseguenze ha sempre richiesto. L'Atto lo sta semplicemente rendendo obbligatorio.

Stai distribuendo sistemi di IA in produzione in Europa e hai bisogno di capacità di ingegneria che operi già con questi controlli di governance integrati? Parliamone — i nostri team nearshore costruiscono sistemi di IA con log di audit, hook di supervisione umana e runbook di conformità come pratica standard.