AI Act + DORA: timeline regolatorio per chi costruisce AI agents in EU

Nota di metodo: tutti i casi descritti sono pattern composti da audit reali, modificati per garantire la riservatezza dei clienti coinvolti. Nessun caso identifica un singolo cliente specifico. Questo articolo non sostituisce consulenza legale formale: per gare, contratti e rischi specifici, fate validare ogni interpretazione con il vostro legal team.

Maggio 2026, ufficio legale di una banca regionale italiana, sede a Padova, asset under management sui sei miliardi. Il Chief Compliance Officer mi sta facendo una intake review preliminare per un progetto di automazione documentale che dovremmo cominciare a luglio. (Sono io l'ICT third-party che le regole DORA le dicono di auditare.) La conversazione dura quaranta minuti e arriva al punto in cui mi chiede: il vostro fornitore LLM ha un piano di business continuity certificato secondo gli articoli 11 e 12 di DORA, oppure no?

Pausa. Non lo so, dico. Allora andiamo a vedere insieme.

Apriamo il DPA del provider, ci sono ventitre pagine, in nessuna delle ventitre la parola "DORA" appare. Possiamo costruire il modello legale insieme, dice il CCO. La gara non parte se non risolviamo questo.

Da quel punto in poi, la mia checklist DORA è cambiata.

AI Act in tre date che devi sapere

L'EU AI Act è entrato in vigore in fasi scaglionate, e la confusione che vedo nelle PMI italiane nasce dal fatto che "AI Act diventa effettivo" è una frase senza senso: quale parte dell'AI Act, e per chi.

Le tre date che contano davvero, secondo l'Article 113 sull'entry into force, sono queste.

2 febbraio 2025. Entrano in vigore le Chapters I e II: definizioni generali, ambito di applicazione, e (la parte che ha avuto coverage media) le prohibition dell'Articolo 5 sui sistemi a rischio inaccettabile (subliminal manipulation, social scoring, certi tipi di sistema biometrico). Per la stragrande maggioranza delle PMI italiane questa data è irrilevante. Se il tuo agente non fa social scoring non sei nel perimetro.

2 agosto 2026. La data degli obblighi di trasparenza. Diventa applicabile l'Articolo 50 sulle transparency obligations per provider e deployer, entrano in funzione i poteri di enforcement della Commissione (incluse le sanzioni sui modelli GPAI), e si applicano gli articoli sulle penalties (99 e 101). Un chiarimento che genera confusione: gli obblighi sui General-Purpose AI Models (GPAI) erano già applicabili dal 2 agosto 2025, ad agosto 2026 arriva la potestà sanzionatoria della Commissione, non l'obbligo in sé. Se il tuo agente AI interagisce con persone fisiche o genera contenuto, da agosto 2026 sei obbligato a informare l'utente in modo chiaro che sta interagendo con AI e a etichettare il contenuto sintetico in modo machine-readable (per i sistemi già sul mercato la marcatura dell'Art. 50(2) ha un periodo transitorio fino al 2 dicembre 2026).

2 agosto 2027. La deadline finale per i provider di GPAI models che erano sul mercato prima del 2 agosto 2025. Hanno avuto due anni di transizione; nel 2027 devono essere fully compliant. Se usi via API un modello che era già live nel 2024, questa data riguarda il tuo provider, non te direttamente, ma le clausole contrattuali del DPA dovrebbero riflettere la sua compliance roadmap.

C'è una quarta data che vale la pena segnare: ottobre 2026. Il Governo italiano è atteso adottare decreti attuativi della legge nazionale italiana sull'AI (Law No. 132/2025, prima legge nazionale AI in EU, entrata in vigore il 10 ottobre 2025) per definire i poteri sanzionatori delle autorità nazionali. L'Articolo 20 della legge designa AgID (Agenzia per l'Italia Digitale) come notifying authority (responsabile di promozione AI plus assessment, accreditation e monitoring dei conformity bodies), e ACN (Agenzia per la Cybersicurezza Nazionale) come market surveillance authority plus single point of contact con istituzioni EU. Banca d'Italia, Consob e IVASS restano confermate come market surveillance authorities per i settori di rispettiva competenza, nei limiti consentiti dall'AI Act. Da ottobre 2026 in poi, l'enforcement italiano non è più ipotetico.

Aggiornamento giugno 2026: il Digital Omnibus sposta le date alto rischio

La timeline sopra è cambiata mentre la stavamo applicando. Il 7 maggio 2026 Consiglio e Parlamento EU hanno raggiunto un accordo politico sul Digital Omnibus, il pacchetto di semplificazione che rinvia gli obblighi più pesanti dell'AI Act. La data dei sistemi ad alto rischio standalone dell'Allegato III (recruitment, credit scoring, scoring scolastico, law enforcement) passa dal 2 agosto 2026 al 2 dicembre 2027. I sistemi ad alto rischio incorporati in prodotti regolati dell'Allegato I (dispositivi medici, macchinari, veicoli) slittano al 2 agosto 2028.

Tre precisazioni che contano per non leggere male la notizia. Primo: l'accordo è politico, prende effetto legale solo con l'adozione formale e la pubblicazione in Gazzetta Ufficiale, prevista entro il 2 agosto 2026. Secondo: gli obblighi di trasparenza dell'Articolo 50 restano al 2 agosto 2026, il rinvio riguarda l'alto rischio, non la trasparenza. Per i sistemi già sul mercato la sola marcatura dei contenuti sintetici dell'Art. 50(2) ha un periodo transitorio fino al 2 dicembre 2026. Terzo: la direzione è rinvio, non cancellazione. L'obbligo arriva, hai più tempo per arrivarci pronto, e i clienti enterprise continueranno a chiedere le stesse evidenze nelle RFP molto prima della scadenza di legge.

DORA: chi è dentro il perimetro, chi pensa di non esserlo ma lo è

DORA (Regolamento UE 2022/2554) è applicato dal 17 gennaio 2025 al settore finance EU. Banche, assicurazioni, fintech, gestori di fondi, enti previdenziali. La parte che le PMI italiane scoprono troppo tardi è che Articolo 28 sui rischi ICT third-party trascina dentro il perimetro chiunque eroghi servizi ICT a un'entità finanziaria EU regolata.

Vendi un agente AI a una banca regionale italiana? Sei ICT third-party provider. La banca DEVE tenere un Register of Information dei suoi contratti ICT, dove tu sei dentro, ed è soggetta a oversight su come ti gestisce. Plus, l'articolo 28(3) richiede che il register sia accessibile a entity-level, sub-consolidated, consolidated.

Vendi un servizio SaaS a un'assicurazione? Idem, sei ICT third-party. Vendi un'integrazione API a una società di gestione fondi? Idem.

La conseguenza pratica: se i tuoi clienti includono anche solo una entity finance EU, devi rispondere a domande DORA durante ogni rinnovo contratto, ogni RFP, ogni audit annuale. E i tuoi sub-fornitori (incluso il provider LLM che usi) sono nel perimetro indirettamente, perché DORA estende la due diligence lungo la supply chain.

Le tre domande DORA che ucciono i preventivi italiani

Sono le domande che vedo arrivare a clienti PMI mid-procurement, e che, se non hanno risposta pronta, fanno deragliare la trattativa per due-tre mesi.

Domanda uno. Qual è la vostra incident response policy, e in che modo è allineata all'Articolo 11 di DORA su ICT-related incident management? Risposta accettabile: documento policy versionato, runbook scritto, tempi di reporting documentati (DORA richiede notification entro tempi specifici), evidenze di simulazione almeno annuale. Se hai solo "ne parliamo se succede", la trattativa si ferma.

Domanda due. Come monitorate la supply chain del modello AI che usate? Risposta accettabile: hai un DPA con il tuo LLM provider che include data residency, training opt-out, retention period, notification dei cambi di modello, certificazioni di sicurezza che ha lui, piano di business continuity nel caso lui vada down. Se la risposta è "boh, usiamo OpenAI via API", la trattativa si ferma.

Domanda tre. Avete un exit strategy per ICT services che supportano critical or important functions del nostro business? Domanda che cita direttamente Articolo 28 DORA sull'exit strategy obbligatoria. Risposta accettabile: piano di transizione documentato, alternative provider identificati, procedura per estrarre dati e modelli e portarli altrove o internalizzarli, contingency measures testate. Se la risposta è "speriamo non serva", la trattativa si ferma.

Le tre domande arrivano sempre insieme, mai separate. È una checklist standardizzata che tutti i compliance officer hanno imparato a usare nel 2025.

Cosa dovresti già avere documentato

I cinque artefatti minimi che permettono di rispondere alle tre domande sopra senza panico.

Prompt registry con versioning. Il prompt di sistema dell'agente vive in un sistema versionato, ogni cambio ha autore + timestamp + reason + signed-off, c'è un log di chi ha modificato cosa quando. Mette al riparo da accuse di "l'AI ha fatto qualcosa di strano e nessuno sa perché".

IAM policy documentata per service account agente. Capability-based, scoped, con audit log delle chiamate ai tool. Risponde alla domanda "che potere ha esattamente questo agente". Approfondito nel cluster sull'articolo dedicato a least authority per AI agents.

Threat model OWASP-style mappato al tuo caso. I dieci ASI01-ASI10 della Top 10 Agentic 2026 (vedi OWASP Top 10 for Agentic Applications mappato alle PMI italiane) applicati al tuo deployment, con valutazione di likelihood + impact + mitigation in essere. Tre pagine, aggiornate ogni trimestre.

Log policy che dichiara cosa loggi e per quanto. Tradeoff GDPR Article 5 minimization vs DORA traceability documentato esplicitamente. Approfondito nel cluster su audit-ready agents logging.

Runbook di incident response. Tre step concreti (contain, document, post-mortem), responsabilità assegnate, escalation path interno + verso clienti enterprise, integration con DORA Articolo 17 reporting requirements.

Cinque documenti, tre giorni di lavoro la prima volta, mezz'ora di update mensile. Sono il prerequisito per essere production-ready in qualunque vendita verso entity finance EU dal 2025 in poi.

Plus Articolo 50: trasparenza GPAI da agosto 2026

Una nota tecnica spesso ignorata. L'Articolo 50 dell'AI Act, che diventa applicabile il 2 agosto 2026 (data confermata anche dopo il Digital Omnibus), richiede che providers e deployer informino chiaramente gli utenti quando interagiscono con un sistema AI, quando il contenuto è generato o manipolato artificialmente (incluso deepfake e public-interest text), quando vengono usati sistemi di emotion recognition o biometric categorisation. La labelling del contenuto sintetico deve essere machine-readable e detectable dove tecnicamente fattibile. Unica eccezione temporale: per i sistemi già sul mercato prima del 2 agosto 2026, l'obbligo di marcatura dell'Art. 50(2) ha un periodo transitorio fino al 2 dicembre 2026.

In termini pratici per una PMI italiana: l'agente AI di customer support deve dichiarare a inizio conversazione che è un AI. Le email autogenerate dovrebbero contenere un marker. I documenti AI-generated dovrebbero essere etichettabili tramite metadata. Sono cose semplici da implementare se le pensi prima del deploy, costose da retrofittare dopo.

Non è opzionale, e non è sanction theater: l'Articolo 99 prevede penalità fino a 15 milioni di euro o 3% del fatturato annuale globale (whichever is higher) per violazioni di obblighi di trasparenza.

La disciplina vale più della speranza

C'è una traiettoria comune nelle PMI italiane che lavorano con AI: deployano qualcosa che funziona, vendono a un primo cliente entusiasta, poi al secondo cliente arrivano le domande DORA o le clausole AI Act, e si rendono conto che non hanno carta scritta. La risposta tipica è "facciamo, intanto". Il problema è che i tre mesi che servono per produrre i cinque documenti minimi sono esattamente i tre mesi in cui la trattativa enterprise muore.

OWASP Top 10 e regolamentazione EU sono lo stesso problema visto da due angoli. La disciplina tecnica produce documenti che il legal regulatorio chiede. Chi ha già fatto il lavoro vince le gare; chi spera che le gare non arriveranno, le perde quando arrivano.

Vuoi un audit DORA-ready sul tuo agente in produzione? Il calendario è pubblico, prenota un appuntamento e parliamone. Trenta minuti gratis, poi se ha senso costruiamo insieme. Danilo Lapegna · DL Solutions