AGGIORNAMENTO · AGOSTO 2026

Il calendario dell’AI Act descritto originariamente in questo articolo è stato modificato dal Digital Omnibus sull’IA, Regolamento (UE) 2026/1744, pubblicato in Gazzetta Ufficiale il 24 luglio 2026 e in vigore dal 27 luglio. Dal 2 agosto 2026 si applicano gli obblighi di trasparenza dell’art. 50 e sono pienamente operative governance e sanzioni. Gli obblighi sui sistemi ad alto rischio slittano invece al 2 dicembre 2027 (Allegato III) e al 2 agosto 2028 (sistemi integrati in prodotti disciplinati dall’Allegato I, macchinari compresi). Il testo che segue è stato aggiornato di conseguenza.

In un contesto geopolitico sempre meno definito e più caotico, quantomeno in evoluzione, i dati confermano il trend per cui l’Unione Europea è sempre più bersaglio di cyber attacchi. Durante il 2025 gli attacchi DDoS in Europa sono aumentati del 75%, evidenziando una persistenza critica per le infrastrutture (qui). Parallelamente,- si è registrato un record di 443 notifiche giornaliere di data breach, segnando un incremento del 22% rispetto all’anno precedente (qui).

Questo trend non è certo una novità e non a caso negli scorsi anni sono maturati regolamenti e direttive europei che troveranno la loro piena applicazione tra il 2026 e il 2028. Il nuovo quadro normativo nasce dalla necessità di garantire sicurezza strategica interna, dei propri cittadini e prodotti europei. Si tratta di un obiettivo reale e necessario, ma muoversi all’interno di questo labirinto giuridico e certificativo può risultare complicato e problematico. Il rischio principale è quello di perdere l’orientamento. Le aziende così vengono accecate rispetto alle reali possibilità che si aprono di fronte a loro; che siano una migliore sicurezza (e quindi minori perdite economiche dovute a cyber attacchi) o un potenziale vantaggio competitivo, implicito nella tanto agognata conformità CE, ossia prodotti garanti di qualità e maturità pressoché uniche a livello mondiale su temi di sicurezza e protezione dei dati.

Le prove da superare in questo labirinto sono le norme NIS 2, CRA, AI Act e Nuovo Regolamento Macchine, e in questo articolo cercheremo di districarne la complessità e fornire una mappa e una chiave di lettura immediate e pratiche.

Indice

Il percorso

Negli ultimi anni abbiamo visto una crescita esponenziale della digitalizzazione industriale, grazie al paradigma europeo dell’Industry 4.0, che possiamo sintetizzare nell’interconnessione di tre pilastri: Informazione, Sicurezza e Qualità. Come diretta conseguenza l’automazione e i prodotti industriali si sono mossi verso un’interconnessione OT/IT sempre maggiore, abbandonando la best practice basata sulla segregazione di rete OT delle linee di produzione/packaging ed entrando in una nuova era di apertura dei dispositivi OT. Se questa apertura da un lato ha portato ad un maggior controllo (grazie alla migliore qualità dei dati raccolti) e ad una maggiore efficienza in termini di sviluppo e qualità, dall’altro è stata anche la porta che ha attirato cyber attacchi mirati verso la supply chain. Attacchi che si sono trasformati da ricattatori (ransomware) a tentativi di modificare e danneggiare le performance e le caratteristiche del prodotto finale.

L’UE, spesso criticata per eccessiva lentezza burocratica, non è rimasta inerme e ha reagito con un pacchetto normativo coordinato che affronta insieme i temi di cybersecurity, sicurezza fisica e supply chain e la più recente evoluzione dell’IA. L’obiettivo strategico dichiarato è una maggiore resilienza del mercato interno, la riduzione di dipendenze critiche e la sicurezza di cittadini, aziende e stati membri. Gli strumenti utilizzati dalla UE per raggiungere i suoi obiettivi sono stati un ampliamento della prima direttiva NIS, in cui sono stati ampliati i settori critici e importanti ed introdotti principi di governance e supervisione molto più stringenti, e poi l’introduzione del concetto di sicurezza-by-design per tutti i prodotti con elementi digitali superando di fatto la suddivisione concettuale tra “safety” e “security”; in particolare il principio di security è stato ampliato con l’inclusione della cyber security dei componenti hardware. Inoltre, il boom dell’utilizzo di IA generativa e “non deterministica” ha di fatto imposto la necessità di una valutazione di questo strumento in termini di rischio e, quindi, di obblighi connessi all’uso di una tecnologia booster e rivoluzionaria dei processi di lavoro.

Nota di contesto: Sovranità digitale
Questo pacchetto normativo è maturato in un contesto geopolitico in cui gli USA erano considerati un partner tecnologico affidabile e sicuro. Gli eventi dell’ultimo anno hanno ribaltato questa visione. Non è un caso che si inizia a discutere a livello europeo del tema di sovranità digitale, ossia l’indipendenza dai servizi tecnologici extraeuropei (in particolare statunitensi) per gli usi critici dello stato.
La Francia è stato il primo paese a muoversi in tal senso. A giugno 2025 (qui), il direttore legale di Microsoft Francia ha ammesso sotto giuramento al Senato francese che Microsoft non può garantire che i dati europei siano al riparo da richieste delle autorità statunitensi, anche se fisicamente ospitati in Europa, un conflitto strutturale tra CLOUD Act americano e GDPR europeo. La risposta francese è stata concreta: entro il 2027 sostituirà Microsoft Teams e Zoom con Visio (qui), piattaforma sviluppata internamente dalla DINUM (Direction Interministérielle du Numérique), vincolando gli acquisti pubblici digitali a fornitori francesi ed europei (qui).

Pillole di storia

Il termine Industrie 4.0 fu coniato in Germania e utilizzato per la prima volta nel 2011 alla Hannover Messe, una delle principali fiere industriali mondiali. 

Due anni dopo, nel 2013, sempre ad Hannover, Siegfried Dais e Henning Kagermann, presidenti del gruppo di lavoro sull'I4.0, presentarono il rapporto finale che fissò i principi fondanti del paradigma. 

Nei cinque anni successivi, organizzazioni di tutto il mondo pubblicarono studi sull'impatto dell'I4.0 in termini di costi, investimenti e occupazione, mentre le principali aziende globali costituirono unità di ricerca dedicate alla sua applicazione. 

L'Italia non rimase a guardare: il 21 settembre 2016, il Ministro dello Sviluppo Economico Carlo Calenda presentò ufficialmente il Piano Nazionale Industria 4.0, sviluppato a partire dalle conclusioni dell'indagine conoscitiva parlamentare della Decima Commissione della Camera dei Deputati. Il Piano prevedeva 23 miliardi di euro di investimenti pubblici in quattro anni, con strumenti come l'iperammortamento al 250% e il credito d'imposta per R&S, pensati specificamente per accompagnare il tessuto produttivo italiano, composto da Piccole e Medie Imprese (PMI) e manifattura diffusa, verso la trasformazione digitale. 

Nel 2017 il Piano fu aggiornato in Impresa 4.0, estendendo il perimetro dal solo settore manifatturiero anche al settore dei servizi.

La sfida principale emerse presto: il disallineamento tra i tempi dell'informatica, in crescita esponenziale, e quelli delle tecnologie meccaniche e di automazione, che richiedono cicli molto più lunghi di sviluppo, validazione e adozione industriale.

I guardiani del labirinto

Il momento di addentrarsi è arrivato. Come abbiamo anticipato, questo labirinto europeo non ha un solo custode. Quattro normative distinte presidiano altrettante dimensioni della sicurezza digitale e industriale: chi entra nel perimetro si trova a dover rispondere non a un’unica regola, ma a un sistema coordinato di obblighi che si intrecciano e si sovrappongono. Capire cosa presidia ciascun guardiano, e dove finisce la sua giurisdizione, è il primo passo per orientarsi senza perdersi.

Network and Information Systems 2 (NIS 2)

Direttiva (UE) 2022/2555

La NIS2 è il guardiano che presidia l’interno delle organizzazioni: non valuta i prodotti che un’azienda vende né i servizi che eroga ai clienti finali, ma il modo in cui quella stessa azienda gestisce i propri processi, sistemi e rischi informatici. È una distinzione che vale la pena fissare subito, perché è anche il malinteso più frequente: la direttiva non certifica nulla ma impone una governance.

Adottata dal Parlamento europeo e dal Consiglio il 14 dicembre 2022, la NIS2 ha sostituito la precedente direttiva NIS del 2016, ampliandone il perimetro. In Italia è stata recepita con il Decreto Legislativo 4 settembre 2024, n. 138, pubblicato in Gazzetta Ufficiale il 1° ottobre 2024 ed entrato in vigore il 16 ottobre 2024. L’autorità nazionale competente è l’Agenzia per la Cybersicurezza Nazionale (ACN), che gestisce il registro dei soggetti obbligati e coordina l’attuazione della normativa con il supporto di nove Ministeri quali autorità di settore.

Le scadenze operative in Italia:

15 gennaio 2026: entra in vigore l’obbligo pieno di notifica degli incidenti significativi al CSIRT Italia, secondo la Determinazione ACN n. 379907/2025. La procedura si articola in tre fasi inderogabili: pre-notifica entro 24 ore, notifica formale entro 72 ore, relazione finale entro un mese.
Ottobre 2026: termine per la completa implementazione delle misure di sicurezza obbligatorie. Da quella data l’ACN avvia le attività ispettive, transitando dalla fase di accompagnamento alla fase di verifica.

Chi è coinvolto? La direttiva identifica due categorie di soggetti, definite in base alla criticità del settore di appartenenza e alle dimensioni dell’organizzazione:

Entità Essenziali (EES): operano in settori ad alta criticità per la società e l’economia; i settori interessati sono: energia, trasporti, sanità, acqua, banche, infrastrutture digitali critiche, settore spaziale, mercati finanziari.
Entità Importanti (IES): operano in settori strategici ma con impatto sistemico minore; si tratta di fornitori digitali non critici, telecomunicazioni di minore rilevanza, industria manifatturiera non primaria, servizi postali, gestione rifiuti.

In pratica, la direttiva introduce l’obbligo di gestire il rischio informatico in modo strutturato: identificarlo, valutarlo e applicare misure di mitigazione documentate. Questo si traduce in una governance interna che prevede la nomina di responsabili e coordinatori, la redazione di policy aggiornate periodicamente e, questa è la novità rilevante rispetto alla NIS1, la responsabilizzazione diretta degli organi di amministrazione: il CdA non può più delegare interamente la cybersicurezza all’ufficio IT, ma deve approvare le misure, vigilare sulla loro implementazione e formarsi in materia. Entra inoltre in campo il concetto di controllo della supply chain: i soggetti obbligati devono valutare i rischi introdotti dai fornitori terzi e adottare misure preventive di conseguenza.

Le sanzioni per chi non si adegua sono calibrate sulla categoria di appartenenza: fino a 10 milioni di euro o il 2% del fatturato globale annuo per le Entità Essenziali, fino a 7 milioni di euro o l’1,4% del fatturato per le Entità Importanti. A partire da ottobre 2026 saranno pienamente operative anche le attività ispettive dell’ACN.

Cyber Resilience Act (CRA)

Regolamento (UE) 2024/2847

Se NIS2 guarda dentro le organizzazioni, il CRA guarda fuori: ai prodotti che escono dalla fabbrica e arrivano sul mercato europeo. I due guardiani presidiano lati opposti della stessa porta, e insieme coprono l’intero perimetro. C’è una differenza strutturale che vale la pena sottolineare subito: il CRA non è una direttiva, è un regolamento. Questo significa che è direttamente applicabile in tutti gli Stati membri senza necessità di recepimento nazionale, nessun decreto legislativo, nessun margine di adattamento locale. Entra in vigore, e vale.

Pubblicato in Gazzetta Ufficiale dell’Unione Europea il 20 novembre 2024 ed entrato in vigore il 10 dicembre 2024, il Regolamento (UE) 2024/2847 introduce per la prima volta requisiti orizzontali di cybersicurezza obbligatori per tutti i prodotti con elementi digitali (PDE) immessi sul mercato europeo, coprendo sia la componente hardware che quella software, e stabilendo obblighi vincolanti lungo tutta la filiera.

Cosa è un prodotto con elementi digitali? La definizione risulta più ampia di quanto si possa immaginare. Rientrano nel perimetro:

Dispositivi elettronici con software integrato. Esempi sono: smartphone, computer, router, stampanti, dispositivi IoT, elettrodomestici intelligenti.
Componenti hardware il cui corretto funzionamento dipende da software (firmware). In questo caso rientrano: chip, moduli elettronici, sensori, schede programmate.
Prodotti che interagiscono con reti o sistemi digitali e possono essere soggetti a vulnerabilità di cybersicurezza, anche se non connessi direttamente a Internet.

Quest’ultimo punto è particolarmente rilevante per il mondo industriale: un dispositivo embedded (i.e. sensori) che non ha accesso alla rete ma che interagisce con sistemi di controllo digitali rientra nel campo di applicazione del CRA.

Chi è coinvolto? Il regolamento distribuisce la responsabilità su tre figure distinte, ciascuna con obblighi attivi. In questo caso non siamo di fronte ad una catena in cui basta passare il prodotto al soggetto successivo per non essere più coinvolti. I tre protagonisti sono:

Manufacturer (Produttore): progetta o fa assemblare il PDE per proprio conto. È il responsabile primario a cui compete progettazione sicura, gestione delle patch, documentazione tecnica, marcatura CE. Include sia chi produce fisicamente l’hardware sia chi ne sviluppa il software integrato.
Importer (Importatore): immette sul mercato UE un prodotto fabbricato fuori dall’Unione. Non può limitarsi a “portare dentro” il prodotto, a lui spetta la verifica attiva della conformità al CRA ed garantisce che il produttore fornisca tutta la documentazione necessaria e i meccanismi di aggiornamento adeguati.
Distributor (Distributore): commercializza il prodotto senza modificarlo. Deve assicurarsi che la conformità sia mantenuta durante la distribuzione, che le istruzioni per gli aggiornamenti siano accessibili agli utenti e che eventuali rischi segnalati dai produttori vengano comunicati correttamente.

Gli obblighi principali ruotano attorno a tre assi:

Gestione delle vulnerabilità: identificazione, valutazione e mitigazione dei rischi di cybersicurezza durante tutto il ciclo di vita del prodotto.
Aggiornamenti di sicurezza obbligatori: rilascio di patch tempestive per vulnerabilità note, con una durata minima garantita di 5 anni dall’immissione sul mercato, salvo vita utile più breve documentata e giustificata. Gli aggiornamenti devono essere accessibili agli utenti o, dove possibile, implementati automaticamente.
Marcatura CE: il prodotto deve dimostrare la conformità ai requisiti CRA prima di essere immesso sul mercato. Il marchio CE diventa, a tutti gli effetti, anche un attestato di cyber-resilienza.

Le scadenze operative:

11 settembre 2026: entra in vigore l’obbligo di segnalazione (art. 14); i manufacturer devono notificare alle autorità nazionali e all’ENISA le vulnerabilità attivamente sfruttate nei propri prodotti. La procedura rispecchia lo schema ormai consolidato, presente anche nella NIS2: early warning entro 24 ore, segnalazione completa entro 72 ore, rapporto finale entro i termini stabiliti.
11 dicembre 2027: piena applicazione del regolamento. Da quella data nessun prodotto con elementi digitali potrà essere immesso sul mercato UE senza rispettare i requisiti CRA e senza marcatura CE conforme.

Una precisazione importante per il mondo OT e industriale: non tutto il software ricade sotto il CRA. Il discrimine è la necessità funzionale. Il firmware di una macchina, essenziale al suo funzionamento, rientra nel perimetro. Il software supervisore che gira su un PC separato e non è integrato nel prodotto, no o almeno non direttamente. Tutto ciò che è necessario al funzionamento automatizzato del prodotto è soggetto al regolamento; le applicazioni opzionali o gestionali che vivono al di fuori del prodotto seguono logiche diverse. Una distinzione che in fase di progettazione vale la pena chiarire con precisione, perché le implicazioni sulla documentazione tecnica e sulla marcatura CE sono significative.

Le sanzioni per chi non rispetta i requisiti del CRA sono più severe rispetto alla controparte NIS2 in ambito cybersicurezza: fino a 15 milioni di euro o il 2,5% del fatturato mondiale annuo per le violazioni più gravi. Una soglia superiore a quella prevista dalla NIS2, coerente con la priorità che l’UE assegna alla sicurezza dei prodotti come presupposto di fiducia nell’intero mercato digitale.

AI Act

Regolamento (UE) 2024/1689

Proseguendo nella nostra similitudine, i primi due guardiani presidiano i confini fisici del labirinto: NIS2 controlla i processi interni delle organizzazioni, il CRA controlla i prodotti che escono dalla fabbrica. Il terzo guardiano lavora su un piano diverso: non si occupa di come le organizzazioni operano né di cosa producono, ma di come decidono. L’AI Act porta la responsabilità dentro il modello stesso, dentro la logica con cui un sistema automatizzato elabora dati e produce output che incidono su persone, diritti e sicurezza.

Pubblicato in Gazzetta Ufficiale dell’Unione Europea il 12 luglio 2024 ed entrato in vigore il 1° agosto 2024, il Regolamento (UE) 2024/1689 è il primo quadro giuridico completo al mondo sull’intelligenza artificiale. Come il CRA, è un regolamento, direttamente applicato in tutti gli Stati membri senza recepimento nazionale. Il testo è stato modificato una prima volta dal Digital Omnibus sull’IA, il Regolamento (UE) 2026/1744, in vigore dal 27 luglio 2026, che ne ha riscritto il calendario di applicazione a pochi giorni dalla scadenza del 2 agosto. L’Italia ha tuttavia anticipato i tempi sul piano istituzionale: con la Legge 132/2025 ha designato le autorità nazionali competenti, affidando ad AgID le funzioni di notifica e accreditamento degli organismi di valutazione e ad ACN i compiti di vigilanza, sanzione e sicurezza cibernetica (la stessa agenzia che presidia l’attuazione della NIS2).

La classificazione per livelli di rischio è il cuore architetturale del regolamento. A differenza di NIS2 e CRA, che definiscono obblighi per categorie di soggetti o prodotti, l’AI Act valuta ogni sistema in base all’impatto che può avere su persone e diritti fondamentali, collocandolo su una scala a quattro livelli:

Rischio inaccettabile: sistemi vietati e non ammissibili sul mercato UE. Rientrano in questa categoria i sistemi che rappresentano una minaccia diretta ai diritti fondamentali, alla sicurezza o alla dignità delle persone: social scoring, manipolazione comportamentale subliminale, identificazione biometrica remota in tempo reale in spazi pubblici, sistemi che sfruttano vulnerabilità di gruppi fragili. Non è una questione di adeguamento: questi sistemi non possono esistere nel mercato europeo. Le esclusioni: sono esclusi i sistemi AI sviluppati a fini militari o in ambito di ricerca.
Alto rischio: sistemi che possono causare gravi danni a salute, sicurezza o diritti fondamentali se falliscono o vengono usati in modo improprio. Rientrano in questa fascia i sistemi AI per diagnostica medica, gestione di infrastrutture critiche, selezione del personale, accesso a crediti o prestazioni pubbliche, gestione di frontiere, supporto alla giustizia. Per questi sistemi sono obbligatori una valutazione di conformità, un sistema di gestione del rischio per l’intero ciclo di vita, una documentazione tecnica con dati di training e misure di bias mitigation, sorveglianza umana, registrazione in un database europeo pubblico. Gli obblighi restano quelli previsti, ma il Digital Omnibus ne ha spostato in avanti l’applicazione (2 dicembre 2027 per i sistemi dell’Allegato III, 2 agosto 2028 per quelli integrati in prodotti).
Rischio limitato: sistemi che non comportano rischi gravi ma possono influenzare significativamente l’esperienza o le decisioni degli utenti. Per questi il regolamento impone obblighi di trasparenza, applicabili dal 2 agosto 2026 (art. 50): informare l’utente che sta interagendo con un’IA, indicare quando i contenuti sono generati da un modello, etichettare chiaramente deepfake e contenuti sintetici.
Rischio minimo: sistemi con impatto trascurabile su diritti e sicurezza; si tratta di filtri antispam, IA nei videogiochi, funzioni non critiche. Nessun obbligo specifico sotto l’AI Act, fatta salva la normativa generale del mercato UE. Gli operatori possono adottare codici di condotta volontari.

Chi è coinvolto? Anche l’AI Act distribuisce la responsabilità lungo la filiera, con tre figure principali:

Provider / Developer: chi progetta, sviluppa o produce il sistema AI. È il responsabile primario della conformità prima dell’immissione sul mercato, obbligato a documentazione tecnica, valutazioni di rischio, gestione dei bias, misure di sicurezza e trasparenza.
Importer / Distributore: chi introduce il sistema AI nel mercato UE o lo distribuisce. Deve verificare la conformità al regolamento e garantire che istruzioni, avvisi e aggiornamenti siano disponibili per l’utente finale.
User / Deployer: chi utilizza il sistema AI per finalità operative o commerciali. Per i sistemi ad alto rischio, il deployer è spesso il soggetto meno consapevole degli obblighi che lo riguardano, che sono monitoraggio umano, gestione degli incidenti, uso conforme alle istruzioni del provider. Vale la pena sottolinearlo: acquistare un sistema AI ad alto rischio da un fornitore esterno non trasferisce automaticamente tutta la responsabilità, ma parte degli obblighi rimane in capo a chi lo usa.

Gli obblighi dell’AI Act hanno portata extraterritoriale: si applicano anche ad aziende con sede fuori dall’UE, se i loro sistemi vengono utilizzati nel territorio europeo o producono effetti su soggetti europei. Altro punto di attrito con le big tech statunitensi, ma anche cinesi su cui si reinserisce il tema di sovranità digitale.

Le scadenze seguono una logica a ondate progressive. Il calendario originale è stato però modificato dal Digital Omnibus sull’IA (Regolamento UE 2026/1744) a pochi giorni dalla scadenza principale (2 agosto 2026), quindi conviene leggerlo nella versione aggiornata:

2 febbraio 2025: in vigore i divieti per le pratiche a rischio inaccettabile e gli obblighi di alfabetizzazione del personale. I sistemi vietati non possono già oggi essere immessi sul mercato UE.
2 agosto 2025: operative le norme di governance, gli obblighi per i modelli di AI per finalità generali (GPAI) e il regime sanzionatorio.
2 agosto 2026: il regolamento entra nella fase di applicazione generale. Si applicano gli obblighi di trasparenza dell’art. 50 (chatbot, deepfake, riconoscimento delle emozioni) e diventano pienamente operative governance e sanzioni, con le autorità nazionali a pieni poteri e la possibilità per la Commissione di sanzionare i fornitori di modelli GPAI.
2 dicembre 2026: obbligo di etichettatura machine-readable dei contenuti generati dall’IA per i sistemi già sul mercato, e due nuovi divieti introdotti dall’Omnibus (generazione di immagini intime non consensuali e di materiale di abuso sessuale su minori).
2 dicembre 2027: requisiti per i sistemi ad alto rischio dell’Allegato III, quelli usati in ambiti come selezione del personale, merito creditizio, biometria, istruzione e giustizia. Nel calendario originale la data era il 2 agosto 2026.
2 agosto 2028: requisiti per i sistemi ad alto rischio integrati in prodotti già disciplinati da normativa settoriale (Allegato I), quindi dispositivi medici, macchine e sistemi di trasporto. Nel calendario originale la data era il 2 agosto 2027.

Non si tratta di una sospensione. Il rinvio nasce dal fatto che gli standard armonizzati e gli strumenti di conformità non erano pronti, e imporre obblighi senza gli strumenti per rispettarli avrebbe prodotto incertezza invece di tutela. Il tempo guadagnato però va speso bene: censire i sistemi di IA in uso e classificarli per rischio potrebbe richiedere mesi, non settimane.

Le sanzioni sono le più elevate dell’intero pacchetto normativo europeo in ambito digitale, articolate su due livelli: fino a 35 milioni di euro o il 7% del fatturato mondiale annuo per chi viola i divieti sulle pratiche a rischio inaccettabile; fino a 15 milioni di euro o il 3% del fatturato per le violazioni degli obblighi generali a carico di provider, deployer, importatori e distributori.

Nuovo Regolamento Macchine

Regolamento (UE) 2023/1230

Siamo arrivati al quarto guardiano, quello che chiude il cerchio e riporta tutto al mondo fisico. Il Regolamento Macchine presidia le macchine stesse e lo fa nel momento in cui la distinzione tra sicurezza fisica e sicurezza informatica è diventata, nei fatti, impossibile da mantenere. Un ransomware che blocca un asse di movimento non è più un problema IT: è un problema di safety.

Pubblicato in Gazzetta Ufficiale dell’Unione Europea il 29 giugno 2023 ed entrato in vigore il 19 luglio 2023, il Regolamento (UE) 2023/1230 sostituisce la Direttiva Macchine 2006/42/CE, che governava il settore dal 2009. Come il CRA e l’AI Act, è un regolamento, direttamente applicato in tutti gli Stati membri senza recepimento nazionale, eliminando le disomogeneità interpretative che la vecchia direttiva aveva generato tra i diversi ordinamenti nazionali. La piena applicazione è fissata al 20 gennaio 2027: da quella data la Direttiva 2006/42/CE è formalmente abrogata e ogni macchina immessa sul mercato UE deve essere conforme al nuovo regolamento.

Cosa cambia davvero rispetto alla vecchia direttiva? Tre elementi strutturali distinguono il nuovo regolamento dal precedente quadro normativo:

Cybersecurity come requisito essenziale di sicurezza: per la prima volta, la protezione informatica entra esplicitamente nei requisiti di progettazione e costruzione delle macchine (Allegato III, punti 1.1.9 e 1.2.1). Le macchine connesse devono essere progettate per resistere ad alterazioni e accessi esterni non autorizzati. La sicurezza informatica non è più un optional di sistema, ma parte integrante della conformità CE.
Riconoscimento di AI e sistemi auto-evolutivi: la definizione di “macchina” viene aggiornata per includere software con funzioni di sicurezza e sistemi con comportamento auto-evolutivo basati su apprendimento automatico. Per queste categorie sono previste procedure di valutazione della conformità obbligatoria. Una macchina che “impara” è una macchina che deve essere certificata per quello che potrebbe diventare, non solo per quello che è al momento dell’immissione sul mercato.
Documentazione digitale: il regolamento introduce la possibilità di fornire manuale di istruzioni e dichiarazione di conformità in formato esclusivamente digitale con QR code, superando l’obbligo cartaceo.

Il concetto di modifica sostanziale è probabilmente il punto più critico e meno compreso del nuovo regolamento, soprattutto per chi gestisce impianti esistenti. Qualsiasi intervento che alteri le prestazioni di sicurezza, introduca nuovi rischi o cambi la destinazione d’uso prevista dal fabbricante originale è considerato una modifica sostanziale. Quando questo accade, la marcatura CE originale decade completamente e chi ha eseguito la modifica diventa legalmente il nuovo fabbricante con tutti gli obblighi che ne derivano: nuova valutazione di conformità, aggiornamento della documentazione tecnica e nuova dichiarazione CE. Tre esempi per rendere concreto il concetto:

L’aggiornamento di un software di supervisione che introduce nuove funzionalità di automazione è una modifica sostanziale e richiede nuova valutazione di conformità.
La sostituzione di un sensore o attuatore con uno equivalente che non impatta la sicurezza è manutenzione ordinaria e non richiede nuova conformità.
L’integrazione di un nuovo robot in un impianto esistente è una modifica sostanziale e impone ri-valutazione obbligatoria.

Questo concetto avrà implicazioni significative nei progetti di retrofit e revamping di impianti esistenti, tema che approfondiremo nella prossima sezione.

Il periodo di transizione è ancora aperto ma si sta chiudendo. Fino al 19 gennaio 2027 è ancora possibile immettere sul mercato macchine conformi alla vecchia Direttiva 2006/42/CE, purché già completamente prodotte. Dal 20 gennaio 2027 questo non sarà più possibile. Le macchine già legittimamente immesse sul mercato prima di quella data mantengono la loro conformità a meno che non vengano successivamente modificate in modo sostanziale, nel qual caso rientrano integralmente nel nuovo regime.

Le conseguenze della non conformità seguono una logica diversa rispetto agli altri tre regolamenti: il Regolamento Macchine non stabilisce sanzioni pecuniarie dirette a livello europeo (che sono demandate agli ordinamenti nazionali) ma la conseguenza operativa è altrettanto netta: senza conformità non si ottiene la marcatura CE, e senza marcatura CE il prodotto non può essere immesso né messo in servizio sul mercato dell’Unione Europea.

Il quadro normativo europeo relativo a sicurezza, prodotti digitali e intelligenza artificiale è oggi un ecosistema interconnesso. Le quattro normative non occupano stanze separate del labirinto: sono pareti che si toccano, e capire come avviene questo tocco è tanto importante quanto capire cosa prescrive ciascuna, per evitare di perdersi e finire in un vicolo cieco.

La NIS2, tramite l’adozione di politiche e strumenti aziendali, si concentra sulla protezione dei servizi e delle infrastrutture critiche, mentre il CRA tutela i prodotti digitali che quelle stesse infrastrutture utilizzano. Chi produce il dispositivo e chi lo usa in un contesto critico hanno obblighi distinti ma complementari sullo stesso oggetto: insieme garantiscono una copertura end-to-end, dalla macchina o dal software fino alla rete e ai servizi connessi.

Parallelamente, le funzioni di sicurezza basate su AI integrate in una macchina rientrano nella categoria high-risk dell’AI Act, ma quegli stessi sistemi devono rispettare anche i requisiti essenziali di salute e sicurezza del Regolamento Macchine, generando un doppio binario di certificazione: compliance digitale e fisica in parallelo.

Una stessa funzione deve rispondere a due regolatori con logiche diverse: uno valuta il rischio AI, l’altro la sicurezza fisica. Fino a luglio 2026 le due scadenze erano quasi allineate sul 2027, il che rendeva la sovrapposizione gestibile in un unico percorso. Con il Digital Omnibus questo allineamento non è più tale, almeno sulla carta: il Regolamento Macchine si applica dal 20 gennaio 2027, mentre i requisiti AI Act per i sistemi ad alto rischio integrati in prodotti arrivano solo il 2 agosto 2028. Restano più di diciotto mesi in cui una macchina con funzioni di sicurezza basate su IA dovrà essere conforme al Regolamento Macchine senza che gli obblighi AI Act corrispondenti siano ancora applicabili.

Quel divario, però, non è un vuoto normativo. Lo stesso Digital Omnibus interviene anche sul Regolamento Macchine, con una modifica strutturale che merita attenzione: il riferimento alla vecchia Direttiva 2006/42/CE passa dalla sezione A alla sezione B dell’allegato I dell’AI Act, aggiornato per rinviare al Regolamento (UE) 2023/1230. Si tratta di un passaggio a un approccio settoriale, in cui i requisiti per i sistemi di IA ad alto rischio utilizzati come componenti di sicurezza in macchine (o che costituiscono essi stessi macchine) non resteranno nell’AI Act, ma confluiranno nel Regolamento Macchine.

Il trasferimento avviene tramite atti delegati che la Commissione dovrà adottare per inserire nell’allegato III del Regolamento Macchine i requisiti del capo III sezione 2 e degli articoli 17, 19, 72 e 73 dell’AI Act. La delega ha durata quinquennale dal 27 luglio 2026.

Per chi progetta, questo cambia la lettura dei diciotto mesi: non sono una finestra in cui l’IA nelle macchine è fuori perimetro, sono l’intervallo in cui i requisiti cambiano casa, e indicano dove guardare fin da subito. Il capo III sezione 2 dell’AI Act (sistema di gestione del rischio, governance dei dati, documentazione tecnica, registrazione, trasparenza, sorveglianza umana, accuratezza e robustezza) è l’anteprima ragionevole di quello che finirà nell’allegato III del Regolamento Macchine. Chi imposta oggi l’architettura di sicurezza e il fascicolo tecnico di una macchina con funzioni IA può allinearsi a quei requisiti prima che diventino formalmente parte della disciplina macchine. Il margine di incertezza resta, ed è onesto dichiararlo: finché gli atti delegati non sono pubblicati, il testo esatto non è noto.

Infine, le macchine connesse e dotate di componenti IoT ricadono nell’ambito della NIS2 se utilizzate da operatori di infrastrutture critiche. In questo contesto la cybersecurity diventa parte integrante della sicurezza fisica della macchina, richiedendo che misure di protezione informatica e meccanica siano valutate e integrate in maniera coordinata.

La sovrapposizione non è un difetto del sistema normativo europeo: è una caratteristica strutturale. Chi la legge come mappa invece che come ostacolo può costruire un percorso di adeguamento integrato invece di quattro percorsi separati ed è esattamente quello che esploreremo nel prossimo paragrafo.

Il filo di Arianna: la IEC 62443

Nel mito greco, il filo di Arianna non abbatteva i muri del labirinto, li rendeva navigabili. Teseo nel seguirlo non doveva capire la struttura del labirinto per uscirne, doveva solo non lasciarlo mai. La IEC 62443 funziona allo stesso modo rispetto al quadro normativo che abbiamo appena attraversato. Non sostituisce NIS2, CRA, AI Act o Regolamento Macchine, ma offre un linguaggio tecnico comune per attraversarli tutti senza perdersi: la mappa che ci serve.

La IEC 62443 è lo standard internazionale di riferimento per la cybersecurity dei sistemi industriali OT, progettato per proteggere dispositivi, sistemi integrati e reti da minacce digitali lungo tutto il ciclo di vita. Ha un suo ruolo unificante. Ampiamente raccomandata nella documentazione di compliance NIS2 come quadro tecnico per la protezione di infrastrutture e servizi critici, può dimostrare in maniera concreta la sicurezza dei prodotti digitali secondo il CRA, e fornisce i criteri per la corretta integrazione della cybersecurity nei sistemi macchine richiesta dal Regolamento Macchine. Adottarla non è un vezzo; anzi, significa armonizzare i requisiti di sicurezza IT e OT in un unico quadro coerente, verificabile e continuo lungo tutto il ciclo di vita dell’impianto o del prodotto con elementi digitali.

La struttura dello standard si articola su quattro layer fondamentali, ciascuno con un perimetro di applicazione preciso:

Component layer: riguarda i singoli dispositivi e moduli, con requisiti di autenticazione, gestione sicura delle credenziali, protezione contro configurazioni errate e resilienza a vulnerabilità note.
System layer: considera l’integrazione dei componenti in un sistema, la segmentazione interna, la gestione di utenti e ruoli e la protezione dei canali di comunicazione.
Zone & conduit layer: dedicato alla segmentazione delle reti OT in zone di sicurezza e conduit protetti, con firewall industriali e monitoraggio continuo per evitare la propagazione di compromissioni tra aree separate dell’impianto.
Lifecycle/organizational layer: copre la gestione dei processi organizzativi, la gestione delle vulnerabilità, il patching, gli audit periodici e la documentazione lungo tutto il ciclo di vita.

Due parti dello standard meritano attenzione particolare per chi deve dimostrare conformità normativa.

IEC 62443-4-1

Definisce i requisiti del Secure Product Development Lifecycle (SDL): gestione dei requisiti di sicurezza, tracciabilità delle vulnerabilità, controllo di configurazione, test di sicurezza e verifica durante lo sviluppo.

IEC 62443-4-2

Definisce i requisiti tecnici dei componenti, Component Security Requirements (CSR), tra cui autenticazione, protezione delle comunicazioni, gestione sicura di credenziali e log, resistenza a vulnerabilità note e controlli di configurazione. Il certificato IEC 62443-4 attesta che sia il processo di sviluppo sia i componenti soddisfano questi requisiti, offrendo una sicurezza verificabile e standardizzata che i regolatori riconoscono.

Per essere compliant, un’organizzazione deve implementare controlli tecnici e procedurali su tutti i layer, documentare tutte le misure di sicurezza, effettuare test periodici, gestire vulnerabilità e aggiornamenti, e garantire responsabilità chiare tra manufacturer, integratori e operatori. Un approccio che, non a caso, rispecchia la logica distribuita della responsabilità che abbiamo visto in ciascuno dei quattro regolamenti: nessun attore è esonerato, ogni ruolo nella filiera ha obblighi propri.

Chi adotta la IEC 62443 non percorre quattro labirinti separati: ne percorre uno solo, con un filo che attraversa tutti e quattro i confini normativi contemporaneamente.

Retrofit o revamping: non è la stessa cosa

Il retrofit consiste nel sostituire o aggiornare componenti di un impianto esistente mantenendone la funzione originale: un nuovo azionamento al posto di uno obsoleto, un sensore più preciso in sostituzione di uno usurato, un’interfaccia aggiornata senza toccare la logica di controllo. L’impianto fa la stessa cosa di prima, in modo più efficiente o con componenti più recenti. In linea generale, un retrofit ben eseguito non altera il comportamento sicuro della macchina e non richiede nuova certificazione CE, a patto che non introduca nuovi rischi.

Il revamping è un’altra cosa. Comporta una modifica sostanziale della funzione, della logica di controllo, dell’automazione o della sicurezza dell’impianto. Si aggiungono capacità nuove, si cambia il modo in cui la macchina decide, si integrano sistemi che prima non c’erano. Qui il perimetro normativo si riapre.

La distinzione non è sempre netta nella pratica, ed è esattamente per questo che vale la pena capirla prima di approvare un intervento.

Il caso dell’estensione di impianto

Uno dei casi più ambigui e più frequenti è l’estensione di un impianto esistente. Si aggiunge una nuova cella, una nuova linea, un nuovo braccio robotico. L’intervento sembra circoscritto, ma il discrimine normativo non è la dimensione fisica dell’estensione: è chi controlla l’estensione.

Se la nuova sezione ha sistemi di controllo e safety propri e indipendenti, può essere certificata come macchina nuova autonoma. L’intervento è limitato: la nuova sezione ottiene la sua marcatura CE, l’impianto esistente rimane sotto il regime precedente.

Se invece la nuova sezione si aggancia ai sistemi di controllo esistenti, condividendone la logica di sicurezza, i PLC, le funzioni di emergenza, i circuiti di interblocco, allora l’intervento non è più circoscritto. La modifica è diffusa sull’intero impianto e trascina con sé la rivalutazione dell’insieme. In questo caso chi esegue la modifica diventa legalmente il nuovo fabbricante dell’intero sistema, con tutti gli obblighi che ne conseguono.

La domanda pratica da porsi non è “quanto è grande l’estensione?” ma “la nuova sezione condivide la logica di sicurezza con l’impianto esistente?”

Quando alzare la testa: i campanelli d’allarme

Lo abbiamo introdotto parlando del Nuovo Regolamento Macchine, ma vale la pena approfondire il concetto. Non tutti gli interventi richiedono una revisione normativa approfondita, ma alcuni segnali indicano che vale la pena fermarsi a riflettere prima di procedere:

Si introduce o sostituisce software con funzioni di controllo o sicurezza, anche solo un aggiornamento che aggiunge nuove funzionalità di automazione.
Si aggiungono componenti digitali connessi: sensori IoT, moduli di comunicazione, accessi remoti. Se il componente interagisce con sistemi digitali, può attivare il perimetro CRA.
Si integra un modulo AI o si modifica la logica di automazione in modo che il sistema prenda decisioni in autonomia che prima non prendeva.
La macchina opera in un contesto soggetto a NIS2: chi la utilizza è un operatore di infrastruttura critica, e la supply chain di quel sistema rientra negli obblighi di sicurezza.
Si cambia fornitore di un componente critico, non solo il componente fisico, ma la sua documentazione, il suo firmware, il suo ciclo di aggiornamenti.

Nessuno di questi punti è automaticamente un problema: sono semplicemente i momenti in cui una valutazione preliminare costa molto meno di una non conformità scoperta a valle.

Consigli operativi

Prima di avviare un progetto di revamping, alcune azioni concrete riducono significativamente il rischio normativo:

Analisi preliminare cross-normativa: mappare quali regolamenti sono potenzialmente coinvolti dall’intervento (Regolamento Macchine, CRA, NIS2, AI Act) prima di definire il perimetro tecnico del progetto.
Chiarire i ruoli nella filiera: chi progetta, chi integra, chi fornisce i componenti digitali, chi opera l’impianto. Ogni ruolo ha obblighi specifici e la sovrapposizione non chiarita è la principale fonte di lacune documentali.
Coinvolgere un Notified Body quando necessario: per le categorie di macchine ad alto rischio o quando l’intervento tocca funzioni di sicurezza primarie, la valutazione di un organismo notificato non è solo un obbligo, è una protezione.
Predisporre SBOM e tracciabilità: un Software Bill of Materials aggiornato sui componenti digitali introdotti nell’intervento è il primo strumento di vulnerability management e di dimostrazione della conformità CRA.
Usare IEC 62443 come framework di documentazione: mappare zone e conduit dell’impianto modificato, definire il security level target della nuova configurazione, documentare i controlli minimi adottati e gestire l’integrazione tra sistemi legacy e componenti moderni. È il modo più efficace per rendere la compliance verificabile e comunicabile lungo tutta la filiera.

Un revamping fatto con metodo non è solo un adeguamento tecnico: è l’occasione per portare un impianto legacy dentro il perimetro normativo in modo strutturato, trasformando un obbligo in una base documentale solida per i prossimi anni.

Conclusioni

In questo articolo abbiamo camminato in un labirinto reale, articolato e in continuo cambiamento. Le normative che abbiamo trattato, NIS2, CRA, AI Act e il Nuovo Regolamento Macchine, sono vincoli presenti, con date, sanzioni e autorità di controllo già attive.

Questi quattro guardiani presidiano dimensioni diverse e complementari: i processi interni delle organizzazioni, i prodotti digitali immessi sul mercato, la logica dei sistemi AI, la sicurezza fisica e digitale delle macchine. Le responsabilità sono distribuite lungo tutta la filiera e non esiste un attore esonerato, dal produttore all’utilizzatore finale. Le loro giurisdizioni si sovrappongono e queste sovrapposizioni non sono un difetto del sistema normativo europeo, ma espressione di una volontà da comprendere per controllarla.

Esiste un filo che aiuta a non perdersi in questo dedalo. La IEC 62443 non risolve la complessità normativa, ma offre un linguaggio tecnico comune, una struttura di documentazione verificabile e un framework di controllo che attraversa trasversalmente NIS2, CRA e Regolamento Macchine. Chi la adotta non percorre quattro percorsi di adeguamento separati, ma uno solo, più solido e più comunicabile verso clienti, auditor e autorità di controllo.

Il tesoro al centro di questo labirinto non è l’assenza di obblighi: è la conformità come vantaggio competitivo. Un’azienda che dimostra di gestire la cybersecurity lungo tutta la filiera, di documentare correttamente i propri prodotti digitali, di avere una governance del rischio informatico tracciabile e aggiornata, non sta solo evitando sanzioni, sta costruendo un asset. Di fronte a un mercato europeo sempre più esigente, la conformità CE estesa ai requisiti di cyber-resilienza è un argomento di vendita, un criterio di qualificazione nei bandi pubblici e un elemento di differenziazione nei confronti di competitor extra-europei che operano senza questi vincoli.

Le aziende che sapranno dimostrare sicurezza, tracciabilità e governance solida avranno un vantaggio competitivo duraturo.

In noname.solutions accompagniamo i nostri clienti in questo percorso: dalla progettazione di sistemi sicuri alla documentazione tecnica, dal secure development lifecycle alla gestione della supply chain digitale.
Per noi applicare i cardini di queste norme non significa solo rispettare vincoli legislativi, ma progettare prodotti e servizi che rimangano affidabili nel tempo.

“Ogni nuova tecnologia merita entusiasmo, ma anche silenzio e riflessione. Prima di chiedere a una macchina di decidere per noi, proviamo a chiederci cosa stiamo smettendo di decidere insieme”
— citazione originale nata in noname.solutions

👉🏻 Contattaci per valutare insieme il tuo punto di partenza.

Il labirinto europeo – NIS2, CRA, AI Act e Nuovo Regolamento Macchine: cosa cambia davvero e come orientarsi