---
title: "Cybersecurity Act 2, Cyber Resilience Act e AI Act: perché dicembre 2027 è una sola scadenza"
url: https://zerofive.ai/blog/compliance/cybersecurity-act-2-cra-ai-act-dicembre-2027
canonical: https://zerofive.ai/blog/compliance/cybersecurity-act-2-cra-ai-act-dicembre-2027
language: it
published: 2026-09-06
updated: 2026-09-18
author: "ZeroFive.AI"
tags: Cyber Resilience Act, Cybersecurity Act 2, AI Act, NIS2, supply chain ICT
abstract: "CRA dall'11 settembre 2026, AI Act dal 2 dicembre 2027, piena applicazione CRA dall'11 dicembre. Perimetro, impatti e sequenza operativa."
---

# Cybersecurity Act 2, Cyber Resilience Act e AI Act: perché dicembre 2027 è una sola scadenza

Un cliente ci ha scritto in agosto per chiederci se il Cyber Resilience Act lo riguardasse, visto che il suo prodotto è un gestionale in cloud e non un dispositivo connesso. La risposta ha richiesto una telefonata di quaranta minuti, perché la domanda giusta non era quella. Quel gestionale incorpora un assistente conversazionale fornito da terzi, viene distribuito con il marchio dell'azienda e serve un processo di selezione del personale. Tre normative diverse lo toccano, e due di esse chiudono a nove giorni di distanza.

Tra l'11 settembre 2026 e il dicembre 2027 il quadro europeo su sicurezza dei prodotti digitali e intelligenza artificiale si salda. Chi produce, integra o acquista software con componenti AI ha davanti obblighi che sembrano appartenere a mondi separati e che invece condividono documentazione, evidenze e responsabilità. Questo articolo ricostruisce che cosa è stato proposto il 20 gennaio 2026, che cosa diventa applicabile adesso, chi rientra davvero nel perimetro e quali decisioni conviene prendere prima di firmare il prossimo contratto di fornitura. In fondo trovate un vocabolario di tutti gli acronimi e dei termini tecnici usati, perché in questa materia la barriera d'ingresso è quasi sempre lessicale.

![Convergenza dicembre 2027: calendario CRA e AI Act, ponte dell'articolo 12 e catena di fornitura del Cybersecurity Act 2](/csa2-cra-ai-act-dicembre-2027-it.png)

## Undici settembre, due dicembre, undici dicembre

La prima scadenza è già arrivata. Dall'11 settembre 2026 diventa applicabile l'articolo 14 del Cyber Resilience Act, e i produttori di prodotti con elementi digitali immessi sul mercato europeo devono segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi secondo tempistiche molto strette.

La seconda arriva il 2 dicembre 2027, quando si applicano gli obblighi dell'AI Act per i sistemi ad alto rischio dell'Allegato III, secondo il calendario riscritto dal Regolamento (UE) 2026/1744, pubblicato in Gazzetta ufficiale il 24 luglio 2026 ed entrato in vigore il terzo giorno successivo alla pubblicazione.

La terza cade l'11 dicembre 2027, con la piena applicazione del Cyber Resilience Act e dei requisiti essenziali di cybersicurezza del suo Allegato I.

Nove giorni separano le due scadenze piene. Per un'azienda che sviluppa o integra software con componenti di intelligenza artificiale destinati al mercato europeo questo significa una sola finestra di preparazione e un solo budget, anche quando la governance interna oggi tratta i due temi in direzioni separate e con due responsabili che non si parlano.

## Che cosa è successo il 20 gennaio 2026

Quel giorno la Commissione europea ha presentato un pacchetto cyber composto da due proposte legislative collegate. La prima sostituisce il Cybersecurity Act del 2019 con un nuovo Cybersecurity Act 2, la seconda modifica in modo mirato la direttiva NIS2 allineandola alla prima.

Il testo di riferimento della prima proposta è COM(2026) 11, che riguarda l'agenzia europea per la cybersicurezza, il quadro europeo di certificazione e la sicurezza della catena di fornitura ICT, e che abroga il Regolamento (UE) 2019/881. Il secondo testo è COM(2026) 13, proposta di direttiva su misure di semplificazione e allineamento al Cybersecurity Act.

La Commissione descrive la proposta principale attraverso quattro blocchi costitutivi: un quadro orizzontale per la sicurezza della catena di fornitura ICT che affronta anche le dipendenze strategiche e i rischi di interferenza straniera, un quadro europeo di certificazione semplificato e potenziato, misure di semplificazione collegate all'attuazione di NIS2, e un mandato rafforzato per l'agenzia.

Sul ruolo dell'agenzia la proposta interviene in profondità. ENISA verrebbe abilitata a emettere allerte precoci su minacce e incidenti, a gestire repository europei di minacce e incidenti, a operare una piattaforma unificata di notifica, a supportare le organizzazioni nella risposta e nel recupero da attacchi ransomware e a contribuire allo sviluppo degli schemi di certificazione. È il passaggio da agenzia di coordinamento a centro operativo europeo della cybersicurezza, con tutto quello che comporta in termini di aspettative sulla velocità di risposta.

## La parte che cambia le regole del procurement

Il blocco sulla catena di fornitura merita attenzione da parte di chiunque acquisti tecnologia, non solo da parte di chi la produce, e questo è il motivo per cui il tema entra a pieno titolo nella governance dell'intelligenza artificiale.

La proposta esce dal perimetro della cybersicurezza come tradizionalmente intesa nel diritto dell'Unione. Avrebbe conseguenze rilevanti per diciotto settori critici e per i loro fornitori ICT, con implicazioni ampie sul commercio internazionale e sui rapporti con i partner commerciali. È la prima volta che l'Unione utilizza uno strumento vincolante per imporre restrizioni commerciali fondate su ragioni geopolitiche e di sicurezza nazionale con effetti sulle catene di fornitura tecnologica dei settori critici.

Il meccanismo funziona così. La Commissione verrebbe abilitata a designare paesi terzi come portatori di preoccupazioni di cybersicurezza e a classificare come ad alto rischio i fornitori controllati da quei paesi. Una designazione di questo tipo comporterebbe l'esclusione automatica da finanziamenti europei, standardizzazione e appalti pubblici, e potrebbe imporre obblighi di dismissione progressiva che richiedono a soggetti di tutti i settori critici di rimuovere apparecchiature acquisite in modo del tutto legittimo. La Commissione potrebbe specificare i periodi di dismissione per ciascun tipo di componente: per le reti mobili, a titolo di esempio, tali periodi non potranno eccedere trentasei mesi dalla pubblicazione dell'elenco dei fornitori ad alto rischio, secondo l'articolo 110, paragrafo 3, della proposta.

Sul piano sanzionatorio l'impianto proposto è a scaglioni, con un massimo dell'1 per cento del fatturato mondiale annuo totale per determinate violazioni relative agli obblighi informativi, del 2 per cento per altre inadempienze e del 7 per cento per le infrazioni più gravi.

Qui serve una precisazione che molti commenti omettono, e che conviene tenere ben ferma nelle discussioni con il board. Il Cybersecurity Act 2 è una proposta in corso di negoziato, non diritto vigente. Il testo procede attraverso la procedura legislativa ordinaria, con negoziati in Parlamento e Consiglio attesi lungo tutto il 2026, e una volta adottato si applicherà direttamente in tutti gli Stati membri, mentre per le regole sulla catena di fornitura saranno gli atti di esecuzione della Commissione a fissare i periodi di transizione settoriali.

Il percorso ha già incontrato attrito. Nel Progress Report del 22 maggio 2026 il Consiglio dell'Unione europea ha segnalato criticità sul quadro proposto e ha chiesto maggiore chiarezza sulla metodologia e sulle procedure di identificazione dei fornitori ad alto rischio, oltre che sull'ambito e sull'impatto probabile delle misure. Chi pianifica oggi deve quindi trattare questa parte come segnale di direzione più che come obbligo imminente, tenendo però presente che le decisioni di acquisto prese nei prossimi diciotto mesi produrranno i loro effetti dentro quel quadro.

## L'obbligo che scatta l'11 settembre

Il Cyber Resilience Act, a differenza del pacchetto di gennaio, è già diritto vigente. Il regolamento è entrato in vigore il 10 dicembre 2024 e segue un calendario di applicazione scaglionato. Un primo pezzo è operativo dall'11 giugno 2026, il capo IV con gli articoli dal 35 al 51, che disciplina le autorità e gli organismi responsabili del controllo di conformità. Il secondo pezzo arriva ora.

La cascata delle segnalazioni è la parte che cambia il lavoro quotidiano dei team. Per una vulnerabilità attivamente sfruttata il produttore deve trasmettere una prima allerta entro ventiquattro ore dal momento in cui ne viene a conoscenza, seguita da una notifica completa entro settantadue ore con le informazioni disponibili sulla vulnerabilità e sulle misure correttive, e da un rapporto finale entro quattordici giorni dalla disponibilità di una misura correttiva o di mitigazione. Per un incidente grave che incide sulla sicurezza del prodotto la sequenza iniziale è identica, mentre la relazione finale va presentata entro un mese dalla notifica delle settantadue ore.

Il canale è unico e centralizzato. Le comunicazioni passano attraverso la Single Reporting Platform gestita da ENISA, con un solo invio da parte del produttore, indirizzato al CSIRT designato come coordinatore e, salvo circostanze eccezionali, reso disponibile simultaneamente all'agenzia europea. In Italia il CSIRT nazionale competente opera all'interno dell'Agenzia per la Cybersicurezza Nazionale.

L'obbligo di segnalazione si applica anche ai prodotti messi a disposizione sul mercato prima dell'11 dicembre 2027, e questa previsione allarga il perimetro di parecchi portafogli prodotto. Il parco installato non è escluso, quindi il processo di notifica deve coprire anche versioni che l'azienda considerava in manutenzione o addirittura a fine vita commerciale.

Il 27 luglio 2026 la Commissione ha pubblicato le linee guida applicative allegate alla Comunicazione C(2026) 5252, un documento non vincolante articolato in nove sezioni con esempi pratici e casi d'uso, che chiarisce ambito di applicazione, trattamento del software libero e open source, definizione di modifica sostanziale e obblighi di segnalazione. Le linee guida dedicano un passaggio esplicito a microimprese e piccole imprese, suggerendo percorsi semplificati di autovalutazione senza però ridurre la sostanza degli obblighi, perché chi vende un prodotto connesso sul mercato europeo li deve rispettare indipendentemente dalle proprie dimensioni.

Vale la pena ricordare quanto sia largo l'ambito oggettivo, perché la parola prodotto porta fuori strada. Il regolamento si applica a un numero molto ampio di dispositivi connessi a internet e di software, tra cui router, modem, prodotti per la casa intelligente, giocattoli connessi, orologi e altri indossabili, sistemi operativi, firewall, VPN, browser e antivirus. Un software distribuito commercialmente rientra anche senza alcun hardware associato, e un modello linguistico impacchettato dentro un prodotto software immesso sul mercato europeo rientra insieme al prodotto che lo contiene.

## Il perimetro reale di chi è coinvolto

La domanda che le aziende pongono per prima riguarda quasi sempre l'appartenenza al perimetro, e la risposta dipende da come il prodotto arriva sul mercato più che dalla quantità di codice scritto internamente.

Il primo profilo è quello di chi immette sul mercato con il proprio marchio, ed è il fabbricante ai sensi del regolamento. Deve avere un processo di rilevazione e notifica funzionante già da settembre 2026, una distinta base del software, una valutazione della distanza dai requisiti essenziali dell'Allegato I e, entro dicembre 2027, documentazione tecnica e valutazione di conformità completate. La responsabilità non si trasferisce a monte per via contrattuale, per quanto il contratto sia lo strumento con cui si ottengono in tempo utile le informazioni necessarie.

Il secondo profilo riguarda chi integra componenti di terzi. Un'azienda che incorpora un modello, una libreria o un servizio esterno dentro un prodotto proprio e lo immette sul mercato assume la responsabilità di fabbricante su quel prodotto. Il punto contrattuale critico diventa la notifica a monte, perché se il fornitore del componente scopre una vulnerabilità attivamente sfruttata e la comunica al cliente in cinque giorni le ventiquattro ore sono già bruciate da un pezzo. Le clausole di notifica accelerata nei contratti di fornitura software passano così da raffinatezza legale a requisito operativo.

Il terzo profilo è quello di chi compra e utilizza, formalmente fuori dagli obblighi di fabbricante e sostanzialmente esposto su tre fronti diversi. Come utilizzatore ai sensi dell'AI Act, se impiega sistemi ad alto rischio. Come soggetto NIS2, se opera in un settore rientrante nell'ambito della direttiva. Come acquirente, nel caso in cui un proprio fornitore venisse designato ad alto rischio secondo il futuro impianto del Cybersecurity Act 2. Questo terzo profilo copre la maggioranza delle imprese italiane ed è oggi quello che si percepisce come meno coinvolto.

## Dove entra l'intelligenza artificiale

Fino a qui il discorso appartiene alla sicurezza dei prodotti. Il passaggio successivo è quello che trasforma la materia in una questione di governance dell'intelligenza artificiale, e passa da una norma di raccordo che quasi nessuno sta usando.

L'articolo 12 del Cyber Resilience Act stabilisce che, fatti salvi i requisiti di accuratezza e robustezza dell'articolo 15 dell'AI Act, i prodotti con elementi digitali che rientrano nell'ambito del regolamento e che sono classificati come sistemi di intelligenza artificiale ad alto rischio ai sensi dell'articolo 6 dell'AI Act si considerano conformi ai requisiti di cybersicurezza dell'articolo 15 dell'AI Act quando soddisfano i requisiti essenziali della Parte I dell'Allegato I, quando i processi messi in atto dal fabbricante rispettano i requisiti essenziali della Parte II dell'Allegato I, e quando il raggiungimento del livello di protezione richiesto viene dimostrato nella dichiarazione di conformità emessa ai sensi del regolamento stesso.

La stessa norma prevede una semplificazione anche sul lato degli organismi, perché gli organismi notificati competenti a controllare la conformità dei sistemi ad alto rischio ai sensi dell'AI Act sono competenti anche a controllare la conformità di quegli stessi sistemi ai requisiti dell'Allegato I del Cyber Resilience Act, a condizione che la loro conformità ai requisiti dell'articolo 39 sia stata valutata nell'ambito della procedura di notifica prevista dall'AI Act.

Un secondo ponte passa dal quadro di certificazione. L'articolo 42 dell'AI Act stabilisce che un sistema di intelligenza artificiale il quale abbia ottenuto una certificazione di cybersicurezza pertinente ai sensi del Cybersecurity Act può presumersi conforme a determinati requisiti di cybersicurezza dell'AI Act, il che apre una strada di riuso delle evidenze già prodotte.

Il significato operativo di queste due norme è semplice e ampiamente sottoutilizzato. L'evidenza prodotta per il regime cyber vale come evidenza per il regime dell'intelligenza artificiale, a condizione che il perimetro documentale venga progettato con questo obiettivo fin dall'inizio. Chi costruisce due dossier separati paga due volte lo stesso lavoro, ottiene due volte lo stesso risultato e in più si espone al rischio di produrre affermazioni tecniche che divergono tra un fascicolo e l'altro, con tutto quello che questo comporta quando arriva un auditor.

## L'articolo 15 dell'AI Act letto per intero

Il testo è tecnico ma vale la pena riportarlo, perché definisce il campo di gioco per chi sviluppa sistemi destinati a usi ad alto rischio.

I sistemi ad alto rischio devono essere progettati e sviluppati in modo da conseguire un livello adeguato di accuratezza, robustezza e cybersicurezza, e da funzionare in modo coerente sotto questi profili lungo tutto il ciclo di vita. Devono inoltre essere resilienti rispetto ai tentativi di terzi non autorizzati di alterarne l'uso, gli output o le prestazioni sfruttando le vulnerabilità del sistema.

Le vulnerabilità considerate sono specifiche dell'intelligenza artificiale, e questo è il punto in cui il tema si allontana dalla sicurezza informatica tradizionale. Le soluzioni tecniche devono includere, ove opportuno, misure per prevenire, rilevare, rispondere, risolvere e controllare gli attacchi che tentano di manipolare il set di dati di addestramento, i componenti pre-addestrati utilizzati nell'addestramento, gli input progettati per indurre il modello all'errore, oltre agli attacchi alla riservatezza e ai difetti del modello. In gergo tecnico si parla di data poisoning, model poisoning, adversarial examples e model evasion, e sono categorie che il team di sicurezza tradizionale in azienda quasi mai presidia.

Per chi lavora su architetture ad agenti il perimetro si allarga ulteriormente. Un sistema che pianifica, invoca strumenti esterni e compie azioni porta dentro il confine di conformità l'autenticazione tra agenti, i permessi associati a ciascuna chiamata di strumento e la registrazione che consente di ricostruire a posteriori che cosa è successo e su quale base. In un'architettura multi-agente ogni componente che svolge una funzione ad alto rischio nella catena rientra nel perimetro, non soltanto quello che produce la decisione finale.

## Il calendario dell'AI Act dopo il Digital Omnibus

Il rinvio dell'estate 2026 ha spostato le scadenze senza cancellare gli obblighi, e la distinzione è tutt'altro che formale.

Il Regolamento (UE) 2026/1744 ha rinviato l'applicazione delle disposizioni sull'alto rischio. I sistemi autonomi riconducibili all'Allegato III dovranno rispettare i requisiti a partire dal 2 dicembre 2027, mentre i sistemi ad alto rischio integrati in prodotti già soggetti alla normativa di armonizzazione dell'Unione elencata nell'Allegato I, sezione A, avranno tempo fino al 2 agosto 2028. Resta pienamente applicabile dal 2 agosto 2026 tutto ciò che il rinvio non tocca, compresi i divieti dell'articolo 5 e gli obblighi di trasparenza dell'articolo 50.

Il rinvio va letto per quello che è. Le date sono fisse e non risultano condizionate alla disponibilità delle norme armonizzate, perché il meccanismo condizionale inizialmente proposto dalla Commissione è stato abbandonato nel corso del negoziato. Chi aveva pianificato la conformità sul 2 agosto 2026 dispone quindi di tempo aggiuntivo e non di una sospensione a data indeterminata.

C'è poi un cambio di interlocutore che passa quasi sempre inosservato e che vale la pena verificare nei gruppi societari. L'utilizzatore che faccia parte della stessa impresa del fornitore passa sotto la vigilanza esclusiva dell'AI Office a decorrere dal 2 agosto 2026. Per un gruppo che sviluppa internamente e distribuisce alle proprie controllate cambia l'autorità competente, e con essa cambiano interlocutori, tempi e forma della documentazione da tenere pronta.

## La catena di fornitura come rischio di intelligenza artificiale

Nel nostro modello di AI Rating la dimensione dedicata al rischio copre compliance, etica, bias, sicurezza e privacy. Il pacchetto del 2026 introduce una variabile che finora pesavamo poco, ossia la sostenibilità del fornitore nel tempo.

La quasi totalità delle imprese italiane non addestra modelli ma li acquista, e le domande di due diligence che si pongono oggi su un fornitore riguardano accuratezza, costo per token, latenza e residenza dei dati. Le domande che il quadro proposto rende rilevanti sono di natura diversa: chi controlla societariamente il fornitore, da quale giurisdizione, con quali dipendenze infrastrutturali a monte, e che cosa accadrebbe al servizio se quel fornitore finisse in un elenco di soggetti ad alto rischio con obbligo di dismissione entro un numero definito di mesi.

Per un'azienda che ha appena costruito un processo core su un assistente conversazionale di terze parti questa diventa una questione di continuità operativa prima ancora che di conformità formale. Il costo di uscita da una dipendenza di intelligenza artificiale cresce con il tempo di adozione, e cresce più rapidamente di quanto i piani di procurement tendano ad assumere, perché al contratto si aggiungono progressivamente prompt, integrazioni, dati storici e abitudini di lavoro.

Tre indicatori entrano quindi in modo naturale nella valutazione di rischio, senza bisogno di modificare l'impianto a quattro dimensioni del modello: la capacità dimostrata di notificare entro ventiquattro ore, l'esistenza e la manutenzione di una distinta base del software, la mappatura dell'esposizione verso fornitori potenzialmente designabili.

## NIS2 e il resto del quadro

La proposta di modifica della direttiva NIS2 lavora sulla semplificazione più che sull'ampliamento, e questo la rende meno visibile di quanto meriti.

Le modifiche mirate proposte il 20 gennaio 2026 puntano ad aumentare la chiarezza giuridica, semplificando la conformità alle regole europee e ai requisiti di gestione del rischio per le imprese che operano nell'Unione, con un beneficio stimato dalla Commissione su 28.700 imprese, tra cui 6.200 microimprese e piccole imprese. Il pacchetto promette confini di ambito più chiari, regole giurisdizionali semplificate, strumenti di vigilanza transfrontaliera più efficaci e un approccio unificato alla raccolta dei dati sugli attacchi ransomware, incoraggiando l'uso degli schemi di certificazione europei come percorso rapido per dimostrare la conformità.

Sui tempi conviene non farsi illusioni. La proposta è attesa in adozione a fine 2026 o, più realisticamente, nel 2027, dopodiché gli Stati membri avranno dodici mesi per il recepimento e solo a quel punto la Commissione fisserà i requisiti tecnici e settoriali di dettaglio.

Il perimetro soggettivo si allarga in alcuni punti specifici, perché la proposta estende l'ambito del settore delle infrastrutture digitali includendo i fornitori di portafogli europei di identità digitale e di portafogli aziendali europei, oltre agli operatori di infrastrutture sottomarine di trasmissione dati. Compare inoltre una categoria dimensionale intermedia, quella delle small mid-cap, designate come soggetti importanti anziché essenziali e quindi sottoposte a un regime di vigilanza e sanzionatorio più leggero.

Un elemento è passato quasi inosservato e merita un posto stabile nel piano pluriennale di chiunque gestisca infrastrutture. Il nuovo articolo 7, paragrafo 2, lettera k), richiederebbe a ogni Stato membro di adottare all'interno delle proprie strategie nazionali di cybersicurezza le politiche per la transizione alla crittografia post-quantistica, allineate a tempistiche e requisiti già delineati in atti giuridici e documenti di indirizzo dell'Unione. È il momento in cui il rischio quantistico smette di essere un tema da conferenza e diventa una voce di programmazione.

## Gli impatti sui singoli ambiti aziendali

Sul fronte del prodotto e dello sviluppo la distinta base del software smette di essere una buona pratica e diventa documentazione attesa. Le modifiche sostanziali a un prodotto già in commercio riaprono la valutazione di conformità, e le linee guida di luglio dedicano spazio proprio a definire quando una modifica debba considerarsi sostanziale. Il ciclo di rilascio va quindi progettato tenendo conto della finestra di supporto dichiarata all'utente.

Per gli acquisti e per il legale i contratti software esistenti vanno riletti almeno su due voci: l'obbligo del fornitore di notificare entro tempi compatibili con le ventiquattro ore, e il diritto di ottenere la distinta base dei componenti forniti. Nessuna delle due è standard nei contratti firmati prima del 2025, e la rinegoziazione realistica avviene ai rinnovi.

Sul fronte della sicurezza e delle operazioni serve un punto di contatto identificato e realmente raggiungibile, una procedura di triage che distingua una vulnerabilità attivamente sfruttata da una vulnerabilità semplicemente nota, e la registrazione alla piattaforma di segnalazione. Ventiquattro ore non consentono di costruire il processo mentre l'incidente è in corso, tanto più se l'evento arriva di venerdì sera o durante una chiusura aziendale.

Per il consiglio di amministrazione e il comitato rischi l'esposizione va rappresentata su un'unica mappa con una sola scadenza. Portare in consiglio due roadmap separate, una cyber e una sull'intelligenza artificiale, produce due decisioni di budget scoordinate su un problema che ne richiede una sola.

Sul versante finanziario il costo di conformità va stimato al netto delle sovrapposizioni. Le presunzioni di conformità dell'articolo 12 del Cyber Resilience Act e dell'articolo 42 dell'AI Act rappresentano, in termini pratici, una voce di risparmio concreta, a condizione che la documentazione venga impostata una volta sola e con entrambi i regimi in mente.

## La sequenza operativa da seguire

La prima mossa riguarda il processo di notifica e ha scadenza già maturata. Serve un responsabile nominato, un flusso interno di valutazione delle segnalazioni e l'accesso alla piattaforma europea. È l'unico obbligo la cui data è passata mentre leggete.

La seconda mossa, da chiudere entro la fine del 2026, è l'inventario. Servono due elenchi che quasi nessuna azienda possiede in forma aggiornata: i prodotti con elementi digitali immessi sul mercato, compresi quelli antecedenti alla piena applicazione, e i sistemi di intelligenza artificiale in uso o in sviluppo, ciascuno con fornitore, giurisdizione di controllo societario e criticità del processo servito.

La terza mossa, collocabile nel primo trimestre 2027, è la valutazione congiunta della distanza dai requisiti. Una sola analisi che copra i requisiti essenziali dell'Allegato I del Cyber Resilience Act e i requisiti del Capo III dell'AI Act, con mappatura esplicita delle evidenze riutilizzabili tra i due regimi. Due esercizi separati costano di più e producono contraddizioni documentali difficili da spiegare.

La quarta mossa occupa il 2027 e riguarda la conformità vera e propria: classificazione dei prodotti, scelta della procedura applicabile, coinvolgimento di un organismo notificato dove richiesto, documentazione tecnica e dichiarazione di conformità.

In parallelo a tutto questo va condotta la revisione contrattuale, con le clausole corrette dalla prima firma sui fornitori nuovi e la rinegoziazione progressiva sui fornitori esistenti.

## Tre errori che vediamo ricorrere

Il primo consiste nel guardare soltanto al 2027. La scadenza di settembre 2026 non richiede conformità di prodotto ma un processo funzionante, e chi la salta arriva al 2027 senza il presupposto organizzativo su cui poggia tutto il resto.

Il secondo consiste nel separare la sicurezza informatica dalla governance dell'intelligenza artificiale. Sono due direzioni normative con un raccordo giuridico esplicito, e trattarle come progetti indipendenti significa produrre due volte le stesse evidenze rinunciando alle presunzioni di conformità che il legislatore ha previsto proprio per evitarlo.

Il terzo consiste nel delegare al fornitore. La responsabilità di chi immette un prodotto sul mercato con il proprio marchio non si sposta a monte per via contrattuale, e il contratto serve a ottenere le informazioni in tempo utile più che a trasferire l'obbligo.

## Vocabolario dei termini usati

**ACN, Agenzia per la Cybersicurezza Nazionale.** Autorità italiana competente in materia di cybersicurezza. Ospita il CSIRT Italia, destinatario delle notifiche previste dal Cyber Resilience Act per i soggetti italiani.

**AI Act.** Regolamento (UE) 2024/1689 sull'intelligenza artificiale. Classifica i sistemi per livello di rischio e impone obblighi differenziati a fornitori e utilizzatori.

**AI Office.** Ufficio europeo per l'intelligenza artificiale, struttura della Commissione con compiti di vigilanza e coordinamento sull'applicazione dell'AI Act, in particolare sui modelli per finalità generali.

**Allegato I del Cyber Resilience Act.** Elenco dei requisiti essenziali di cybersicurezza, diviso in Parte I sui requisiti di prodotto e Parte II sui processi di gestione delle vulnerabilità in capo al fabbricante.

**Allegato III dell'AI Act.** Elenco dei casi d'uso che qualificano un sistema come ad alto rischio, tra cui selezione del personale, gestione dei lavoratori, accesso a servizi essenziali, biometria e istruzione.

**Allegati III e IV del Cyber Resilience Act.** Elenchi dei prodotti definiti importanti e critici, sottoposti a procedure di valutazione della conformità più severe rispetto al regime ordinario.

**Atto di esecuzione e atto delegato.** Strumenti con cui la Commissione specifica il dettaglio tecnico di un regolamento dopo la sua adozione. Molti aspetti operativi del Cybersecurity Act 2 sono rinviati a questi atti.

**CER.** Direttiva (UE) 2022/2557 sulla resilienza dei soggetti critici, complementare a NIS2 sul versante della sicurezza fisica.

**COM seguito da anno e numero.** Codice identificativo di un documento della Commissione europea. COM(2026) 11 è la proposta di Cybersecurity Act 2, COM(2026) 13 la proposta di modifica di NIS2.

**CRA, Cyber Resilience Act.** Regolamento (UE) 2024/2847 sui requisiti di cybersicurezza dei prodotti con elementi digitali.

**CSA, Cybersecurity Act.** Regolamento (UE) 2019/881, istitutivo del mandato di ENISA e del quadro europeo di certificazione. Il Cybersecurity Act 2 è la proposta destinata a sostituirlo.

**CSIRT.** Squadra nazionale di risposta agli incidenti informatici, designata per ricevere e gestire segnalazioni di incidenti e vulnerabilità.

**Data poisoning.** Manipolazione deliberata dei dati di addestramento allo scopo di alterare il comportamento di un modello. Rientra tra le vulnerabilità citate dall'articolo 15 dell'AI Act.

**Dichiarazione di conformità.** Documento con cui il fabbricante attesta sotto la propria responsabilità che il prodotto soddisfa i requisiti applicabili. È il punto in cui si materializza il raccordo tra Cyber Resilience Act e AI Act.

**Digital Omnibus.** Pacchetto di semplificazione della normativa digitale europea. Sul versante dell'intelligenza artificiale ha prodotto il Regolamento (UE) 2026/1744, che ha modificato il calendario dell'AI Act.

**DORA.** Regolamento (UE) 2022/2554 sulla resilienza operativa digitale del settore finanziario.

**ECCF.** Quadro europeo di certificazione della cybersicurezza istituito dal Cybersecurity Act, oggi a partecipazione volontaria.

**ENISA.** Agenzia dell'Unione europea per la cybersicurezza. Gestisce la piattaforma unica di segnalazione e il database europeo delle vulnerabilità.

**Fabbricante.** Chi immette un prodotto sul mercato europeo con il proprio nome o marchio assumendone la responsabilità commerciale. Non coincide necessariamente con chi ha scritto il codice.

**Incidente grave.** Evento che incide negativamente sulla sicurezza di un prodotto con elementi digitali, secondo la soglia definita dal regolamento. Attiva la cascata di ventiquattro ore, settantadue ore e un mese.

**ISO/IEC 42001.** Standard internazionale per i sistemi di gestione dell'intelligenza artificiale, certificabile da organismi accreditati. Utile come impianto documentale, distinto però dagli obblighi di legge.

**NIS2.** Direttiva (UE) 2022/2555 sulla sicurezza delle reti e dei sistemi informativi. Impone misure di gestione del rischio e obblighi di segnalazione a soggetti essenziali e importanti nei settori individuati.

**Organismo notificato.** Soggetto terzo autorizzato da uno Stato membro a svolgere valutazioni di conformità. Il capo IV del Cyber Resilience Act ne disciplina la notifica ed è applicabile dall'11 giugno 2026.

**PQC, crittografia post-quantistica.** Insieme di algoritmi crittografici progettati per resistere ad attacchi condotti con computer quantistici. La proposta di modifica di NIS2 li nomina espressamente.

**Presunzione di conformità.** Meccanismo per cui il rispetto di un requisito in un regime normativo fa considerare soddisfatto il requisito corrispondente in un altro regime. È il fulcro dell'articolo 12 del Cyber Resilience Act.

**Procedura legislativa ordinaria.** Iter con cui Parlamento europeo e Consiglio adottano congiuntamente un atto su proposta della Commissione. Comprende la fase di negoziato informale detta trilogo.

**Prodotto con elementi digitali.** Categoria del Cyber Resilience Act che comprende hardware e software con connessione diretta o indiretta a dispositivi o reti.

**SBOM, distinta base del software.** Elenco strutturato dei componenti software di un prodotto, comprese le dipendenze di terze parti e open source.

**Small mid-cap.** Categoria dimensionale intermedia tra piccola e media impresa e grande impresa, introdotta nella proposta di modifica di NIS2 con un regime alleggerito.

**SRP, Single Reporting Platform.** Piattaforma unica gestita da ENISA per ricevere le segnalazioni previste dal Cyber Resilience Act, con inoltro automatico ai CSIRT interessati.

**Utilizzatore.** Nel linguaggio dell'AI Act, chi impiega un sistema di intelligenza artificiale sotto la propria autorità nell'ambito di un'attività professionale. Si distingue dal fornitore, che sviluppa e immette sul mercato.

**Vulnerabilità attivamente sfruttata.** Difetto di sicurezza per cui esistono prove di sfruttamento in corso da parte di un attore malevolo. È la condizione che attiva l'obbligo di allerta entro ventiquattro ore.

## Il punto di decisione

La convergenza di dicembre 2027 rende visibile una cosa che era già vera da tempo. La governance dell'intelligenza artificiale in azienda passa dalla catena di fornitura tecnologica almeno quanto passa dai modelli, e chi non sa quali sistemi utilizza, chi glieli fornisce e da quale giurisdizione non possiede gli elementi minimi per stimare la propria esposizione su nessuno dei due versanti.

La misurazione precede la decisione. Prima di aprire un cantiere di conformità conviene sapere a che punto si trova l'organizzazione: quali sistemi sono in uso, quale documentazione esiste già, quali evidenze sono riutilizzabili tra i due regimi, quali fornitori rappresentano una dipendenza critica e quanto costerebbe uscirne.

Per una valutazione strutturata della maturità e dell'esposizione normativa scrivete a hello@zerofive.ai oppure prenotate un confronto su calendly.com/fabiolalli/zerofive.

**Fonti.** Commissione europea, proposte COM(2026) 11 e COM(2026) 13 del 20 gennaio 2026, e Comunicazione C(2026) 5252 del 27 luglio 2026. Testi normativi citati: Cyber Resilience Act, Regolamento (UE) 2024/2847; AI Act, Regolamento (UE) 2024/1689; Digital Omnibus sull'intelligenza artificiale, Regolamento (UE) 2026/1744 pubblicato in Gazzetta ufficiale il 24 luglio 2026. Consiglio dell'Unione europea, Progress Report del 22 maggio 2026. Agenzia per la Cybersicurezza Nazionale, comunicazione di settembre 2026.