Quella che segue è la mia lettura personale di cosa sta cambiando nel software europeo nei prossimi 18-24 mesi, con riferimento ai saggi che ho scritto su ogni tema. Non è un parere legale — è il punto di vista di chi disegna architetture software che devono entrare in produzione e restare là.
Ultima revisione: 27 maggio 2026. Aggiorno questa pagina quando esce una scadenza nuova o ritorno su un punto in un saggio.
Tesi in una frase
La compliance europea 2026–2027 non si “spunta” a fine progetto: si progetta in architettura dal giorno uno, come qualsiasi altro vincolo non funzionale.
Tutto quello che segue è il ragionamento dietro questa frase.
I sei regolamenti, in un respiro
- CRA (Cyber Resilience Act) — obblighi di sicurezza per “prodotti con elementi digitali”: SBOM, gestione vulnerabilità, segnalazione incidenti, supporto per un periodo dichiarato.
- AI Act — obblighi scaglionati per sistemi AI in base al livello di rischio: modelli generali, sistemi ad alto rischio (HR, credito, giustizia), sistemi vietati, GPAI (general purpose AI).
- PLD (nuova direttiva responsabilità prodotto) — estende la responsabilità oggettiva al software: il produttore risponde dei danni da difetto indipendentemente da colpa.
- NIS2 — sicurezza informatica per entità essenziali e importanti: governance, incident reporting entro 24/72h, obblighi sulla supply chain digitale.
- EAA (European Accessibility Act) — accessibilità obbligatoria per e-commerce, ebook, banking online, biglietteria, servizi di telefonia e trasporto a partire da giugno 2025.
- DORA (Digital Operational Resilience Act) — resilienza operativa per il settore finanziario UE: gestione del rischio ICT, test di resilienza, oversight di fornitori critici di terze parti. In vigore da gennaio 2025; la sua influenza fuori dal perimetro finanziario è notevole, perché ridefinisce gli standard di operational resilience per tutta la supply chain digitale.
Sono sei regolamenti scritti in anni diversi da DG diverse con stili diversi. Ma convergono su un’idea operativa comune: il software non è più “opera dell’ingegno esente da responsabilità tecnica” — è un prodotto industriale con obblighi di conformità paragonabili a quelli di un frigorifero.
Specificità italiana — ACN. L’Agenzia per la Cybersicurezza Nazionale ha pubblicato una matrice di qualificazione (QC1–QC4) sui servizi cloud per la PA che si sovrappone a NIS2, CRA e GDPR con vincoli operativi più stretti. Per chi vende a PA italiana è una variabile non opzionale, da leggere insieme — non in alternativa — al pacchetto UE.
I miei saggi, raggruppati per regolamento
CRA, architettura, SBOM
AI Act, governance, deployer
Governance e il mestiere del software in un mondo di vincoli
Come userei questa pagina
Se sei un CTO o Head of Engineering: il mio suggerimento operativo è trattare queste scadenze come release engineering — ownership esplicito, milestone in roadmap, RACI. Non legale con code review.
Se sei un product manager: inizia dall’EAA se hai un prodotto rivolto al consumatore, dal CRA se vendi B2B. Sono i due con implicazioni di prodotto più tangibili.
Se sei una PMI software italiana: non è catastrofico, ma servono decisioni adesso su tre piani — logging/audit, SBOM, procedura incidenti. Parlo di questo direttamente in alcuni saggi che ho raccolto sopra.
Se sei un consulente advisory: la finestra per fare assessment di readiness è adesso, non quando esce il primo processo esemplare.
Fonti primarie (le letture obbligatorie)
- Cyber Resilience Act — Regolamento (UE) 2024/2847
- AI Act — Regolamento (UE) 2024/1689
- Product Liability Directive — Direttiva (UE) 2024/2853
- NIS2 — Direttiva (UE) 2022/2555
- European Accessibility Act — Direttiva (UE) 2019/882
Lavoriamo insieme
Il mio ingaggio qui non è dirti ‘ecco la norma’. È aiutarti a trasformare sei regolamenti europei in una serie di scelte architetturali ordinate, con una roadmap e un ownership interno. Il legale resta necessario, ma non è il posto giusto dove cominciare.
Per chi è utile
CTO e Head of Engineering di software vendor e SaaS che operano sul mercato UE
Product manager che devono capire cosa cambia nel loro prodotto prima di pianificare i prossimi quattro trimestri
Fondatori di PMI tech che si accorgono che la scadenza CRA è troppo vicina per essere ignorata
Compliance officer che vogliono tradurre i requisiti in backlog e non in policy PDF
Come lavoro
- Assessment di readiness (2–4 settimane)
Prendo il prodotto, la pipeline e la supply chain e li confronto con i requisiti CRA, AI Act, PLD, NIS2, EAA e DORA applicabili. Output: una mappa dei gap con priorità, effort stimato e suggerimenti di design-in.
- Disegno del piano di compliance (3–6 settimane)
Dall’assessment alla roadmap. Chi fa cosa, con quali milestone misurabili, con quali milestone sincronizzate con le scadenze UE. Un documento che un board può approvare e un team può eseguire.
- Seconda opinione su RFP e fornitori (1–2 settimane)
Leggo un contratto con un fornitore o una proposta di acquisto e ti dico se la catena di responsabilità regge al nuovo PLD e al CRA. Utile prima di firmare.
Domande operative
- Sei un avvocato?
No. Sono un architetto di sistemi che lavora con team legali. Il mio output è operativo: diagrammi di flusso, RACI, backlog. Il parere giuridico lo dà il tuo avvocato.
- Lavori anche con singoli articoli (es. solo AI Act)?
Sì, ma con riluttanza. I sei regolamenti interagiscono in modo sottile (per esempio CRA e PLD, o AI Act e NIS2, o NIS2 e DORA). Guardarne uno solo spesso nasconde costi che emergono sul secondo.
- Quanto dura un ingaggio tipico?
Due–sei settimane per un assessment o una review, due–tre mesi per un piano di compliance completo.
- Fai delivery o audit di certificazione?
No a entrambi. L’advisory è indipendente proprio perché non ha incentivo a venderti lavoro di delivery. Per la certificazione ti indirizzo a organismi accreditati.
Scrivimi a hello@margiovanni.it con due righe di contesto. Rispondo entro qualche giorno lavorativo con una proposta concreta o un cortese no se non è il mio perimetro.
Vuoi essere avvisato quando aggiorno questa pagina?
L’RSS IT segnala ogni aggiornamento ai saggi principali. Per conversazioni più dirette, scrivimi: hello@margiovanni.it.
Domande e risposte
Quali regolamenti europei impattano il software nel 2026–2027?
Sei: Cyber Resilience Act (CRA), AI Act, Product Liability Directive (PLD), NIS2, European Accessibility Act (EAA), DORA (settoriale, finanza). Entrano in vigore in momenti diversi tra il 2024 e il 2027 ma producono effetti cumulati che ridisegnano l’architettura del software europeo.
La compliance è un problema legale o di ingegneria?
Entrambi, ma viene sistematicamente sottovalutato l’aspetto ingegneristico. Questi regolamenti sono vincoli di sistema — scadenze di consegna di funzionalità (log, audit, SBOM, accessibilità) con una data obbligatoria. Trattarli come burocrazia da sistemare a fine progetto costa 5-10× design-in a monte.
A chi si applica il Cyber Resilience Act?
A qualsiasi ‘prodotto con elementi digitali’ venduto sul mercato UE: software commerciale, firmware, dispositivi connessi, SDK. Molti saas rientrano nella categoria. La prima ondata di obblighi (rapporto incidenti) scatta a settembre 2026, il grosso a dicembre 2027.
Il mio software non è AI: l'AI Act mi riguarda?
Potenzialmente sì. L’AI Act si applica anche ai fornitori di sistemi che integrano AI di terzi (API OpenAI, Claude, Gemini ecc.), e ai ruoli di ‘deployer’ — chi usa AI per prendere decisioni su persone (HR, credito, welfare). Le scadenze vanno da febbraio 2025 ad agosto 2027.
Posso iniziare dopo, quando ci sono più esempi?
No. Design-in di compliance richiede scelte architetturali (logging, data retention, SBOM, accessibilità) che diventano molto costose da retrofittare. Chi aspetta ‘di vedere come fanno gli altri’ paga il doppio.