DORA · EU AI Act · L. 132/2025 · contesto regolatorio
Il punto di attrito normativo non è trasformare il codice — è dimostrare che il cambiamento è stato governato, tracciabile e non ha degradato la resilienza. Questa pagina mappa, requisito per requisito, l'evidenza che CATALYST produce oggi e cosa resta al cliente. Aggiornata a ottobre 2026, pensata per Risk & Compliance Officer e auditor esterni: stampabile in A4, deep-linkable articolo-per-articolo (#dora-art-28, #ai-art-14, ecc.).
DORA — Regolamento UE 2022/2554
Digital Operational Resilience Act. Pienamente applicabile dal 17 gennaio 2025, senza periodo di grazia formale. Le sanzioni le fissano gli Stati membri (Art. 50): in Italia il D.Lgs. 23/2025 prevede da €30.000 fino al 10% del fatturato per banche e assicurazioni (7% per un secondo gruppo di articoli, tra cui i 28-30 sulle terze parti ICT), applicabili anche ai loro fornitori terzi di servizi ICT; per i fornitori critici (CTPP), penalità giornaliere fino all'1% del fatturato medio mondiale per max 6 mesi (Art. 35). Vigilano Banca d'Italia sulle banche e IVASS sulle assicurazioni. In una migrazione pesano soprattutto la valutazione dei sistemi legacy (Art. 8, par. 7), change management e test (Art. 9, 24-25, RTS 2024/1774) e le terze parti ICT, CATALYST incluso (Art. 28-30). Mappatura articolo-per-articolo ai domini operativi del framework.
| Articolo | Requisito | Contributo di CATALYST |
|---|---|---|
| Art. 6 | Quadro di gestione del rischio ICT, approvato dall'organo di gestione (Art. 5) | Il programma entra nel quadro del cliente con un perimetro documentato: inventario delle applicazioni e delle dipendenze, gate di fase con soglie dichiarate, decisioni e bypass registrati con motivazione e autore. Approvazione e registro dei rischi restano del cliente. |
| Art. 8 | Identificazione degli asset e valutazione dei sistemi legacy (par. 7) | Inventario delle applicazioni, mappa delle dipendenze fra app e librerie condivise e, per ogni app, l'enumerazione degli elementi nel contratto di Fase 1 (DISCOVER): la base tecnica per la valutazione del rischio che il par. 7 impone sui sistemi legacy almeno ogni anno e prima e dopo ogni collegamento o modifica, migrazione inclusa. Criticità e funzioni di business le assegna il cliente. |
| Art. 9 | Protezione e prevenzione · change management (par. 4, lett. e; RTS 2024/1774 Art. 16-17) | Ogni change passa da gate deterministici di fase e da un sign-off umano separato da chi implementa; i bypass richiedono motivazione e autore. Gli hook impediscono ai tool di scrittura di uscire dal perimetro autorizzato e di toccare il codice legacy. Fallback del cutover, log centralizzati e controlli di rete restano nell'ambiente del cliente. |
| Art. 17-20 | Gestione, classificazione e notifica degli incidenti ICT | Non è un output CATALYST: classificazione (RTS 2024/1772) e notifica nelle finestre DORA (4h/72h/1 mese, RTS 2025/301) restano del cliente. Per l'analisi delle cause, i contratti di fase registrano quale skill o agent ha prodotto ogni artefatto e quando, e il codice migrato è versionato. |
| Art. 24-25 | Programma di test (incl. source code review statica e dinamica, RTS 2024/1774 Art. 16) | Audit semantico statico legacy↔migrato elemento per elemento (verifier read-only), contratto di copertura a 3 stati, build e controlli deterministici, sign-off del business owner. Il confronto a runtime legacy↔migrato lo esegue il cliente in pre-produzione. Output di VALIDATE: non una prova matematica, un pacchetto di evidenze ispezionabile. |
| Art. 26 | TLPT (Threat-Led Penetration Testing), per le entità designate, almeno ogni 3 anni | Non è un output CATALYST: charter, threat intelligence e red team sono del cliente e dei suoi tester (TIBER-IT). CATALYST fornisce la documentazione della superficie applicativa migrata. |
| Art. 28 | Rischio da terze parti ICT (Register of Information) | KVA fornisce i dati per le voci del Register of Information del cliente: se stessa come fornitore ICT e il provider del modello (diretto o come subfornitore, con LEI e localizzazione dei dati). Due diligence, concentration risk e submission xBRL-CSV restano del cliente. |
| Art. 29 | Concentration risk + exit plan | Asset di modernizzazione in formati aperti (contratti YAML, knowledge base Markdown, AGENTS.md / CLAUDE.md, MCP) e dipendenza dal provider LLM tracciata nel registro (Art. 28): la base per l'exit plan del cliente, che ne fissa RTO/RPO e ne testa le alternative. Deployment raccomandato: Claude via AWS Bedrock in UE; alternativa Mistral on-prem documentata, non ancora eseguita. |
| Art. 30 | Contractual key provisions | Contratto con clausole Art. 30(2)(3) per servizi CIF: location, audit right, security, sub-contracting, exit, incident notification. Template di MSA appendix (a cura legale Excellence). |
EU AI Act — Regolamento UE 2024/1689
Pratiche vietate in vigore dal 2 febbraio 2025 e obblighi GPAI dal 2 agosto 2025. Gli obblighi high-risk erano fissati al 2 agosto 2026: il Digital Omnibus (Reg. UE 2026/1744, in vigore dal 27 luglio 2026) li ha differiti al 2 dicembre 2027 per i sistemi Annex III e al 2 agosto 2028 per l'IA integrata nei prodotti. Le scadenze di DORA e NIS2 non sono cambiate. Non-conformità high-risk sanzionata fino al 3% del turnover globale (€15M); pratiche vietate fino al 7% (€35M). Il primo standard armonizzato (EN 18286, sul QMS) è approvato da luglio 2026 ma non ancora citato in OJEU: nessuna presunzione di conformità disponibile.
Sistema migrato deterministico
Un gestionale, un motore a regole definite da persone, un batch: non sono sistemi AI ai sensi dell'Art. 3, quindi l'AI Act non impone requisiti sul sistema migrato e gli articoli in tabella non si applicano. CATALYST mantiene comunque tracciabilità e supervisione umana, come buona pratica e per DORA.
Il sistema migrato è AI Annex III
Scoring creditizio (punto 5b), valutazione del rischio e pricing vita/salute (5c), selezione del personale (4) basati su modelli: dal 2 dicembre 2027 valgono gli Art. 9-15 e 17, l'Annex IV e, per il deployer, la FRIA. Sono obblighi del cliente come provider o deployer; CATALYST fornisce le evidenze in tabella.
L'agent che esegue la migrazione
Non è un sistema high-risk: scrive codice, non decide sulle persone. Gli obblighi GPAI (Art. 53-55) sono del provider del modello, Anthropic, firmataria del Code of Practice. La review umana del codice generato è governance della migrazione (Principio 02, L. 132/2025), non la supervisione dell'Art. 14.
| Articolo | Requisito (sistema AI high-risk) | Contributo di CATALYST |
|---|---|---|
| Art. 9 | Sistema di gestione dei rischi del sistema AI, mantenuto dal provider | Inventario, mappa delle dipendenze e decisioni registrate nei contratti come input sui rischi introdotti dal cambiamento. |
| Art. 10 | Dati di addestramento, validazione e test del modello | Solo se la migrazione tocca i dati o il ri-addestramento del modello. Le trace usate per la parità vanno documentate, ma non sono dati di addestramento. |
| Art. 12 | Registrazione automatica degli eventi da parte del sistema in esercizio | Requisito del sistema migrato, non della migrazione: il logging va preservato e verificato nella parità. I contratti di fase documentano invece lo sviluppo (Annex IV). |
| Art. 13 | Trasparenza e istruzioni per l'uso destinate al deployer | La documentazione prodotta in DOCUMENT alimenta le istruzioni d'uso aggiornate. |
| Art. 14 | Supervisione umana sul sistema in uso, progettata dal provider | Le misure di supervisione del sistema (override, arresto, lettura degli output) vanno preservate e verificate nella parità. La review umana del codice generato dall'agente è un'altra cosa: governance della migrazione, non Art. 14. |
| Art. 15 | Accuratezza, robustezza, cybersicurezza | La parità (audit statico + validazione del cliente) documenta che il sistema migrato mantiene i livelli dichiarati; SECURE copre la cybersicurezza. |
| Art. 17 | Sistema di gestione della qualità del provider | Gate, contratti e controlli documentati di CATALYST alimentano la parte progettazione, sviluppo e verifica del QMS (Art. 17, par. 1, lett. b-d). Lo standard di riferimento è EN 18286, non ancora citato in OJEU. |
| Art. 27 | FRIA — valutazione d'impatto sui diritti fondamentali: obbligo del deployer per scoring creditizio e pricing vita/salute, per la PA e per chi fornisce servizi pubblici | La compila il cliente: CATALYST fornisce gli elementi tecnici sul sistema migrato, il DPO e la Compliance del cliente quelli legali. |
| Art. 111 | Sistemi high-risk già in servizio prima del 2 dicembre 2027 | Restano fuori dagli obblighi finché il design non cambia in modo significativo; per le PA l'adeguamento resta dovuto entro il 2 agosto 2030. Una migrazione che riprogetta il sistema può farlo rientrare: la Discovery lo valuta caso per caso. |
| Annex IV | Documentazione tecnica del sistema high-risk (Art. 11) | Gli output dei 5 domini coprono la descrizione del processo di sviluppo (punto 2) e alimentano il fascicolo, che il cliente assembla e conserva per 10 anni (Art. 18). |
Legge 132/2025 — responsabilità umana non delegabile
In vigore dal 10 ottobre 2025. Legge-quadro che ripartisce i ruoli sull'AI tra AgID (promozione, notifica, accreditamento) e ACN (vigilanza, ispezione, sanzione), e codifica il principio che la responsabilità umana non è delegabile. È il fondamento normativo del modo in cui CATALYST opera: l'AI propone, i gate deterministici e il sign-off umano dispongono.
Responsabilità umana non delegabile
Per la PA l'Art. 14 la rende esplicita: chi firma l'atto ne resta pienamente responsabile anche se prodotto con l'AI — principio già affermato da Consiglio di Stato sent. 4857/2025. CATALYST la operazionalizza in ogni engagement: verifier read-only (l'agente non spedisce da solo), review umana tipizzata per livello di rischio (Principio 02) e sign-off di parità. Da dichiarare esplicitamente nei contratti di engagement.
Settori toccati dalla legge nazionale
Articolo 14 PA, articoli 7-8 sanità, articoli 11-12 lavoro, articolo 13 professioni, articolo 25 copyright, articolo 26 (nuovo Art. 612-quater C.P. su deepfake illeciti). Tassonomia rilevante per gli engagement adiacenti (PA, Sanità) coperti dal framework.
Complementare, non sostitutiva
La legge italiana integra il Regolamento UE 2024/1689 senza creare nuovi obblighi per sistemi e modelli di IA (Art. 3, c. 5): stessi principi di trasparenza, supervisione umana e accuratezza, declinati per il contesto nazionale e i suoi settori.
Altro contesto regolatorio
DORA, EU AI Act e L. 132/2025 sono il cuore regolatorio di una migrazione assicurata. Il quadro si completa con la cybersicurezza (NIS2), le autorità di settore (Banca d'Italia, IVASS, AgID per la PA), la protezione dei dati (GDPR) e i dati di rischio delle banche (BCBS 239): qui in forma sintetica, sempre con l'evidenza che CATALYST produce.
Cybersicurezza e supply chain
In vigore dal 16 ottobre 2024 (autorità ACN); misure di sicurezza di base da adottare entro ottobre 2026. Nel finanziario prevale DORA, ma le banche inviano le notifiche degli incidenti anche a CSIRT Italia (D.Lgs. 23/2025) e le entità non-financial della supply chain restano sotto NIS2. Modernizzare uscendo dai runtime EOL abbassa la superficie d'attacco; la toolchain AI resta a superficie minima. Output: audit trail delle decisioni dell'agente, documentazione della catena di fornitura.
Governance ICT delle banche
Il 51° aggiornamento (3 feb. 2026) rinvia a DORA e abroga le sezioni duplicate del Titolo IV, Parte I: sistema informativo, rischio ICT e sicurezza, change management, outsourcing ICT. CATALYST produce quindi direttamente le evidenze DORA. Banca d'Italia riceve le notifiche dei gravi incidenti ICT delle banche.
DORA per le assicurazioni
Autorità competente DORA per le imprese di assicurazione e riassicurazione (art. 3): riceve le notifiche dei gravi incidenti ICT (art. 4) e sanziona secondo il Codice delle assicurazioni, fino al 10% del fatturato (art. 310 CAP). In un gruppo bancario-assicurativo le stesse evidenze CATALYST servono a entrambe le vigilanze.
AI nella PA
Linee guida per l'adozione dell'IA nella PA (Det. 17/2025) e per sviluppo e procurement (Det. 43/2026, consultazione chiusa l'11 aprile 2026): i criteri con cui la PA sceglie e controlla un fornitore AI. Con l'Art. 14 della L. 132/2025 sono il punto di ingresso per gli engagement pubblici.
Dati by design, garanzie preservate
In pre-produzione DORA ammette solo dati anonimizzati, pseudonimizzati o randomizzati, salvo occasioni approvate (RTS 2024/1774, Art. 16): vale anche per le trace della validazione, che il cliente esegue nel proprio ambiente. Minimizzare i dati nei prompt è una regola di processo (Art. 25/32); il mascheramento automatico dei valori è pianificato. L'Art. 22 riguarda il sistema migrato quando decide in automatico sulle persone (es. credito): la parità deve preservarne le garanzie, come l'intervento umano. Il provv. Garante 755/2024 (OpenAI) è stato annullato dal Tribunale di Roma (sent. del 18 marzo 2026) per incompetenza, senza esame nel merito.
Dati di rischio delle banche
Principi su aggregazione e reporting dei dati di rischio, che la BCE si aspetta dalle banche significative. Contano quando la migrazione tocca la catena del risk reporting: la parità protegge completezza e accuratezza dei numeri, e il lineage legacy↔migrato va documentato.