Compliance eu 2026: è architettura, non solo legale

Mi capita spesso una scena che ormai riconosco al primo minuto. Qualcuno nomina la compliance, magari in una riunione di progetto o durante una call con un cliente un po’ più strutturato, e la risposta arriva quasi automatica.

"ci pensa il legale".

Non lo dico per fare il cinico. È proprio che quella frase, nel 2026, rischia di diventare una delle più costose che un’azienda software europea possa pronunciare.

Perché quello che sta arrivando non assomiglia a un aggiornamento di policy o a un giro di informative. Assomiglia di più a un cambio di fondamenta. E, cosa ancora più scomoda, ha delle scadenze molto ravvicinate.

## La tempesta perfetta: cinque scadenze in un arco troppo corto

Se fai software per il mercato europeo, il calendario non è più un dettaglio da tenere in un file condiviso. È una timeline che ti entra in architettura.

Tra la fine del 2024 e il 2026 si addensano normative che, prese singolarmente, potresti anche gestire con fatica. Insieme, però, si incastrano apposta.

Nis2 è già in vigore da ottobre 2024 e ha allargato il perimetro di chi deve prendersi sul serio la cybersecurity, inclusa la supply chain. E qui spesso scatta la prima sorpresa: non serve essere “critici” per sentirne gli effetti. Basta essere fornitori di qualcuno che lo è.

L’european accessibility act è già operativo da giugno 2025 e, al netto di come verrà interpretato nei vari contesti, sposta l’accessibilità dal mondo dei “miglioramenti” al mondo dei “requisiti”.

Poi arriva il 2026, che è l’anno in cui si stringe il nodo.

Ad agosto 2026 l’ai act entra in piena applicazione per i sistemi ad alto rischio. Non è solo una questione di etica o di trasparenza. Parliamo di valutazioni di conformità, documentazione tecnica, governance dei dati, supervisione umana. E sì, anche di sanzioni reali, fino al 3% del fatturato globale o 15 milioni.

A settembre 2026 il cyber resilience act porta obblighi che, per come sono scritti, non puoi “aggiungere dopo”. Tra questi c’è la segnalazione di vulnerabilità attivamente sfruttate entro 24 ore e di incidenti gravi entro 72 ore. E la parte che molti sottovalutano è questa: non vale solo per i prodotti futuri. Vale anche per quello che hai già sul mercato. Legacy incluso.

A dicembre 2026 la product liability directive ridefinisce cosa sia un “prodotto” nell’era digitale. Il software, anche standalone o in forma saas, diventa prodotto a tutti gli effetti, con responsabilità oggettiva. I bug smettono di essere solo un fastidio operativo e diventano potenzialmente un difetto del prodotto, con conseguenze legali dirette. E la responsabilità non finisce al rilascio, finisce quando non hai più la capacità di fornire aggiornamenti.

E sullo sfondo resta il gdpr, che non se n’è mai andato, con un enforcement sempre meno timido.

Forse la cosa più destabilizzante è che queste norme non si sommano in modo lineare. Si *rinforzano*.

## L’errore fondamentale: trattare la compliance come un layer esterno

La reazione più comune è comprensibile: “chiamiamo il consulente, aggiorniamo le policy, mettiamo a posto la documentazione, facciamo le checklist”. È l’approccio che potremmo chiamare compliance-as-paperwork.

Con il gdpr, per quanto spesso fatto male, questa strategia a volte reggeva. Potevi incollare sopra un sistema esistente una serie di processi, informative, registri, ruoli.

Con il pacchetto 2026 non regge più. E non perché manchi la buona volontà. Perché ci sono requisiti che, se non sono supportati dalla tua architettura e dal tuo modo di costruire e rilasciare software, semplicemente non esistono.

Prendiamo il caso più concreto possibile: per rispettare il cra, quando emerge una vulnerabilità sfruttata attivamente, devi poter reagire e segnalare nei tempi previsti. Ma per farlo devi sapere con precisione cosa c’è dentro il tuo prodotto. Non “più o meno”. Proprio *esattamente*.

Dipendenze dirette, transitive, componenti, versioni, build. Tutto.

Questo ti porta dritto a un oggetto che non è legale e non è burocratico: la sbom, software bill of materials. E non una sbom in pdf generata una volta per far contento qualcuno. Una sbom viva, rigenerata a ogni build, in formato leggibile dalle macchine, integrata nella pipeline.

Se il tuo processo di build non produce una sbom come output naturale, non è che “sei un po’ indietro con la compliance”. È che non puoi esserlo, punto.

E qui secondo me si chiarisce la frase più importante di tutto questo discorso: la compliance non è un requisito che aggiungi. È una proprietà emergente della tua architettura.

## Compliance come vincolo architetturale

In architettura software siamo abituati ai vincoli. Latenza, disponibilità, scalabilità, compatibilità, costi. Sono cose che restringono lo spazio delle soluzioni possibili.

Ecco, la compliance eu 2026 è un vincolo architetturale. Non un ticket da assegnare “a fine progetto”, non un documento da produrre “prima della gara”. Un vincolo che attraversa il sistema.

E quando lo guardi così, alcune conseguenze diventano quasi ovvie.

### L’observability non è più un extra

L’ai act, per certi sistemi, richiede log e tracciabilità. Il cra ti spinge verso capacità di rilevazione e risposta. La pld ti mette nella posizione di dover dimostrare lo stato del software al momento dell’incidente.

Se non hai audit trail sufficienti, non è che “monitori poco”. Stai costruendo un sistema che non riesce a sostenere le domande che il mercato e le norme ti faranno.

### La gestione delle dipendenze diventa un processo critico

Per anni abbiamo normalizzato l’idea che aggiornare librerie sia un lavoro “da quando avanza tempo”. Un `npm install` fatto di fretta, un lockfile che nessuno guarda, un aggiornamento rimandato perché “tanto funziona”.

Con cra e nis2, questa leggerezza diventa rischio di supply chain. E il rischio di supply chain, nel 2026, non resta confinato al reparto tecnico. Si propaga a contratti, gare, partnership.

La domanda a cui devi saper rispondere è molto semplice e molto dura: “questo cve appena uscito impatta i nostri prodotti in produzione?”. E la risposta deve arrivare in minuti o ore, non in settimane.

### Il concetto di “prodotto finito” si sfalda

La pld e il cra, insieme, rendono meno credibile l’idea che un rilascio chiuda un capitolo. Rilasciare diventa l’inizio di una relazione a lungo termine con un sistema che va mantenuto, monitorato, curato.

Questo cambia anche il modo in cui stimiamo, pianifichiamo, vendiamo. Perché una parte del valore, e della responsabilità, vive dopo la consegna.

### L’accessibilità è una proprietà del design system

L’eaa non è gentile con i retrofit. Se hai un design system accessibile by default, hai un vantaggio strutturale. Se devi “rendere accessibile” un frontend cresciuto per anni senza regole, la quantità di finding che ti torna indietro può diventare ingestibile.

E qui mi chiedo spesso se non stiamo sottovalutando quanto l’accessibilità sia, in realtà, una forma di standardizzazione interna. Non solo un requisito esterno.

### La human oversight non è un bottone

Uno dei fraintendimenti più comuni sull’ai act è pensare che “supervisione umana” significhi aggiungere un passaggio di approvazione alla fine.

In pratica, è un tema di flussi: dove l’umano può intervenire, con quali informazioni, con quale possibilità di override, e con quale tracciabilità. È architettura del processo decisionale, prima ancora che architettura software.

## L’intersezione che molti non stanno guardando

Il punto più interessante, e forse più pericoloso, non sono i singoli obblighi. È come si incastrano.

La pld dice che un prodotto software è difettoso se non soddisfa i requisiti di sicurezza informatica applicabili. Il cra definisce una parte importante di quei requisiti. L’ai act aggiunge requisiti specifici quando c’è ai.

Quindi la mancata compliance con il cra può diventare un *difetto di prodotto* ai sensi della pld.

Non stiamo più parlando solo di una multa amministrativa o di una non conformità “da sistemare”. Stiamo parlando di responsabilità civile per danni, con dinamiche come l’inversione dell’onere della prova.

E per difenderti, devi poter dimostrare che il prodotto era conforme al momento dell’incidente. Che, di nuovo, ti riporta a sbom, audit trail, logging, documentazione tecnica. Non come teatro della compliance, ma come architettura difensiva.

## Il paradosso italiano: fragili, ma veloci

Qui entra un pezzo che sento molto vicino, perché è la realtà quotidiana di tante aziende con cui parlo.

Il tessuto software italiano è fatto in gran parte di pmi: team da 5 a 20 persone, prodotti verticali, crescita per stratificazione, roadmap dettata dai clienti, debito tecnico accumulato con la logica del feature-first.

Molte di queste aziende sono impreparate. Non per incapacità, ma per struttura.

Eppure c’è un paradosso: la stessa struttura che le rende vulnerabili può trasformarsi in vantaggio.

Un’azienda di 10 persone, se decide davvero, può ridisegnare pezzi importanti della propria architettura in 12 mesi. Una grande organizzazione spesso impiega mesi solo per capire cosa ha in produzione.

Un team piccolo conosce il proprio dominio e il proprio prodotto in modo intimo. Può fare una gap analysis realistica in settimane.

E un founder-cto che investe oggi in compliance-by-design può muoversi in una finestra che, tra 18 mesi, sarà già chiusa. Non perché sarà impossibile, ma perché sarà troppo tardi per farlo con calma.

## Compliance-by-design: decisioni architetturali, non slogan

Quando dico compliance-by-design non intendo “fare le cose per bene” in modo generico. Intendo scelte concrete che puoi iniziare a fare adesso, anche senza rivoluzionare tutto.

La sbom come artefatto di prima classe, per esempio. Ogni build produce una sbom in formato cyclonedx o spdx. La pipeline la genera, la conserva, la confronta con database di vulnerabilità, e se serve blocca un deploy. Strumenti come syft, grype o trivy rendono questa cosa molto più accessibile di quanto sembri.

Poi c’è l’audit trail, ma non quello dei log di sistema. Un audit trail di dominio: chi ha fatto cosa, quando, perché, con quale ruolo, in quale contesto. Può essere event sourcing o un append-only log, ma l’idea è che sia un cittadino di prima classe del modello dati.

La documentazione tecnica come codice è un altro punto chiave. Se la documentazione vive in un wiki aggiornato a mano, prima o poi smette di rappresentare la realtà. Se invece usi adr versionati, specifiche dichiarative, e documentazione generata dal codice, allora la documentazione diventa un sottoprodotto inevitabile del lavoro.

E il vulnerability management non può essere un evento annuale. Deve essere un processo continuo: scanning automatico, triage, remediation con tempi definiti. Quando arriva la segnalazione di una vulnerabilità sfruttata, il sistema deve aiutarti a reagire in ore.

Sull’accessibilità, la cosa che ho visto funzionare davvero è trattarla come design token e come regola del design system. Se i componenti nascono accessibili, il prodotto tende a restarlo. Se devi correggere dopo, ogni nuova schermata aggiunge debito.

## Ai-native development come acceleratore, non solo come rischio

C’è una piccola ironia nel fatto che l’ai act arrivi mentre l’ai sta cambiando il modo in cui scriviamo software.

Molti vedono lo sviluppo ai-native come un rischio per la compliance: più codice generato, meno controllo. Io sospetto che, in molti casi, sia vero il contrario.

Un approccio spec-driven, dove il software nasce da specifiche dichiarative leggibili e verificabili, è *intrinsecamente* più favorevole alla conformità. Perché le specifiche sono documentazione. Perché sono versionate. Perché rendono esplicite assunzioni che altrimenti restano nella testa di chi ha scritto quel pezzo di codice due anni fa.

Strumenti come file di progetto tipo claude.md, speckit, pipeline che generano artefatti di compliance come parte del flusso, non sono fantascienza. Sono un modo diverso di lavorare, che può rendere più facile produrre evidenze, tracciabilità, ricostruibilità.

Forse il futuro non è “scrivere più documentazione”. È costruire software in modo che la documentazione sia inevitabile.

## Il vero costo della non conformità è molto più vicino di una multa

Le sanzioni fanno impressione, ma per molte pmi restano astratte. Non è la paura della multa che cambia le priorità.

Il costo reale è più quotidiano.

È il bando pubblico a cui non puoi partecipare perché non soddisfi i requisiti di sicurezza del capitolato.

È il cliente enterprise che ti chiede la sbom e tu non sai da dove cominciare.

È un partner che fa supply chain risk management e ti esclude dalla shortlist.

È un incidente che non riesci a gestire nei tempi previsti dal cra e che si incastra in un contesto di responsabilità più duro.

Per molte aziende italiane, questi non sono scenari teorici. Sono cose che assomigliano molto al 2027.

## La finestra è adesso, e in fondo parla di buona ingegneria

Da architetto software, con la testa spesso divisa tra roadmap, budget, debito tecnico e richieste del mercato, capisco bene che tutto questo possa sembrare schiacciante.

Però c’è un aspetto che vale la pena tenere in primo piano: molte delle pratiche richieste da queste normative sono semplicemente buona ingegneria.

Generare una sbom è buona ingegneria. Avere un audit trail è buona ingegneria. Gestire le vulnerabilità delle dipendenze è buona ingegneria. Documentare le decisioni architetturali è buona ingegneria. Costruire interfacce accessibili è buona ingegneria.

Quello che la compliance eu 2026 sta facendo, forse, è rendere obbligatorio ciò che avremmo dovuto fare comunque. Sta trasformando le best practice in baseline.

E sta creando un mercato in cui chi tratta la compliance come un problema architetturale, e non come una pratica da demandare al legale, si ritrova con software più robusto, più manutenibile e anche più vendibile.

La finestra per costruire quel vantaggio è aperta ora. Tra diciotto mesi, chi non ha iniziato rincorrerà. Chi inizia adesso, probabilmente, si ritroverà dall’altra parte.