L’AI Act dell’UE: cosa cambia nei progetti software, nei contratti, nei ruoli, nei registri (log) e nella responsabilità. Una guida pratica per CEO e IT Manager. Se sei un CEO o un IT Manager, l’AI Act dell’UE non è una legge che vive nell’ufficio legale, è una legge che si presenterà nella tua roadmap di prodotto.
L’AI Act dell’UE: cosa cambia nei progetti software, nei contratti, nei ruoli, nei log e nella responsabilità. Una guida pratica per CEO e IT Manager. Se sei un CEO o un IT Manager, l’AI Act dell’UE non è una legge relegata all’ufficio legale; è una legge che si manifesterà nella tua roadmap di prodotto, nei modelli di acquisto, nei processi di gestione degli incidenti, nelle trattative con i fornitori e nel tuo modello operativo. Il cambiamento più grande è semplice da dire, ma sorprendentemente difficile da attuare: l’IA smette di essere una funzionalità accessoria e diventa un componente decisionale governato. Questo significa che devi essere in grado di rispondere, in qualsiasi momento, a chi ne è proprietario, come viene controllata, come viene monitorata e come puoi dimostrare ciò che è accaduto.
Le tempistiche, perché guidano budget e priorità L’AI Act è entrato in vigore il 1° agosto 2024 e sarà pienamente applicabile dal 2 agosto 2026, con tappe scaglionate: le pratiche vietate e le misure di alfabetizzazione sull’IA hanno iniziato ad applicarsi dal 2 febbraio 2025, le regole di governance e gli obblighi per i modelli di IA per scopi generali sono diventati applicabili il 2 agosto 2025, mentre alcuni sistemi ad alto rischio integrati in prodotti regolamentati hanno un periodo di transizione più lungo fino al 2 agosto 2027.
Per la maggior parte delle aziende, questo significa che il 2026 non è una scadenza di conformità lontana, ma una realtà di consegna attuale: qualsiasi cosa tu lanci oggi e che sarà ancora operativa nel 2026, dovrebbe essere costruita tenendo a mente queste aspettative.
La prima domanda che cambia tutto: qual è il tuo ruolo nella catena? Prima di discutere di modelli, accuratezza o scelte cloud, fai una domanda: siamo un provider (fornitore) o un deployer (utilizzatore), per questa specifica funzionalità di IA? Nel linguaggio dell’AI Act, il provider è il soggetto che immette sul mercato un sistema di IA o lo mette in servizio a proprio nome, il deployer è il soggetto che lo utilizza all’interno di un’organizzazione e di un processo. Molte aziende svolgono entrambi i ruoli: deployer quando utilizzano IA di terze parti, provider quando forniscono ai clienti prodotti basati sull’IA. Il motivo per cui questo è fondamentale per un CEO e un IT Manager è che il ruolo determina cosa devi essere in grado di dimostrare e cosa devi esigere dai fornitori. Se sbagli questo passaggio, ti ritroverai con una lacuna di conformità che nessuna quantità di ingegneria potrà colmare all’ultimo minuto.
Il logging diventa architettura, perché la tracciabilità diventa un requisito Nella maggior parte dei progetti software, il logging (la registrazione degli eventi) è trattato come una preferenza ingegneristica; in molti progetti di IA, è considerato un extra opzionale. Sotto l’AI Act, per i sistemi ad alto rischio, la tenuta dei registri è un’aspettativa esplicita: i sistemi di IA ad alto rischio devono consentire tecnicamente la registrazione automatica degli eventi, per tutta la durata del sistema. Anche lato deployer c’è un obbligo operativo molto concreto: gli utilizzatori di sistemi di IA ad alto rischio devono conservare i log generati automaticamente dal sistema, nella misura in cui sono sotto il loro controllo, per un periodo appropriato allo scopo previsto e comunque per almeno sei mesi, salvo diversa disposizione del diritto dell’UE o nazionale.
Ora, cosa significa questo in un progetto reale, senza tecnicismi di facciata? Significa che devi essere in grado di ricostruire un episodio decisionale, in un secondo momento, con sicurezza: quale versione era in esecuzione, quale input è stato utilizzato, cosa ha prodotto il sistema, cosa ci ha fatto l’umano (l’ha accettato, modificato, rifiutato) e perché.
Questa è la parte che sfugge alla maggior parte dei team: l’output dell’IA da solo non basta; il rischio aziendale risiede solitamente nella decisione umana successiva. Se la tua interfaccia non offre un modo semplice per acquisire una forzatura (override), una correzione o una motivazione, perderai due cose contemporaneamente: l’auditability (verificabilità) e l’apprendimento. Quindi l’AI Act ti spinge, indirettamente ma con forza, a progettare la supervisione direttamente nell’esperienza del prodotto, e non ad aggiungerla a posteriori.
La responsabilità (Accountability) cambia, perché l’IA non può non essere di nessuno In molte organizzazioni, il primo progetto pilota funziona perché un piccolo team se ne prende cura; poi il sistema cresce e la proprietà diventa sfumata. Le operations pensano che sia del team prodotto, il prodotto pensa che sia dell’IT, l’IT pensa che sia del fornitore e l’ufficio legale appare solo quando qualcosa va storto.
L’AI Act spinge nella direzione opposta: premia la chiarezza delle responsabilità, specialmente per gli usi a rischio più elevato. In pratica, CEO e IT Manager devono assicurarsi che ci sia un modello operativo chiaro: qualcuno è responsabile dei risultati di business, qualcuno del processo e della user experience, qualcuno delle operazioni tecniche e dei cambiamenti, qualcuno del rischio e della conformità (anche se questo responsabile del rischio ha un ruolo leggero). Questa non è burocrazia, è un meccanismo di scalabilità: quando la responsabilità è chiara, l’IA può essere adottata ampiamente; quando è poco chiara, l’IA verrà messa in quarantena, o spenta al primo incidente.
I contratti sono quelli che cambiano di più, perché la conformità vive nelle relazioni con i fornitori La maggior parte dei progetti di IA non viene costruita da zero, ma viene assemblata: si utilizza un foundation model, una piattaforma, un system integrator, un fornitore di dati, un servizio di annotazione, uno strumento di monitoraggio. La conformità diventa forte quanto l’anello più debole della catena di fornitura, e il contratto è il luogo in cui quell’anello viene assicurato o ignorato. Ci sono due scenari comuni: acquisti o integri l’IA come deployer, oppure fornisci l’IA come provider.
Se sei un deployer che acquista o integra IA, cosa deve comparire nel contratto Primo, trasparenza operativa, non spiegazioni di marketing. Hai bisogno di istruzioni pratiche per l’uso, dei limiti, di sapere dove è affidabile e dove non lo è, e cosa dovrebbero fare gli operatori quando sono insicuri; altrimenti non puoi rivendicare un uso sicuro e appropriato su larga scala.
Secondo, logging e accesso alle prove. Se devi conservare i log per almeno sei mesi nei casi ad alto rischio, devi poter accedere ad essi ed esportarli, e devi sapere cosa contengono, dove sono archiviati e con quali regole di conservazione.
Terzo, gestione del cambiamento. L’IA cambia: i modelli vengono aggiornati, i prompt vengono ottimizzati, i guardrail vengono regolati, le basi di conoscenza vengono aggiornate. Una clausola software tradizionale che afferma “potrebbero verificarsi aggiornamenti” non è sufficiente. Vuoi aspettative esplicite: come vengono comunicati gli aggiornamenti, come vengono testati, come vengono gestite le regressioni, come funziona il rollback, come puoi bloccare una versione per un periodo critico.
Quarto, gestione degli incidenti. Il contratto deve definire come si gestiscono i malfunzionamenti gravi: chi viene avvisato, in quali tempi, quali prove vengono fornite, come si coordina il ripristino. Senza questo, ogni incidente diventa una discussione su di chi sia la colpa, non un processo di recupero. Un modello utile è quello di allegare agli acquisti un allegato sulla governance dell’IA, scritto con linguaggio operativo, che specifichi di default il logging, la supervisione, gli aggiornamenti, la gestione degli incidenti e le responsabilità.
Se sei un provider che fornisce software basato sull’IA, cosa cambia nella postura di fornitura e responsabilità Quando fornisci a tuo nome, ti avvicini agli obblighi del provider, specialmente se il tuo sistema opera in un contesto regolamentato o ad alto rischio. In quel caso, hai bisogno di documentazione tecnica e di un approccio al rischio basato sul ciclo di vita — prima dell’implementazione, non dopo — e devi mantenere aggiornati questi artefatti man mano che il sistema evolve. Anche se non sei classificato ad alto rischio, le aspettative del mercato si sposteranno, i clienti ti chiederanno: “mostrami i tuoi log, mostrami i tuoi controlli, mostrami la tua disciplina sugli aggiornamenti”, perché saranno loro stessi deployer con i propri obblighi. Ecco perché la governance dell’IA diventa un vantaggio competitivo, non solo un costo di conformità.
L’alfabetizzazione sull’IA (AI literacy) non è una presentazione per la formazione, è un requisito operativo Dal 2 febbraio 2025, l’AI Act include l’obbligo di adottare misure per garantire l’alfabetizzazione sull’IA del personale e di altri soggetti che operano sistemi di IA per tuo conto; la Commissione ha pubblicato delle FAQ chiarendo che l’obbligo è già in vigore. Per CEO e IT Manager, il significato pratico è che l’uso sicuro non è solo una policy, ma un insieme di abitudini e interfacce. Se vuoi che questo funzioni nella vita reale, devi combinare tre cose: una formazione leggera che spieghi le modalità di fallimento tipiche, regole semplici che definiscano quando è necessaria la revisione umana, e un design del prodotto che renda il comportamento corretto anche quello più facile — ad esempio, chiari indicatori di affidabilità, percorsi di escalation e l’aggiunta di “attrito” per le azioni sensibili.
Come questo si riflette nel tuo piano di progetto: cosa cambiare a partire dalla prossima settimana Se vuoi un approccio pratico, tratta l’AI Act come un modello di delivery (consegna), non come un evento legale.
Inizia con un inventario: dove viene utilizzata l’IA oggi, inclusi i copilot di terze parti; classifica i casi d’uso per impatto e sensibilità; chiarisci se sei deployer o provider; introduci il “logging by design”; definisci le responsabilità operative; aggiorna i tuoi modelli di acquisto con un allegato sulla governance dell’IA; e definisci un playbook per gli incidenti e i rollback. Questa sequenza si allinea con le tempistiche del Regolamento e con la sua enfasi sull’alfabetizzazione, sulla tracciabilità e sull’applicabilità scaglionata.
Il nuovo modello mentale: la governance non è controllo, è fiducia scalabile L’AI Act viene spesso descritto come una regolamentazione, ma per la maggior parte delle aziende l’effetto pratico è la standardizzazione. Spinge le organizzazioni verso un’IA prevedibile, tracciabile e responsabile. Se lo fai bene, ottieni più della semplice conformità: ottieni sistemi che la tua organizzazione ha il coraggio di utilizzare, in modo diffuso, in flussi di lavoro reali, perché sono comprensibili, controllabili e ripristinabili.
