Se la tua azienda sviluppa e vende un prodotto con dentro l'intelligenza artificiale — un'app, un plug-in, un agente installabile, un dispositivo connesso — c'è un obbligo che è già in vigore e che nella conversazione sull'AI Act passa quasi inosservato. Dall'11 settembre 2026 devi segnalare entro 24 ore le vulnerabilità del prodotto sfruttate attivamente. Non lo dice l'AI Act: lo dice il Cyber Resilience Act (CRA), il Regolamento (UE) 2024/2847.
L'AI Act ha spostato in avanti l'alto rischio; il CRA no. E vale per qualsiasi prodotto con elementi digitali, non solo per l'IA ad alto rischio.
Che cos'è il Cyber Resilience Act e quando si applica
Il CRA fissa requisiti di cybersicurezza obbligatori per i prodotti con elementi digitali: software o hardware, comprese le loro soluzioni di elaborazione dati da remoto (Art. 3, punti 1 e 2). Il calendario è in due tempi:
| Data | Cosa si applica |
|---|---|
| 10 dicembre 2024 | Entrata in vigore |
| 11 settembre 2026 | Obblighi di segnalazione (Art. 14): vulnerabilità sfruttate attivamente e incidenti gravi |
| 11 dicembre 2027 | Applicazione piena: requisiti essenziali (Allegato I), valutazione di conformità, marcatura CE |
Il punto che sfugge: in base all'Art. 69, par. 3, le segnalazioni valgono anche per i prodotti già immessi sul mercato prima dell'11 dicembre 2027. Il software che hai venduto l'anno scorso è già coperto.
Chi è dentro e chi è fuori
- Dentro: app desktop e mobile, librerie e SDK commercializzati, agenti e componenti installabili, firmware, dispositivi IoT con modelli a bordo — più il backend che hai progettato tu e senza cui il prodotto non funziona.
- In genere fuori: il SaaS puro, erogato interamente da remoto e che non accompagna un prodotto distribuito. Il Considerando 12 esclude i servizi cloud progettati fuori dalla responsabilità di un fabbricante.
La linea passa per l'architettura, non per l'etichetta commerciale: un «SaaS» che richiede un client installato va analizzato.
Le segnalazioni in 24 ore: cosa prevede l'Art. 14
Quando vieni a conoscenza di una vulnerabilità sfruttata attivamente o di un incidente grave che incide sulla sicurezza del prodotto, notifichi contemporaneamente al CSIRT designato come coordinatore nello Stato membro del tuo stabilimento principale e all'ENISA, tramite la piattaforma unica di segnalazione:
- Preallarme entro 24 ore, indicando dove possibile gli Stati membri in cui il prodotto è distribuito.
- Notifica entro 72 ore, con natura del problema, misure correttive adottate e misure che gli utenti possono applicare.
- Relazione finale: entro 14 giorni dalla disponibilità della correzione (vulnerabilità) o entro un mese dalla notifica (incidente grave).
In più, l'Art. 14, par. 8 impone di informare gli utenti impattati e le misure che possono adottare. Un incidente è «grave» se compromette, o può compromettere, la disponibilità, autenticità, integrità o riservatezza di dati o funzioni importanti, oppure porta all'esecuzione di codice malevolo nel prodotto o nei sistemi dell'utente.
Questa catena è distinta dalla segnalazione degli incidenti gravi dell'art. 73 dell'AI Act e dal data breach GDPR (72 ore al Garante): lo stesso evento può attivarle tutte e tre.
Dove CRA e AI Act si toccano
Per un prodotto che è anche un sistema di IA ad alto rischio (Art. 6 del Regolamento UE 2024/1689), l'Art. 12 del CRA crea un raccordo:
- se il prodotto soddisfa i requisiti essenziali dell'Allegato I del CRA (prodotto e processi) e la dichiarazione UE di conformità lo dimostra, si presume conforme ai requisiti di cybersicurezza dell'art. 15 dell'AI Act;
- la valutazione di conformità segue di regola la procedura dell'art. 43 dell'AI Act, che copre anche i requisiti CRA; fanno eccezione i prodotti «importanti» o «critici» del CRA valutati con il solo controllo interno AI Act.
Ma l'art. 15 dell'AI Act chiede anche accuratezza e robustezza, e nomina minacce proprie dell'IA: avvelenamento dei dati, avvelenamento del modello, esempi avversari, attacchi alla riservatezza, difetti del modello. Il CRA non le copre al posto tuo. Ricorda poi le date diverse: per l'alto rischio, dopo il Digital Omnibus (Regolamento UE 2026/1744), si parla di 2 dicembre 2027 (Allegato III) e 2 agosto 2028 (Allegato I); la segnalazione CRA corre già oggi.
Le cinque cose da mettere in piedi adesso
- Mappa i prodotti: per ogni prodotto distribuito, decidi se è nel perimetro CRA e documenta perché (soprattutto per i casi SaaS «ibridi»).
- Inventaria i componenti (SBOM): modelli, librerie open source, SDK di terze parti. L'Art. 13, par. 5 chiede due diligence sui componenti di terzi, open source compreso.
- Scrivi la procedura delle 24 ore: chi decide che una vulnerabilità è «sfruttata attivamente», chi notifica sulla piattaforma ENISA, chi informa i clienti. Prova la catena con una simulazione.
- Aggiungi i rischi specifici dell'IA alla gestione delle vulnerabilità: prompt injection, estrazione di dati di addestramento, manipolazione dei modelli acquistati.
- Fissa il periodo di supporto: dal 2027 il fabbricante dovrà gestire le vulnerabilità per un periodo pari alla vita attesa del prodotto e, di regola, non inferiore a cinque anni (Art. 13, par. 8). Va prezzato nei contratti oggi.
Quanto costa sbagliare
Fino a 15 milioni di euro o il 2,5% del fatturato mondiale annuo per la violazione dei requisiti essenziali e degli obblighi degli artt. 13 e 14 (Art. 64, par. 2). Micro e piccole imprese non sono sanzionabili per il solo ritardo sul preallarme di 24 ore (Art. 64, par. 10), ma restano tenute a notificare.
Da dove partire
Se sviluppi prodotti con IA, la domanda giusta non è «sono ad alto rischio?» ma «quali dei miei prodotti sono già soggetti agli obblighi di segnalazione, e la mia procedura regge 24 ore?». Una gap assessment indipendente sul perimetro CRA e sul raccordo con l'AI Act ti dà la risposta, con priorità e responsabilità, prima che te la chieda un'autorità.