La tecnica offensiva denominata “ghostjacking” descrive una situazione nella quale un’azione apparentemente innocua — l’inserimento di una voce manipolata in un registro di sicurezza o in un log di sistema — è sufficiente a indurre un agente di intelligenza artificiale aziendale a eseguire operazioni dannose, trasformandolo di fatto in uno strumento di attacco interno. La tecnica si colloca nell’ampia famiglia delle “prompt injection” indirette, già oggetto di attenzione da parte dell’ENISA e dell’OWASP, e presenta caratteri di particolare insidiosità perché non richiede accesso diretto ai sistemi bersaglio: l’agente AI, dotato di permessi legittimi, diventa il veicolo dell’offesa.

Per quanto di stretto interesse in questa sede, il fenomeno si colloca all’intersezione di tre grandi corpi normativi europei che si trovano in fase di piena applicazione o di progressiva entrata a regime: il Regolamento (UE) 2016/679 (GDPR), il Regolamento (UE) 2024/1689 sull’intelligenza artificiale (AI Act), e la Direttiva (UE) 2022/2555 in materia di sicurezza delle reti e dei sistemi informativi (NIS2), recepita in Italia con il decreto legislativo 4 settembre 2024, n. 138. Vengono inoltre in rilievo le Linee Guida dell’EDPB, i provvedimenti del Garante per la protezione dei dati personali e le indicazioni operative emanate dall’Agenzia per la Cybersicurezza Nazionale (ACN).

Il presente contributo si propone di analizzare la natura tecnica e giuridica del ghostjacking, di mappare il quadro normativo applicabile e di fornire indicazioni operative per i DPO e i responsabili della compliance nelle organizzazioni che impiegano sistemi di intelligenza artificiale agentica.

La tecnica del ghostjacking: definizione, meccanismo e tassonomia

Il termine “ghostjacking” — va detto sin dall’inizio — non è ancora consolidato nella letteratura tecnica ufficiale né è oggetto di una definizione normativa. Si tratta, infatti, di una denominazione emergente per una variante evoluta di prompt injection indiretta, nella quale il vettore di attacco non è un input dell’utente umano all’agente AI, bensì un dato esterno che l’agente legge autonomamente nel corso della propria operatività.

In termini più pragmatici: un agente AI aziendale — si pensi a un sistema di monitoraggio della sicurezza, a un assistente alla gestione degli incidenti, o a un copilot integrato nei sistemi DevOps — opera leggendo fonti di dati strutturati: log di sistema, registri di eventi, database di ticket, output di tool di orchestrazione. Se uno di questi dati contiene una stringa progettata per essere interpretata come istruzione dall’agente, quest’ultimo può eseguire l’istruzione stessa con i propri privilegi, che sono per definizione legittime credenziali di sistema.

La differenza rispetto alla prompt injection diretta — già ampiamente studiata — risiede nella superficie di attacco. Mentre la prompt injection diretta richiede accesso all’interfaccia utente del modello, quella indiretta, di cui il ghostjacking è una declinazione, sfrutta la catena di approvvigionamento dei dati che l’agente elabora.

L’ENISA, nel suo rapporto sulle minacce emergenti ai sistemi di AI (ENISA, Threat Landscape for Artificial Intelligence), ha già censito le prompt injection indirette come una delle principali categorie di rischio per i sistemi di intelligenza artificiale dispiegati in contesti aziendali. Analogamente, l’OWASP Top 10 for Large Language Model Applications annovera la “Indirect Prompt Injection” tra le vulnerabilità critiche per i sistemi LLM.

Il ghostjacking si distingue ulteriormente per il fatto che il vettore di iniezione è specificamente un registro di sicurezza o un log di evento, ovvero un dato che per sua natura è letto frequentemente dagli agenti di monitoraggio e che gode di un livello di fiducia elevato nell’architettura di sicurezza dell’organizzazione. Trattasi, in altri termini, di un attacco che mina la catena di fiducia interna ai sistemi informativi, sfruttando le stesse misure difensive come punto di ingresso.

Il quadro normativo di riferimento

Il Regolamento (UE) 2016/679 (GDPR)

Il GDPR non disciplina direttamente gli agenti di intelligenza artificiale né le tecniche di prompt injection, ma fornisce il quadro entro cui valutare le conseguenze di un attacco ghostjacking quando questo coinvolge dati personali — circostanza tutt’altro che ipotetica, considerato che i log di sistema spesso contengono informazioni personali riferibili a dipendenti, utenti o soggetti terzi.

L’articolo 5, paragrafo 1, lettera f), del GDPR sancisce il principio di “integrità e riservatezza”, imponendo che i dati personali siano trattati in maniera da garantirne “un’adeguata sicurezza […], compresa la protezione, mediante misure tecniche e organizzative adeguate, da trattamenti non autorizzati o illeciti e dalla perdita, dalla distruzione o dal danno accidentali.” Un agente AI compromesso che accede, esfiltra o modifica dati personali costituisce per definizione un trattamento non autorizzato, con conseguente violazione del principio di integrità e riservatezza.

L’articolo 32 GDPR, che declina il principio di sicurezza in obblighi concreti, richiede al titolare e al responsabile del trattamento di adottare misure tecniche e organizzative adeguate, tenendo conto — tra gli altri elementi — “della natura, dell’ambito di applicazione, del contesto e delle finalità del trattamento, nonché del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche.” È di immediata evidenza che un sistema di AI agentica con accesso a repository di dati personali configura un contesto ad elevato rischio, che impone misure corrispondentemente rafforzate.

L’articolo 33 GDPR disciplina la notifica al Garante in caso di violazione dei dati personali, fissando il termine di settantadue ore dalla conoscenza dell’evento. Un attacco ghostjacking che determini accesso non autorizzato, perdita o alterazione di dati personali costituisce, ad ogni evidenza, una “violazione dei dati personali” ai sensi dell’articolo 4, paragrafo 12, GDPR, con conseguente obbligo di notifica — salvo che l’organizzazione sia in grado di dimostrare che “è improbabile che la violazione dei dati personali presenti un rischio per i diritti e le libertà delle persone fisiche.” Questa condizione appare difficilmente sostenibile quando l’agente compromesso aveva accesso a sistemi sensibili.

La Data Protection Impact Assessment (DPIA), prevista dall’articolo 35 GDPR, riveste un ruolo centrale: si ritiene che qualunque sistema di AI agentica con accesso a dati personali e con capacità di azione autonoma su sistemi informativi debba essere soggetto a DPIA preliminare, in ragione dell’elevato rischio strutturale che presenta. Il Garante italiano ha già indicato, nei propri provvedimenti in materia di AI, che i sistemi dotati di autonomia decisionale e accesso massivo a dati personali rientrano nelle categorie per le quali la DPIA è obbligatoria.

Il Regolamento (UE) 2024/1689 (AI Act)

L’AI Act, entrato in vigore il 1° agosto 2024, con applicazione progressiva delle diverse disposizioni sino al 2027, introduce un sistema di classificazione dei sistemi di AI per livello di rischio che rileva direttamente ai fini dell’analisi del ghostjacking.

Va detto che la categoria degli “agenti AI” non è disciplinata dall’AI Act con una norma ad hoc: la nozione di “sistema di intelligenza artificiale” rilevante è quella dell’articolo 3, paragrafo 1, AI Act, che definisce il sistema di AI come “un sistema automatizzato progettato per funzionare con livelli di autonomia variabili e che, per obiettivi espliciti o impliciti, inferisce, a partire dagli input che riceve, come generare output quali previsioni, contenuti, raccomandazioni o decisioni che possono influenzare ambienti fisici o virtuali.” Gli agenti AI aziendali rientrano senza difficoltà in questa definizione.

La classificazione per livello di rischio dell’AI Act determina gli obblighi applicabili. Per i sistemi di AI ad “alto rischio” — che includono, ai sensi dell’Allegato III, i sistemi destinati a essere utilizzati come componenti di sicurezza nella gestione e nel funzionamento delle infrastrutture digitali critiche — l’AI Act impone una serie di requisiti di robustezza, trasparenza e supervisione umana che appaiono direttamente pertinenti al problema del ghostjacking.

In particolare, l’articolo 9 AI Act richiede l’adozione di un sistema di gestione dei rischi “continuo e iterativo”, che identifichi e mitighi i rischi noti e ragionevolmente prevedibili per i sistemi ad alto rischio. L’articolo 15 impone requisiti di “accuratezza, robustezza e cybersicurezza”, stabilendo che i sistemi di AI ad alto rischio devono essere “progettati e sviluppati in modo da raggiungere un livello appropriato di accuratezza, robustezza e cybersicurezza” e “da resistere, nei limiti del ragionevole, ai tentativi di soggetti terzi non autorizzati di alterarne l’uso, gli output o le prestazioni attraverso l’utilizzo di vulnerabilità.” Il ghostjacking è per l’appunto un tentativo di questo tipo.

L’articolo 14 AI Act disciplina la “supervisione umana” (human oversight), richiedendo che i sistemi ad alto rischio siano progettati in modo da consentire agli utenti di monitorare il funzionamento e di intervenire, sospendere o interrompere l’operatività del sistema. Questa previsione ha un’immediata ricaduta sulla progettazione degli agenti AI: un sistema privo di meccanismi efficaci di supervisione umana che venga compromesso tramite ghostjacking non solo subisce un danno, ma viola anche i requisiti strutturali dell’AI Act.

Per i sistemi di AI a uso generale (General Purpose AI — GPAI), disciplinati dagli articoli da 51 a 56 AI Act, vigono obblighi specifici per i fornitori, tra cui la predisposizione di politiche di sicurezza e la documentazione delle capacità e limitazioni del modello. Chi integra un modello GPAI in un agente aziendale riveste spesso anche il ruolo di “deployer” ai sensi dell’AI Act, con obblighi corrispondenti in materia di monitoraggio e supervisione.

La Direttiva NIS2 e il decreto legislativo n. 138/2024

La Direttiva (UE) 2022/2555 (NIS2), recepita in Italia con il decreto legislativo 4 settembre 2024, n. 138, introduce obblighi di sicurezza informatica per i soggetti essenziali e importanti operanti in settori critici. Per quanto di stretto interesse in questa sede, la NIS2 rileva sotto tre profili principali.

Il primo profilo riguarda le misure di sicurezza. L’articolo 21 della Direttiva NIS2 — recepito dall’articolo 24 del d.lgs. 138/2024 — impone ai soggetti interessati di adottare misure tecniche, operative e organizzative “adeguate e proporzionate” per gestire i rischi posti alla sicurezza dei sistemi informativi, tra cui esplicitamente: la gestione degli incidenti, la sicurezza della catena di approvvigionamento, le pratiche di igiene informatica di base, le politiche relative all’uso della crittografia, la sicurezza delle risorse umane e il controllo degli accessi. Un sistema di AI agentica compromesso tramite ghostjacking costituisce tipicamente un incidente di sicurezza rilevante ai fini della NIS2.

Il secondo profilo riguarda la notifica degli incidenti. L’articolo 23 della Direttiva NIS2 — recepito dall’articolo 25 del d.lgs. 138/2024 — prevede una procedura di notifica articolata: un “preallarme” entro ventiquattro ore dalla conoscenza dell’incidente significativo, una notifica completa entro settantadue ore, e una relazione finale entro un mese. L’ACN è il CSIRT nazionale designato per la ricezione delle notifiche. Un attacco ghostjacking che comprometta sistemi rilevanti di un soggetto essenziale o importante è suscettibile di configurare un “incidente significativo” ai sensi dell’articolo 23, paragrafo 3, della Direttiva.

Il terzo profilo riguarda la responsabilità del management. L’articolo 20 della Direttiva NIS2 — recepito dall’articolo 23 del d.lgs. 138/2024 — impone agli organi di gestione dei soggetti essenziali e importanti di approvare le misure di sicurezza, di supervisionarne l’attuazione e di rispondere personalmente in caso di violazione. Ciò implica che la decisione di dispiegare sistemi di AI agentica senza adeguata analisi del rischio non è una questione tecnica delegabile, ma una decisione di governance con conseguenze dirette in capo al management.

Le Linee Guida dell’EDPB e i provvedimenti del Garante

L’EDPB ha adottato, nel corso degli anni, diversi documenti rilevanti per il tema in esame, unitamente a quelli ereditati dal Gruppo di lavoro Articolo 29. [Nota redazionale: verificare gli estremi di eventuali linee guida EDPB in materia di uso di sistemi di AI nel contesto lavorativo prima della pubblicazione; le Linee Guida 05/2022 hanno per oggetto l’uso della tecnologia di riconoscimento facciale da parte delle autorità di contrasto.] Il Parere 2/2017 del Gruppo di lavoro Articolo 29 sul trattamento dei dati sul luogo di lavoro (WP 249) rileva per i log di sistema che contengano dati riferibili ai dipendenti.

Il Garante per la protezione dei dati personali ha mostrato un’attenzione crescente ai sistemi di AI: si ricordano, in questa sede, i provvedimenti in materia di ChatGPT (provvedimento del 30 marzo 2023 e successivi aggiornamenti), che hanno fissato principi applicabili anche ai sistemi di AI dispiegati in contesti aziendali, e le indicazioni generali sui sistemi di monitoraggio dei lavoratori che impiegano tecnologie di AI. Non si ha evidenza, alla data del presente contributo, di provvedimenti specifici del Garante in materia di prompt injection o ghostjacking, ma le categorie concettuali già elaborate sono pienamente applicabili.

Analisi giuridica del fenomeno: responsabilità, qualificazioni e nessi causali

La qualificazione del ghostjacking come trattamento non autorizzato

Quando un agente AI compromesso tramite ghostjacking accede, copia, modifica o trasmette dati personali, si realizza un trattamento non autorizzato ai sensi del GDPR. La peculiarità giuridica del fenomeno sta nel fatto che l’agente opera con credenziali legittime: non vi è, dal punto di vista tecnico, un accesso non autorizzato nel senso tradizionale (violazione di autenticazione o bypass di controllo degli accessi), ma vi è un uso distorto di accessi legittimi per finalità non autorizzate.

Questa circostanza non esclude la violazione del GDPR: il principio di “limitazione della finalità” di cui all’articolo 5, paragrafo 1, lettera b), GDPR impone che i dati personali siano trattati “per finalità determinate, esplicite e legittime, e successivamente trattati in modo che non sia incompatibile con tali finalità.” L’uso dell’agente AI per finalità imposte da un attaccante esterno è manifestamente incompatibile con qualsiasi finalità determinata e legittima.

Il nesso di causalità e la responsabilità del titolare del trattamento

Un profilo problematico — e, secondo il parere di chi scrive, tra i più interessanti sotto il profilo dogmatico — riguarda il nesso di causalità tra la condotta del titolare del trattamento e il danno prodotto dall’attacco ghostjacking.

Il GDPR adotta, all’articolo 82, un regime di responsabilità civile per danni derivanti da violazione del Regolamento che prevede un’inversione dell’onere della prova: il titolare o il responsabile è responsabile del danno cagionato da un trattamento non conforme al GDPR, salvo che dimostri “che l’evento dannoso non gli è in alcun modo imputabile.” La Corte di Giustizia dell’Unione Europea, nella sentenza del 4 maggio 2023 (causa C-300/21, UI c. Österreichische Post AG), ha chiarito che non esiste una soglia minima di gravità del danno per l’accesso al risarcimento, ma che il danno deve essere reale e non meramente ipotetico.

Il titolare del trattamento che ha dispiegato un agente AI senza adeguata analisi del rischio, senza DPIA, senza misure di sicurezza appropriate ai sensi dell’articolo 32 GDPR, difficilmente potrà invocare l’esonero da responsabilità. La robustezza del sistema rispetto alle prompt injection è da considerarsi un rischio “ragionevolmente prevedibile” — come attestano i documenti ENISA e OWASP già citati — e la sua mancata considerazione configura culpa in eligendo e in vigilando.

La responsabilità ai sensi dell’AI Act

L’AI Act introduce, agli articoli 72 e seguenti, un sistema di sorveglianza del mercato e di enforcement. Per i sistemi ad alto rischio, la mancata adozione delle misure di cybersicurezza previste dall’articolo 15 può comportare sanzioni amministrative sino a 15 milioni di euro o al 3% del fatturato mondiale annuo totale, a seconda di quale importo sia superiore, ai sensi dell’articolo 99, paragrafo 4, AI Act.

A livello nazionale, si applica il regime generale della responsabilità extracontrattuale e, per i produttori di sistemi AI, il Codice del Consumo e la normativa sui prodotti difettosi.

Il profilo penale: la rilevanza del reato informatico

Sotto il profilo penale, l’attacco ghostjacking — nella fase realizzata dall’aggressore — può integrare diverse fattispecie del codice penale italiano. L’articolo 615-ter c.p. (accesso abusivo a un sistema informatico) potrebbe essere integrato dalla condotta dell’aggressore che inserisce la stringa malevola nel log, qualora ciò implichi accesso non autorizzato al sistema di logging. L’articolo 617-quater c.p. (intercettazione, impedimento o interruzione illecita di comunicazioni informatiche) e l’articolo 635-bis c.p. (danneggiamento di informazioni, dati e programmi informatici) possono rilevare a seconda dell’esito dell’attacco.

Per l’organizzazione vittima, il profilo penale rileva indirettamente: la mancata adozione di misure di sicurezza adeguate può essere elemento valutabile nell’ambito del d.lgs. 231/2001, qualora l’ente non abbia adottato un modello organizzativo adeguato che preveda presidi specifici per i rischi connessi all’uso di sistemi AI.

Profili critici: le zone grigie del quadro normativo vigente

L’assenza di una disciplina specifica per gli agenti AI

Si ritiene che una delle lacune più significative del quadro normativo vigente sia l’assenza di una disciplina specifica per gli agenti AI autonomi — ossia per quei sistemi che non si limitano a generare testo o raccomandazioni, ma che compiono azioni concrete su sistemi informativi, interagiscono con API esterne, modificano database, inviano comunicazioni.

L’AI Act disciplina i “sistemi di AI” in senso lato, ma non contiene una regolamentazione ad hoc dell’AI agentica, la cui specificità risiede proprio nella capacità di azione autonoma e nella conseguente amplificazione del rischio. Nè si ha evidenza, allo stato, di documenti interpretativi da parte della Commissione europea o dell’AI Office che colmino questa lacuna.

Il problema del “trust boundary” nei sistemi di logging

Un profilo tecnico-giuridico di notevole interesse riguarda la questione del “trust boundary” — ossia del perimetro di fiducia entro cui un sistema AI è autorizzato a operare. I log di sicurezza sono tradizionalmente considerati fonti affidabili nell’architettura di sicurezza aziendale: sono generati da sistemi interni, protetti da controlli di accesso, e letti da strumenti di analisi con elevati privilegi.

Il ghostjacking sovverte questa logica: trasforma una fonte fidata in vettore di attacco. Da un punto di vista giuridico, ciò pone la questione se il titolare del trattamento — e il produttore del sistema AI — debbano considerare anche le fonti di dati interne come potenzialmente compromesse, e dunque adottare misure di sanitizzazione degli input anche per i log di sistema.

Si ritiene che questa sia una misura che rientra nel novero di quelle “adeguate” ai sensi dell’articolo 32 GDPR e dell’articolo 15 AI Act, considerato lo stato attuale della conoscenza tecnica sul tema. In termini più pragmatici: un sistema AI che accetta come istruzione qualsiasi stringa contenuta in un log non ha implementato misure di sicurezza adeguate per il contesto in cui è dispiegato.

La sovrapposizione di regimi normativi e il rischio di frammentazione della compliance

Un ulteriore profilo critico riguarda la sovrapposizione — non sempre coordinata — tra GDPR, AI Act e NIS2 in relazione allo stesso evento. Un incidente ghostjacking che coinvolga dati personali e colpisca un soggetto essenziale ai sensi della NIS2 genera obblighi di notifica paralleli: al Garante (art. 33 GDPR, entro 72 ore), all’ACN/CSIRT nazionale (art. 25 d.lgs. 138/2024, entro 24 ore per il preallarme), e — qualora il sistema AI coinvolto sia ad alto rischio — eventualmente anche all’autorità di vigilanza sull’AI Act.

Appare chiaro allo scrivente che questa frammentazione dei canali di notifica e delle autorità competenti genera un rischio operativo significativo per le organizzazioni, che possono trovarsi a dover gestire contemporaneamente più procedimenti con tempistiche differenti e interlocutori diversi. Una risposta coordinata richiede che i piani di incident response siano predisposti tenendo conto di tutti e tre i regimi, con processi interni chiari e responsabilità assegnate.

Adempimenti per DPO e imprese

Alla luce di quanto sviluppato nei paragrafi precedenti, possono, a titolo esemplificativo, essere proposti alcuni adempimenti basilari per imprese e DPO strutturati secondo un approccio progressivo dalla fase di progettazione a quella di gestione degli incidenti.

Va innanzitutto effettuata la mappatura dei sistemi AI agentici. il DPO e il responsabile della sicurezza devono condurre una ricognizione completa dei sistemi di AI dotati di capacità di azione autonoma su sistemi informativi aziendali, distinguendo tra sistemi sviluppati internamente, sistemi acquisiti da fornitori e sistemi basati su modelli GPAI di terze parti. La mappatura deve includere le fonti di dati lette dall’agente (log, database, API, strumenti di orchestrazione), i privilegi di accesso di cui dispone e le azioni che è autorizzato a compiere.

Occorre, inoltre, procedere alla classificazione del rischio AI Act. Per ciascun sistema di AI agentica identificato, è necessario determinare la categoria di rischio applicabile ai sensi dell’AI Act (rischio inaccettabile, alto rischio, rischio limitato, rischio minimo) e verificare se il sistema rientra in una delle categorie dell’Allegato III. I sistemi di AI impiegati nella gestione della sicurezza informatica e nel controllo degli accessi sono candidati forti alla classificazione come sistemi ad alto rischio, con conseguente applicazione degli obblighi previsti dagli articoli da 9 a 16 AI Act.

Va eseguita la DPIA, perché per tutti i sistemi di AI agentici che trattano dati personali e presentano un rischio elevato, è obbligatoria l’esecuzione di una DPIA ai sensi dell’articolo 35 GDPR, prima del dispiegamento del sistema. La DPIA deve includere una valutazione specifica del rischio di prompt injection indiretta e ghostjacking, con descrizione delle misure di mitigazione adottate.

Analogamente, appare utile procedere ad una revisione architetturale dei sistemi AI. In collaborazione con i team tecnici, il DPO deve verificare che i sistemi AI agentici dispiegati implementino misure di sicurezza adeguate rispetto al rischio di ghostjacking, tra cui: separazione logica tra dati di configurazione e dati elaborati, sanitizzazione degli input provenienti da fonti esterne (inclusi i log di sistema), meccanismi di validazione delle istruzioni rispetto a un insieme predefinito di azioni autorizzate, e sistemi di logging delle azioni dell’agente AI separati dai log di sistema generali.

Essenziale, inoltre, appare l’aggiornamento dei contratti con i fornitori di AI, per cui le clausole contrattuali relative ai sistemi di AI forniti da terze parti devono essere integrate con previsioni specifiche in materia di sicurezza rispetto alle vulnerabilità di tipo prompt injection, obblighi di notifica in caso di scoperta di vulnerabilità nel sistema AI, e attestazioni di conformità all’articolo 15 AI Act per i sistemi ad alto rischio.

Di particolare importanza anche la formazione del personale. Infatti, i team che gestiscono sistemi di AI agentici devono ricevere formazione specifica sui rischi di prompt injection e ghostjacking, con particolare attenzione ai segnali di compromissione (comportamenti anomali dell’agente, azioni non attese, accessi a risorse non usuali) e alle procedure di escalation e contenimento.

I piani di incident response devono essere aggiornati per includere scenari specifici di compromissione di agenti AI, con indicazione delle soglie di notifica, dei canali di comunicazione (Garante e ACN) e dei responsabili interni. Il piano deve prevedere la possibilità di sospendere immediatamente l’operatività dell’agente AI compromesso senza interrompere i sistemi sottostanti.

Sotto il profilo degli adempimenti GDPR, occorrerà procedere alla revisione dei registri delle attività di trattamento (RAT). il registro ex articolo 30 GDPR deve essere aggiornato per includere i trattamenti di dati personali effettuati tramite agenti AI, con indicazione specifica delle fonti di dati elaborate, delle finalità, delle categorie di dati coinvolti e delle misure di sicurezza adottate. Sotto lo stesso profilo, dovrà procedersi alla supervisione del fornitore di AI come responsabile del trattamento, poiché qualora il sistema AI sia gestito da un fornitore esterno che accede a dati personali dell’organizzazione, è necessario verificare la sussistenza di un accordo di responsabilità del trattamento ai sensi dell’articolo 28 GDPR, con previsione specifica degli obblighi di sicurezza applicabili ai sistemi di AI agentici.

Da ultimo, occorrerà verificare la conformità NIS2 dei sistemi in uso, perché i soggetti che rientrano nell’ambito di applicazione del d.lgs. 138/2024 devono verificare che la gestione del rischio connesso ai sistemi di AI agentici sia integrata nel sistema di gestione della sicurezza informatica richiesto dall’articolo 24 del decreto, con documentazione delle misure adottate e dei processi di revisione periodica.

Considerazioni sulla progettazione sicura dei sistemi di AI agentica: il principio di “security by design”

Il principio di “privacy by design e by default” — sancito dall’articolo 25 GDPR e ispirato alla filosofia progettuale di Ann Cavoukian — trova un corrispondente nel principio di “security by design” che permea l’articolo 15 dell’AI Act e l’approccio NIS2 alla gestione del rischio. Per quanto di stretto interesse in questa sede, entrambi i principi impongono che la sicurezza non sia aggiunta ex post come strato superficiale, ma sia integrata sin dalla fase di progettazione del sistema.

In termini più pragmatici: un sistema di AI agentica che non sia stato progettato tenendo conto del rischio di prompt injection indiretta non potrà essere reso sicuro semplicemente aggiungendo filtri successivi. Le scelte architetturali fondamentali — la definizione del “trust boundary” dell’agente, il meccanismo di validazione degli input, l’insieme delle azioni autorizzate, i meccanismi di supervisione umana — devono essere effettuate sin dall’inizio, con documentazione adeguata delle scelte e delle motivazioni.

L’ENISA, nelle proprie linee guida sulla sicurezza dei sistemi di AI, raccomanda l’adozione di un approccio “least privilege” per gli agenti AI: l’agente deve disporre del minimo insieme di privilegi necessari per svolgere il proprio compito, in modo che una sua eventuale compromissione abbia un impatto limitato. Questo principio — ben noto nell’ambito della sicurezza informatica tradizionale — assume un’importanza ancora maggiore nel contesto dei sistemi AI agentici, che per loro natura tendono ad accumulare permessi per poter operare in modo efficace.

Si suggerisce, in questa prospettiva, di adottare un modello di “sandboxing” per gli agenti AI: confinare l’operatività dell’agente in un ambiente controllato, con accessi limitati e monitorati, e con meccanismi di approvazione umana per le azioni ad alto impatto. Questo approccio è coerente con il requisito di supervisione umana dell’articolo 14 AI Act e con il principio di minimizzazione del rischio del GDPR.

Il ruolo del DPO nella governance dei sistemi di AI agentica

Il DPO — figura prevista dall’articolo 37 GDPR e dotata dei compiti di cui all’articolo 39 — è chiamato a svolgere un ruolo centrale nella governance dei sistemi di AI agentica, ruolo che va ben oltre la tradizionale consulenza in materia di trattamento dei dati personali.

In termini più concreti: il DPO deve essere coinvolto sin dalla fase di selezione e progettazione dei sistemi di AI agentici, non solo nella fase di implementazione o, peggio, di risposta agli incidenti. Questo coinvolgimento precoce è funzionale alla conduzione della DPIA, alla valutazione delle misure di sicurezza adottate e alla verifica della conformità al GDPR e all’AI Act.

Va detto che l’AI Act introduce, accanto al DPO, ulteriori figure di governance: il “deployer responsabile” dei sistemi ad alto rischio (art. 26 AI Act) e — per i sistemi GPAI — gli obblighi specifici in capo al fornitore del modello. In sostanza, si profila un sistema di governance multilivello in cui DPO, CISO, Legal e management sono chiamati a operare in modo coordinato, con responsabilità e compiti chiaramente definiti.

Il tema della catena di approvvigionamento dell’AI: responsabilità lungo la filiera

Un profilo di crescente rilevanza pratica riguarda la catena di approvvigionamento dei sistemi di AI agentici. Nella maggior parte dei casi, un’organizzazione non sviluppa internamente il modello di AI che alimenta il proprio agente: acquista o licenzia un modello GPAI da un fornitore (tipicamente un grande operatore tecnologico internazionale), lo integra in un’architettura di orchestrazione, lo collega ai propri sistemi informativi e lo configura per i propri casi d’uso.

In questo schema, la responsabilità per le vulnerabilità del sistema — inclusa la suscettibilità a prompt injection indirette — è distribuita lungo la filiera. Il fornitore del modello GPAI è responsabile della robustezza intrinseca del modello rispetto alle tecniche di injection. Il fornitore del framework di orchestrazione è responsabile della sicurezza dell’architettura di integrazione. L’organizzazione deployer è responsabile della configurazione sicura, della definizione dei privilegi dell’agente e delle misure di supervisione.

L’AI Act affronta questo tema attraverso il sistema di obblighi differenziati per fornitori e deployer, ma — secondo il parere di chi scrive — non fornisce una risposta esaustiva al problema della responsabilità condivisa in caso di incidente che coinvolga più livelli della filiera. In assenza di una chiarificazione normativa o interpretativa, si suggerisce alle organizzazioni di disciplinare contrattualmente — in modo puntuale e non generico — la ripartizione delle responsabilità in caso di incidente connesso a vulnerabilità del sistema AI, incluse le vulnerabilità di tipo ghostjacking.

Conclusioni

Il ghostjacking, pur essendo una tecnica emergente ancora priva di una definizione normativa consolidata, rappresenta un caso esemplare delle tensioni che i sistemi di AI agentica introducono nel quadro giuridico europeo. Esso mette in evidenza almeno tre questioni aperte di rilievo sistematico, sulle quali si attende un’evoluzione normativa e interpretativa nei prossimi anni.

La prima questione riguarda l’adeguatezza del concetto di “misura tecnica adeguata” rispetto alla specificità dei rischi dell’AI agentica. L’articolo 32 GDPR e l’articolo 15 AI Act fanno entrambi riferimento a misure “adeguate” rispetto allo stato dell’arte e al rischio, ma la determinazione di cosa sia adeguato rispetto a tecniche di attacco come il ghostjacking richiede standard tecnici specifici che, alla data del presente contributo, non sono stati emanati né dall’ENISA né dall’AI Office. Si auspica che i prossimi documenti tecnici di questi organismi colmino questa lacuna.

La seconda questione riguarda la governance della catena di approvvigionamento dell’AI. La distribuzione della responsabilità tra fornitori di modelli, fornitori di framework di orchestrazione e deployer finali è, allo stato attuale, affidata principalmente alla contrattualistica privata, senza una disciplina normativa chiara.

La terza questione riguarda il coordinamento tra le autorità di supervisione. Un incidente ghostjacking che coinvolga dati personali, sistemi essenziali ai sensi della NIS2 e sistemi AI ad alto rischio genera, come si è visto, obblighi di notifica verso il Garante, verso l’ACN e — prospetticamente — verso l’autorità di vigilanza sull’AI Act. La frammentazione di questi canali, con tempistiche diverse e interlocutori diversi, costituisce un rischio operativo reale che richiede non solo adeguamenti interni alle organizzazioni, ma anche un coordinamento istituzionale tra le autorità nazionali. Non si ha evidenza, alla data del presente contributo, di meccanismi formali di coordinamento tra il Garante e l’ACN specificamente per gli incidenti che coinvolgano sistemi di AI, sebbene il d.lgs. 138/2024 preveda forme generali di cooperazione tra autorità.

In prospettiva evolutiva, appare chiaro allo scrivente che il quadro normativo europeo dovrà affrontare, nei prossimi anni, la sfida di disciplinare in modo più specifico l’AI agentica — un paradigma tecnologico che differisce sostanzialmente dall’AI generativa tradizionale per la sua capacità di azione autonoma e per la conseguente amplificazione dei rischi. Le organizzazioni che oggi dispiegano sistemi di AI agentici si trovano in una fase di transizione normativa complessa, in cui la prudenza, la documentazione delle scelte e il coinvolgimento precoce di tutte le funzioni di governance — DPO, CISO, Legal, management — rappresentano gli strumenti operativi di riferimento.

L'articolo Ghostjacking: quando l’agente AI diventa vettore di attacco interno proviene da 01magazine.

Con sentenza della Prima Sezione civile, resa in composizione monocratica e datata 1° luglio 2026, il Tribunale di Cosenza ha accolto l’opposizione proposta da un ente pubblico avverso l’ordinanza-ingiunzione del Garante per la protezione dei dati personali n. 135 del 13 marzo 2025, annullandola integralmente, e ha conseguentemente dichiarato l’invalidità della cartella di pagamento emessa per la riscossione della sanzione, quantificata in 50.000 euro. Il provvedimento sanzionatorio, adottato a seguito del reclamo di una dipendente, aveva contestato la violazione degli artt. 5, 6, 13, 25, 35 e 88 del Regolamento (UE) 2016/679, nonché degli artt. 113 e 114 del d.lgs. 30 giugno 2003, n. 196, in relazione al trattamento dei dati di posizione geografica del personale in lavoro agile, effettuato per il tramite di un applicativo di rilevazione delle presenze denominato “Time Relax”.

Trattasi, per quanto di stretto interesse in questa sede, di una delle poche pronunce di merito che affrontano ex professo il nodo della compatibilità fra strumenti di timbratura geolocalizzata e disciplina del controllo a distanza, e che lo fanno ribaltando l’esito amministrativo. La decisione tocca quattro questioni che il professionista della protezione dei dati incontra con frequenza crescente: la qualificazione dello strumento ai sensi dell’art. 4 della legge 20 maggio 1970, n. 300, richiamato dall’art. 114 del Codice; il valore del consenso del lavoratore quale base giuridica; la funzione e i requisiti dell’accordo sindacale; infine, e sullo sfondo, l’estensione dei poteri valutativi dell’Autorità di controllo rispetto a scelte organizzative e contrattuali del datore di lavoro.

Va detto in premessa che si tratta di pronuncia di primo grado, non definitiva, la cui portata sistematica deve essere misurata con la prudenza che compete a una decisione singola, resa su una piattaforma probatoria specifica e non ancora vagliata nei gradi successivi. Ciò nondimeno, l’articolazione della motivazione — e le divergenze che essa apre rispetto all’orientamento consolidato dell’Autorità — meritano un esame analitico, perché incidono direttamente sulle scelte di compliance che DPO e titolari sono chiamati a compiere oggi.

La vicenda: lavoro agile, tre sedi dichiarate e controlli a campione

La ricostruzione in fatto operata dal Tribunale è essenziale per comprendere l’esito. Una dipendente dell’Agenzia era autorizzata a prestare la propria attività in regime di lavoro agile, in forza di un accordo individuale che le consentiva di operare da tre distinti luoghi da lei stessa indicati, con impegno a rendere la prestazione esclusivamente da tali sedi. La rilevazione delle presenze era demandata all’applicativo “Time Relax”, il cui impiego, secondo quanto riportato in sentenza, era stato oggetto di confronto sindacale nella riunione di delegazione dell’8 giugno 2023 — verbalizzata con protocollo del 26 giugno 2023 — e in un successivo incontro del 27 maggio 2024, ed era stato recepito nella sezione dedicata al lavoro agile del Piano integrato di attività e organizzazione per il periodo 2024-2026, adottato con delibera del 31 gennaio 2024.

Nelle giornate del 23 e 25 gennaio 2024, in occasione di un controllo sul rispetto delle condizioni contrattuali del lavoro da remoto, veniva contestato alla dipendente di trovarsi in luoghi non compatibili con alcuna delle tre postazioni dichiarate, circostanza che la stessa ammetteva in sede di accertamento. Ne scaturivano un procedimento disciplinare — successivamente sospeso —, un esposto alla Procura della Repubblica, definito con decreto di archiviazione del giudice per le indagini preliminari, e infine il reclamo al Garante, presentato il 19 febbraio 2024, che conduceva all’ordinanza-ingiunzione oggetto di opposizione.

Il Tribunale dedica un paragrafo autonomo alla descrizione tecnica dell’applicativo, ritenendola premessa metodologica indispensabile. Secondo tale ricostruzione, il sistema opera come timbratura da remoto: rileva e registra le coordinate geografiche e la sede in cui il lavoratore si trova, unitamente a giorno e orario di ingresso e uscita, “ma solo al momento della timbratura”. Durante l’orario di servizio non vengono effettuate ulteriori rilevazioni, salvo che il datore attivi una verifica sull’effettiva esecuzione della prestazione: verifica che avviene in modo casuale, entro una fascia oraria di reperibilità, previa chiamata diretta del responsabile dell’unità organizzativa di controllo ispettivo, con invito al lavoratore a effettuare una doppia timbratura. Il sistema non registra altri dati e non opera oltre l’orario di servizio; l’accesso ai dati è riservato al dirigente di settore, alla postazione di timbratura, alla società proprietaria della piattaforma nella qualità di responsabile del trattamento e al responsabile del servizio ispettivo.

L’ordinanza-ingiunzione: la struttura dell’addebito

L’impianto del provvedimento sanzionatorio, per come riportato nella sentenza, si regge su una premessa qualificatoria e su una serie di conseguenze. La premessa è che l’applicativo integri uno strumento di monitoraggio “diretto, costante e indiscriminato” dell’attività del lavoratore, e che la finalità concretamente perseguita — verificare l’osservanza dell’obbligo di rendere la prestazione dalle sedi concordate — non sia riconducibile ad alcuna delle finalità tassative indicate dall’art. 4, comma 1, dello Statuto dei lavoratori.

Da qui il passaggio più netto della motivazione amministrativa, testualmente riportato: “le diverse esigenze di controllo dell’osservanza dei doveri di diligenza del lavoratore – che pure rientrano nelle prerogative datoriali se perseguite personalmente dal datore di lavoro o attraverso la propria organizzazione gerarchica (artt. 2086 e 2104 c.c.) – non possono invece essere perseguite con strumenti tecnologici a distanza, che, riducendo lo spazio di libertà e dignità della persona in modo meccanico e anelastico, comportano un monitoraggio diretto dell’attività del lavoratore non consentito dall’ordinamento vigente e dal quadro costituzionale”. Il controllo a distanza sull’attività — prosegue il provvedimento — è ammesso “solo incidentalmente, ossia in occasione del perseguimento di tali legittime finalità, così assumendo un carattere tipicamente indiretto e preterintenzionale“, con richiamo a Cassazione penale, sez. III, n. 22148/2017.

Ne discendono i corollari: l’irrilevanza dell’accordo sindacale, poiché “il perseguimento della predetta finalità di controllo diretto non è ammissibile nell’ordinamento neppure in presenza di un eventuale accordo con la rappresentanza sindacale unitaria o con le rappresentanze sindacali aziendali”; l’irrilevanza del consenso del lavoratore quale presupposto di liceità; la violazione dei principi di limitazione della finalità, minimizzazione, protezione dei dati fin dalla progettazione e per impostazione predefinita; la sussistenza di un rischio elevato tale da imporre la valutazione d’impatto ai sensi dell’art. 35 del Regolamento, con richiamo alle Linee guida WP 248 del 4 aprile 2017 e al provvedimento del Garante 11 ottobre 2018, n. 467, che nell’elenco delle tipologie di trattamento soggette a valutazione d’impatto menziona espressamente i “trattamenti effettuati nell’ambito del rapporto di lavoro mediante sistemi tecnologici (omissis) dai quali derivi la possibilità di effettuare un controllo a distanza dell’attività dei dipendenti”.

Il provvedimento, infine, indicava misure alternative meno invasive, quali “la redazione da parte del lavoratore di report periodici o documenti di sintesi in merito all’attività svolta oppure (omissis) momenti di confronto nei giorni di presenza in sede sugli obiettivi raggiunti in relazione a quelli assegnati”, con richiamo a una direttiva del 29 dicembre 2023 e alla direttiva della Presidenza del Consiglio dei ministri n. 3 del 2017.

Il quadro normativo di riferimento

Le basi giuridiche e i principi del Regolamento

Il trattamento di dati di posizione effettuato da un datore di lavoro pubblico richiede, come noto, la simultanea presenza di una base giuridica ai sensi dell’art. 6 del Regolamento e il rispetto dei principi dell’art. 5. Per un’amministrazione pubblica le basi realisticamente utilizzabili sono quelle di cui alle lettere c) ed e) del par. 1: l’adempimento di un obbligo legale e l’esecuzione di un compito di interesse pubblico o connesso all’esercizio di pubblici poteri. Il par. 3 richiede che tali basi siano stabilite dal diritto dell’Unione o dello Stato membro, e il par. 2 consente agli Stati membri di introdurre “disposizioni più specifiche” per adeguare l’applicazione del Regolamento.

In sostanza, il datore pubblico non “sceglie” liberamente la propria base giuridica: la rinviene in una norma dell’ordinamento che definisce finalità e limiti del trattamento. In termini più pragmatici, il fondamento del trattamento dei dati di presenza risiede nella disciplina del rapporto di lavoro pubblico e negli obblighi di rilevazione della prestazione; ciò che resta da verificare è se quella base giuridica si estenda fino a coprire l’acquisizione del dato di localizzazione.

Il rinvio dell’art. 88 e le norme di dettaglio del Codice

L’art. 88, par. 1, del Regolamento consente agli Stati membri di prevedere, “con legge o tramite contratti collettivi, norme più specifiche per assicurare la protezione dei diritti e delle libertà con riguardo al trattamento dei dati personali dei dipendenti nell’ambito dei rapporti di lavoro”, con espressa menzione, fra le finalità, dell'”esecuzione del contratto di lavoro” e della “gestione, pianificazione e organizzazione del lavoro”. Il par. 2 impone che tali norme comprendano “misure appropriate e specifiche a salvaguardia della dignità umana, degli interessi legittimi e dei diritti fondamentali degli interessati, in particolare per quanto riguarda la trasparenza del trattamento (omissis) e i sistemi di monitoraggio sul posto di lavoro”.

Nell’ordinamento interno, tale rinvio si concretizza in due disposizioni del Codice. L’art. 113, rubricato “Raccolta di dati e pertinenza”, fa salvo quanto disposto dall’art. 8 dello Statuto dei lavoratori, che vieta al datore indagini su fatti non rilevanti ai fini della valutazione dell’attitudine professionale del lavoratore. L’art. 114, rubricato “Garanzie in materia di controllo a distanza”, stabilisce che “Resta fermo quanto disposto dall’articolo 4 della legge 20 maggio 1970, n. 300”. Ne consegue un dato strutturale spesso sottovalutato: il rispetto dell’art. 4 dello Statuto non è un adempimento giuslavoristico “parallelo” alla normativa sulla protezione dei dati, bensì una condizione interna di liceità del trattamento. La violazione dell’art. 4 si traduce, di per sé, in violazione degli artt. 5, par. 1, lett. a), e 6 del Regolamento.

A ciò si aggiunge l’art. 2-ter del Codice, che ammette il trattamento da parte di un’amministrazione pubblica “se necessario per l’adempimento di un compito svolto nel pubblico interesse o per l’esercizio di pubblici poteri ad esse attribuiti”, precisando che tale esercizio non deve “arrecare un pregiudizio effettivo e concreto alla tutela dei diritti e delle libertà degli interessati”. [Nota redazionale: verificare l’esatta formulazione dell’art. 2-ter del Codice, con particolare riguardo all’inciso sul pregiudizio effettivo e concreto, prima della pubblicazione.]

L’art. 4 dello Statuto: la dicotomia fra primo e secondo comma

L’art. 4, comma 1, ammette l’impiego di impianti audiovisivi e altri strumenti dai quali derivi anche la possibilità di controllo a distanza dell’attività dei lavoratori esclusivamente per esigenze organizzative e produttive, per la sicurezza del lavoro e per la tutela del patrimonio aziendale, e subordina l’installazione all’accordo collettivo con la rappresentanza sindacale unitaria o con le rappresentanze sindacali aziendali ovvero, in mancanza, all’autorizzazione della competente sede dell’Ispettorato nazionale del lavoro. Il comma 2 sottrae a tale regime “gli strumenti utilizzati dal lavoratore per rendere la prestazione lavorativa e (omissis) gli strumenti di registrazione degli accessi e delle presenze”. Il comma 3, comune a entrambe le ipotesi, condiziona l’utilizzabilità delle informazioni raccolte “a tutti i fini connessi al rapporto di lavoro” alla circostanza “che sia data al lavoratore adeguata informazione delle modalità d’uso degli strumenti e di effettuazione dei controlli e nel rispetto di quanto disposto dal decreto legislativo 30 giugno 2003, n. 196”.

La distinzione, in termini operativi, può essere ricondotta a due categorie tipologiche:

• gli strumenti di registrazione degli accessi e delle presenze in senso stretto — il tesserino, il tornello, l’applicativo che memorizza inizio e fine turno —, che ricadono nel comma 2 e non richiedono accordo sindacale né autorizzazione;
• gli strumenti dai quali derivi un controllo a distanza dell’attività lavorativa — geolocalizzazione continuativa, ricostruzione degli spostamenti, analisi comportamentale, misurazione della produttività —, che ricadono nel comma 1 e soggiacciono al doppio requisito di finalità tipica e di procedura autorizzativa.

La linea di confine, come si dirà, non è tracciata dal nome dello strumento ma dal suo funzionamento concreto.

La disciplina del lavoro agile e il pubblico impiego

L’art. 18 della legge 22 maggio 2017, n. 81 definisce il lavoro agile come “modalità di esecuzione del rapporto di lavoro subordinato stabilita mediante accordo tra le parti, anche con forme di organizzazione per fasi, cicli e obiettivi e senza precisi vincoli di orario o di luogo di lavoro, con il possibile utilizzo di strumenti tecnologici per lo svolgimento dell’attività lavorativa”. L’art. 21, comma 1, dispone che “L’accordo relativo alla modalità di lavoro agile disciplina l’esercizio del potere di controllo del datore di lavoro sulla prestazione resa dal lavoratore all’esterno dei locali aziendali nel rispetto di quanto disposto dall’articolo 4 della legge 20 maggio 1970, n. 300”, mentre il comma 2 impone che l’accordo individui “le condotte, connesse all’esecuzione della prestazione lavorativa all’esterno dei locali aziendali, che danno luogo all’applicazione di sanzioni disciplinari”.

Il dato normativo è dunque chiaro nel rinviare, quanto ai controlli, alla disciplina statutaria: la specialità del lavoro agile non introduce un regime derogatorio, ma richiede che il potere di controllo sia disciplinato nell’accordo individuale e comunque contenuto entro i limiti dell’art. 4. Nel settore pubblico si innestano poi le fonti organizzative: le linee guida in materia di lavoro agile nelle amministrazioni pubbliche, la programmazione contenuta nel Piano integrato di attività e organizzazione e la contrattazione collettiva di comparto.

La ricostruzione del funzionamento come premessa metodologica

Il primo passaggio argomentativo del Tribunale è, in sé, condivisibile sul piano del metodo. Il giudice ha ritenuto necessario “fare preliminare chiarezza sulle modalità di funzionamento dell’applicativo”, per poi verificare se lo strumento, così come concretamente configurato, rientrasse nel comma 1 o nel comma 2 dell’art. 4. Tale impostazione trova conferma nella giurisprudenza di legittimità richiamata in sentenza, secondo cui la valutazione del regime giuridico applicabile dipende dal funzionamento effettivo dello strumento, a prescindere dalla denominazione o dalla qualificazione datane dal datore di lavoro (Cass. civ., sez. lav., 22 settembre 2021, n. 25732).

Sulla base di tale accertamento il Tribunale conclude che “Non sono, pertanto, stati rinvenuti elementi per ritenere, come invece reputa il Garante per la protezione dei dati personali, che il controllo subito dalla lavoratrice sia stato prolungato, costante, indiscriminato e invasivo”. La differenza rispetto alla timbratura in azienda consisterebbe unicamente nella “remotizzazione del sistema di verifica, che impone giocoforza l’istantanea ed estemporanea geolocalizzazione del dipendente”.

Si ritiene che qui risieda il vero fulcro della decisione, e insieme il suo punto di maggiore fragilità potenziale. La qualificazione dello strumento come “timbratura ibrida” discende da un accertamento di fatto: che il sistema rilevi la posizione solo al momento della vidimazione e in occasione delle verifiche a campione. Se tale accertamento è corretto, la conclusione sulla natura non continuativa del monitoraggio è coerente. Non si ha evidenza, dal testo della pronuncia, dell’acquisizione di una documentazione tecnica indipendente — ad esempio una relazione peritale, la documentazione del fornitore quale responsabile del trattamento, i log di sistema — che abbia consentito di verificare le funzionalità disponibili e non solo quelle dichiarate. Appare chiaro allo scrivente che, in materia di strumenti di controllo, l’accertamento delle capacità tecniche potenziali — e non solo dell’uso dichiarato — costituisca un profilo dirimente, tanto in sede ispettiva quanto in sede giudiziale.

Va segnalata, inoltre, una tensione interna al testo. L’ente ricorrente aveva dedotto che l’applicativo “non consente tecnicamente la conservazione di dati, né minuta, né massiva”; la ricostruzione del giudice afferma invece che il sistema “rileva, registra e conserva le coordinate geografiche e la sede in cui il lavoratore autorizzato al lavoro agile si trova”. Le due proposizioni non coincidono, e la sentenza non affronta il tema del periodo di conservazione delle coordinate né quello dei presupposti di cui all’art. 5, par. 1, lett. e), del Regolamento. Si tratta, secondo il parere di chi scrive, di un profilo che sarebbe stato meritevole di autonomo approfondimento, anche perché la contestazione del Garante investiva la conformità ai principi e non soltanto la base giuridica.

La qualificazione dello strumento e il precedente della “timbratura potenziata”

Il Tribunale richiama, quale precedente più prossimo, Cass. civ., sez. lav., 13 maggio 2016, n. 9904, secondo cui “La rilevazione dei dati di entrata ed uscita dall’azienda mediante un’apparecchiatura predisposta dal datore di lavoro (nella specie, un ‘badge’ elettronico idoneo a rilevare non solo la presenza ma anche le sospensioni, i permessi e le pause, ed a comparare nell’immediatezza i dati di tutti i dipendenti) ove sia utilizzabile anche in funzione di controllo a distanza del rispetto dell’orario di lavoro e della correttezza dell’esecuzione della prestazione, si risolve in un accertamento sul ‘quantum’ dell’adempimento, sicché è illegittima ai sensi dell’art. 4, comma 2, della l. n. 300 del 1970 se non concordata con le rappresentanze sindacali, ovvero autorizzata dall’ispettorato del lavoro”.

La lettura che il giudice ne trae è che i sistemi di timbratura “potenziati”, cioè idonei a registrare dati ulteriori rispetto alla mera alternativa presenza/assenza, non siano vietati in radice, ma richiedano i presupposti dell’art. 4. Di conseguenza — conclude il Tribunale — l’applicativo, pur assimilabile agli strumenti di rilevazione delle presenze del comma 2, presenta “potenzialità tecniche che suggeriscono (omissis) l’adozione del complesso di garanzie di cui al primo comma”, garanzie che l’Agenzia avrebbe in concreto osservato. Quanto alla finalità tipica, il giudice riconduce l’impiego dello strumento alle “esigenze organizzative e produttive”, escludendo invece che ricorrano la sicurezza del lavoro e la tutela del patrimonio aziendale.

Qui si colloca la divergenza sostanziale con l’Autorità. Per il Garante, la verifica dell’osservanza dell’obbligo di rendere la prestazione da una sede determinata è controllo “diretto” sulla diligenza, non riconducibile alle finalità tipiche; per il Tribunale, la medesima verifica è espressione dell’esigenza organizzativa e produttiva, e l’incidenza sull’attività del lavoratore resta incidentale.

Si ritiene che entrambe le letture siano argomentabili, ma che la questione non possa essere risolta in astratto. Il criterio distintivo elaborato dalla giurisprudenza — il carattere “preterintenzionale” del controllo sull’attività — presuppone che lo strumento sia installato per una finalità diversa dalla verifica della prestazione, e che il controllo su quest’ultima ne sia una conseguenza non ricercata. Nel caso in esame, la finalità dichiarata dell’attivazione della geolocalizzazione in occasione delle verifiche a campione — accertare che il lavoratore si trovi in una delle sedi dichiarate — appare, allo scrivente, difficilmente qualificabile come effetto collaterale: essa è, per l’appunto, l’oggetto immediato della verifica. Il che non conduce necessariamente all’illiceità, ma sposta il problema sul terreno della proporzionalità e della configurazione tecnica, più che su quello della radicale inammissibilità.

Il preteso sviamento di potere e i confini della competenza dell’Autorità

Il passaggio più originale — e più delicato — della motivazione è quello in cui il Tribunale ravvisa nell’ordinanza-ingiunzione un “eccesso di potere” e uno “sviamento di potere”. Secondo il giudice, “non rientra fra i poteri del Garante per la protezione dei dati personali valutare se il contratto di lavoro agile adottato (omissis) rientri o meno, e in che misura, nel modello legale di lavoro agile e se le concrete modalità di esecuzione della prestazione lavorativa siano o meno conformi al dettato normativo”, giacché il campo di indagine dell’Autorità sarebbe “la correttezza o meno della raccolta e del trattamento dei dati personali (omissis) a prescindere dalla validità o rispondenza normativa del contratto in cui si innesta”.

Il rilievo si salda a una critica di merito sulla nozione di lavoro agile: il Tribunale osserva che l’art. 18 della legge n. 81/2017 configura una modalità di esecuzione fondata sull’accordo delle parti e sulla flessibilità, e che il lavoro agile è “anche, e non solo o non necessariamente, quello svolto da casa (o luoghi diversi dall’ufficio e dall’azienda) e senza vincoli di orario o continuità temporale”. Ne consegue che, ove le parti abbiano pattuito l’obbligo di operare da sedi determinate, la verifica del rispetto di tale obbligo non può essere censurata assumendo un modello legale di lavoro agile diverso da quello concretamente adottato.

Sul punto si impongono due considerazioni distinte. La prima: l’argomento relativo alla configurabilità di un lavoro agile “con vincolo di luogo” appare, secondo il parere di chi scrive, testualmente fondato, poiché l’art. 18 usa la formula “anche con forme di organizzazione per fasi, cicli e obiettivi”, ammettendo dunque modelli diversi, e poiché l’art. 21 presuppone che l’accordo individui condotte rilevanti sul piano disciplinare, il che implica la verificabilità del loro rispetto.

La seconda: la qualificazione in termini di “sviamento di potere” suscita perplessità sul piano dogmatico e su quello processuale. Sul piano dogmatico, perché — come si è visto — l’art. 114 del Codice incorpora l’art. 4 dello Statuto fra le condizioni di liceità del trattamento, sicché la verifica del rispetto di quella disposizione rientra pienamente nei compiti dell’Autorità ai sensi dell’art. 57, par. 1, lett. a), del Regolamento; e poiché l’art. 88 del Regolamento assegna espressamente rilievo, ai fini della protezione dei dati, ai “sistemi di monitoraggio sul posto di lavoro”, la lettura delle regole giuslavoristiche non è un’incursione in campo altrui, ma un passaggio necessario dell’accertamento. Sul piano processuale, perché il giudizio di opposizione ai provvedimenti del Garante — regolato dall’art. 152 del Codice e dall’art. 10 del d.lgs. 1° settembre 2011, n. 150 — è un giudizio di merito sul rapporto sanzionatorio, nel quale il giudice ordinario riesamina la fondatezza della pretesa e non annulla l’atto per vizi di legittimità secondo le categorie proprie del sindacato amministrativo. In termini più pragmatici: l’esito — l’annullamento — sarebbe stato raggiungibile sulla base della sola diversa qualificazione dei fatti, senza ricorrere a categorie che, in quel rito, appaiono estranee.

Ciò detto, il nucleo di senso del rilievo giudiziale merita attenzione: esiste un confine, non sempre agevole da tracciare, fra la valutazione della proporzionalità del trattamento e la sostituzione dell’Autorità al datore nella scelta delle modalità organizzative del controllo. Il provvedimento, laddove indicava quali misure alternative i report periodici e i momenti di confronto in presenza, si è collocato — secondo la lettura del Tribunale — oltre quel confine. Si ritiene, per parte propria, che l’indicazione di misure meno invasive costituisca esercizio fisiologico del sindacato di necessità e proporzionalità, e sia anzi funzionale a rendere intelligibile il giudizio di eccedenza; resta però fondato il rilievo secondo cui tale indicazione, per essere persuasiva, deve confrontarsi con l’idoneità delle alternative rispetto alla specifica finalità perseguita, che nel caso di specie non era misurare il risultato, bensì verificare il luogo della prestazione.

Il consenso del lavoratore: il passaggio più discusso

Il Tribunale dedica un’articolata argomentazione alla rilevanza del consenso prestato dalla dipendente all’attivazione della geolocalizzazione. La tesi dell’irrilevanza del consenso discenderebbe, secondo il giudice, “da un’interpretazione esageratamente estensiva della normativa di protezione posta a tutela dei soggetti ‘deboli'”, che ridurrebbe i titolari dei diritti individuali “da soggetti attivi della contrattazione (omissis) a individui completamente passivi”. Il giudice aggiunge un argomento sistematico: se il consenso esplicito abilita, ai sensi dell’art. 9, par. 2, lett. a), del Regolamento, il trattamento di categorie particolari di dati, “a maggior ragione esso vale ad autorizzare la semplice geolocalizzazione, su consenso informato”. Viene infine richiamata Cass. civ., sez. lav., 24 novembre 2025, n. 30822, secondo cui “In tema di controllo a distanza, le informazioni raccolte tramite impianti audiovisivi autorizzati ai sensi dell’art. 4 della legge n. 300/1970 nel testo modificato dal D.Lgs. n. 151/2015, sono utilizzabili a tutti i fini connessi al rapporto di lavoro, inclusi quelli disciplinari, a condizione che sia data al lavoratore adeguata informazione delle modalità d’uso degli strumenti e dell’effettuazione dei controlli, e nel rispetto delle disposizioni dettate dal Codice in materia di protezione dei dati personali”.

Secondo il parere di chi scrive, questo è il segmento della motivazione che presenta le maggiori criticità, per tre ordini di ragioni.

In primo luogo, per una ragione terminologica che si riverbera sul piano sostanziale: la sentenza qualifica ripetutamente il lavoratore come “titolare dei dati trattati”, laddove il Regolamento denomina “interessato” la persona fisica cui i dati si riferiscono e riserva la qualifica di “titolare del trattamento” a chi determina finalità e mezzi. La sovrapposizione lessicale non è neutra, perché evoca uno schema proprietario-dispositivo del dato personale — rafforzato dal richiamo all’art. 5 c.c. in tema di atti di disposizione del proprio corpo — che il diritto europeo non accoglie: il consenso non è atto di disposizione di un bene, ma condizione di liceità revocabile in ogni momento ai sensi dell’art. 7, par. 3.

In secondo luogo, per una ragione di sistema. Il considerando 43 del Regolamento chiarisce che il consenso non costituisce valido presupposto di liceità qualora sussista un “evidente squilibrio tra l’interessato e il titolare del trattamento”, con specifico riferimento all’ipotesi in cui il titolare sia un’autorità pubblica. Su tale base si è formato l’orientamento del Gruppo di lavoro Articolo 29 nell’Opinione 2/2017 sul trattamento dei dati sul luogo di lavoro e, successivamente, quello del Comitato europeo per la protezione dei dati nelle Linee guida 05/2020 sul consenso, secondo cui nel contesto lavorativo il consenso è, di regola, inidoneo a fondare il trattamento per difetto del requisito della libertà. Vi si aggiunga che, per un’amministrazione pubblica, l’art. 2-ter del Codice indirizza il fondamento del trattamento verso il compito di interesse pubblico, e non verso il consenso.

In terzo luogo, per una ragione che attiene alla lettura del precedente di legittimità richiamato. La massima riportata in sentenza pone l’accento sull'”adeguata informazione” e sul rispetto del Codice, non sul consenso: l’art. 4, comma 3, dello Statuto configura per l’appunto un obbligo informativo, non un requisito di consenso. Si ritiene, dunque, che la pronuncia della Cassazione confermi la centralità della trasparenza — e in particolare degli obblighi di cui all’art. 13 del Regolamento — piuttosto che avvalorare la tesi del consenso quale base giuridica autonoma.

Va tuttavia riconosciuto che l’argomentazione del Tribunale contiene un nucleo pratico non liquidabile: nel lavoro agile la scelta della modalità di esecuzione della prestazione è, per definizione, oggetto di accordo individuale e presuppone un margine di autodeterminazione del lavoratore, che indica le sedi e aderisce volontariamente al regime. Il punto, allo scrivente, appare correttamente inquadrabile non in termini di consenso ex art. 6, par. 1, lett. a), bensì in termini di condizione contrattuale e organizzativa che concorre a definire la ragionevole aspettativa di riservatezza e, di conseguenza, il giudizio di proporzionalità. Diversa è, infatti, l’aspettativa di riservatezza rispetto al dato di localizzazione di chi ha assunto contrattualmente l’obbligo di operare da sedi determinate e ne è stato compiutamente informato.

L’accordo sindacale: forma, contenuto, collocazione temporale

Il Tribunale ritiene assorbita l’obiezione secondo cui non vi sarebbe mai stata contrattazione sindacale sull’uso dell’applicativo, richiamando i verbali di riunione, le note protocollate recanti in allegato “un prospetto esplicativo del funzionamento dell’applicativo e delle istruzioni per l’utilizzo” e il regolamento sul lavoro agile inserito nel Piano integrato di attività e organizzazione.

Il tema merita un supplemento di analisi, perché costituisce il profilo di maggiore ricaduta operativa. L’art. 4, comma 1, richiede un “accordo collettivo stipulato dalla rappresentanza sindacale unitaria o dalle rappresentanze sindacali aziendali” e lo pone come condizione preventiva rispetto all’installazione dello strumento. Ne discendono tre requisiti che il DPO è chiamato a verificare: la natura di accordo — e non di mera informativa o di verbale di confronto —; la specificità dell’oggetto, che deve riguardare l’installazione e le modalità d’uso del determinato strumento; l’anteriorità rispetto all’attivazione.

Sul primo punto, non si ha evidenza, dal testo della sentenza, di una valutazione espressa circa la qualificazione dei verbali di delegazione trattante come accordi collettivi in senso tecnico. Sul terzo punto, si osserva che il verbale del 27 maggio 2024 — indicato in sentenza come atto che “confermava le modalità di svolgimento della prestazione lavorativa in modalità lavoro agile, ivi compresa la geolocalizzazione occasionale” — è successivo ai controlli del gennaio 2024. Un accordo o un chiarimento sopravvenuto non sana, secondo il parere di chi scrive, un difetto di legittimazione preventiva, ancorché possa concorrere a dimostrare la coerenza complessiva dell’assetto adottato. Sul secondo punto, l’inserimento della disciplina del lavoro agile in un atto di programmazione organizzativa — quale il Piano integrato di attività e organizzazione — assolve a una funzione di trasparenza organizzativa, ma non equivale, di per sé, alla stipula dell’accordo richiesto dall’art. 4.

Va infine ricordato che l’art. 4 prevede, in mancanza di accordo, il percorso alternativo dell’autorizzazione dell’Ispettorato nazionale del lavoro. Nella prassi applicativa dei sistemi di gestione, la scelta fra i due percorsi è spesso condizionata dalla struttura territoriale del titolare; per gli enti con articolazioni in più ambiti provinciali o regionali la disposizione individua rispettivamente le associazioni sindacali comparativamente più rappresentative sul piano nazionale e la sede centrale dell’Ispettorato.

Minimizzazione, protezione by design e valutazione d’impatto: i profili rimasti in ombra

Il Tribunale contesta l’affermazione del Garante secondo cui il trattamento avrebbe carattere “massivo e indiscriminato”, replicando che “il sistema opera una rilevazione molto specifica, precisa e circoscritta della posizione del dipendente solo al momento della timbratura”, e qualifica come “apodittico” e “ipotetico” il giudizio di sproporzione, osservando che l’Autorità sembrerebbe sanzionare “per ciò che potrebbe fare con il programma di controllo remoto, più che per quello che ha concretamente fatto”.

Il rilievo è, in linea di principio, corretto sotto il profilo del rispetto del principio di legalità in materia sanzionatoria: l’illecito si accerta sui trattamenti effettivamente posti in essere. Nondimeno, si ritiene che esso trascuri la peculiare struttura degli artt. 25 e 35 del Regolamento, che sono per definizione norme di rischio e di progettazione, e non di evento. L’art. 25, par. 1, impone di attuare misure tecniche e organizzative adeguate “sia al momento di determinare i mezzi del trattamento sia all’atto del trattamento stesso”; l’art. 25, par. 2, richiede che siano trattati per impostazione predefinita solo i dati necessari per ogni specifica finalità. L’art. 35 impone la valutazione d’impatto quando un trattamento “può presentare un rischio elevato”, con valutazione prognostica. In termini più concreti: la circostanza che una funzionalità invasiva non sia stata attivata non esclude la violazione dell’art. 25, se la configurazione predefinita del sistema la rendeva disponibile.

Proprio su questo terreno si colloca, secondo il parere di chi scrive, l’occasione argomentativa non colta dalla sentenza. La finalità dichiarata — verificare che il lavoratore si trovi in una delle tre sedi concordate — è tecnicamente perseguibile senza registrare le coordinate geografiche puntuali, mediante una verifica di corrispondenza che restituisca al titolare un esito binario, del tipo “posizione compatibile / non compatibile” con una delle sedi dichiarate, senza conservazione della localizzazione esatta. Una simile configurazione avrebbe consentito di raggiungere lo scopo riducendo drasticamente l’interferenza nella sfera privata, che è precisamente ciò che il Garante contestava richiamando l’acquisizione dell’informazione “relativa alla specifica località in cui temporaneamente l’interessata si trovava” e, con essa, l’art. 113 del Codice. In altri termini, il confronto fra le parti si è concentrato sull’an del controllo, mentre il terreno decisivo — quello del quomodo, ossia della configurazione dello strumento secondo i canoni della protezione dei dati fin dalla progettazione — è rimasto sullo sfondo.

Quanto alla valutazione d’impatto, la difesa dell’ente aveva sostenuto che essa “è stata eseguita in sede di accordo con le rappresentanze sindacali”. La sentenza non dedica a tale profilo un autonomo sviluppo motivazionale. Si ritiene che l’equazione fra confronto sindacale e valutazione d’impatto non sia sostenibile: l’art. 35, par. 7, richiede un contenuto minimo tipizzato — descrizione sistematica dei trattamenti, valutazione della necessità e proporzionalità, valutazione dei rischi per i diritti e le libertà, misure previste per affrontarli — e l’art. 35, par. 2, impone di consultare il responsabile della protezione dei dati. L’accordo sindacale e la valutazione d’impatto operano su piani distinti e non fungibili: il primo legittima l’installazione dello strumento sul piano giuslavoristico; la seconda documenta l’analisi del rischio sul piano dell’accountability ex art. 5, par. 2. Va aggiunto che il provvedimento del Garante n. 467 dell’11 ottobre 2018 include espressamente, nell’elenco delle tipologie di trattamento soggette a valutazione d’impatto, quelli effettuati nell’ambito del rapporto di lavoro mediante sistemi tecnologici dai quali derivi la possibilità di controllo a distanza.

Archiviazione penale, cartella di pagamento e profili processuali

Il Tribunale liquida in poche righe il rilievo relativo al decreto di archiviazione emesso dal giudice per le indagini preliminari, affermando che esso “non rileva, se non ad colorandum”. La conclusione è coerente con i principi generali: il decreto di archiviazione non è sentenza e non produce effetti di giudicato nei giudizi civili o amministrativi, sicché l’accertamento dell’insussistenza di un illecito penale non preclude la contestazione di una violazione amministrativa in materia di protezione dei dati, che risponde a presupposti e a beni giuridici differenti.

Sul versante processuale, la vicenda presenta alcuni elementi di interesse pratico. Il giudizio di opposizione alla cartella di pagamento — emessa a seguito della sanzione — è stato riunito a quello di opposizione all’ordinanza-ingiunzione, con conseguente estensione alla cartella delle ragioni di merito accolte. L’agente della riscossione aveva eccepito il difetto di giurisdizione del giudice ordinario in favore di quello tributario, eccezione respinta con ordinanza resa a verbale: soluzione condivisibile, giacché la pretesa azionata ha natura di sanzione amministrativa non tributaria e la contestazione investe l’esistenza stessa del credito. Le spese sono state poste a carico dell’Autorità in ragione della soccombenza, e compensate nei confronti dell’agente della riscossione in considerazione del suo ruolo processuale. Il giudice ha inoltre motivato la maggiorazione della fase di studio “per via dell’assenza di riferimenti giurisprudenziali specifici e per la complessità della materia”: indicazione che, per quanto marginale, conferma la novità della questione.

Profili critici di sistema e portata della pronuncia

Alcune considerazioni di sintesi si impongono.

La prima riguarda l’effetto della decisione sull’assetto della compliance. Una sentenza di primo grado che annulla un provvedimento sanzionatorio non modifica l’orientamento dell’Autorità, che continua a costituire il parametro di riferimento nell’attività di controllo. Il titolare che assumesse la pronuncia quale autorizzazione generalizzata all’impiego della geolocalizzazione per la verifica delle presenze in lavoro agile si esporrebbe, secondo il parere di chi scrive, a un rischio significativo, tanto più che la ratio decidendi è fortemente ancorata alla specifica configurazione tecnica accertata e all’articolato corredo documentale prodotto dall’ente.

La seconda riguarda il rapporto fra qualificazione giuslavoristica e disciplina della protezione dei dati. La sentenza mostra come, nel contenzioso in materia, l’esito dipenda in misura decisiva dalla ricostruzione in fatto del funzionamento dello strumento. Ne discende un’indicazione metodologica: la documentazione tecnica — architettura del sistema, dati effettivamente raccolti, tempi di conservazione, profili di accesso, log delle interrogazioni — costituisce il vero fascicolo probatorio del titolare, e la sua assenza o genericità pregiudica ogni difesa, sia in sede di istruttoria dinanzi all’Autorità sia in sede giudiziale.

La terza riguarda una divergenza interpretativa che resta aperta e che il legislatore, non l’interprete, potrebbe essere chiamato a comporre: se la verifica del rispetto del vincolo di luogo, laddove pattuito nell’accordo individuale di lavoro agile, rientri fra le “esigenze organizzative e produttive” dell’art. 4, comma 1, ovvero costituisca controllo diretto sulla diligenza, come tale precluso. L’art. 21 della legge n. 81/2017, nel prevedere che l’accordo individui le condotte rilevanti sul piano disciplinare, presuppone una qualche forma di verificabilità; ma non chiarisce con quali strumenti essa possa essere condotta. Si ritiene che l’assenza di una disciplina di dettaglio — o di linee guida condivise fra Autorità di controllo e amministrazione del lavoro — sia all’origine di buona parte dell’incertezza applicativa oggi rilevabile.

Indicazioni operative per DPO, titolari pubblici e privati

Ferma la specificità del caso, la vicenda consente di isolare un insieme di adempimenti verificabili, utili tanto nella progettazione di nuovi sistemi quanto nella revisione di quelli esistenti.

La qualificazione funzionale dello strumento: prima di ogni altra valutazione occorre documentare che cosa il sistema fa e che cosa può fare, distinguendo le funzionalità attivate da quelle disponibili ma disattivate. La verifica va condotta su base documentale — scheda tecnica del fornitore, manuale di configurazione, evidenza dei parametri impostati — e non sulla sola denominazione commerciale del prodotto, secondo il criterio di metodo affermato da Cass. n. 25732/2021.

La scelta consapevole fra comma 1 e comma 2 dell’art. 4: ove residui un margine di dubbio sulla riconducibilità dello strumento ai meri dispositivi di registrazione degli accessi e delle presenze, si suggerisce di adottare in via prudenziale il regime più garantista del comma 1, attivando l’accordo sindacale o, in mancanza, il procedimento autorizzativo dinanzi all’Ispettorato nazionale del lavoro. L’adozione volontaria delle garanzie rafforzate è stata valorizzata, nel caso in esame, come indice di correttezza dell’operato del titolare.

L’anteriorità e specificità dell’accordo: l’accordo collettivo deve precedere l’attivazione dello strumento e avere ad oggetto quello specifico sistema, con indicazione delle finalità, dei dati trattati, delle modalità e della frequenza dei controlli, dei soggetti abilitati e dei tempi di conservazione. Un verbale di confronto sindacale privo di tali elementi, ovvero sopravvenuto rispetto all’avvio del trattamento, espone il titolare a una contestazione difficilmente superabile.

La base giuridica formalizzata e non affidata al consenso: per il datore di lavoro — a maggior ragione se pubblico — la base giuridica va individuata nell’art. 6, par. 1, lett. c) o e), del Regolamento, in combinato con l’art. 2-ter del Codice e con la disciplina del rapporto di lavoro. Il consenso dell’interessato, alla luce del considerando 43 e delle Linee guida 05/2020 del Comitato europeo per la protezione dei dati, non costituisce fondamento affidabile; si suggerisce di non costruire l’architettura di conformità su di esso, pur potendo l’adesione volontaria al regime di lavoro agile essere valorizzata nel giudizio di proporzionalità.

L’informativa specifica ai sensi dell’art. 13: le note organizzative e i prospetti esplicativi sul funzionamento dell’applicativo assolvono all’obbligo di “adeguata informazione” di cui all’art. 4, comma 3, dello Statuto, ma non sostituiscono l’informativa privacy, che deve indicare titolare e dati di contatto del responsabile della protezione dei dati, finalità e base giuridica, categorie di destinatari, periodo di conservazione, diritti dell’interessato e diritto di reclamo. Si suggerisce di conservare evidenza della consegna e della data.

La valutazione d’impatto autonoma e documentata: la valutazione ai sensi dell’art. 35 va redatta come documento a sé stante, con il contenuto minimo del par. 7 e con la consultazione documentata del responsabile della protezione dei dati ai sensi del par. 2. Il confronto sindacale non è surrogato della valutazione d’impatto; la loro sovrapposizione, ricorrente nella prassi, costituisce una delle carenze più frequentemente rilevate.

La minimizzazione tecnica e privacy by design: si suggerisce di privilegiare architetture che restituiscano l’esito della verifica anziché il dato di posizione — ad esempio la sola indicazione di compatibilità con una delle sedi dichiarate —, ovvero che applichino tecniche di riduzione della precisione, e di documentare nella valutazione d’impatto le alternative considerate e le ragioni della scelta.

Le politiche di conservazione e cancellazione: occorre definire e implementare tecnicamente un tempo di conservazione differenziato per il dato di posizione, di regola più breve di quello del dato di presenza, con cancellazione automatica e verifica periodica dell’effettivo funzionamento della procedura.

Il governo dei ruoli e delle abilitazioni: il fornitore della piattaforma va designato responsabile del trattamento ai sensi dell’art. 28, con atto giuridico che disciplini istruzioni, sub-responsabili, assistenza al titolare e cancellazione dei dati a fine rapporto. Le abilitazioni di accesso vanno limitate ai profili strettamente necessari e tracciate mediante registrazione degli accessi.

La disciplina dell’uso a fini sanzionatori: l’utilizzabilità delle informazioni “a tutti i fini connessi al rapporto di lavoro” presuppone il rispetto del comma 3 dell’art. 4 e delle disposizioni del Codice. Si suggerisce di formalizzare in una procedura interna i presupposti di attivazione della verifica a campione, la relativa tracciatura e le modalità di contestazione, evitando che l’accesso ai dati avvenga in via estemporanea e non documentata.

Conclusioni

La pronuncia del Tribunale di Cosenza si colloca in una zona di frizione fra due impostazioni che il diritto vivente non ha ancora composto. Da un lato, l’orientamento dell’Autorità di controllo, che legge l’art. 4 dello Statuto come sbarramento rispetto a ogni forma di verifica tecnologica direttamente preordinata al riscontro dell’adempimento, e che nel lavoro agile valorizza l’attenuazione dei confini fra sfera professionale e sfera privata quale ragione di rafforzamento della tutela. Dall’altro, la lettura del giudice ordinario, che ancora la qualificazione dello strumento al suo funzionamento concreto, riconosce cittadinanza al lavoro agile con vincolo di luogo pattuito e assegna rilievo all’adesione informata del lavoratore quale elemento del giudizio di proporzionalità.

Restano aperte, allo stato, alcune questioni puntuali. La prima concerne l’idoneità dei verbali di delegazione trattante nel pubblico impiego a integrare l’accordo collettivo richiesto dall’art. 4, comma 1, e la rilevanza dell’anteriorità di tale accordo rispetto all’attivazione dello strumento: profilo che, nel caso esaminato, la sentenza ha risolto in fatto, ma che merita approfondimento sistematico. La seconda concerne il coordinamento fra la disciplina del controllo a distanza e la funzione dell’accordo individuale di lavoro agile ai sensi dell’art. 21 della legge n. 81/2017: se l’accordo deve individuare le condotte disciplinarmente rilevanti connesse all’esecuzione della prestazione all’esterno dei locali aziendali, occorre chiarire con quali strumenti — e con quali garanzie — il rispetto di quelle prescrizioni possa essere verificato. La terza concerne il rapporto fra accertamento dell’illecito e struttura prognostica degli artt. 25 e 35 del Regolamento: la contestazione di una configurazione tecnica potenzialmente eccedente, ancorché non pienamente utilizzata, richiede una motivazione che espliciti il nesso fra funzionalità disponibili e rischio per gli interessati, e la giurisprudenza di merito appare, sul punto, ancora in formazione.

Una prospettiva evolutiva merita infine una segnalazione. Ove sistemi di rilevazione e verifica della prestazione incorporino componenti di “intelligenza artificiale” — ad esempio per l’analisi automatizzata dei dati di presenza o per la generazione di segnalazioni di anomalia —, al quadro sin qui descritto si aggiungeranno gli obblighi del regolamento (UE) 2024/1689, che nell’Allegato III include fra i sistemi ad alto rischio quelli destinati all’occupazione e alla gestione dei lavoratori, e che all’art. 26, par. 7, impone ai deployer datori di lavoro di informare i rappresentanti dei lavoratori e i lavoratori interessati prima della messa in servizio. La sovrapposizione fra art. 4 dello Statuto, artt. 35 e 88 del Regolamento generale e obblighi informativi del regolamento sull’intelligenza artificiale configurerà un adempimento a più livelli, che appare opportuno progettare in modo unitario sin dalla fase di selezione del fornitore, anziché ricostruire ex post in sede di contestazione.

L'articolo Geolocalizzazione in lavoro agile: annullata la sanzione del Garante proviene da 01magazine.

In premessa va detto che il regolamento (UE) 2024/2847 del Parlamento europeo e del Consiglio, relativo a requisiti orizzontali di cibersicurezza per i prodotti con elementi digitali — comunemente noto come “Cyber Resilience Act” o “CRA” — ha una struttura applicativa scaglionata, che colloca l’entrata in funzione degli obblighi di segnalazione in anticipo rispetto alla piena applicabilità dei requisiti sostanziali di prodotto. Trattasi di una scelta legislativa non neutrale: il legislatore europeo ha ritenuto prioritario attivare, prima di ogni altra cosa, il flusso informativo verso le autorità nazionali e verso l’Agenzia dell’Unione europea per la cibersicurezza (ENISA) in ordine alle vulnerabilità attivamente sfruttate e agli incidenti gravi che incidono sulla sicurezza dei prodotti con elementi digitali immessi sul mercato dell’Unione.

Il documento oggetto del presente approfondimento è un factsheet pubblicato da ENISA e dedicato alla “CRA Single Reporting Platform” (SRP), ossia alla piattaforma unica di segnalazione prevista dall’articolo 16 del CRA. Il factsheet — di natura divulgativa e non normativa — indica la data dell’11 settembre 2026 come momento a partire dal quale i fabbricanti sono tenuti a segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi, e a partire dal quale il medesimo obbligo grava sui gestori di software libero e open source nella misura in cui essi siano coinvolti nello sviluppo di prodotti con elementi digitali. Il documento descrive la piattaforma come “an online tool for manufacturers and open-source software stewards to meet the obligation to report actively exploited vulnerabilities and severe incidents”, precisando che si tratta di “an electronic system to report only once to communicate to all relevant authorities”.

Le disposizioni richiamate dal factsheet sono, in particolare, l’articolo 3, punto 42, del CRA per la definizione di vulnerabilità attivamente sfruttata; l’articolo 3, punto 44, per la nozione di incidente grave; l’articolo 14, paragrafo 5, per i criteri di gravità; l’articolo 14, paragrafo 7, per l’individuazione del CSIRT nazionale destinatario; l’articolo 16, paragrafo 2, per il differimento della diffusione delle informazioni in circostanze eccezionali, con l’ulteriore specificazione — sempre secondo quanto riportato dalla fonte — recata dal regolamento delegato (UE) 2026/881.

La rilevanza dell’atto per il pubblico dei DPO, dei giuristi d’impresa e dei responsabili compliance non è immediatamente intuitiva, poiché il CRA non è una normativa di protezione dei dati personali. Si ritiene, tuttavia, che il tema sia di stretto interesse per almeno tre ragioni. La prima è che un numero considerevole di imprese italiane — dall’industria manifatturiera con componenti connesse, ai produttori di software gestionale, agli sviluppatori di applicazioni e dispositivi IoT — rientra nella nozione di fabbricante di prodotti con elementi digitali, spesso senza averne piena consapevolezza. La seconda è che gli eventi da segnalare al CSIRT ai sensi del CRA si sovrappongono con frequenza a eventi qualificabili come violazione di dati personali ai sensi dell’articolo 4, punto 12, del GDPR, ovvero come incidente significativo ai sensi della direttiva (UE) 2022/2555 (NIS2) e del decreto legislativo 4 settembre 2024, n. 138. La terza è che la gestione dei termini brevissimi — ventiquattro ore per l’allerta precoce — richiede procedure interne, matrici di responsabilità e presidi documentali che intersecano inevitabilmente il perimetro di attività del DPO e delle funzioni di controllo.

Il documento ENISA e la sua collocazione nel sistema del Cyber Resilience Act

Il factsheet in esame è un documento di sintesi, strutturato per rispondere a domande elementari: che cos’è la piattaforma, a chi si rivolge, quali eventi vanno segnalati, entro quali termini, a quale CSIRT, cosa accade dopo la trasmissione. Non ha valore interpretativo vincolante e non si sostituisce né al testo del regolamento né alla guidance della Commissione europea, alla quale il documento stesso rinvia per gli aspetti di dettaglio, segnalando che la sezione 9.1 della guida della Commissione sul CRA contiene ulteriori chiarimenti in materia di obblighi di segnalazione. ENISA indica come punto di accesso informativo la pagina dedicata alle FAQ sulla SRP, raggiungibile all’indirizzo https://www.enisa.europa.eu/cra-srp, e un canale di assistenza dedicato all’indirizzo di posta elettronica cra-srp-helpdesk@enisa.europa.eu.

Appare chiaro allo scrivente che il valore pratico del documento risieda non tanto nel contenuto informativo — in larga parte ricavabile dalla lettura del regolamento — quanto nella conferma operativa di due elementi. Il primo è la conferma della data di decorrenza: l’11 settembre 2026 non è una scadenza ipotetica soggetta a rinvii tecnici, ma il termine attorno al quale l’Agenzia sta costruendo l’infrastruttura di raccolta. Il secondo è la conferma dell’architettura “single reporting”: una sola trasmissione, effettuata attraverso un sistema elettronico unico, con successiva diffusione automatica verso gli altri destinatari istituzionali. In termini più pragmatici, il fabbricante non deve moltiplicare le comunicazioni verso i ventisette CSIRT nazionali, ma deve individuare correttamente il CSIRT di riferimento e trasmettere una volta sola, lasciando che la piattaforma esegua la distribuzione.

Il flusso di utilizzo descritto dal factsheet è articolato in tre passaggi: accesso autenticato, selezione del CSIRT nazionale, compilazione e invio delle informazioni. Si tratta, in apparenza, di una sequenza banale. Nella prospettiva del practitioner, tuttavia, ciascuno dei tre passaggi presuppone attività preparatorie da svolgere prima dell’evento: la registrazione e la gestione delle credenziali, la determinazione a priori del CSIRT competente in base al criterio del luogo di stabilimento principale, la predisposizione di modelli informativi coerenti con i campi richiesti. Chi affronta la compilazione per la prima volta durante la gestione di un incidente in corso, con un termine di ventiquattro ore, si trova nella condizione meno favorevole possibile.

Il quadro normativo di riferimento

La disciplina europea: il regolamento (UE) 2024/2847

Il CRA è un regolamento di armonizzazione fondato sulla logica della legislazione di prodotto: introduce requisiti essenziali di cibersicurezza, obblighi degli operatori economici lungo la catena di distribuzione, procedure di valutazione della conformità, marcatura CE e vigilanza del mercato. L’ambito di applicazione ruota attorno alla nozione di “prodotto con elementi digitali”, che comprende i prodotti software e hardware e le loro soluzioni di elaborazione dati a distanza, connessi direttamente o indirettamente a un dispositivo o a una rete.

In sostanza, il regolamento estende ai prodotti digitali la logica che il diritto dell’Unione applica da decenni alla sicurezza delle macchine, dei giocattoli o dei dispositivi elettrici: chi immette sul mercato deve garantire la conformità a requisiti essenziali, deve documentarla, deve mantenerla nel tempo. In termini più concreti, l’allegato I del CRA distingue tra requisiti relativi alle proprietà di cibersicurezza del prodotto — configurazione sicura di default, protezione dell’integrità e della riservatezza dei dati, minimizzazione delle superfici di attacco, aggiornamenti sicuri — e requisiti relativi alla gestione delle vulnerabilità, che includono l’identificazione e la documentazione dei componenti, con predisposizione di una distinta base del software (la cosiddetta “software bill of materials”), la messa a disposizione tempestiva di aggiornamenti di sicurezza e l’adozione di una politica di divulgazione coordinata delle vulnerabilità.

L’obbligo di segnalazione, collocato all’articolo 14, non è dunque un adempimento isolato, ma la proiezione esterna del processo interno di gestione delle vulnerabilità richiesto dall’allegato I. Si ritiene che questa lettura sistematica sia essenziale: un fabbricante che non abbia strutturato un processo di vulnerability management difficilmente sarà in condizione di rispettare i termini dell’articolo 14, perché non disporrà né delle informazioni tecniche né dei presidi organizzativi necessari a riconoscere e qualificare l’evento.

La decorrenza dell’11 settembre 2026 e l’applicazione scaglionata

Il regolamento è entrato in vigore nel dicembre 2024 e prevede un’applicazione differita e frazionata. Gli obblighi di segnalazione di cui all’articolo 14 si applicano a decorrere dall’11 settembre 2026, mentre il corpo principale delle disposizioni — requisiti essenziali, valutazione della conformità, marcatura — diviene applicabile a decorrere dall’11 dicembre 2027; le disposizioni relative alla notifica degli organismi di valutazione della conformità hanno una decorrenza anticipata rispetto a quest’ultima data.

Va detto che questa asimmetria produce, nel periodo intermedio, una situazione peculiare e non priva di attriti concettuali: dall’11 settembre 2026 il fabbricante è tenuto a segnalare vulnerabilità attivamente sfruttate e incidenti gravi relativi a prodotti che non sono ancora soggetti ai requisiti essenziali dell’allegato I e che, in molti casi, sono stati progettati e immessi sul mercato prima dell’entrata in vigore del regolamento. Secondo il parere di chi scrive, ne deriva che nel periodo compreso tra settembre 2026 e dicembre 2027 l’obbligo di segnalazione opera come obbligo autonomo, di natura essenzialmente informativa e di vigilanza, sganciato dal giudizio di conformità del prodotto. Ciò non attenua l’obbligo, ma ne circoscrive gli effetti: la segnalazione, in questa fase, non equivale a una confessione di non conformità ai requisiti essenziali, che non sono ancora applicabili.

Resta aperta — e non si ha evidenza di chiarimenti definitivi sul punto nei documenti richiamati dal factsheet — la questione del trattamento dei prodotti immessi sul mercato prima delle rispettive decorrenze e successivamente interessati da modifiche sostanziali. Si suggerisce, in via prudenziale, di considerare l’obbligo di segnalazione come riferito a tutti i prodotti con elementi digitali disponibili sul mercato dell’Unione al momento dell’evento, indipendentemente dalla data di prima immissione, salvo diversa e più circoscritta indicazione delle autorità competenti.

Il raccordo con la direttiva NIS2 e con il quadro nazionale

La struttura temporale della segnalazione CRA — allerta precoce entro ventiquattro ore, notifica entro settantadue ore, relazione finale — riproduce consapevolmente lo schema dell’articolo 23 della direttiva (UE) 2022/2555, recepita in Italia con il decreto legislativo 4 settembre 2024, n. 138. La simmetria è funzionale: consente ai CSIRT nazionali di operare con procedure omogenee e consente ai soggetti obbligati di riutilizzare, almeno in parte, i medesimi processi interni.

Va però evidenziato che i due regimi hanno oggetto e presupposti diversi. La NIS2 impone obblighi a soggetti qualificati come essenziali o importanti in ragione del settore di attività e delle dimensioni, e riguarda incidenti significativi che incidono sulla fornitura dei servizi del soggetto notificante. Il CRA impone obblighi a fabbricanti in quanto tali, indipendentemente dal settore e dalla dimensione — con talune modulazioni per le microimprese e le piccole imprese quanto alla proporzionalità degli oneri documentali — e riguarda eventi che incidono sulla sicurezza del prodotto immesso sul mercato. In termini più pragmatici, un’impresa manifatturiera di medie dimensioni, non rientrante nel perimetro NIS2 come soggetto essenziale o importante, può essere pienamente soggetta agli obblighi di segnalazione del CRA per il software embedded nei propri prodotti.

Nel contesto italiano, il CSIRT Italia è collocato presso l’Agenzia per la cybersicurezza nazionale e opera come punto di contatto per le notifiche NIS2 e, in forza della legge 28 giugno 2024, n. 90, per le segnalazioni dei soggetti pubblici ivi indicati, con i noti termini di ventiquattro e settantadue ore. Ne consegue che, per un fabbricante italiano che sia anche soggetto NIS2, il medesimo interlocutore istituzionale riceverà segnalazioni fondate su titoli giuridici distinti, con perimetri di rilevanza differenti. Si ritiene che ciò renda opportuna la costruzione di un registro unico degli eventi con classificazione multipla del titolo di notifica, per evitare tanto la duplicazione inutile quanto l’omissione.

La Legge 17 marzo 2026 n. 36 ha individuato l’ACN in Italia come l’Autorità preposta alla vigilanza per l’applicazione del CRA, tramite il raccordo con il CSIRT Italia.

Il rapporto con il GDPR e con gli altri regimi settoriali

Per quanto di stretto interesse in questa sede, occorre chiarire che la segnalazione ai sensi dell’articolo 14 del CRA non assorbe né sostituisce la notificazione della violazione di dati personali ai sensi degli articoli 33 e 34 del GDPR. I due obblighi hanno presupposti oggettivi diversi: il CRA guarda alla sicurezza del prodotto e alla presenza di uno sfruttamento attivo di una vulnerabilità o di un incidente con impatto grave su disponibilità, autenticità, integrità o riservatezza; il GDPR guarda alla violazione di sicurezza che comporta accidentalmente o in modo illecito la distruzione, la perdita, la modifica, la divulgazione non autorizzata o l’accesso a dati personali trasmessi, conservati o comunque trattati.

Un medesimo fatto storico può integrare entrambi i presupposti. Si pensi allo sfruttamento attivo di una vulnerabilità in un componente software di un dispositivo medico connesso, che consenta l’accesso non autorizzato a dati relativi alla salute: il fabbricante dovrà valutare la segnalazione al CSIRT ai sensi del CRA e, ove sia titolare del trattamento, dovrà valutare la notificazione al Garante per la protezione dei dati personali ai sensi dell’articolo 33 e l’eventuale comunicazione agli interessati ai sensi dell’articolo 34, ovvero, ove operi come responsabile ai sensi dell’articolo 28 del GDPR, dovrà assistere il titolare. Va aggiunto che il termine di settantadue ore del GDPR decorre dal momento in cui il titolare viene a conoscenza della violazione, mentre il termine di ventiquattro ore del CRA decorre dalla conoscenza dello sfruttamento attivo o dell’incidente grave: le due decorrenze possono non coincidere.

Analoga logica di coordinamento — e non di assorbimento — vale rispetto ad altri regimi: il regolamento (UE) 2022/2554 (DORA) per gli incidenti connessi alle tecnologie dell’informazione e della comunicazione nel settore finanziario; il regolamento (UE) 2017/745 e il regolamento (UE) 2017/746 quanto alla vigilanza sui dispositivi medici e diagnostici in vitro; le discipline settoriali in materia di aeronautica e autoveicoli. Il CRA contiene clausole di coordinamento e di esclusione per taluni settori regolati; la verifica dell’applicabilità va condotta caso per caso e non può essere risolta con formule generali.

Merita segnalazione, sul versante della gestione delle vulnerabilità, l’esistenza della banca dati europea delle vulnerabilità istituita in attuazione della direttiva NIS2 e gestita da ENISA, che si affianca ai repertori internazionali. Si ritiene che la coesistenza tra segnalazione riservata al CSIRT ai sensi del CRA e pubblicazione informativa in banche dati costituisca uno dei nodi di maggiore delicatezza pratica, sul quale si tornerà nella sezione dedicata ai profili critici.

I soggetti obbligati: fabbricanti e gestori di software libero e open source

Il factsheet individua due categorie di destinatari: i fabbricanti e i gestori di software libero e open source (open-source software stewards). La distinzione merita un chiarimento incrementale.

Il fabbricante è, nella logica della legislazione di prodotto, il soggetto che fabbrica un prodotto con elementi digitali, ovvero che lo fa progettare o fabbricare e lo commercializza con il proprio nome o marchio, a titolo oneroso o gratuito. In sostanza, non conta chi materialmente scrive il codice o assembla l’hardware, ma chi assume verso il mercato la paternità commerciale del prodotto. In termini più pragmatici, l’impresa italiana che commissiona a un fornitore terzo lo sviluppo di un’applicazione e la distribuisce con il proprio marchio è fabbricante ai fini del CRA, con tutti gli obblighi che ne derivano, ivi compresi quelli di segnalazione; il fornitore che ha sviluppato il software su specifica altrui non è, per ciò solo, fabbricante di quel prodotto.

Il gestore di software libero e open source è una figura di nuova introduzione, pensata dal legislatore per intercettare quei soggetti — tipicamente fondazioni e organizzazioni senza scopo di lucro — che forniscono in modo sistematico e continuativo supporto allo sviluppo di software libero destinato a essere utilizzato in attività commerciali, senza però immettere essi stessi il prodotto sul mercato. Il regime a loro applicabile è deliberatamente alleggerito e proporzionato: il CRA prevede per tali soggetti obblighi attenuati, incentrati sull’adozione di una politica di cibersicurezza e sulla cooperazione con le autorità di vigilanza. Il factsheet, coerentemente, precisa che il CRA richiede ai gestori di segnalare gli eventi “to the extent that they are involved in the development of products with digital elements”.

Va detto che il singolo sviluppatore che contribuisce a un progetto open source al di fuori di un’attività commerciale non è, in linea di principio, destinatario degli obblighi del CRA. Si suggerisce comunque alle imprese che utilizzano componenti open source nei propri prodotti di non confidare nella traslazione degli obblighi verso la comunità di sviluppo: il fabbricante che integra un componente di terzi nel proprio prodotto resta responsabile della sicurezza del prodotto nel suo complesso e, di conseguenza, resta il soggetto obbligato alla segnalazione quando la vulnerabilità attivamente sfruttata risieda nel componente integrato.

Occorre inoltre ricordare che il CRA, come tutta la legislazione di prodotto dell’Unione, opera con un criterio di collegamento fondato sulla disponibilità del prodotto sul mercato dell’Unione, e non sulla nazionalità o sulla sede del fabbricante. I fabbricanti stabiliti in Paesi terzi che rendono disponibili prodotti sul mercato europeo sono soggetti al regolamento e possono designare un rappresentante autorizzato con mandato scritto; importatori e distributori sono a loro volta gravati di obblighi di verifica e di informazione. Nella prospettiva di un’impresa italiana che importi e distribuisca prodotti con elementi digitali fabbricati altrove, si ritiene essenziale verificare contrattualmente l’esistenza di canali di comunicazione rapida con il fabbricante, poiché la conoscenza di una vulnerabilità sfruttata attivamente può maturare in capo al distributore prima che in capo al fabbricante.

L’oggetto della segnalazione: vulnerabilità attivamente sfruttate e incidenti gravi

Il factsheet identifica due tipologie di eventi soggetti a segnalazione, con ancoraggio definitorio preciso.

La prima tipologia è quella delle vulnerabilità attivamente sfruttate, descritte come “Vulnerabilities in products with digital elements that are known to be currently exploited by a malicious actor”, con richiamo all’articolo 3, punto 42, del CRA. In sostanza, non è la vulnerabilità in sé a generare l’obbligo, ma la circostanza — nota al fabbricante — che essa sia oggetto di sfruttamento attuale da parte di un attore malevolo. La distinzione è di rilievo pratico: un fabbricante che scopra, attraverso un’attività interna di ricerca o attraverso una segnalazione di un ricercatore indipendente, una vulnerabilità grave ma non sfruttata, non è tenuto alla segnalazione ai sensi dell’articolo 14, pur essendo tenuto — nel regime pieno applicabile dal dicembre 2027 — a porvi rimedio secondo il processo di gestione delle vulnerabilità di cui all’allegato I. In termini più concreti, l’elemento che innesca l’obbligo è l’evidenza dello sfruttamento: la presenza di indicatori di compromissione, la disponibilità pubblica di codice di exploit effettivamente impiegato, le segnalazioni di clienti compromessi, le informazioni ricevute da CSIRT o da fornitori di threat intelligence.

La seconda tipologia è quella degli incidenti gravi, descritti come incidenti che hanno un impatto severo sulla sicurezza del prodotto con elementi digitali, con esemplificazione riferita alla compromissione di disponibilità, autenticità, integrità o riservatezza, e con richiamo all’articolo 3, punto 44, del CRA per la definizione e all’articolo 14, paragrafo 5, per i criteri di gravità. Si ritiene che la lettura combinata delle due disposizioni sia indispensabile: la definizione fissa il tipo di evento, i criteri di gravità ne delimitano la soglia di rilevanza. In assenza di un’analisi preventiva di tali criteri, calibrata sulle caratteristiche del prodotto e sulla base installata, la valutazione dovrebbe essere condotta sotto pressione temporale, con esito facilmente incoerente.

E’ opinione dello scrivente che il punto di maggiore difficoltà applicativa consista nella qualificazione dell’evento come incidente “che ha un impatto grave sulla sicurezza del prodotto”. La formulazione impone una valutazione tecnica che non coincide con la valutazione di impatto sull’organizzazione del fabbricante: un incidente che comprometta gravemente la sicurezza del prodotto presso gli utilizzatori può avere effetti trascurabili sull’infrastruttura del fabbricante, e viceversa. Si suggerisce pertanto di costruire una matrice di valutazione dedicata, distinta da quella utilizzata per la classificazione degli incidenti di sicurezza aziendali e da quella impiegata per la valutazione del rischio per i diritti e le libertà degli interessati ai sensi del GDPR.

Le scansioni temporali: allerta precoce, notifica, relazione finale

Il factsheet chiarisce che il processo di segnalazione inizia nel momento in cui il fabbricante o il gestore OSS acquisisce conoscenza dello sfruttamento attivo di una vulnerabilità o dell’incidente grave, e articola tre adempimenti successivi.

Il primo è l’allerta precoce (early warning), da trasmettere entro ventiquattro ore dalla conoscenza dell’evento. In sostanza, si tratta di una comunicazione minimale, destinata ad attivare il sistema di allerta europeo, il cui contenuto non presuppone un’analisi compiuta. La ratio è quella già nota nel sistema NIS2: privilegiare la tempestività dell’informazione grezza rispetto alla completezza dell’informazione elaborata.

Il secondo adempimento è la notifica della vulnerabilità attivamente sfruttata o dell’incidente grave, da trasmettere entro settantadue ore dalla conoscenza, con indicazione — secondo il factsheet — di informazioni generali e di una valutazione iniziale. In termini più pragmatici, questa è la comunicazione che consente alle autorità di comprendere la natura dell’evento, la sua portata, i prodotti e le versioni interessati, le eventuali misure di mitigazione già disponibili.

Il terzo adempimento è la relazione finale (final report), il cui termine varia secondo la tipologia di evento. Per le vulnerabilità, la relazione va trasmessa non oltre quattordici giorni dalla disponibilità di una misura correttiva, ad esempio una patch. Per gli incidenti gravi, la relazione va trasmessa entro un mese dalla trasmissione della notifica delle settantadue ore.

Va rilevata la differenza strutturale tra i due termini. Per gli incidenti gravi il termine è ancorato a un evento certo e già verificatosi — la trasmissione della notifica intermedia — e ha dunque natura fissa. Per le vulnerabilità, invece, il termine è ancorato alla disponibilità della misura correttiva, evento futuro e non necessariamente prossimo: la conseguenza è che il termine per la relazione finale può collocarsi a mesi di distanza dalla segnalazione iniziale, se lo sviluppo della patch richiede tempi lunghi. Secondo il parere di chi scrive, questa asimmetria è coerente con la logica della disclosure coordinata — non si chiede al fabbricante di chiudere il procedimento informativo prima di avere una soluzione — ma introduce un’esigenza di tracciamento prolungato: occorre mantenere aperto un fascicolo per ciascuna vulnerabilità segnalata, con un presidio che colleghi il rilascio della patch alla decorrenza del termine di quattordici giorni. Nella prassi dei sistemi di gestione, un termine agganciato a un evento tecnico interno è tra i più frequentemente disattesi, non per volontà elusiva ma per assenza di un collegamento automatico tra il processo di rilascio e il processo di compliance.

Occorre aggiungere che il regolamento prevede altresì, accanto agli obblighi verso le autorità, l’informazione degli utenti del prodotto interessato in ordine all’evento e, ove necessario, alle misure correttive o di mitigazione che l’utente può adottare. Trattasi di un obbligo distinto e ulteriore, che nella pratica pone problemi di sequenza e di contenuto: informare gli utenti prima della disponibilità di una correzione può ampliare la platea dei potenziali attaccanti; informarli tardivamente li espone a un rischio per un periodo prolungato. Si ritiene che la scelta debba essere documentata come decisione motivata, in modo da poterne dare conto in sede di vigilanza.

L’individuazione del CSIRT destinatario e il flusso di diffusione

Il factsheet indica che il CSIRT nazionale al quale segnalare attraverso la SRP è determinato in via principale dal luogo di stabilimento principale del soggetto obbligato, con rinvio all’articolo 14, paragrafo 7, del CRA per i dettagli che consentono l’identificazione. In termini più concreti, per un fabbricante con stabilimento principale in Italia il destinatario sarà il CSIRT Italia; per un fabbricante stabilito in un Paese terzo, l’individuazione seguirà criteri sussidiari specificati nel regolamento.

La determinazione del CSIRT competente è un adempimento preparatorio, non una scelta da compiere nell’emergenza. Si suggerisce di formalizzarla in un documento interno, con motivazione sintetica del criterio applicato, aggiornato in caso di riorganizzazioni societarie, trasferimenti di sede o modifiche della struttura del gruppo. Nei gruppi multinazionali con più entità produttive in diversi Stati membri, la questione si complica: il criterio del luogo di stabilimento principale va riferito al soggetto che riveste la qualifica di fabbricante del prodotto interessato, e non genericamente alla capogruppo. Non si ha evidenza di indicazioni specifiche, nei documenti richiamati dal factsheet, in ordine alla gestione dei casi in cui più entità dello stesso gruppo siano fabbricanti di prodotti diversi con stabilimenti in Stati membri differenti; si ritiene che la soluzione più prudente consista nel mappare preventivamente la corrispondenza tra prodotti, entità fabbricante e CSIRT competente.

Quanto al flusso successivo alla trasmissione, il factsheet descrive un meccanismo di diffusione automatica: il CSIRT che riceve inizialmente la notifica la diffonde senza indugio agli altri CSIRT degli Stati membri nei quali il prodotto è disponibile, e la notifica è contestualmente messa a disposizione di ENISA. I CSIRT nazionali condividono inoltre determinate informazioni con le rispettive autorità di vigilanza del mercato, per consentire a queste ultime di adempiere ai propri obblighi di applicazione della normativa.

Quest’ultimo passaggio merita attenzione particolare nella prospettiva del giurista d’impresa. La segnalazione al CSIRT, pur avendo finalità primariamente cooperative e di sicurezza, alimenta un flusso informativo verso l’autorità che esercita poteri di vigilanza e sanzionatori. In sostanza, l’informazione trasmessa in adempimento di un obbligo di sicurezza può divenire elemento di conoscenza per l’autorità competente a valutare la conformità del prodotto. Secondo il parere di chi scrive, ciò non giustifica alcuna reticenza — l’omessa segnalazione è essa stessa violazione, e per di più agevolmente accertabile ex post — ma impone accuratezza redazionale: la segnalazione deve essere veritiera, completa rispetto a quanto noto al momento, e priva di qualificazioni giuridiche non necessarie. Si suggerisce di descrivere fatti e dati tecnici, evitando formule valutative che possano essere lette come ammissioni di non conformità, e di far precedere la trasmissione da una revisione della funzione legale, compatibilmente con i tempi.

Il factsheet precisa altresì che la piattaforma incorpora misure di sicurezza destinate a proteggere la riservatezza delle informazioni trasmesse. Va detto che la questione della riservatezza dei dati di vulnerabilità è centrale: la concentrazione, in un unico sistema europeo, di informazioni su vulnerabilità attivamente sfruttate in prodotti diffusi sul mercato dell’Unione crea, per definizione, un obiettivo di elevato valore per attori malevoli. Non si ha evidenza, nel documento in esame, di dettagli tecnici sull’architettura di sicurezza della piattaforma; si ritiene che tali informazioni, allorché rese disponibili, meriteranno attenta valutazione, anche perché la fiducia dei fabbricanti nel sistema di segnalazione dipende in misura decisiva dalla percezione della sua sicurezza.

Il differimento della diffusione e il regolamento delegato

Il factsheet conferma che, in circostanze eccezionali, la diffusione delle informazioni può essere differita ai sensi dell’articolo 16, paragrafo 2, del CRA, e che il regolamento delegato richiamato dal factsheet specifica ulteriormente le condizioni alle quali la diffusione delle notifiche può essere differita.

La ratio dell’istituto è comprensibile. Nella logica della disclosure coordinata, la circolazione di informazioni su una vulnerabilità attivamente sfruttata prima della disponibilità di una correzione può aggravare il rischio anziché ridurlo, ampliando la platea di soggetti in grado di replicare l’attacco. Il differimento serve, dunque, a conciliare l’esigenza informativa delle autorità con l’esigenza di contenimento del rischio.

Va rilevato che il differimento riguarda la diffusione da parte del CSIRT ricevente, non la trasmissione da parte del soggetto obbligato: l’obbligo di segnalare entro ventiquattro e settantadue ore non è sospendibile. In termini più pragmatici, il fabbricante deve segnalare nei termini e può — nei casi previsti — rappresentare l’esigenza di differire la diffusione, con argomentazione fondata sui criteri stabiliti dalla normativa delegata. Si suggerisce di predisporre, già in fase preparatoria, uno schema di motivazione della richiesta di differimento, che consenta di articolare in modo sintetico e documentato le ragioni tecniche per le quali la diffusione anticipata aumenterebbe il rischio.

i criteri e le condizioni fissate dai cinque articoli del regolamento delegato 881/2026, alla cui lettura di dettaglio si rinvia è pertanto passaggio necessario per chiunque debba costruire una procedura interna completa.

Profili critici e questioni interpretative

La nozione di conoscenza e la decorrenza delle ventiquattro ore

Il presupposto di ogni termine è la conoscenza dell’evento. Il factsheet colloca l’inizio del processo nel momento in cui il soggetto obbligato “become aware” dello sfruttamento attivo o dell’incidente grave. La formula riecheggia l’articolo 33 del GDPR e, come per quest’ultimo, solleva la questione di individuare il momento e il soggetto rilevanti.

Nell’esperienza applicativa maturata sul GDPR — e recepita nelle linee guida dell’EDPB in materia di notifica delle violazioni dei dati personali — la conoscenza si radica nel momento in cui l’organizzazione ha un ragionevole grado di certezza che un evento di sicurezza si è verificato, e non nel momento in cui ne ha piena e definitiva contezza tecnica; si ammette un breve periodo di verifica iniziale, che non può però trasformarsi in una dilazione strumentale. Si ritiene che un’impostazione analoga possa essere ragionevolmente adottata ai fini del CRA, con l’avvertenza che il termine, ridotto a un terzo rispetto a quello del GDPR, riduce drasticamente lo spazio per la verifica preliminare.

La questione più delicata riguarda l’imputazione della conoscenza all’interno dell’organizzazione. Un’informazione che raggiunga un tecnico di secondo livello dell’assistenza clienti, o che pervenga a un indirizzo di posta elettronica generico di sicurezza non monitorato nei giorni festivi, integra la conoscenza del fabbricante? Secondo il parere di chi scrive, la risposta tende ad essere affermativa: l’organizzazione che si dota di canali di ricezione ha l’onere di presidiarli, e l’inefficienza interna del flusso di escalation non è opponibile all’autorità. Ne consegue, sul piano operativo, che il presidio dei canali di ricezione delle segnalazioni di sicurezza — inclusi i canali della politica di divulgazione coordinata delle vulnerabilità — deve essere continuativo e documentato, con reperibilità definita anche al di fuori dell’orario ordinario. Si osserva incidentalmente che un termine di ventiquattro ore comprensivo di fine settimana e giorni festivi ha, come conseguenza pratica inevitabile, la necessità di un presidio di turno o di una procedura di allerta automatica.

Il rischio di divulgazione prematura e la tensione con la disclosure coordinata

Il secondo profilo critico riguarda l’ampliamento del numero di soggetti che, in tempi brevissimi, vengono a conoscenza di una vulnerabilità attivamente sfruttata e non ancora corretta. Il flusso descritto dal factsheet prevede la trasmissione al CSIRT del luogo di stabilimento, la diffusione ai CSIRT degli Stati membri in cui il prodotto è disponibile, la messa a disposizione di ENISA e la condivisione di informazioni con le autorità di vigilanza del mercato. Anche assumendo la piena affidabilità di ciascun destinatario istituzionale, l’aumento del numero di soggetti informati incrementa statisticamente la probabilità di fuoriuscita non voluta dell’informazione.

Va riconosciuto che il legislatore europeo ha considerato il problema, prevedendo l’istituto del differimento della diffusione e imponendo alla piattaforma misure di protezione della riservatezza. Si ritiene tuttavia che il tema resti aperto e che la sua gestione dipenderà in larga misura dalla prassi: dalla rapidità con cui le richieste di differimento verranno valutate, dalla granularità delle informazioni effettivamente condivise con le autorità di vigilanza, dalla robustezza operativa dei presidi tecnici. Nella prospettiva del fabbricante, si suggerisce di modulare il contenuto delle segnalazioni secondo il principio di necessità: fornire le informazioni richieste, senza allegare spontaneamente dettagli tecnici di riproducibilità dell’attacco che non siano indispensabili alla comprensione dell’evento da parte dell’autorità.

Le sovrapposizioni con gli altri obblighi di notifica

Il terzo profilo critico è quello della moltiplicazione degli obblighi. La piattaforma unica risolve — apprezzabilmente — la moltiplicazione interna al CRA, consentendo una sola trasmissione verso tutti i destinatari del sistema CRA. Non risolve, però, la moltiplicazione esterna: un medesimo evento può richiedere la segnalazione al CSIRT ai sensi del CRA, la notifica al CSIRT ai sensi della NIS2 e del decreto legislativo n. 138 del 2024 se il soggetto è anche soggetto essenziale o importante, la notificazione al Garante ai sensi dell’articolo 33 del GDPR se vi è violazione di dati personali, la comunicazione agli interessati ai sensi dell’articolo 34, le segnalazioni settoriali eventualmente applicabili, la comunicazione agli utenti del prodotto prevista dal CRA, nonché — per le società quotate — le valutazioni in materia di informazione privilegiata.

Appare chiaro allo scrivente che l’unico presidio efficace consista in una procedura unica di gestione degli eventi di sicurezza, che a monte della qualificazione giuridica raccolga i fatti in modo standardizzato e, a valle, attivi in parallelo i diversi canali di notifica secondo una matrice predefinita. La frammentazione dei processi — un flusso per la privacy, un flusso per la NIS2, un flusso per la conformità di prodotto — è, nell’esperienza dei sistemi di gestione, la principale causa di segnalazioni tardive o incoerenti tra loro. L’incoerenza tra segnalazioni relative al medesimo evento presentate ad autorità diverse è, di per sé, un fattore di rischio: espone a contestazioni di inesattezza e mina la credibilità complessiva della rappresentazione dei fatti.

Riservatezza, segreti commerciali e dati personali nelle notifiche

Il quarto profilo attiene al contenuto informativo delle segnalazioni. Le informazioni relative a vulnerabilità di prodotto e ad architetture software costituiscono, in molti casi, informazioni commerciali riservate ai sensi della direttiva (UE) 2016/943 e del decreto legislativo 10 febbraio 2005, n. 30, come modificato. La trasmissione ad autorità pubbliche in adempimento di un obbligo di legge non fa perdere alle informazioni il carattere di riservatezza, ma è opportuno che le segnalazioni rechino l’espressa qualificazione delle parti riservate, quando la piattaforma lo consenta.

Sul versante della protezione dei dati personali, va considerato che le segnalazioni possono contenere dati personali: nominativi e contatti dei referenti del fabbricante, informazioni relative ai ricercatori che hanno individuato la vulnerabilità, in taluni casi dati riferiti a utenti interessati dall’incidente. Il trattamento connesso alla segnalazione trova base giuridica nell’adempimento di un obbligo legale ai sensi dell’articolo 6, paragrafo 1, lettera c), del GDPR. Si suggerisce, comunque, l’applicazione rigorosa del principio di minimizzazione di cui all’articolo 5, paragrafo 1, lettera c): la segnalazione deve contenere i dati personali strettamente necessari, e in particolare va evitata la trasmissione di dati relativi a singoli utenti quando la descrizione dell’evento possa essere resa in forma aggregata o anonima. Il registro dei trattamenti di cui all’articolo 30 del GDPR dovrebbe essere integrato con il trattamento connesso agli obblighi di segnalazione, e l’informativa ai sensi degli articoli 13 e 14 dovrebbe menzionare la comunicazione dei dati alle autorità competenti quando ciò sia prevedibile.

La catena di fornitura e i rapporti contrattuali

Il quinto profilo riguarda la catena di fornitura. Il fabbricante è tenuto a segnalare eventi che possono avere origine in componenti di terzi: librerie open source, moduli hardware, servizi di elaborazione a distanza integrati nel prodotto. Il rispetto del termine di ventiquattro ore presuppone dunque che il fabbricante venga a conoscenza dell’evento tempestivamente, il che dipende dalla qualità dei flussi informativi con i fornitori.

Si ritiene pertanto necessario un intervento sulla contrattualistica di fornitura, con l’introduzione di obblighi di comunicazione tempestiva delle vulnerabilità e degli incidenti, con termini interni più stretti di quelli di legge — poiché il fabbricante deve disporre di un margine per la valutazione — e con obblighi di cooperazione nella predisposizione delle informazioni da trasmettere. Nella prassi contrattuale, clausole di questo tipo sono già diffuse in attuazione dell’articolo 28 del GDPR per i rapporti di responsabile del trattamento e in attuazione delle previsioni NIS2 in materia di sicurezza della catena di approvvigionamento; si suggerisce di estenderne l’ambito agli aspetti di sicurezza di prodotto, evitando però la mera duplicazione di clausole concepite per finalità diverse.

Va aggiunto un profilo di allocazione del rischio: la responsabilità per l’omessa segnalazione grava sul fabbricante, non sul fornitore inadempiente all’obbligo contrattuale di informazione. Le clausole di manleva possono riequilibrare il danno economico, ma non escludono l’imputazione della violazione. Ne consegue che il presidio contrattuale deve essere accompagnato da un presidio di verifica: monitoraggio autonomo delle vulnerabilità dei componenti utilizzati, gestione aggiornata della distinta base del software, sottoscrizione di flussi di threat intelligence pertinenti alle tecnologie impiegate.

I gestori di software libero e open source e la proporzionalità degli oneri

Il sesto profilo riguarda la sostenibilità degli adempimenti per i gestori OSS. Trattasi, in molti casi, di organizzazioni con risorse limitate, prive di funzioni legali strutturate e operanti su base volontaria. L’estensione a tali soggetti di obblighi di segnalazione con termini di ventiquattro ore solleva, secondo il parere di chi scrive, un tema di effettività: un obbligo che l’organizzazione destinataria non è strutturalmente in grado di adempiere rischia di produrre, come effetto principale, la disapplicazione di fatto oppure la contrazione dell’offerta di componenti open source verso il mercato europeo.

Il legislatore ha mitigato il regime, prevedendo per i gestori obblighi attenuati e proporzionati e limitando l’obbligo di segnalazione all’ambito del loro coinvolgimento nello sviluppo di prodotti con elementi digitali. Si ritiene che la prassi delle autorità nazionali sarà determinante: un approccio orientato al supporto e alla gradualità, piuttosto che alla sanzione immediata, appare più coerente con la finalità del regolamento. Non si ha evidenza, nel documento in esame, di indicazioni specifiche in ordine a modalità semplificate di accesso alla piattaforma per tali soggetti; si osserva che la predisposizione di percorsi guidati e di modelli precompilati potrebbe contribuire in misura significativa all’effettività dell’obbligo.

Il regime sanzionatorio come fattore di priorità

Va infine considerato il profilo sanzionatorio, che nell’economia delle decisioni aziendali incide sulla priorità assegnata al progetto di adeguamento. Il CRA prevede, per le violazioni dei requisiti essenziali di cui all’allegato I e degli obblighi di cui agli articoli 13 e 14, sanzioni amministrative pecuniarie fino a 15.000.000 di euro o, se superiore, fino al 2,5 per cento del fatturato mondiale totale annuo dell’esercizio precedente; per le violazioni degli altri obblighi del regolamento il massimale è fissato a 10.000.000 di euro o al 2 per cento del fatturato mondiale; per la comunicazione di informazioni inesatte, incomplete o fuorvianti agli organismi notificati e alle autorità di vigilanza del mercato, a 5.000.000 di euro o all’1 per cento del fatturato. Il regolamento prevede altresì una modulazione per le microimprese e le piccole imprese.

Si osserva che l’obbligo di segnalazione di cui all’articolo 14 rientra nella fascia sanzionatoria più elevata. Ciò conferma la centralità sistematica che il legislatore attribuisce al flusso informativo. Va rilevato, inoltre, che la fascia sanzionatoria relativa alla comunicazione di informazioni inesatte o fuorvianti alle autorità costituisce un ulteriore argomento in favore dell’accuratezza redazionale delle segnalazioni: la fretta imposta dai termini brevi non attenua l’onere di veridicità, e la segnalazione approssimativa può esporre a un rischio autonomo.

Adempimenti operativi per DPO, funzioni compliance e imprese

Quanto segue è concepito come traccia di lavoro per la costruzione o la revisione dei presidi interni in vista della decorrenza dell’11 settembre 2026. Le indicazioni presuppongono la verifica preliminare dell’applicabilità del CRA all’impresa e ai suoi prodotti e vanno intese a titolo meramente esemplificativo e non esaustivo. Chi scrive, ritiene che debba concentrarsi l’attenzione sulle seguenti attività di massima:

La verifica di applicabilità e qualificazione soggettiva: occorre accertare, in via preliminare, se l’impresa rivesta la qualifica di fabbricante di prodotti con elementi digitali resi disponibili sul mercato dell’Unione, ovvero di gestore di software libero e open source, ovvero ancora di importatore, distributore o rappresentante autorizzato. Si suggerisce di condurre la verifica prodotto per prodotto e non a livello di entità giuridica, poiché la stessa impresa può essere fabbricante di alcuni prodotti e mero distributore di altri, con obblighi differenti; l’esito va formalizzato in un documento di qualificazione, sottoscritto dalle funzioni tecniche e legali e sottoposto a riesame periodico.

Il censimento dei prodotti e dei mercati di disponibilità: la diffusione della segnalazione ai CSIRT degli Stati membri in cui il prodotto è disponibile presuppone che il fabbricante sappia indicare tali Stati. Si ritiene pertanto necessario mantenere un inventario dei prodotti con elementi digitali che riporti, per ciascuno, le versioni supportate, i mercati di commercializzazione, i canali distributivi e i componenti di terzi integrati, con collegamento alla distinta base del software.

La determinazione preventiva del CSIRT competente: l’individuazione del CSIRT destinatario ai sensi dell’articolo 14, paragrafo 7, del CRA va effettuata prima del verificarsi di qualunque evento, sulla base del criterio del luogo di stabilimento principale del soggetto obbligato e dei criteri sussidiari applicabili ai fabbricanti di Paesi terzi. Nei gruppi con più entità fabbricanti in Stati membri diversi, si suggerisce di predisporre una tabella di corrispondenza tra prodotto, entità fabbricante e CSIRT competente.

La registrazione e gestione degli accessi alla piattaforma: poiché il flusso descritto da ENISA prevede accesso autenticato, occorre completare tempestivamente la registrazione, individuare i soggetti abilitati, definire deleghe e supplenze, verificare periodicamente la funzionalità delle credenziali e documentare la procedura di accesso in modo che essa sia utilizzabile anche da personale reperibile fuori orario.

La procedura interna di rilevazione, escalation e qualificazione: si suggerisce di formalizzare una procedura che definisca i canali di ricezione delle informazioni su vulnerabilità e incidenti — assistenza clienti, casella dedicata prevista dalla politica di divulgazione coordinata, monitoraggio tecnico, flussi di threat intelligence, comunicazioni di fornitori e CSIRT —, i tempi massimi di inoltro al gruppo di valutazione e i criteri di qualificazione dell’evento come vulnerabilità attivamente sfruttata o incidente grave. Il momento della prima ricezione va registrato con orario, poiché è da esso che, in caso di verifica, si tenderà a far decorrere la conoscenza.

La creazione di una matrice di gravità calibrata sui criteri dell’articolo 14, paragrafo 5: la valutazione della gravità dell’incidente va condotta sulla base dei criteri normativi, tradotti in una matrice applicabile alle specificità dei prodotti dell’impresa. Si ritiene opportuno che la matrice sia distinta da quella utilizzata per la classificazione degli incidenti aziendali e da quella impiegata per la valutazione del rischio ai sensi degli articoli 33 e 34 del GDPR, ferma la necessità di un raccordo procedurale tra le tre valutazioni.

La predisposizione anticipata di modelli di segnalazione : occorre predisporre bozze di allerta precoce, di notifica delle settantadue ore e di relazione finale, coerenti con i campi informativi della piattaforma, in lingua inglese e nella lingua eventualmente richiesta dal CSIRT competente. La predisposizione anticipata riduce il rischio di omissioni e di formulazioni improprie redatte sotto pressione.

L’implementazione di una procedura per la richiesta di differimento della diffusione: alla luce dell’articolo 16, paragrafo 2, del CRA e delle condizioni specificate dal regolamento delegato 881/2026, si suggerisce di predisporre uno schema di motivazione della richiesta di differimento, con individuazione dei presupposti tecnici e delle evidenze a supporto, e di definire chi, all’interno dell’organizzazione, è competente a decidere se avanzarla.

La predisposizione di un presidio continuativo e di sistemi di reperibilità: il termine di ventiquattro ore impone una copertura che comprenda fine settimana e periodi di chiusura aziendale. Si ritiene necessario definire turni di reperibilità, meccanismi di allerta automatica sui canali di ricezione e procedure di attivazione rapida del gruppo di valutazione, con evidenza documentale del funzionamento del presidio.

Il tracciamento dei termini agganciati al rilascio delle correzioni: poiché per le vulnerabilità la relazione finale è dovuta entro quattordici giorni dalla disponibilità della misura correttiva, occorre collegare il processo di rilascio delle patch al processo di compliance, mediante un flusso di lavoro che generi automaticamente l’adempimento al momento della pubblicazione della correzione.

Il coordinamento con la notificazione di data breach: il DPO dovrebbe essere inserito nel flusso informativo relativo agli eventi CRA, con il compito di valutare in parallelo la sussistenza di una violazione di dati personali e i conseguenti obblighi di cui agli articoli 33 e 34 del GDPR. Si suggerisce di integrare il registro delle violazioni previsto dall’articolo 33, paragrafo 5, con l’indicazione dell’eventuale segnalazione effettuata ai sensi del CRA, per garantire coerenza tra le rappresentazioni fornite alle diverse autorità.

La revisione della contrattualistica di fornitura: occorre introdurre nei contratti con fornitori di componenti software e hardware obblighi di comunicazione tempestiva di vulnerabilità e incidenti, con termini interni compatibili con quelli di legge, obblighi di cooperazione informativa e presidi di riservatezza, valutando le clausole di manleva senza confidare in esse quale sostituto del presidio organizzativo.

L’informazione agli utenti del prodotto: va definita una procedura per la comunicazione agli utenti interessati, con criteri di scelta del momento e del contenuto, coordinati con la strategia di disclosure coordinata e con l’eventuale differimento della diffusione istituzionale; la decisione va motivata e documentata.

La formazione e le simulazioni: si ritiene opportuno sottoporre il processo a esercitazioni periodiche, anche in forma di simulazione documentale, verificando in particolare il rispetto del termine di ventiquattro ore in scenari di ricezione dell’informazione in orario non lavorativo. L’esito delle esercitazioni va verbalizzato e utilizzato per la revisione delle procedure.

L’integrazione nel sistema di gestione e di audit interno: gli adempimenti CRA vanno inseriti nel sistema di gestione della sicurezza delle informazioni eventualmente adottato, con indicatori, responsabilità formalizzate e inclusione nel piano di audit interno; la mancanza di evidenze documentali del funzionamento del presidio è, nella prassi di audit, la carenza rilevata con maggiore frequenza.

Conclusioni

Il factsheet di ENISA sulla Single Reporting Platform non introduce obblighi nuovi rispetto a quanto già stabilito dal regolamento (UE) 2024/2847, ma segnala con chiarezza che l’infrastruttura destinata a ricevere le segnalazioni è in costruzione e che la data dell’11 settembre 2026 costituisce il riferimento operativo attorno al quale organizzare l’adeguamento. Si ritiene che il documento, per la sua natura sintetica, vada letto come conferma di un cronoprogramma più che come fonte di chiarimenti interpretativi, i quali continuano a dipendere dal testo del regolamento, dalla guidance della Commissione europea e dagli atti delegati.

Restano aperte alcune questioni specifiche, sulle quali si ritiene utile mantenere attenzione. La prima riguarda il contenuto informativo esatto dei campi della piattaforma: la definizione dei modelli interni di segnalazione richiede di conoscere quali informazioni saranno effettivamente richieste nelle tre fasi, e la pubblicazione di specifiche tecniche e di schemi dei campi costituirebbe un contributo significativo alla preparazione dei soggetti obbligati. La seconda riguarda i criteri di valutazione delle richieste di differimento della diffusione: il regolamento delegato richiamato dal factsheet ne specifica le condizioni, ma l’effettività dell’istituto dipenderà dalla tempestività con cui i CSIRT saranno in grado di deliberare, in un contesto nel quale ogni ora incide sul rischio. La terza riguarda il coordinamento pratico tra segnalazione CRA e notificazione NIS2 verso il medesimo interlocutore nazionale: non si ha evidenza, alla data di redazione, di indicazioni operative italiane che chiariscano se e in quale misura le due comunicazioni possano essere presentate in modo coordinato, e un chiarimento in tal senso sarebbe apprezzabile per ridurre la duplicazione degli adempimenti.

Una quarta questione, di natura più sistematica, riguarda l’esatta perimetrazione della nozione di incidente grave rispetto alla nozione di violazione dei dati personali. Le due categorie, pur distinte per presupposti e finalità, condividono un’area di sovrapposizione ampia, e l’esperienza applicativa del GDPR suggerisce che la qualificazione dei fatti sotto pressione temporale produce esiti disomogenei. Secondo il parere di chi scrive, la costruzione anticipata di criteri di qualificazione coerenti tra i diversi regimi — non identici, ma reciprocamente consapevoli — è la principale attività preparatoria che le imprese possono utilmente compiere nei mesi che precedono la decorrenza.

Una quinta questione riguarda l’assetto istituzionale nazionale. La designazione delle autorità di vigilanza del mercato competenti per il CRA, la definizione dei loro poteri istruttori e la disciplina interna delle sanzioni sono passaggi necessari per rendere pienamente operativo il sistema; la loro tempistica inciderà sull’effettività della vigilanza e, indirettamente, sulla percezione di priorità del tema presso le imprese.

Va infine osservato che il CRA introduce, nel diritto dell’Unione, un obbligo di segnalazione riferito alla sicurezza dei prodotti immessi sul mercato e non alla sicurezza dell’organizzazione che li produce. Trattasi di uno spostamento concettuale rilevante: la responsabilità informativa segue il prodotto lungo il suo ciclo di vita, presso una platea di utilizzatori spesso non identificabili individualmente. Le implicazioni di questo spostamento — sul piano della responsabilità civile da prodotto, del coordinamento con la nuova disciplina europea in materia di responsabilità per danno da prodotti difettosi, e della gestione documentale di lungo periodo — meriteranno approfondimenti autonomi, che il presente contributo si limita a segnalare come prospettive evolutive da monitorare.

L'articolo Cyber Resilience Act: obbligo di segnalazione dal 11 settembre 2026 proviene da 01magazine.

Il progressivo radicamento dei sistemi di intelligenza artificiale nei processi aziendali e nella vita quotidiana pone con crescente urgenza una questione che si colloca al crocevia tra informatica e diritto: cosa accade ai dati personali che sono stati utilizzati per addestrare un modello di machine learning quando l’interessato esercita il proprio diritto alla cancellazione ai sensi dell’articolo 17 del Regolamento (UE) 2016/679 (GDPR)? La risposta tecnica a questa domanda giuridica si chiama machine unlearning, vale a dire l’insieme delle tecniche volte a rimuovere o neutralizzare l’influenza di specifici dati di addestramento all’interno di un modello già addestrato. Il tema interseca il quadro normativo del GDPR, le Linee Guida dell’European Data Protection Board (EDPB), le disposizioni del Regolamento (UE) 2024/1689 sull’intelligenza artificiale (AI Act) e i provvedimenti dell’Autorità Garante per la protezione dei dati personali, assumendo rilievo operativo centrale per DPO, responsabili del trattamento e fornitori di sistemi AI. Il presente articolo analizza il problema in tutte le sue dimensioni — normativa, tecnica e pratica — per offrire al professionista della protezione dei dati gli strumenti concettuali e le indicazioni operative necessari ad affrontare la questione.

—

I. Introduzione e inquadramento generale

I dati personali non vengono più soltanto raccolti e archiviati, ma utilizzati per l’addestramento di modelli statistici. I moderni sistemi di intelligenza artificiale — dai modelli di linguaggio di grandi dimensioni (Large Language Models, LLM) ai classificatori di immagini, dai sistemi di raccomandazione ai motori di analisi predittiva — apprendono rappresentazioni complesse del mondo a partire da enormi quantità di dati di addestramento. Una volta completato il processo di training, i parametri del modello (i cosiddetti pesi) incorporano, in forma statisticamente distribuita e non immediatamente leggibile, le informazioni contenute in quei dati. Il modello, in altri termini, ha “imparato” qualcosa da ciascun dato: e quel qualcosa non scompare facilmente.

Questo meccanismo proietta un esteso cono d’ombra su uno dei diritti fondamentali riconosciuti dall’ordinamento europeo: il diritto alla cancellazione dei dati personali, comunemente noto come “diritto all’oblio”, sancito dall’articolo 17 del GDPR. Se un individuo chiede che i propri dati vengano rimossi da un sistema di intelligenza artificiale, cosa significa concretamente soddisfare quella richiesta? È sufficiente eliminare i dati dal dataset di addestramento originario? O è necessario intervenire anche sul modello già addestrato, che porta in sé le tracce di quei dati? E, in questo secondo caso, come è tecnicamente possibile farlo senza vanificare l’utilità del modello?

Queste domande non sono più meramente accademiche. Il Garante per la protezione dei dati personali italiano ha già dimostrato di voler applicare il GDPR ai sistemi di intelligenza artificiale con determinazione — il caso ChatGPT ne è la testimonianza più nota (sebbene interrotta nel suo sviluppo giurisprudenziale dalla decisione del Tribunale di Roma che ha sancito l’incompetenza territoriale del Garante italiano) — e l’EDPB ha avviato un percorso di riflessione sistematica sul tema. L’AI Act, entrato in vigore il 1° agosto 2024 e applicabile in modo scaglionato, aggiunge ulteriori obblighi di trasparenza e di governance dei dati che si intrecciano con quelli già derivanti dal GDPR. Il machine unlearning emerge, in questo contesto, non come una mera curiosità informatica, ma come una necessità giuridica e operativa.

L’obiettivo di questo articolo è triplice. In primo luogo, ricostruire il quadro normativo rilevante, identificando le norme che impongono o presuppongono la possibilità di “disimparare” dati da parte di un sistema AI. In secondo luogo, illustrare — con il rigore necessario ma senza eccessive tecnicità — le principali metodologie di machine unlearning oggi disponibili, evidenziandone i limiti. Infine, tradurre tutto ciò in indicazioni operative concrete per DPO, responsabili del trattamento e consulenti.

—

II. Il quadro normativo di riferimento

A. Il GDPR e il diritto alla cancellazione

Il punto di partenza normativo è, inevitabilmente, l’articolo 17 del Regolamento (UE) 2016/679. La disposizione riconosce all’interessato il diritto di ottenere dal titolare del trattamento la cancellazione dei dati personali che lo riguardano “senza ingiustificato ritardo” quando ricorra una delle condizioni tassativamente elencate: i dati non sono più necessari rispetto alle finalità per cui sono stati raccolti; l’interessato revoca il consenso e non sussiste altro fondamento giuridico; l’interessato si oppone al trattamento; i dati sono stati trattati illecitamente; la cancellazione è imposta dal diritto dell’Unione o dello Stato membro; i dati sono stati raccolti nell’ambito di servizi della società dell’informazione offerti direttamente a minori.

La norma fa parte di un sistema coerente che include anche il principio di limitazione della conservazione (articolo 5, paragrafo 1, lettera e), secondo cui i dati personali devono essere “conservati in una forma che consenta l’identificazione degli interessati per un arco di tempo non superiore al conseguimento delle finalità per le quali sono trattati”. Combinati, questi principi delineano un’architettura di diritti che presuppone — implicitamente ma necessariamente — che il titolare abbia il controllo effettivo dei dati in ogni momento del loro ciclo di vita.

Il problema che il machine learning introduce è precisamente qui: il ciclo di vita dei dati non termina con la fine dell’addestramento. I dati, una volta usati per costruire un modello, continuano a “vivere” nei parametri di quel modello in forma latente. Se il titolare del trattamento cancella il file originario ma mantiene il modello addestrato su quei dati, ha davvero adempiuto all’obbligo di cancellazione? La risposta dipende, in larga misura, dalla natura del modello e dal contributo che quel singolo dato ha apportato alla sua costruzione — e questa è già, di per sé, una valutazione complessa.

B. Il principio di privacy by design e la minimizzazione dei dati

L’articolo 25 del GDPR impone al titolare del trattamento di adottare, sia al momento della determinazione dei mezzi del trattamento sia all’atto del trattamento stesso, misure tecniche e organizzative adeguate — come la pseudonimizzazione — e di trattare, per impostazione predefinita, solo i dati personali necessari per ciascuna finalità specifica. Il Considerando 78 chiarisce che questi principi si applicano a tutti i trattamenti, compresi quelli realizzati tramite sistemi automatizzati.

Applicato ai sistemi AI, il principio di privacy by design impone che già nella fase di progettazione del sistema si considerino le modalità con cui verranno gestite le eventuali richieste di cancellazione. Un sistema progettato senza tenere conto del machine unlearning è, per definizione, un sistema che non rispetta il principio di privacy by design con riferimento all’intero ciclo di vita del dato.

C. Le Linee Guida dell’EDPB e la posizione delle autorità di controllo

L’EDPB ha affrontato il tema dell’intelligenza artificiale e della protezione dei dati in più occasioni, con un approccio progressivamente più articolato. Le Linee Guida 05/2022 sull’uso della tecnologia di riconoscimento facciale nel settore delle attività di contrasto e il Parere 28/2024 su taluni aspetti di protezione dei dati relativi al trattamento di dati personali nel contesto dei modelli di IA affrontano, da diverse angolazioni, la questione del trattamento dei dati nel contesto dell’intelligenza artificiale.

In particolare, l’EDPB ha chiarito che la base giuridica del trattamento per l’addestramento di modelli AI deve essere identificata con precisione, che il principio di minimizzazione dei dati si applica anche alla fase di training, e che i diritti degli interessati — incluso il diritto alla cancellazione — devono essere garantiti non soltanto sul dataset originario ma sull’intero sistema di trattamento. Questo orientamento, pur non contenendo ancora prescrizioni tecniche specifiche sul machine unlearning, ne costituisce il fondamento giuridico implicito.

Il Garante per la protezione dei dati personali italiano, dal canto suo, ha dimostrato di applicare questi principi con rigore. Il provvedimento nei confronti di OpenAI per il servizio ChatGPT — adottato il 30 marzo 2023 e poi seguito da un’istruttoria approfondita — ha tra l’altro evidenziato la difficoltà di garantire i diritti degli interessati (incluso il diritto alla cancellazione) nell’ambito di un Large Language Model. Secondo quanto emerso nel corso del procedimento, OpenAI non era in grado di garantire la rettifica o la cancellazione delle informazioni personali eventualmente “assorbite” dal modello durante il training, il che aveva portato il Garante a contestare, tra l’altro, la violazione delle disposizioni del GDPR in materia di base giuridica del trattamento e di trasparenza verso gli interessati.

D. L’AI Act: obblighi di governance dei dati e interazione con il GDPR

Il Regolamento (UE) 2024/1689 sull’intelligenza artificiale introduce un livello ulteriore di regolamentazione che interagisce direttamente con le problematiche oggetto del presente articolo. L’AI Act non abroga né sostituisce il GDPR — il Considerando 10 del Regolamento chiarisce espressamente che le disposizioni del GDPR continuano ad applicarsi a qualsiasi trattamento di dati personali effettuato nel contesto dei sistemi AI — ma lo integra con obblighi specifici per i sistemi ad alto rischio e per i modelli di IA per uso generale (General Purpose AI models, GPAI).

Per i sistemi AI ad alto rischio, l’articolo 10 dell’AI Act impone specifici requisiti in materia di governance dei dati di addestramento, validazione e test. In particolare, i paragrafi 2 e 3 dell’articolo 10 prevedono che i fornitori di sistemi AI ad alto rischio debbano essere in grado di identificare e documentare i dataset utilizzati per l’addestramento, e che debbano adottare misure per garantire che i dati siano pertinenti, sufficientemente rappresentativi e, nella misura del possibile, esenti da errori e completi rispetto alle finalità perseguite. La possibilità di rimuovere specifici dati dal processo di apprendimento — o di neutralizzarne l’influenza sul modello — è una precondizione implicita di questi obblighi.

Per i modelli GPAI, gli articoli da 53 a 56 dell’AI Act prevedono obblighi di trasparenza, documentazione tecnica e rispetto delle norme applicabili in materia di diritto d’autore. I fornitori di modelli GPAI con rischio sistemico (articolo 51) sono soggetti a obblighi ancora più stringenti, inclusa la valutazione delle capacità del modello e la gestione dei rischi sistemici.

In questo quadro, il machine unlearning emerge non soltanto come uno strumento utile per dare attuazione al diritto alla cancellazione, ma come uno degli elementi della più ampia governance dei dati che l’AI Act richiede ai fornitori di sistemi AI.

E. La normativa nazionale: il Codice Privacy e i provvedimenti del Garante

A livello nazionale, il Decreto Legislativo 30 giugno 2003, n. 196 (Codice in materia di protezione dei dati personali), come modificato dal Decreto Legislativo 10 agosto 2018, n. 101, adegua l’ordinamento italiano alle disposizioni del GDPR. L’articolo 2-quinquiesdecies del Codice attribuisce al Garante il potere di prescrivere specifiche misure a tutela degli interessati quando il trattamento presenta rischi elevati, potere che può essere utilmente impiegato anche in materia di AI.

Il Garante ha già esercitato poteri analoghi nell’ambito del citato procedimento relativo a ChatGPT, imponendo a OpenAI misure specifiche — inclusa la predisposizione di uno strumento che consentisse agli interessati di opporsi all’uso dei propri dati per il training del modello — che si avvicinano concettualmente all’idea di machine unlearning, pur non prescrivendolo esplicitamente in termini tecnici. Tale importante precedente, purtroppo, ha trovato interruzione in sede giurisdizionale da parte del Tribunale di Roma che, sancendo l’incompetenza territoriale del Garante italiano, pur non entrando nel merito della questione, ha stabilito la giurisdizione del Garante Irlandese che non ha ancora preso in carico la questione specifica ereditata dall’Italia, prediligendo, piuttosto che azioni preventive di blocco, l’apertura di inchieste formali mirate, richiedendo modifiche strutturali agli algoritmi e collaborando con il Comitato Europeo per la Protezione dei Dati.

—

III. Analisi tecnica e giuridica del machine unlearning

A. Cosa si intende per machine unlearning

Il termine machine unlearning (talvolta tradotto in italiano come “disapprendimento automatico”) indica l’insieme delle tecniche informatiche finalizzate a rimuovere o ridurre significativamente l’influenza di uno specifico sottoinsieme di dati di addestramento su un modello già addestrato, senza dover procedere a un nuovo addestramento completo (retraining from scratch) — operazione che, per i modelli moderni di grandi dimensioni, richiederebbe risorse computazionali e temporali proibitive.

Il problema nasce da una caratteristica fondamentale dell’apprendimento automatico: quando un modello viene addestrato su un dataset, i parametri del modello vengono aggiornati iterativamente in modo da minimizzare una funzione di errore rispetto all’intero dataset. L’informazione contenuta in ciascun dato di addestramento viene, per così dire, “distribuita” su tutti i parametri del modello in forma non lineare e non separabile. Non esiste, nella struttura interna del modello, un “cassetto” in cui sono conservate le informazioni relative a uno specifico individuo: queste sono diffuse, mescolate, trasformate.

Di conseguenza, la semplice cancellazione del dato originario dal dataset non implica la sua rimozione dall’influenza esercitata sul modello. Il modello “ricorda” — in senso tecnico — le caratteristiche statistiche del dato attraverso i suoi pesi, anche dopo che il dato originale è stato eliminato.

B. Le principali tecniche di machine unlearning

La letteratura scientifica ha sviluppato diverse famiglie di approcci al machine unlearning, ciascuna con caratteristiche, vantaggi e limitazioni proprie. Pur senza pretesa di esaustività tecnica, è utile illustrarne le principali per comprendere le implicazioni giuridiche.

Il primo e più robusto approccio è il retraining esatto (exact unlearning): il modello viene semplicemente riaddestrato da zero escludendo i dati da rimuovere. Questo approccio garantisce la rimozione completa dell’influenza del dato, ma è computazionalmente insostenibile per i modelli moderni. Un Large Language Model come quelli alla base dei sistemi di IA generativa è costituito da miliardi di parametri e richiede settimane di calcolo distribuito su migliaia di GPU: rifare l’addestramento ogni volta che un interessato esercita il diritto alla cancellazione è, allo stato attuale, praticamente impossibile.

Il secondo approccio è il cosiddetto approximate unlearning o disapprendimento approssimato: invece di rimuovere completamente e matematicamente l’influenza del dato, si applicano tecniche che la riducono a un livello statisticamente trascurabile. Rientrano in questa categoria tecniche come l’influence function unlearning (che misura l’influenza di ciascun dato sul comportamento del modello e la compensa), il gradient ascent (che inverte l’aggiornamento dei parametri effettuato durante il training su quel dato), il fine-tuning selettivo e il knowledge distillation (che riaddestra un modello più piccolo escludendo i dati da dimenticare, e lo usa come riferimento per aggiornare il modello originale).

Una terza famiglia di tecniche è basata sulla partizione dei dati: il dataset di addestramento viene diviso in shards (frammenti), e vengono addestrati modelli separati su ciascun frammento. Quando un dato deve essere rimosso, è sufficiente riaddestrare solo il modello corrispondente al frammento che lo conteneva, aggregando poi i risultati. Questo approccio — noto come SISA (Sharded, Isolated, Sliced, and Aggregated training) — riduce significativamente il costo computazionale del retraining, ma modifica la struttura del processo di addestramento e può influire sulle prestazioni del modello complessivo.

Infine, esistono approcci basati su tecniche di privacy differenziale: addestrare il modello con garanzie di privacy differenziale limita ab initio la quantità di informazione che il modello può “memorizzare” su ciascun singolo dato, rendendo il problema del machine unlearning meno critico — ma al prezzo di una riduzione delle prestazioni del modello stesso.

C. Il problema della “memorizzazione” e della reidentificazione

Un aspetto particolarmente rilevante dal punto di vista giuridico è il fenomeno della memorizzazione (memorization): i modelli di machine learning, soprattutto quelli di grandi dimensioni, tendono in certi casi a “memorizzare” specifici esempi di training in modo quasi letterale, tanto da essere in grado di riprodurli (o di riprodurne porzioni significative) se opportunamente interrogati. Questo fenomeno è stato documentato empiricamente in numerosi studi su LLM e modelli generativi, e costituisce un rischio concreto di violazione del GDPR: il modello diventa, in questi casi, un vettore di diffusione di dati personali.

Dal punto di vista giuridico, un modello che memorizza e può riprodurre dati personali costituisce un archivio di quei dati ai fini del GDPR, anche se i dati originali sono stati cancellati dal dataset. L’articolo 4, numero 6, del GDPR definisce l'”archivio” come “qualsiasi insieme strutturato di dati personali accessibili secondo criteri determinati, indipendentemente dal fatto che tale insieme sia centralizzato, decentralizzato o ripartito in modo funzionale o geografico”. Un modello che memorizza dati potrebbe rientrare in questa definizione, con tutte le conseguenze che ne derivano in termini di applicabilità del GDPR.

La questione è resa ancora più complessa dai fenomeni di membership inference attack e data extraction attack: tecniche di attacco informatico che consentono, rispettivamente, di determinare se un dato specifico era presente nel dataset di addestramento di un modello, e di estrarre dal modello dati di addestramento specifici. L’esistenza di queste tecniche di attacco dimostra che la separazione tra “modello” e “dato originale” non è così netta come si potrebbe pensare, e che il rischio di esposizione di dati personali tramite il modello è reale e documentato.

—

IV. Profili critici: tra obblighi giuridici e limiti tecnici

A. La “completezza” della cancellazione: standard giuridico versus fattibilità tecnica

Il nodo centrale della questione è la definizione dello standard giuridico che deve soddisfare la cancellazione dei dati in un contesto di AI. L’articolo 17 del GDPR parla di cancellazione dei dati personali, ma non specifica cosa debba intendersi per “cancellazione” in relazione a un modello di machine learning. Questa lacuna normativa è, in un certo senso, inevitabile: il GDPR è stato adottato nel 2016, quando i modelli di linguaggio di grandi dimensioni erano ancora un fenomeno marginale, e il legislatore europeo non poteva anticiparne le implicazioni.

Alla data di redazione del presente contributo l’EDPB non ha adottato linee guida specifiche sul machine unlearning, ma l’orientamento generale delle autorità di controllo — incluso il Garante italiano — sembra muoversi nella direzione di richiedere non una rimozione matematicamente perfetta, ma una riduzione dell’influenza del dato a un livello statisticamente non distinguibile dalla sua assenza. Questo approccio pragmatico è giustificato dalla considerazione che anche i sistemi “tradizionali” di cancellazione dei dati raramente garantiscono una rimozione assoluta (si pensi alla possibilità di recuperare dati da supporti di archiviazione mediante tecniche forensi), e che il diritto europeo ha sempre adottato un approccio di proporzionalità.

Tuttavia, questo orientamento pragmatico pone a sua volta una serie di questioni. Chi certifica che il livello di “dimenticanza” raggiunto è sufficiente? Con quale metodo viene misurata l’influenza residua del dato sul modello? Come si documenta l’operazione di unlearning in modo che possa essere verificata dall’autorità di controllo? Queste domande restano, allo stato attuale, senza risposta definitiva.

B. Il problema della proporzionalità e del conflitto tra diritti

Il diritto alla cancellazione non è assoluto: l’articolo 17, paragrafo 3, del GDPR prevede eccezioni quando il trattamento è necessario, tra l’altro, per l’adempimento di un obbligo legale, per l’esecuzione di un compito di interesse pubblico, o per la difesa di un diritto in sede giudiziaria. Anche al di fuori delle eccezioni espressamente previste, la Corte di Giustizia dell’Unione Europea ha ripetutamente affermato — a partire dalla storica sentenza Google Spain del 13 maggio 2014 (causa C-131/12) — che il diritto alla cancellazione deve essere bilanciato con altri diritti e interessi legittimi, inclusa la libertà di informazione e il diritto alla conoscenza.

Nel contesto dei sistemi AI, questo bilanciamento è particolarmente delicato. Un modello linguistico addestrato su dati storici, ad esempio, potrebbe aver appreso informazioni accurate su eventi di dominio pubblico che coinvolgono persone fisiche identificabili. Cancellare l’influenza di quei dati potrebbe ridurre la qualità e l’accuratezza del modello. C’è un interesse legittimo del fornitore del modello — e della società nel suo complesso — alla conservazione di un sistema di alta qualità che si scontra con il diritto dell’interessato alla cancellazione?

Su quest’ultimo terreno si sviluppa il principale nodo del tema di indagine del presente contributo, e non ha ancora trovato una soluzione normativa soddisfacente. L’AI Act, pur introducendo obblighi stringenti per i sistemi ad alto rischio, non risolve esplicitamente il conflitto tra il diritto alla cancellazione e l’integrità del modello AI. È probabile che la questione dovrà essere affrontata caso per caso dalle autorità di controllo e, in ultima istanza, dalla Corte di Giustizia.

C. La questione della “anonimizzazione” dei modelli AI

Un approccio alternativo al machine unlearning che viene talvolta proposto dai fornitori di sistemi AI è quello dell’anonimizzazione: invece di rimuovere l’influenza del dato specifico, si sostiene che il modello, nel suo complesso, non contenga dati personali, poiché ha trasformato l’informazione originaria in rappresentazioni statistiche non riconducibili a individui specifici.

Questo argomento è, nella maggior parte dei casi, giuridicamente debole. Il Considerando 26 del GDPR stabilisce che per determinare se una persona è identificabile occorre tenere conto di tutti i mezzi che il titolare del trattamento o chiunque altro ragionevolmente potrebbe utilizzare — incluse le tecniche di attacco sopra menzionate (membership inference, data extraction). Se esistono tecniche che consentono di estrarre informazioni personali da un modello, la semplice affermazione che il modello è “anonimizzato” non regge alla verifica del test di identificabilità.

Il Gruppo di lavoro Articolo 29 ha chiarito, nel Parere 05/2014 sulle tecniche di anonimizzazione, che l’anonimizzazione è un processo irreversibile che deve resistere a qualsiasi ragionevole tentativo di reidentificazione. Applicato ai modelli AI, questo standard è estremamente difficile da soddisfare in modo verificabile, e certamente non è soddisfatto dai soli modelli addestrati senza specifiche misure di privacy differenziale.

D. La responsabilità nella catena del trattamento: titolare, responsabile e sub-responsabile

Un ulteriore profilo critico riguarda la distribuzione delle responsabilità nella filiera del trattamento. I sistemi AI vengono sempre più spesso sviluppati da soggetti terzi e poi utilizzati da aziende di varie dimensioni che li integrano nei propri processi. In questo schema, il fornitore del modello (ad esempio, un’azienda che offre un LLM tramite API) è tipicamente il responsabile del trattamento ai sensi dell’articolo 28 del GDPR rispetto all’azienda cliente che è il titolare del trattamento.

Se il titolare del trattamento riceve una richiesta di cancellazione da un interessato i cui dati sono stati utilizzati per addestrare il modello base, è in grado di soddisfarla? Dipende interamente dalla capacità tecnica del responsabile del trattamento — il fornitore del modello — di implementare tecniche di machine unlearning. L’articolo 28, paragrafo 3, lettera g), del GDPR impone al responsabile del trattamento di “cancellare o restituire al titolare del trattamento tutti i dati personali dopo che è terminata la prestazione dei servizi relativi al trattamento”. Questa disposizione, interpretata alla luce dell’articolo 17, implica che il contratto tra titolare e responsabile del trattamento debba includere clausole specifiche sulla gestione delle richieste di cancellazione anche con riferimento ai modelli AI addestrati su dati personali.

—

V. Implicazioni operative per DPO e imprese

A. La Data Protection Impact Assessment (DPIA) come strumento anticipatorio

Il primo strumento operativo che il DPO e il titolare del trattamento devono attivare quando intendono sviluppare o adottare un sistema AI addestrato su dati personali è la Valutazione d’Impatto sulla Protezione dei Dati (DPIA), prescritta dall’articolo 35 del GDPR. La DPIA è obbligatoria quando il trattamento può presentare un rischio elevato per i diritti e le libertà delle persone fisiche — il che è tipicamente il caso dei sistemi AI — e deve includere una valutazione dei rischi specifici derivanti dal trattamento, nonché delle misure previste per affrontarli.

Nel contesto del machine unlearning, la DPIA deve affrontare esplicitamente le seguenti questioni: la fattibilità tecnica della cancellazione dei dati dal modello già addestrato; le procedure predisposte per gestire le richieste di cancellazione degli interessati; le misure tecniche adottate per ridurre il rischio di memorizzazione e di estrazione di dati personali dal modello; il bilanciamento tra il diritto alla cancellazione e gli altri interessi in gioco.

Il Garante per la protezione dei dati personali ha pubblicato un elenco delle tipologie di trattamenti soggetti all’obbligo di DPIA, tra cui rientrano “trattamenti che comportano l’utilizzo di tecnologie innovative” che “possono presentare rischi elevati” per i diritti degli interessati. I sistemi AI addestrati su dati personali rientrano tipicamente in questa categoria, e la DPIA deve essere completata prima dell’avvio del trattamento.

B. La predisposizione di procedure di gestione delle richieste di cancellazione

Un secondo profilo operativo riguarda la predisposizione di procedure formali per la gestione delle richieste di esercizio dei diritti, con specifico riferimento alla cancellazione nel contesto AI. Il DPO deve assicurarsi che l’organizzazione disponga di procedure che coprano non solo la cancellazione dei dati dal dataset originario, ma anche l’attivazione delle tecniche di machine unlearning appropriate.

Queste procedure dovrebbero includere: l’identificazione dei soggetti responsabili dell’esecuzione delle operazioni di unlearning; la documentazione tecnica del processo (quale tecnica viene utilizzata, con quale frequenza viene eseguita, come viene verificata l’efficacia); la comunicazione all’interessato dell’avvenuta cancellazione entro il termine di un mese previsto dall’articolo 12, paragrafo 3, del GDPR (prorogabile di ulteriori due mesi in casi di complessità); e la tenuta di un registro delle operazioni di unlearning effettuate.

Quest’ultimo punto è particolarmente rilevante. Il principio di accountability sancito dall’articolo 5, paragrafo 2, del GDPR impone al titolare del trattamento di essere in grado di dimostrare il rispetto dei principi del Regolamento. In assenza di documentazione specifica sulle operazioni di machine unlearning effettuate, il titolare non sarà in grado di soddisfare questo onere probatorio in caso di ispezione dell’autorità di controllo o di contenzioso con l’interessato.

C. La contrattualizzazione con i fornitori di sistemi AI

Come già accennato nel paragrafo precedente, un nodo critico riguarda i rapporti contrattuali con i fornitori di sistemi AI. Il DPO deve assicurarsi che il Data Processing Agreement (DPA) concluso ai sensi dell’articolo 28 del GDPR con il fornitore del sistema AI contenga clausole specifiche che disciplinino:

In primo luogo, l’obbligo del fornitore di implementare tecniche di machine unlearning quando riceva dal titolare una richiesta di cancellazione relativa a dati utilizzati per l’addestramento del modello. In secondo luogo, i tempi entro cui il fornitore deve eseguire l’operazione di unlearning, compatibili con i termini previsti dall’articolo 12 del GDPR. In terzo luogo, la documentazione che il fornitore deve fornire al titolare a prova dell’avvenuta cancellazione. In quarto luogo, le misure tecniche adottate dal fornitore per prevenire la memorizzazione di dati personali nel modello ab initio (ad esempio, l’adozione di tecniche di privacy differenziale durante il training). In quinto luogo, il diritto del titolare — o di un revisore da esso incaricato — di verificare l’efficacia delle misure adottate.

Nella pratica, molti fornitori di sistemi AI di grandi dimensioni non sono attualmente in grado di offrire garanzie contrattuali specifiche sul machine unlearning, il che pone il titolare del trattamento in una posizione di difficoltà. In questi casi, il DPO dovrebbe valutare se è possibile limitare ab initio la quantità di dati personali utilizzati per l’addestramento del modello — applicando il principio di minimizzazione dei dati — o se è preferibile non utilizzare quel sistema per trattamenti che coinvolgono dati personali.

D. L’AI Act e i nuovi obblighi per i fornitori: opportunità di compliance integrata

L’AI Act offre, paradossalmente, un’opportunità di compliance integrata che i DPO dovrebbero saper cogliere. I fornitori di sistemi AI ad alto rischio sono tenuti, ai sensi dell’articolo 9 dell’AI Act, a implementare un sistema di gestione dei rischi che comprenda procedure di monitoraggio e aggiornamento continuo. I fornitori di modelli GPAI con rischio sistemico devono, ai sensi dell’articolo 55, valutare e attenuare i rischi sistemici del modello e garantire un livello adeguato di protezione della cibersicurezza.

Queste disposizioni dell’AI Act si sovrappongono agli obblighi già derivanti dal GDPR e creano uno spazio in cui il DPO e il responsabile della compliance AI possono lavorare congiuntamente per sviluppare soluzioni integrate. La documentazione tecnica richiesta dall’AI Act — che include la descrizione del dataset di addestramento, delle procedure di governance dei dati e delle misure di sicurezza — può essere opportunamente arricchita con le informazioni relative alle tecniche di machine unlearning adottate, creando un corpus documentale che soddisfa simultaneamente i requisiti di entrambi i Regolamenti.

E. Aspetti legati alla sicurezza informatica e alla NIS2

Un profilo operativo che merita menzione, pur nella sua specificità, riguarda il rapporto tra machine unlearning e cybersecurity. La Direttiva (UE) 2022/2555 (NIS2), recepita in Italia con il Decreto Legislativo 4 settembre 2024, n. 138, impone ai soggetti essenziali e importanti l’adozione di misure di gestione dei rischi di sicurezza informatica che includano la gestione degli incidenti, la sicurezza della catena di approvvigionamento e la sicurezza nello sviluppo e nella manutenzione dei sistemi informativi.

I sistemi AI che “memorizzano” dati personali sono potenzialmente vulnerabili agli attacchi di data extraction sopra descritti, che costituiscono una tipologia di violazione dei dati personali ai sensi dell’articolo 33 del GDPR e, a seconda della gravità, un incidente di sicurezza rilevante ai sensi della NIS2. Il DPO deve coordinarsi con il CISO e con il team di sicurezza informatica per assicurarsi che le misure di sicurezza dei sistemi AI includano specifiche contromisure contro gli attacchi di membership inference e data extraction, e che le procedure di machine unlearning siano integrate nel piano di risposta agli incidenti.

F. La formazione e la sensibilizzazione del personale

Un ultimo aspetto operativo, spesso trascurato, riguarda la formazione del personale. L’articolo 29 del GDPR impone che le persone autorizzate al trattamento dei dati personali lo effettuino solo su istruzione del titolare, il che presuppone una conoscenza adeguata delle modalità con cui i sistemi AI trattano i dati personali. I team di data science e di machine learning che sviluppano o gestiscono sistemi AI addestrati su dati personali devono essere formati non solo sugli aspetti tecnici del machine unlearning, ma anche sulle implicazioni giuridiche del loro operato, in modo da potere integrare considerazioni di privacy by design nelle scelte tecniche fin dalla fase di progettazione.

Il DPO dovrebbe promuovere l’adozione di un programma di formazione specifico per questi team, che copra almeno i seguenti temi: i principi del GDPR applicabili ai sistemi AI; le tecniche di machine unlearning disponibili e le loro limitazioni; le procedure aziendali per la gestione delle richieste di cancellazione; i rischi di sicurezza specifici dei sistemi AI e le relative contromisure.

—

VI. Conclusioni

Il machine unlearning si trova oggi in una posizione peculiare: è un obbligo giuridico implicito — derivante dall’articolo 17 del GDPR e dal principio di privacy by design dell’articolo 25 — ma la sua attuazione pratica è ancora un problema tecnico aperto, per il quale non esistono soluzioni universalmente efficaci e computazionalmente sostenibili per i modelli di maggiori dimensioni.

Questa tensione tra diritto e tecnica non è nuova nella storia della protezione dei dati, ma nel contesto dell’intelligenza artificiale assume una peculiare acutezza per almeno tre ragioni. In primo luogo, per la scala: i sistemi AI vengono addestrati su volumi di dati senza precedenti, che coinvolgono potenzialmente miliardi di persone. In secondo luogo, per l’opacità: la struttura interna dei modelli è difficilmente interpretabile anche per gli esperti, rendendo ardua la verifica dell’efficacia delle operazioni di unlearning. Infine, per la velocità di evoluzione: le tecnologie AI evolvono più rapidamente dei tempi di adeguamento normativo e giurisprudenziale.

Le prospettive evolutive si articolano su più fronti. Sul piano normativo, è probabile che l’EDPB adotti nel prossimo futuro linee guida specifiche sul machine unlearning, che definiscano lo standard minimo di cancellazione richiesto in diversi contesti e per diversi tipi di modelli. Il comitato europeo per l’intelligenza artificiale, insieme all’Ufficio europeo per l’intelligenza artificiale istituito presso la Commissione, potrebbe contribuire a definire standard tecnici condivisi per la misurazione dell’efficacia delle operazioni di unlearning. Sul piano tecnico, la ricerca sul machine unlearning è in rapida evoluzione: nuove tecniche più efficienti e verificabili vengono proposte continuamente, e nel giro di pochi anni è plausibile che esistano soluzioni commercialmente praticabili anche per i modelli di maggiori dimensioni.

Sul piano giurisprudenziale, i prossimi anni vedranno probabilmente le prime decisioni significative delle autorità di controllo e dei tribunali nazionali ed europei sul diritto alla cancellazione in relazione ai sistemi AI. Il caso ChatGPT aperto dal Garante italiano, che per la prima volta ha messo sotto esame un LLM di scala globale rispetto agli obblighi del GDPR, potrebbe diventare un caso paradigmatico: l’annullamento da parte del Tribunale di Roma della sanzione originariamente inflitta dal Garante a OPEN AI per difetto di competenza e la rimessione della vicenda al Garante Irlandese apre uno scenario ancora incerto che dovrà vedere, prima o poi, un pronunciamento sul merito di una questione delicatissima.

Le questioni che restano aperte sono numerose e di non facile risoluzione. Come si determina il confine tra “dati personali incorporati nel modello” e “conoscenza anonimizzata”? Qual è lo standard di prova sufficiente per dimostrare l’efficacia di un’operazione di unlearning? Come si bilancia il diritto alla cancellazione con la libertà di ricerca scientifica e con l’interesse pubblico alla disponibilità di sistemi AI di alta qualità? Chi certifica la conformità delle operazioni di unlearning, e con quale metodo?

Per il DPO e il giurista d’impresa, la risposta pratica a queste incertezze non può che essere la prudenza proattiva: progettare i sistemi AI con la cancellazione in mente fin dall’inizio, minimizzare l’uso di dati personali nell’addestramento, contrattualizzare con precisione i rapporti con i fornitori, documentare ogni operazione con il massimo rigore, e monitorare l’evoluzione normativa e giurisprudenziale con attenzione costante.

Il diritto all’oblio ha attraversato la storia della protezione dei dati personali come un principio progressivamente affermato contro le resistenze della tecnologia: dalla difficoltà di cancellare dati dagli archivi cartacei alle complessità dei sistemi informativi distribuiti, fino al caso Google Spain. Il machine unlearning ne rappresenta l’applicazione più recente.

—

L'articolo Machine Unlearning e GDPR: il diritto all’oblio nell’era dell’IA proviene da 01magazine.

L’11 agosto 2026 l’Agenzia per la Cybersicurezza Nazionale (di seguito “ACN” o “l’Agenzia”) ha pubblicato sul proprio portale istituzionale una nuova sezione delle Frequently Asked Questions dedicata alla disciplina NIS2, identificata con il prefisso “MVE” (Monitoraggio, Vigilanza, Esecuzione). Le cinque FAQ — numerate da MVE.1 a MVE.5 — costituiscono un documento di soft law che, pur privo di natura vincolante in senso tecnico, riveste un ruolo interpretativo rilevante: esse provengono dall’Autorità nazionale competente NIS ai sensi del decreto legislativo 4 settembre 2024, n. 138, di recepimento della direttiva (UE) 2022/2555 (NIS2), e chiariscono modalità, principi e ambiti dell’azione di supervisione nei confronti dei soggetti essenziali, dei soggetti importanti e delle pubbliche amministrazioni rientranti nel perimetro di applicazione.

Le norme direttamente coinvolte sono, sul piano europeo, gli articoli da 31 a 37 della direttiva NIS2 — dedicati rispettivamente alla supervisione e all’esecuzione nei confronti dei soggetti essenziali e importanti — nonché, sul piano nazionale, il decreto legislativo n. 138/2024 nelle sue disposizioni relative alla vigilanza (Capo IV) e al regime sanzionatorio (Capo V). Il documento si inserisce in una fase cruciale: la maggior parte dei soggetti inclusi nei registri nazionali ha completato o sta completando la fase di registrazione, e il baricentro del sistema NIS2 si sposta progressivamente dall’adempimento formale alla verifica sostanziale della conformità.

Per il professionista della compliance — DPO, CISO, responsabile legale o consulente di data protection e cybersicurezza — comprendere la struttura dell’azione amministrativa di ACN non è un mero esercizio accademico ma il presupposto per impostare correttamente un programma di gestione del rischio regolatorio che tenga conto non solo degli obblighi tecnico-organizzativi, ma anche della probabilità e delle modalità con cui l’Autorità esercita i propri poteri.

—

Il quadro normativo di riferimento

La direttiva NIS2 e il modello europeo di supervisione

La direttiva (UE) 2022/2555, pubblicata nella Gazzetta Ufficiale dell’Unione Europea il 27 dicembre 2022 ed entrata in vigore il 16 gennaio 2023, ha ridisegnato in modo sostanziale il regime di cybersicurezza applicabile ai soggetti operanti in settori critici. Rispetto alla direttiva NIS1 (direttiva (UE) 2016/1148), il legislatore europeo ha operato scelte di campo nette: ampliamento del perimetro soggettivo con il meccanismo della soglia dimensionale (principio “size-cap rule”), bipartizione dei soggetti tra “essenziali” e “importanti”, potenziamento dei poteri di supervisione delle Autorità nazionali competenti e introduzione di un regime sanzionatorio minimo armonizzato.

Il Capo VII della direttiva — articoli da 31 a 37 — disciplina in dettaglio le misure di supervisione e di esecuzione. L’articolo 31 stabilisce il principio fondamentale: gli Stati membri assicurano che le Autorità competenti dispongano dei poteri necessari per vigilare sull’attuazione degli obblighi da parte dei soggetti essenziali e importanti. La norma prevede, in modo significativo, una distinzione tra supervisione ex ante e supervisione ex post: la prima è riservata ai soggetti essenziali, la seconda costituisce la modalità ordinaria nei confronti dei soggetti importanti.

L’articolo 32 della direttiva regola le misure di supervisione applicabili ai soggetti essenziali, prevedendo un catalogo esteso che comprende ispezioni in loco, audit di sicurezza, richieste di informazioni, accesso a dati e documenti, verifiche specifiche. L’articolo 33 disciplina le misure di supervisione applicabili ai soggetti importanti, con un perimetro più limitato — essenzialmente reattivo — che esclude le verifiche ex ante sistematiche. L’articolo 34 fissa, per le violazioni degli obblighi di cui agli articoli 21 e 23, i massimali sanzionatori minimi: almeno dieci milioni di euro o il due per cento del fatturato mondiale annuo totale, se superiore, per i soggetti essenziali; almeno sette milioni di euro o l’uno virgola quattro per cento del fatturato mondiale annuo totale, se superiore, per i soggetti importanti.

Il considerando 122 della direttiva chiarisce la ratio della differenziazione: i soggetti essenziali operano in settori di maggiore criticità per l’economia e la società, e giustificano pertanto un livello di supervisione più intenso e continuo. Tale distinzione non è meramente quantitativa — non si riduce ai massimali sanzionatori — ma è qualitativa, incidendo sulle modalità stesse con cui l’Autorità può esercitare i propri poteri.

Il decreto legislativo n. 138/2024 e il ruolo di ACN

Il recepimento della direttiva NIS2 nell’ordinamento italiano è avvenuto con il decreto legislativo 4 settembre 2024, n. 138, pubblicato nella Gazzetta Ufficiale n. 230 del 1° ottobre 2024. Il decreto ha attribuito ad ACN il ruolo di Autorità nazionale competente NIS unica, concentrando in capo a essa i poteri di supervisione e di esecuzione che la direttiva distribuisce — nelle sue previsioni — tra Autorità competenti e CSIRT nazionale. In Italia, ACN svolge entrambe le funzioni.

Il Capo V del decreto legislativo n. 138/2024 disciplina le attività di supervisione e vigilanza, riprendendo fedelmente la struttura binaria della direttiva ma adattandola al contesto nazionale. Il Capo V introduce il regime sanzionatorio, con la previsione — in conformità all’articolo 34 della direttiva — di massimali differenziati per soggetti essenziali, soggetti importanti e pubbliche amministrazioni. Quest’ultima categoria costituisce una specificità del recepimento italiano, che ha scelto di mantenere le PA all’interno del perimetro NIS2 — con obblighi e sanzioni proprie — piuttosto che escluderle o assoggettarle integralmente al regime ordinario.

Va detto che il decreto legislativo n. 138/2024 ha delegato ad ACN la definizione di numerosi profili attuativi attraverso atti di natura regolamentare e linee guida. Le FAQ MVE si inseriscono in questo spazio normativo come strumento di chiarimento operativo: esse non creano obblighi nuovi né modificano il testo normativo, ma forniscono l’orientamento interpretativo dell’Autorità rispetto a profili che il testo di legge lascia indeterminati o che richiedono un’applicazione contestualizzata.

Il rapporto con il GDPR e la disciplina della protezione dei dati

Il perimetro della NIS2 e quello del GDPR si sovrappongono in modo significativo per la maggior parte dei soggetti obbligati. La direttiva stessa — all’articolo 2, paragrafo 12 — chiarisce che le sue disposizioni si applicano “fatte salve” le norme del regolamento (UE) 2016/679. In termini pratici, un incidente di sicurezza che determina una violazione dei dati personali fa scattare simultaneamente gli obblighi di notifica previsti dall’articolo 33 del GDPR (notifica al Garante entro 72 ore) e quelli previsti dalla NIS2 (notifica ad ACN nelle forme e nei termini stabiliti dal decreto n. 138/2024). I due regimi sanzionatori sono distinti e cumulabili.

Per il DPO, questa sovrapposizione ha implicazioni concrete: il sistema di gestione della cybersicurezza richiesto dalla NIS2 deve essere progettato in modo da alimentare anche il registro dei trattamenti, la valutazione d’impatto e la documentazione relativa alle misure tecniche e organizzative ai sensi dell’articolo 32 del GDPR. L’integrazione dei due framework non è un’opzione organizzativa ma una necessità derivante dalla struttura stessa delle due discipline.

—

La struttura dell’azione di vigilanza secondo le FAQ MVE

MVE.1: I quattro pilastri del sistema di supervisione

La FAQ MVE.1 costituisce la chiave di volta dell’intera sezione. Essa definisce la struttura dell’azione di vigilanza ed esecuzione articolandola in quattro ambiti: monitoraggio, analisi e supporto; verifiche e ispezioni; misure di esecuzione; sanzioni amministrative pecuniarie e accessorie. Questa tassonomia non è casuale né meramente descrittiva: essa riflette una concezione della supervisione come processo graduale e progressivo, in cui l’escalation sanzionatoria costituisce l’extrema ratio piuttosto che la risposta immediata a qualsiasi inadempimento.

Il principio di gradualità — che la FAQ MVE.1 connette esplicitamente ai criteri di effettività, proporzionalità e dissuasività — è radicato nell’articolo 34 della direttiva NIS2, che al paragrafo 1 impone agli Stati membri di garantire che le sanzioni siano “effettive, proporzionate e dissuasive”. La FAQ traduce questo trittico in un modello operativo: l’Agenzia non parte dalla sanzione, ma dall’accompagnamento; interviene con misure coercitive solo quando il dialogo e il supporto si rivelano insufficienti.

Appare chiaro allo scrivente che questo approccio riflette una scelta di politica regolatoria ben precisa, condivisa da molte Autorità NIS europee: in una fase di prima applicazione della direttiva, in cui la consapevolezza degli obblighi è ancora disomogenea, un modello prevalentemente sanzionatorio rischierebbe di penalizzare i soggetti in buona fede senza produrre un reale miglioramento della postura di sicurezza del sistema paese. Il riferimento alle “peculiarità di ciascuna fattispecie” segnala peraltro che ACN intende esercitare un significativo margine di discrezionalità nell’applicazione dei propri poteri, con valutazioni caso per caso che tengano conto della dimensione del soggetto, della natura del settore, dell’entità e della reiterazione dell’inadempimento.

MVE.2: Il monitoraggio continuo come architettura di conoscenza

La FAQ MVE.2 descrive il primo pilastro — monitoraggio, analisi e supporto — con caratteri che meritano un’analisi approfondita. Il termine “sistematico e continuativo” non è una clausola di stile: esso implica che l’Agenzia ha costruito o sta costruendo infrastrutture informative permanenti per raccogliere dati sullo stato di attuazione degli obblighi NIS2. La piattaforma di registrazione obbligatoria, i questionari periodici sulle misure di sicurezza e le attività di threat intelligence del CSIRT nazionale concorrono a formare questo sistema di conoscenza.

La tripartizione interna al primo pilastro — monitoraggio, analisi, supporto — merita una lettura funzionale. Con il “monitoraggio” ACN acquisisce dati: dati di registrazione, dati sugli incidenti notificati, dati sui questionari di autovalutazione. Con l'”analisi” trasforma questi dati in conoscenza: identifica tendenze, carenze sistemiche, settori a maggiore rischio di inadempimento. Con il “supporto” trasferisce questa conoscenza ai soggetti obbligati: attraverso raccomandazioni, linee guida, circolari, sessioni di formazione, comunicazioni sul portale ACN. In termini più pragmatici, il supporto svolge una funzione preventiva: riduce l’asimmetria informativa tra regolatore e regolati, favorendo l’adempimento spontaneo e riducendo la necessità di interventi coercitivi.

Per i soggetti NIS, la FAQ MVE.2 ha implicazioni organizzative dirette. Il carattere sistematico e continuativo del monitoraggio significa che ogni interazione con ACN — ogni notifica di incidente, ogni aggiornamento del profilo di registrazione, ogni risposta a un questionario — costituisce un input nel sistema di conoscenza dell’Autorità. Di conseguenza, la qualità, la completezza e la coerenza delle informazioni trasmesse assumono un rilievo che va al di là dell’adempimento formale: esse concorrono a definire il profilo di rischio che ACN associa al singolo soggetto e, in definitiva, l’intensità della supervisione cui il soggetto sarà sottoposto.

MVE.3: La distinzione ex ante/ex post nell’attività ispettiva

La FAQ MVE.3 è probabilmente la più rilevante sotto il profilo tecnico-giuridico. Essa chiarisce che l’attività ispettiva può essere esercitata ex ante soltanto nei confronti dei soggetti essenziali. Questa affermazione riprende e chiarisce la distinzione tra articolo 32 e articolo 33 della direttiva NIS2, che costituisce uno degli elementi di maggiore novità rispetto alla direttiva NIS1.

La supervisione ex ante comporta che l’Autorità può effettuare verifiche, ispezioni e audit indipendentemente da qualsiasi segnale di inadempimento o da qualsiasi incidente notificato. Si tratta di un potere di accertamento preventivo — e in questo senso strutturalmente invasivo — che giustifica la sua limitazione ai soli soggetti essenziali: si pensi agli operatori di infrastrutture critiche nel settore energetico, dei trasporti, del settore bancario, delle infrastrutture dei mercati finanziari, del settore sanitario, dell’acqua potabile, delle acque reflue, dell’infrastruttura digitale, della gestione dei servizi ICT. Per questi soggetti, un inadempimento rilevato solo ex post potrebbe avere conseguenze sistemiche irreversibili.

La supervisione ex post, che costituisce la modalità ordinaria per i soggetti importanti, non significa assenza di vigilanza. Essa significa che l’Agenzia interviene con verifiche e ispezioni in presenza di elementi che le fanno ritenere necessario un accertamento: una notifica di incidente, una segnalazione di terzi, le risultanze del monitoraggio continuativo, informazioni acquisite da autorità di altri Stati membri nell’ambito del quadro di cooperazione NIS2. In sostanza, il trigger dell’attività ispettiva sui soggetti importanti è un elemento di allerta, non la mera appartenenza alla categoria.

Per i soggetti importanti, questo regime ha implicazioni strategiche. La probabilità di essere oggetto di un’ispezione è correlata alla visibilità del soggetto nel sistema di monitoraggio di ACN: un soggetto che notifica prontamente gli incidenti, risponde tempestivamente ai questionari e partecipa attivamente alle iniziative di supporto dell’Agenzia costruisce un profilo di collaborazione che, pur non escludendo ispezioni, le rende meno probabili in assenza di segnali specifici di criticità. Al contrario, un soggetto che presenta ripetuti ritardi nelle notifiche, omissioni nei questionari o incoerenze nei dati trasmessi accresce la probabilità di un intervento ispettivo.

MVE.4: Le misure di esecuzione come strumento di conformità guidata

La FAQ MVE.4 descrive il terzo pilastro del sistema: le misure di esecuzione. Esse si distinguono concettualmente dalle sanzioni — che costituiscono il quarto e ultimo pilastro — perché la loro finalità non è punitiva ma conformativa. Attraverso intimazioni e diffide, ACN richiede al soggetto inadempiente di: conformare la propria condotta agli obblighi; rimediare alle carenze accertate; far cessare le condotte assunte in violazione.

Questa tripartizione funzionale corrisponde a tre diverse tipologie di inadempimento. La “conformazione della condotta” si riferisce a situazioni in cui il soggetto non ha ancora adottato le misure richieste: si tratta di un ordine di fare. Il “rimedio alle carenze accertate” si riferisce a situazioni in cui il soggetto ha adottato misure insufficienti o inadeguate: si tratta di un ordine di fare meglio. La “cessazione delle condotte in violazione” si riferisce a situazioni in cui il soggetto sta attivamente ponendo in essere comportamenti contrari agli obblighi: si tratta di un ordine di cessare.

In termini di logica procedurale, le misure di esecuzione costituiscono l’ultimo stadio prima della sanzione. Esse presuppongono che l’Agenzia abbia già acquisito elementi sufficienti — attraverso il monitoraggio, l’analisi e/o l’attività ispettiva — per ritenere sussistente un inadempimento, e che il supporto offerto non sia stato sufficiente a determinare la conformità spontanea. La progressione monitoraggio → ispezione → misura di esecuzione → sanzione è la sequenza tipica del procedimento di vigilanza NIS2, anche se la FAQ MVE.1 precisa che l’approccio è “basato sul rischio” e che l’Agenzia tiene conto delle peculiarità di ciascuna fattispecie: nulla esclude, in presenza di violazioni gravi, un’accelerazione della sequenza.

Il termine “intimazione” richiama un istituto tipico del diritto amministrativo italiano, con carattere ordinatorio e termine per adempiere. La “diffida” ha invece un valore aggiuntivo di messa in mora formale, che costituisce di regola il presupposto per l’applicazione delle sanzioni successive. La distinzione tra i due strumenti, che la FAQ MVE.4 non esplicita ulteriormente, è destinata a essere chiarita dalla prassi applicativa dell’Agenzia e, eventualmente, dalla giurisprudenza amministrativa.

MVE.5: Il regime sanzionatorio differenziato

La FAQ MVE.5 affronta il tema sanzionatorio, chiarendo che l’entità delle sanzioni pecuniarie e l’ambito delle misure accessorie variano a seconda che il soggetto sia essenziale, importante o una pubblica amministrazione. Questa tripartizione — che riprende la distinzione già operata dalla direttiva NIS2, integrando la categoria delle pubbliche amministrazioni come terza fattispecie autonoma — è il cuore del regime sanzionatorio NIS2 italiano.

Il decreto legislativo n. 138/2024 ha recepito i massimali previsti dall’articolo 34 della direttiva con una modulazione specifica per il contesto nazionale. Per i soggetti essenziali, le sanzioni amministrative pecuniarie per le violazioni degli obblighi in materia di misure di gestione dei rischi e di notifica degli incidenti possono raggiungere il massimale europeo minimo di dieci milioni di euro o il due per cento del fatturato mondiale annuo totale, se superiore. Per i soggetti importanti, per le medesime violazioni, il massimale è fissato in sette milioni di euro o all’uno virgola quattro per cento del fatturato mondiale annuo totale, se superiore. Per le pubbliche amministrazioni, il regime sanzionatorio presenta caratteristiche proprie che tengono conto della specificità del settore pubblico: in particolare, l’inapplicabilità del criterio del fatturato — che non ha significato per gli enti non commerciali — comporta l’adozione di massimali assoluti.

Le misure accessorie previste dalla direttiva — e recepite nel decreto n. 138/2024 — comprendono, tra l’altro, l’obbligo di comunicazione pubblica dell’inadempimento accertato e, nei casi più gravi riguardanti i soggetti essenziali, la possibilità di sospensione temporanea dei servizi o di interdizione temporanea degli organi direttivi responsabili dalle funzioni manageriali. Quest’ultima misura — prevista dall’articolo 32, paragrafo 5, della direttiva — costituisce una novità di grande impatto rispetto alla disciplina NIS1 e avvicina il regime NIS2 a quello dei settori finanziario e bancario, dove la responsabilità personale dei vertici è tradizionalmente più accentuata.

Si ritiene che la distinzione tra i regimi applicabili ai tre tipi di soggetti — essenziali, importanti e PA — non si esaurisca nel differenziale quantitativo delle sanzioni pecuniarie. Essa riflette una differente valutazione del rischio sistemico: i soggetti essenziali, operando in settori ad alta criticità, sono esposti a un regime di supervisione più intensa e a sanzioni più severe perché un loro inadempimento è suscettibile di produrre effetti a cascata sull’intera economia e società. Le pubbliche amministrazioni, d’altro canto, presentano specificità — assenza di fine di lucro, vincoli di bilancio pubblico, regime di responsabilità degli agenti pubblici — che richiedono adattamenti del regime ordinario.

—

Profili critici e questioni aperte

La natura giuridica delle FAQ e il principio del legittimo affidamento

Il primo profilo critico riguarda la natura giuridica delle FAQ MVE. Trattandosi di documenti di soft law — privi di forza normativa in senso tecnico — esse non possono derogare né integrare le disposizioni del decreto legislativo n. 138/2024, né introdurre obblighi non previsti dalla legge. Tuttavia, la loro provenienza dall’Autorità competente NIS le investe di un’autorevolezza interpretativa che ne condiziona l’applicazione pratica.

Il principio del legittimo affidamento — riconosciuto dall’articolo 1, comma 2-bis, della legge n. 241/1990, oltre che dalla giurisprudenza amministrativa consolidata — impone che il soggetto il quale abbia orientato la propria condotta conformemente alle indicazioni delle FAQ non possa essere sanzionato sulla base di un’interpretazione successivamente diversa adottata dall’Autorità. Questo principio, che opera in senso protettivo nei confronti del regolato, dovrebbe indurre ACN a un aggiornamento frequente e tempestivo delle FAQ qualora l’orientamento interpretativo dovesse evolvere.

Va detto, peraltro, che il carattere necessariamente generico delle FAQ — che descrivono la struttura del sistema senza entrare nei dettagli procedurali di ciascun tipo di procedimento — lascia margini di indeterminatezza significativi. La FAQ MVE.4, ad esempio, non precisa i termini procedurali delle intimazioni e delle diffide, né le garanzie del contraddittorio nei confronti del soggetto destinatario. Non si ha evidenza, alla data di pubblicazione delle FAQ, di un regolamento procedimentale che disciplini in dettaglio il procedimento di vigilanza ed esecuzione NIS2: colmare questa lacuna appare una priorità per garantire la prevedibilità dell’azione amministrativa e la tutela effettiva dei soggetti obbligati.

La gradualità come discrezionalità: vantaggi e rischi

Il modello basato sul rischio e sulla gradualità — che le FAQ MVE.1 e MVE.2 descrivono come il paradigma dell’azione di ACN — presenta vantaggi evidenti in termini di efficienza regolatoria. Concentrare le risorse ispettive sui soggetti a maggiore rischio e nei settori a maggiore criticità è razionale e proporzionato. Tuttavia, il rovescio della medaglia è una potenziale asimmetria applicativa: soggetti con profili di inadempimento comparabili potrebbero ricevere trattamenti differenti in funzione della loro visibilità nel sistema di monitoraggio, delle loro dimensioni o del settore di appartenenza.

Secondo il parere di chi scrive, la questione della parità di trattamento tra soggetti NIS è destinata a diventare uno dei temi più delicati della fase applicativa. Un regime sanzionatorio che lascia ampia discrezionalità all’Autorità richiede che essa si doti di criteri trasparenti per l’esercizio di tale discrezionalità: la pubblicazione di linee guida sul procedimento sanzionatorio — analoghe a quelle adottate dal Garante per la protezione dei dati personali in materia GDPR — appare auspicabile, anche alla luce del principio di prevedibilità dell’azione amministrativa sancito dall’articolo 97 della Costituzione.

L’interazione con la responsabilità degli organi direttivi

La FAQ MVE.5, nel menzionare le misure accessorie, tocca implicitamente un tema di grande rilevanza per la governance d’impresa: la responsabilità personale dei componenti degli organi direttivi. La direttiva NIS2 — all’articolo 20 — prevede obblighi espliciti a carico degli organi di gestione in materia di approvazione e supervisione delle misure di gestione del rischio di cybersicurezza. L’articolo 20, paragrafo 1, stabilisce che “gli Stati membri assicurano che gli organi di gestione dei soggetti essenziali e importanti approvino le misure di gestione dei rischi di cybersicurezza adottate da tali soggetti per conformarsi all’articolo 21, sovraintendano alla sua attuazione”.

Il decreto legislativo n. 138/2024 ha recepito questo principio, attribuendo agli organi di gestione una responsabilità non delegabile in materia di cybersicurezza. Le misure accessorie previste per i soggetti essenziali — tra cui la possibile interdizione temporanea degli organi direttivi — rendono questa responsabilità non più teorica. Per le imprese che ricadono nella categoria dei soggetti essenziali, l’adeguatezza del sistema di governance della cybersicurezza — inclusa la formazione degli organi direttivi prevista dall’articolo 20, paragrafo 2, della direttiva — è un presidio tanto organizzativo quanto di tutela della responsabilità personale dei manager.

Il coordinamento con altre autorità di settore

Un profilo critico di carattere sistematico riguarda il coordinamento tra ACN e le altre autorità di vigilanza settoriali. Per i soggetti operanti nel settore finanziario, ad esempio, la supervisione NIS2 si sovrappone alla vigilanza di Banca d’Italia, IVASS o Consob. Per i soggetti operanti nel settore della salute, la supervisione NIS2 interagisce con quella del Ministero della Salute e delle Autorità regionali. Per i soggetti che trattano dati personali — la quasi totalità — il raccordo con il Garante per la protezione dei dati personali è strutturale.

La direttiva NIS2 prevede meccanismi di cooperazione tra le Autorità competenti NIS e le Autorità di supervisione del settore finanziario, e all’articolo 35 stabilisce che le Autorità NIS e le Autorità di protezione dei dati collaborano. Non si ha evidenza, allo stato, di accordi formalizzati tra ACN e le altre Autorità italiane che disciplinino i flussi informativi, la ripartizione delle competenze e la gestione dei casi di sovrapposizione. Si ritiene che la definizione di questi raccordi istituzionali sia una priorità per evitare duplicazioni procedimentali e contraddizioni interpretative a carico dei soggetti obbligati.

—

Adempimenti concreti per DPO, CISO e imprese

La sezione che segue traduce il quadro normativo e le indicazioni delle FAQ MVE in adempimenti operativi concreti. La progressione segue la logica del procedimento di vigilanza — dal monitoraggio alla sanzione — in modo che il professionista possa identificare le azioni preventive da compiere in ciascuna fase.

1. Mappatura della categoria di appartenenza: verificare con precisione se il soggetto rientra nella categoria dei soggetti essenziali, dei soggetti importanti o nella categoria delle pubbliche amministrazioni, anche avvalendosi del portale ACN e della documentazione tecnica disponibile sul sito dell’Agenzia. La categoria determina il regime di supervisione applicabile — ex ante o ex post — e il massimale sanzionatorio di riferimento. La mappatura deve essere documentata e aggiornata in caso di variazioni rilevanti (cambio di fatturato, variazioni organizzative, acquisizioni o cessioni di business).
2. Presidio del monitoraggio continuativo: designare un referente interno — che può coincidere con il CISO, il DPO o una figura dedicata alla compliance NIS2 — responsabile dell’interazione con ACN per le attività di monitoraggio. Questo referente deve garantire la tempestività e la completezza delle risposte ai questionari periodici, la coerenza tra i dati trasmessi in occasioni diverse e la tracciabilità documentale delle informazioni fornite all’Agenzia.
3. Sistema di notifica degli incidenti: implementare o aggiornare le procedure interne per la notifica degli incidenti significativi ad ACN, assicurando l’allineamento con le tempistiche previste dal decreto legislativo n. 138/2024 e con le linee guida operative di ACN disponibili sul portale istituzionale. Verificare il coordinamento con le procedure di notifica delle violazioni dei dati personali al Garante ai sensi dell’articolo 33 del GDPR, evitando duplicazioni e garantendo la coerenza tra le due notifiche quando si riferiscono allo stesso evento.
4. Programma di misure di sicurezza documentate: costruire e mantenere aggiornato un sistema documentale che dimostri l’adozione delle misure di gestione del rischio di cybersicurezza previste dall’articolo 21 della direttiva NIS2 e dalle norme di recepimento. Questo sistema deve includere: politiche di sicurezza approvate dall’organo di gestione, risultanze delle analisi del rischio, evidenze dei test e delle verifiche periodiche, registro delle vulnerabilità identificate e dei remediation plan. La documentazione non è un adempimento fine a se stesso: è la principale evidenza difensiva in caso di ispezione.
5. Formazione degli organi direttivi: organizzare sessioni di formazione specifiche per i componenti del consiglio di amministrazione, del collegio sindacale e degli altri organi di gestione sulla disciplina NIS2, sugli obblighi che essa impone agli organi stessi ai sensi dell’articolo 20 della direttiva e sulle responsabilità che derivano dalla sua violazione. La formazione deve essere documentata — con verbali o attestati — per costituire evidenza dell’adempimento dell’obbligo formativo.
6. Procedura di risposta alle ispezioni: predisporre una procedura interna che disciplini le modalità di risposta in caso di ispezione di ACN, identificando i soggetti autorizzati a interagire con i funzionari ispettivi, le modalità di raccolta e trasmissione dei documenti richiesti, i criteri per la valutazione della rispondenza delle richieste ispettive ai poteri di legge dell’Autorità e i canali di comunicazione con i consulenti legali. Per i soggetti essenziali — esposti alla supervisione ex ante — questa procedura ha carattere di urgenza.
7. Gestione delle misure di esecuzione: in caso di ricezione di un’intimazione o di una diffida da parte di ACN, attivare immediatamente le funzioni legali interne o esterne per la valutazione della legittimità del provvedimento e la definizione della strategia di risposta. Verificare i termini indicati nel provvedimento per l’adempimento e predisporre un piano di conformità documentato che dimostri la buona fede e la collaborazione del soggetto. La risposta tempestiva e documentata all’intimazione è un elemento che — nella logica della gradualità descritta dalle FAQ MVE — può influire significativamente sulla decisione di ACN in ordine all’applicazione delle sanzioni.
8. Audit periodici di conformità NIS2: integrare la NIS2 nel programma annuale di audit interno o commissionare audit specifici a soggetti terzi indipendenti, con frequenza almeno annuale. L’audit deve coprire sia i profili tecnici (misure di sicurezza delle reti e dei sistemi informativi) sia i profili organizzativi e documentali (governance, politiche, procedure, formazione, gestione degli incidenti). I risultati dell’audit — incluse le non conformità identificate e i remediation plan — devono essere portati all’attenzione dell’organo di gestione e conservati come documentazione difensiva.

Conclusioni: le questioni aperte e le prospettive evolutive

Le FAQ MVE pubblicate da ACN l’11 agosto 2026 rappresentano un contributo utile alla chiarezza del sistema NIS2, ma lasciano aperte questioni che l’evoluzione del quadro regolatorio dovrà affrontare.

La prima questione riguarda il procedimento sanzionatorio. Le FAQ descrivono la struttura del sistema ma non ne disciplinano il funzionamento interno: termini procedurali, garanzie del contraddittorio, criteri per la determinazione concreta della sanzione all’interno della forchetta di legge, modalità di pubblicazione degli inadempimenti. L’adozione di un regolamento procedimentale da parte di ACN — o di linee guida specifiche sul procedimento sanzionatorio — appare necessaria per colmare questa lacuna e per garantire la prevedibilità dell’azione amministrativa.

La seconda questione riguarda il coordinamento istituzionale. La sovrapposizione tra il perimetro NIS2 e quello del GDPR, del DORA (per i soggetti del settore finanziario), della CER (direttiva sulle entità critiche) e di altre normative di settore richiede meccanismi formali di raccordo tra ACN e le altre Autorità di supervisione. In assenza di tali meccanismi, il rischio di procedimenti paralleli e contraddittori, con duplicazione degli oneri a carico dei soggetti obbligati, è concreto.

La terza questione riguarda l’evoluzione del regime per le pubbliche amministrazioni. La scelta italiana di mantenere le PA all’interno del perimetro NIS2 con un regime sanzionatorio proprio è coraggiosa ma pone problemi applicativi specifici: come si determina la sanzione pecuniaria in assenza del parametro del fatturato? Come si concilia l’interdizione degli organi direttivi con il regime di responsabilità degli agenti pubblici? Come si gestisce la comunicazione pubblica dell’inadempimento per un ente pubblico senza produrre effetti distorsivi? Queste domande rimangono, allo stato, senza risposta definitiva.

La quarta questione riguarda la maturità del sistema nel suo complesso. Il modello basato sul rischio e sulla gradualità funziona bene quando le capacità di monitoraggio dell’Autorità sono adeguate alla complessità e alla numerosità dei soggetti supervisionati. Il numero di soggetti NIS2 registrati in Italia — che dovrebbe attestarsi su diverse migliaia, tra soggetti essenziali e importanti — è significativo, e la capacità di ACN di esercitare una supervisione effettiva e differenziata su tutti questi soggetti dipenderà in larga misura dalle risorse umane e tecnologiche di cui l’Agenzia potrà disporre. Non si ha evidenza, alla data di pubblicazione del presente articolo, di una valutazione pubblica da parte di ACN della propria capacità di supervisione rispetto alla dimensione del perimetro soggettivo NIS2: tale valutazione sarebbe utile non solo per la pianificazione interna dell’Agenzia, ma anche per consentire ai soggetti obbligati di calibrare le proprie aspettative rispetto all’intensità della supervisione cui saranno concretamente esposti.

Per quanto di stretto interesse in questa sede, si ritiene che le FAQ MVE segnino comunque un passo importante verso la definizione di un sistema di supervisione NIS2 più trasparente e prevedibile. Il fatto che ACN abbia scelto di chiarire la struttura del proprio approccio prima di esercitarlo in modo sistematico — piuttosto che lasciare che emergesse dalla prassi applicativa — è coerente con il principio di leale collaborazione tra regolatore e regolati che dovrebbe caratterizzare la fase di prima applicazione di una disciplina strutturalmente nuova e di grande impatto. Sarà la prassi applicativa dei mesi e degli anni a venire a confermare o a smentire questa impostazione.

L'articolo ACN pubblica le FAQ su monitoraggio, vigilanza ed esecuzione NIS2 proviene da 01magazine.

Con la risoluzione del procedimento sanzionatorio n. PS-00454/2024 — adottata dalla Presidencia de la Agencia Española de Protección de Datos (AEPD) e resa pubblica nel 2025 — l’Autorità garante spagnola ha inflitto a Ares Capital, S.A., società attiva nel settore del trasporto privato con conducente (VTC), una sanzione complessiva di 200.000 euro per la violazione degli articoli 5.1.c), 6.1 e 13 del Regolamento (UE) 2016/679 (GDPR). Il fatto materiale sottostante è, nella sua essenzialità, il seguente: l’azienda imponeva ai propri conducenti di installare sul dispositivo mobile personale quattro applicazioni con perimetri di raccolta dati eccedenti lo stretto necessario per lo svolgimento della prestazione lavorativa, senza che sussistesse una valida base giuridica per il trattamento né un’informativa adeguata.

Il provvedimento è rilevante per il panorama italiano ed europeo per almeno tre ragioni convergenti. In primo luogo, affronta in modo sistematico il fenomeno “Bring Your Own Device” (BYOD) nell’ambito del rapporto di lavoro dipendente — tema rispetto al quale il Garante per la protezione dei dati personali italiano non ha ancora adottato linee guida specifiche, sebbene abbia trattato profili contigui in sede di intervento su geolocalizzazione e controllo a distanza. In secondo luogo, il caso illustra con precisione come il consenso del lavoratore non possa fungere da base giuridica autonoma in un contesto caratterizzato da squilibrio strutturale di potere. In terzo luogo, la decisione dell’AEPD chiarisce l’interazione tra il principio di minimizzazione dei dati (art. 5.1.c) GDPR), la liceità del trattamento (art. 6.1 GDPR) e gli obblighi di informazione (art. 13 GDPR), offrendo coordinate interpretative che i DPO e i responsabili legali di impresa possono utilmente impiegare nella revisione dei propri programmi di compliance.

Le norme coinvolte — artt. 5.1.c), 6.1, 7, 13 e 83.5 GDPR; artt. 71, 72, 74 e 76 della Ley Orgánica 3/2018 (LOPDGDD); Linee guida EDPB 05/2020 sul consenso — sono tutte di applicazione trasversale, sicché le conclusioni dell’AEPD offrono parametri direttamente spendibili nell’ordinamento italiano.

Il quadro normativo di riferimento

La disciplina europea: principi fondamentali e base giuridica

Il GDPR costruisce il trattamento dei dati personali attorno a un sistema di principi la cui violazione è presidiata dalla sanzione più severa prevista dall’art. 83.5, applicabile — per le violazioni dei principi di trattamento, delle condizioni di liceità e del consenso, dei diritti degli interessati e delle regole sui trasferimenti — fino a 20 milioni di euro o, per le imprese, fino al 4% del fatturato mondiale totale annuo dell’esercizio precedente, se superiore.

Il principio di minimizzazione dei dati, sancito dall’art. 5.1.c) GDPR, impone che i dati personali siano “adeguati, pertinenti e limitati a quanto necessario rispetto alle finalità per le quali sono trattati”. In sostanza, il titolare del trattamento non è legittimato a raccogliere dati perché potrebbe un giorno trovarne utilità, né a tollerare che applicativi di terza parte installati a fini lavorativi acquisiscano permessi di accesso a informazioni che non hanno alcuna connessione funzionale con la prestazione richiesta. In termini più pragmatici, un’applicazione di geolocalizzazione per la gestione delle flotte non ha ragione di accedere a rubrica telefonica, fotocamera, dati di salute o registrazioni audio del dispositivo ospitante.

La liceità del trattamento è regolata dall’art. 6.1 GDPR, che elenca tassativamente le basi giuridiche ammesse. Nel contesto lavorativo, le più frequentemente invocate sono: l’esecuzione del contratto (art. 6.1.b)); l’obbligo legale (art. 6.1.c)); il legittimo interesse (art. 6.1.f)); il consenso (art. 6.1.a)). Il Considerando 43 del GDPR precisa tuttavia che, laddove esista “un evidente squilibrio tra l’interessato e il titolare del trattamento”, il consenso “non dovrebbe costituire un valido presupposto di liceità per il trattamento”. È una previsione che acquista particolare rilievo nel rapporto di lavoro subordinato, dove la posizione di debolezza strutturale del lavoratore rende fisiologicamente dubbio che il consenso possa essere prestato in modo libero.

L’art. 13 GDPR disciplina il diritto all’informazione quando i dati vengono raccolti direttamente dall’interessato. Il titolare è tenuto a fornire, al momento della raccolta, informazioni complete e comprensibili su: identità del titolare; finalità e base giuridica; destinatari; termini di conservazione; diritti dell’interessato; esistenza di processi decisionali automatizzati. L’informativa deve essere — secondo l’art. 12.1 — “concisa, trasparente, intelligibile e facilmente accessibile, con un linguaggio semplice e chiaro”.

Il quadro spagnolo: la LOPDGDD e i diritti digitali dei lavoratori

La Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales (LOPDGDD) costituisce l’attuazione nazionale del GDPR in Spagna. In materia sanzionatoria, gli artt. 71, 72 e 74 classificano le infrazioni: la violazione dell’art. 5.1.c) e dell’art. 6.1 GDPR è qualificata come “muy grave” con prescrizione triennale (art. 72.1 LOPDGDD); la violazione dell’art. 13 GDPR è qualificata come “leve” con prescrizione annuale (art. 74 LOPDGDD), ancorché la sanzione irrogata in concreto — 20.000 euro — rientri nel massimale più elevato dell’art. 83.5 GDPR per il tramite del rinvio della LOPDGDD.

Di rilievo è anche il fatto che la LOPDGDD, all’art. 88, riconosce esplicitamente il diritto alla disconnessione digitale dei lavoratori — tema su cui l’AEPD insiste nel provvedimento, rilevando che Ares Capital non aveva informato i dipendenti sulle concrete modalità di disconnessione dalle applicazioni al termine della giornata lavorativa.

Il quadro italiano: analogie e differenze

L’ordinamento italiano non dispone di una disciplina BYOD organica dedicata al contesto lavorativo. Tuttavia, diversi strumenti normativi si intersecano con il tema. L’art. 4 della Legge 20 maggio 1970, n. 300 (Statuto dei Lavoratori), come modificato dal d.lgs. 14 settembre 2015, n. 151, disciplina i controlli a distanza dei lavoratori tramite strumenti tecnologici, subordinandoli — se tali strumenti consentono il controllo — ad accordo sindacale o autorizzazione dell’Ispettorato del Lavoro, ovvero — se trattasi di strumenti di lavoro — al mero rispetto degli obblighi di informazione. Il confine tra “strumento di lavoro” e “strumento di controllo” è però poroso quando si tratta di applicazioni su dispositivi personali: il Garante italiano ha più volte rilevato che il semplice fatto di installare un’app di geolocalizzazione su uno smartphone non trasforma automaticamente il dispositivo in “strumento di lavoro” immune da controllo.

Il Garante ha adottato provvedimenti rilevanti in materia di geolocalizzazione dei lavoratori e ha dato attuazione nell’ordinamento italiano, attraverso il d.lgs. 30 giugno 2003, n. 196 (Codice Privacy), come novellato dal d.lgs. 10 agosto 2018, n. 101, ai principi del GDPR applicabili anche al contesto lavorativo.

Le Linee guida EDPB 05/2020 sul consenso, adottate il 4 maggio 2020, non hanno natura vincolante, ma costituiscono il riferimento interpretativo comune delle autorità di controllo dell’Unione: il loro contenuto in materia di consenso libero, specifico, informato e inequivoco è parte integrante del corpus interpretativo applicabile tanto in Spagna quanto in Italia.

I fatti accertati e la struttura dell’illecito

Il modello operativo di Ares Capital

Ares Capital, S.A. — società con oltre 5.787 dipendenti e un fatturato 2024 superiore a 256 milioni di euro — gestisce una flotta di veicoli VTC. Il modello operativo prevedeva che i conducenti potessero scegliere tra l’utilizzo di uno smartphone aziendale e l’utilizzo del proprio dispositivo personale, con corresponsione di un rimborso mensile per le spese connesse all'”uso mobile personale”. Nella pratica, tuttavia, la disponibilità dei terminali aziendali era subordinata a “limitaciones presupuestarias y de plantilla”, con la conseguenza che la “scelta” era spesso solo formale: in assenza di un device aziendale, il lavoratore era di fatto obbligato a usare il proprio smartphone.

Su tale dispositivo — aziendale o personale — erano obbligatoriamente installate quattro applicazioni. Secondo quanto emerge dalle schermate acquisite come prove in data 6 agosto 2024: la prima applicazione includeva permessi per raccogliere dati di ubicazione, informazioni sullo stato fisico, dati personali (nome, indirizzo e-mail, ID utente, numero di telefono), contatti, informazioni finanziarie, registrazioni audio, foto e video; la seconda applicazione — funzionale all’apertura e chiusura dei veicoli tramite Bluetooth — richiedeva permessi per raccogliere ubicazione approssimata e precisa, foto e video, informazioni personali.

Il tema della base giuridica e il consenso nel rapporto di lavoro

Ares Capital ha sostenuto che il trattamento trovasse fondamento nell’esecuzione del contratto di lavoro (art. 6.1.b) GDPR) e nel consenso dei lavoratori (art. 6.1.a) GDPR). L’AEPD ha respinto entrambe le argomentazioni con motivazioni che si ritiene meritino un’analisi distinta.

Quanto alla base contrattuale: l’esecuzione del contratto giustifica il trattamento di dati strettamente necessari allo svolgimento della prestazione. Una geolocalizzazione continua, l’accesso ai contatti personali, alle registrazioni audio e ai dati di salute del lavoratore non presentano — sulla base degli atti — un nesso causale diretto e necessario con la mansione di conducente VTC. Il principio è quello già enunciato dalla giurisprudenza della Audiencia Nacional citata nella risoluzione AEPD : la finalità di controllo dell’attività lavorativa e di erogazione del servizio al cliente “non supera il necessario giudizio di proporzionalità” quando le stesse finalità possano essere conseguite con misure meno intrusive — ad esempio, sistemi di geolocalizzazione installati direttamente sui veicoli anziché sui dispositivi personali dei lavoratori.

Quanto al consenso: l’AEPD richiama il Considerando 43 GDPR e le Linee guida EDPB 05/2020, nella parte relativa alla “libertà” del consenso. Nell’ambito del rapporto di lavoro, il consenso è strutturalmente a rischio di essere non libero per via della dipendenza economica del lavoratore dal datore. L’AEPD osserva che quando l’accesso al dispositivo aziendale è condizionato a risorse e disponibilità dell’impresa — sicché il lavoratore si trova di fatto a dover usare il proprio telefono — il “consenso” all’installazione delle applicazioni non è una manifestazione libera e autonoma della propria volontà, ma una condizione imposta per mantenere il posto di lavoro. In aggiunta, l’impossibilità di modificare i permessi delle applicazioni installate — come risulta esplicitamente dai documenti aziendali che vietano qualunque modifica al terminale senza autorizzazione scritta — esclude che il lavoratore possa esercitare un reale controllo sui propri dati.

Il principio di minimizzazione: eccesso sistematico dei permessi applicativi

L’art. 5.1.c) GDPR è violato ogni qual volta vengano raccolti dati non strettamente pertinenti e necessari rispetto alle finalità dichiarate. Nel caso in esame, la risoluzione constata che le applicazioni obbligatorie — anche là dove vengano installate su terminali aziendali — raccolgono dati chiaramente eccedenti: lo stato fisico del lavoratore, i contatti personali, le registrazioni audio, i video. Nessuna di queste categorie è riconducibile alla necessità di gestire una flotta VTC o di garantire la sicurezza dei passeggeri, finalità che avrebbero potuto essere soddisfatte con sistemi di tracciamento installati sui veicoli e con applicazioni a permessi minimi.

Va detto che l’AEPD non è entrata nel merito tecnico di ciascuna singola applicazione — i cui nomi restano oscurati nella versione pubblica del provvedimento — ma ha fondato la propria valutazione sulle schermate del Play Store di Google che illustravano i permessi richiesti all’atto dell’installazione. Si tratta di una metodologia probatoria rilevante: le informazioni pubblicamente disponibili sugli store applicativi costituiscono evidenza sufficiente per stabilire che il titolare del trattamento ha messo a disposizione dei propri dipendenti strumenti eccedenti la necessità funzionale.

Il difetto di informativa

L’AEPD accerta che Ares Capital non aveva fornito ai lavoratori informazioni sufficienti sulle modalità di funzionamento delle applicazioni, sui dati effettivamente raccolti, sui tempi di conservazione e — aspetto particolarmente significativo — sulle concrete modalità di disconnessione al termine della giornata lavorativa. La clausola contrattuale che prevedeva la possibilità di disconnettersi “fuera de su jornada laboral” era considerata generica e insufficiente, non avendo Ares Capital chiarito se la disconnessione richiedesse la chiusura della sessione, la disinstallazione temporanea o lo spegnimento del dispositivo.

Il difetto di informativa determina non solo una violazione formale dell’art. 13 GDPR, ma incide sulla validità del consenso medesimo: un consenso prestato senza piena consapevolezza di che cosa si stia autorizzando non è “informato” ai sensi dell’art. 4.11 GDPR, né soddisfa i requisiti minimi di contenuto indicati nelle Linee guida EDPB 05/2020.

Profili critici e questioni aperte

Il BYOD tra autonomia contrattuale e tutela dei diritti fondamentali

Il caso Ares Capital pone in evidenza la tensione strutturale insita in qualsiasi politica BYOD in senso lato — ossia in qualsiasi modello organizzativo in cui il confine tra dispositivo personale e strumento di lavoro sia permeabile. L’aspetto più delicato non è l’uso del proprio smartphone, ma l’installazione di applicazioni che estendono i permessi del datore di lavoro a spazi privati del lavoratore — rubrica, galleria fotografica, microfono, dati biometrici — che in condizioni normali sarebbero inaccessibili.

Secondo il parere di chi scrive, la clausola contrattuale che consente al datore di lavoro di imporre l’installazione di applicazioni su dispositivi personali — senza specificare nel dettaglio quali dati vengano raccolti, con quale frequenza, con quale meccanismo di disconnessione — è strutturalmente incompatibile con il GDPR, indipendentemente dalla compensazione economica eventualmente corrisposta. La compensazione monetaria può giustificare l’uso del dispositivo, non l’acquisizione di dati personali eccedenti la finalità lavorativa.

L’irrilevanza del consenso contrattuale in ambito lavorativo

La tematica del consenso nel rapporto di lavoro ha una storia applicativa consolidata a livello europeo. Il Gruppo di lavoro art. 29, nelle Linee guida sul consenso poi confluite nelle Linee guida EDPB 05/2020, aveva già chiarito che nel contesto del datore di lavoro/dipendente è “improbabile che il consenso sia liberamente prestato” per via della dipendenza. L’AEPD segue questa impostazione senza deroghe: il fatto che l’impresa assuma formalmente di non imporre l’uso del telefono personale non vale se la condizione pratica del mercato delle risorse aziendali rende l’alternativa teorica.

Appare chiaro allo scrivente che questo principio è di diretta applicabilità anche nell’ordinamento italiano. Il Garante italiano ha più volte affermato — da ultimo nel contesto dei controlli a distanza — che il consenso del lavoratore non può costituire base autonoma per il trattamento di dati connessi alla gestione del rapporto lavorativo, dovendosi ricorrere ad altre basi giuridiche — in primis l’obbligo legale o il legittimo interesse — accompagnate però dal rispetto del principio di proporzionalità.

La responsabilità del titolare per i permessi delle app di terze parti

Un profilo di interesse teorico-pratico emerge dalla struttura del caso: Ares Capital non è lo sviluppatore delle applicazioni in questione, bensì il soggetto che ne impone l’installazione. L’AEPD non entra in questa distinzione in modo approfondito, ma ne trae una conseguenza operativa netta: il titolare del trattamento che impone l’uso di un’applicazione di terza parte risponde del trattamento che quell’applicazione effettua, se è lui a determinare la necessità dell’installazione. In sostanza, non è possibile scaricare la responsabilità sullo sviluppatore dell’app: il titolare deve verificare — prima di imporne l’utilizzo ai dipendenti — quali permessi l’applicazione richiede, se tali permessi sono giustificati dalla finalità dichiarata, e se esiste un’alternativa tecnica con minor impatto sui dati personali.

Si ritiene che questo approccio sia pienamente coerente con il principio di protezione dei dati by design e by default sancito dall’art. 25 GDPR, il quale impone al titolare di adottare, sin dalla fase di progettazione del trattamento, misure tecniche e organizzative idonee ad attuare i principi di protezione dei dati. L’adozione di un’applicazione con permessi eccedenti equivale, nella sostanza, a una scelta progettuale incompatibile con il principio di minimizzazione.

La quantificazione delle sanzioni e il criterio del fatturato

Le tre sanzioni irrogate — 100.000 euro per la violazione dell’art. 5.1.c); 80.000 euro per la violazione dell’art. 6.1; 20.000 euro per la violazione dell’art. 13 — sommano a 200.000 euro totali. Rispetto al fatturato di Ares Capital (256.229.000 euro nel 2024), l’importo complessivo rappresenta circa lo 0,078% del volume di affari, ben al di sotto del massimale del 4% del fatturato mondiale totale annuo previsto dall’art. 83.5 GDPR per le violazioni ivi elencate. L’AEPD ha optato per una sanzione proporzionata al caso concreto piuttosto che per un utilizzo del massimale, tenendo conto che — almeno formalmente — alcune misure correttive erano già state avviate dall’impresa prima della conclusione del procedimento.

Non si ha evidenza, sulla base del provvedimento pubblicato, che l’AEPD abbia applicato agevolazioni per la cooperazione volontaria con l’Autorità, anche perché Ares Capital non ha presentato memorie difensive al termine del procedimento sanzionatorio, comportamento che — come specificato nella risoluzione stessa — ha determinato la conversione dell’atto di avvio in proposta di risoluzione ai sensi dell’art. 64.2.f) della LPACAP.

Adempimenti concreti per DPO e imprese

La seguente sezione operativa è concepita come strumento di lavoro per il DPO e il responsabile legale d’impresa alle prese con la revisione o l’impostazione di un programma di compliance BYOD in contesto lavorativo. Gli adempimenti seguono la logica progressiva del ciclo di gestione del trattamento: mappatura, valutazione, informazione, governance tecnica.

Mappatura del perimetro BYOD: prima di qualsiasi altra azione, si suggerisce di costruire un inventario completo delle applicazioni la cui installazione è prevista o imposta — a qualunque titolo — su dispositivi dei dipendenti, distinguendo tra quelle installate su terminali aziendali e quelle installate su dispositivi personali usati per finalità lavorative. Per ciascuna applicazione vanno documentati: permessi richiesti dal sistema operativo (iOS/Android); dati raccolti secondo la privacy label disponibile sullo store; destinatari del trattamento; eventuale trasferimento verso Paesi terzi. Questa mappatura costituisce la base per il registro dei trattamenti di cui all’art. 30 GDPR.

Analisi di proporzionalità per ciascuna applicazione: per ogni applicazione censita, il DPO è tenuto a verificare se i permessi concretamente richiesti all’atto dell’installazione siano strettamente necessari rispetto alla finalità lavorativa dichiarata. La verifica dovrebbe avvenire attraverso una matrice funzionale: funzione dell’app → dati minimi necessari per quella funzione → permessi effettivamente richiesti → delta tra necessario e richiesto. Dove il delta è positivo — ovvero l’applicazione richiede più di quanto necessario — si ha un potenziale vizio di minimizzazione ex art. 5.1.c) GDPR, da risolvere con la sostituzione dell’applicazione, la negoziazione con il fornitore per una versione “privacy-reduced”, ovvero la rinuncia all’imposizione di quell’applicazione su dispositivi personali.

Individuazione della base giuridica: per ciascun trattamento connesso all’uso di applicazioni su dispositivi dei dipendenti, la base giuridica va individuata prima dell’avvio del trattamento e documentata nel registro. In ambito lavorativo, si ritiene che le basi giuridiche praticabili siano principalmente l’esecuzione del contratto (art. 6.1.b) GDPR) e il legittimo interesse (art. 6.1.f) GDPR) — quest’ultimo solo previa conduzione del bilanciamento degli interessi e nel rispetto del principio di proporzionalità. Il consenso (art. 6.1.a) GDPR) non dovrebbe essere invocato come base autonoma per trattamenti che afferiscono alla sfera privata del lavoratore, in linea con quanto indicato dall’EDPB e con la giurisprudenza dell’AEPD e del Garante italiano.

Revisione delle clausole contrattuali e delle policy BYOD: qualora l’impresa si avvalga di modelli BYOD — siano essi espliciti o impliciti, come nel caso Ares Capital — è necessario che le relative clausole contrattuali e le policy interne specifichino: le applicazioni la cui installazione è richiesta; i dati raccolti da ciascuna applicazione; le finalità del trattamento; la base giuridica; le modalità di disconnessione al termine della giornata lavorativa; i diritti dell’interessato e le relative modalità di esercizio. Clausole generiche del tipo “l’azienda può accedere ai dispositivi per finalità di sicurezza e controllo” non soddisfano il requisito di trasparenza dell’art. 13 GDPR.

Redazione o revisione dell’informativa ex art. 13 GDPR: l’informativa da fornire al lavoratore che utilizzi dispositivi personali per finalità lavorative deve essere specifica — non può essere la medesima informativa generica consegnata all’atto dell’assunzione. Deve contenere, in aggiunta agli elementi standard: la lista delle applicazioni la cui installazione è richiesta; la categoria di dati raccolta da ciascuna applicazione; le modalità operative di disconnessione (distinguendo tra log-out dall’applicazione, disattivazione del permesso di geolocalizzazione in background, e spegnimento del dispositivo); l’indicazione se le applicazioni continuano a raccogliere dati al di fuori dell’orario di lavoro e in quali condizioni.

Valutazione d’impatto (DPIA) ex art. 35 GDPR: si suggerisce di condurre una DPIA ogni qual volta il trattamento tramite BYOD contempli: geolocalizzazione continua o frequente dei lavoratori; raccolta di dati relativi alla salute o allo stato fisico; elaborazione di profili comportamentali dei dipendenti; accesso a comunicazioni private (chiamate, messaggi). La DPIA è obbligatoria ai sensi dell’art. 35.3.c) GDPR quando il trattamento “prevede la sorveglianza sistematica su larga scala di zone accessibili al pubblico” e, per analogia interpretativa consolidata, dei lavoratori in mobilità.

Accordo sindacale o informativa preventiva per i controlli a distanza (rilevante per il contesto italiano): qualora l’applicazione installata sul dispositivo del lavoratore — personale o aziendale — consenta de facto un controllo a distanza dell’attività lavorativa, l’art. 4, comma 1, dello Statuto dei Lavoratori impone il previo accordo sindacale o l’autorizzazione dell’Ispettorato Nazionale del Lavoro. La geolocalizzazione continua tramite app è, secondo la prassi consolidata, un caso paradigmatico di controllo a distanza. Il mancato rispetto di questo requisito espone l’impresa a sanzioni sia giuslavoristiche sia in materia di protezione dei dati.

Governance tecnica: limitazione dei permessi applicativi tramite MDM: per i terminali aziendali, l’adozione di una soluzione MDM (Mobile Device Management) che consenta di limitare i permessi delle applicazioni al minimo necessario costituisce una misura di protezione dei dati by design e by default ai sensi dell’art. 25 GDPR. Per i dispositivi personali in modalità BYOD, l’impresa non può imporre configurazioni MDM senza il consenso del lavoratore — ma può e deve scegliere applicazioni che rispettino il principio di minimizzazione anche in assenza di controllo tecnico centralizzato.

Formazione periodica dei lavoratori e dei responsabili HR: la formazione sui diritti in materia di protezione dei dati — con particolare riferimento alle modalità di disconnessione digitale, all’esercizio dei diritti ex artt. 15-22 GDPR e ai canali di contatto con il DPO — non è un adempimento una tantum, ma va strutturata come attività periodica e documentata, specie in contesti ad alta rotazione del personale come il settore del trasporto VTC.

—

Tabella operativa — Mappatura adempimenti, norme e evidenze documentali

| Adempimento | Norma di riferimento | Evidenza documentale richiesta | |—|—|—| | Inventario applicazioni e permessi | Art. 30 GDPR; art. 5.1.c) GDPR | Registro trattamenti aggiornato; schede per ciascuna app con permessi e dati raccolti | | Analisi di proporzionalità | Art. 5.1.c) GDPR; art. 25 GDPR | Matrice funzionale app/dati/necessità; eventuale parere tecnico scritto | | Individuazione base giuridica | Art. 6.1 GDPR; Considerando 43 GDPR | Documento di analisi delle basi giuridiche per ciascun trattamento BYOD | | Bilanciamento legittimo interesse | Art. 6.1.f) GDPR; Linee guida EDPB 1/2024 sul legittimo interesse | Legitimate interest assessment (LIA) documentato e datato | | Revisione clausole contrattuali | Art. 13 GDPR; art. 88 GDPR; art. 4 Stat. Lav. | Testo contrattuale aggiornato; policy BYOD specifica con data di adozione | | Informativa specifica ex art. 13 | Art. 13 GDPR; Linee guida EDPB 05/2020 | Informativa BYOD separata, firmata per ricevuta dal lavoratore | | DPIA per trattamenti ad alto rischio | Art. 35 GDPR | Report DPIA datato, approvato dal DPO e, ove necessario, consultazione preventiva con l’Autorità | | Accordo sindacale/autorizzazione INL | Art. 4 L. 300/1970 (solo Italia) | Copia accordo sindacale o provvedimento autorizzatorio INL | | Configurazione MDM su terminali aziendali | Art. 25 GDPR | Policy di gestione MDM; log delle configurazioni applicate | | Formazione periodica dipendenti | Art. 5.1.a) GDPR; art. 24 GDPR | Piano formativo annuale; registri di partecipazione con data e argomenti | | Diritto alla disconnessione digitale | Art. 88 GDPR; art. 13 GDPR; art. 19 L. 81/2017 (solo Italia) | Procedura operativa di disconnessione; comunicazione ai lavoratori |

Conclusioni

Il provvedimento dell’AEPD nel caso Ares Capital non esaurisce la propria portata nel perimetro spagnolo. Sul piano sistematico, esso offre una ricostruzione chiara e documentata di un fenomeno in rapida espansione — la sorveglianza digitale dei lavoratori tramite applicazioni su dispositivi personali — e lo riconduce ai principi fondamentali del GDPR con un rigore argomentativo che lo rende un utile riferimento interpretativo anche per i DPO e i giuristi d’impresa italiani.

Restano aperte alcune questioni di non poco momento. In primo luogo, la risoluzione non affronta il tema della responsabilità degli sviluppatori delle applicazioni installate: è legittimo chiedersi se, in futuro, le Autorità di controllo potrebbero estendere la propria azione anche ai fornitori di applicazioni che mettono a disposizione degli stessi permessi eccessivi, almeno laddove questi abbiano consapevolezza che le proprie soluzioni sono utilizzate in contesti lavorativi. Il tema si intreccia con le previsioni dell’AI Act — Regolamento (UE) 2024/1689 — per i sistemi che elaborano profili comportamentali dei lavoratori.

In secondo luogo, il caso solleva la questione di come debbano essere trattati i dati raccolti tramite applicazioni installate su dispositivi personali quando il rapporto di lavoro si conclude: la risoluzione si limita a menzionare il periodo di conservazione previsto contrattualmente (cinque anni dopo la cessazione), ma non affronta il problema — pratico e non irrilevante — della impossibilità tecnica di “recuperare” dati già trasmessi verso server di terze parti al di fuori del controllo del datore di lavoro.

In terzo luogo, si ritiene che il tema del BYOD meriti un’attenzione sistematica da parte del Garante italiano, che potrebbe muoversi in due direzioni complementari: l’adozione di Linee guida specifiche sul trattamento dei dati personali tramite dispositivi mobili in contesto lavorativo, e l’aggiornamento delle indicazioni in materia di geolocalizzazione dei lavoratori alla luce dell’evoluzione tecnologica — che ha reso quella dell’app su smartphone la forma predominante di tracciamento della posizione, rispetto ai tradizionali sistemi GPS installati sui veicoli.

Infine, vale la pena osservare che la risoluzione dell’AEPD mette in luce una debolezza strutturale nei programmi di compliance BYOD: la tendenza a trattare la questione come prevalentemente contrattuale — predisponendo clausole e policy — senza che tale attività sia accompagnata da una verifica tecnica effettiva dei permessi delle applicazioni imposte. Il principio di accountability ex art. 5.2 GDPR impone al titolare di essere in grado di dimostrare la conformità, non di affermarla. In questo senso, la documentazione tecnica relativa ai permessi applicativi — oggi producibile in modo agevole attraverso i sistemi di gestione delle applicazioni mobili — costituisce tanto un’evidenza a tutela dell’impresa in caso di ispezione, quanto uno strumento di controllo preventivo che il DPO è nella posizione più adeguata per presidiare.

L'articolo AEPD sanziona Ares Capital per BYOD senza base giuridica: 200mila euro proviene da 01magazine.

Questa collocazione sistematica ha conseguenze giuridiche di primo rilievo: la farmacia agisce quale soggetto alimentatore all’interno di un’architettura di titolarità pubblica e multilivello, l’alimentazione del Fascicolo non richiede il consenso dell’assistito mentre la consultazione lo esige, e il diritto di oscuramento esercitato dal paziente si propaga a valle escludendo i dati oscurati tanto dalla consultazione quanto dall’alimentazione dell’EDS. Restano invece soggetti al regime ordinario del GDPR i trattamenti che la farmacia effettua in proprio — schedari clienti, servizi di aderenza terapeutica, presa in carico del paziente cronico, telemedicina — rispetto ai quali essa conserva piena titolarità e i correlati obblighi di base giuridica, informativa, DPIA e sicurezza.

Il tema interseca in modo profondo la disciplina della protezione dei dati personali di categoria particolare ai sensi del Regolamento (UE) 2016/679 (GDPR), il Codice della Privacy (d.lgs. 196/2003 come novellato dal d.lgs. 101/2018), le disposizioni nazionali in materia di FSE introdotte dal d.l. 179/2012 e riformate dalla l. 221/2012 e dal Piano Nazionale di Ripresa e Resilienza (PNRR), nonché le linee di indirizzo e le FAQ del Garante in materia di trattamenti in ambito sanitario. L’analisi rileva che il dossier farmaceutico, pur costituendo un prezioso presidio clinico e di salute pubblica, richiede un’architettura di governance del dato particolarmente robusta, fondata su una corretta perimetrazione dei ruoli, informative trasparenti, misure tecniche e organizzative adeguate e una riflessione approfondita sui flussi di interoperabilità con il FSE, con l’EDS e con le piattaforme di telemedicina.

1. Introduzione e inquadramento generale

Il sistema sanitario italiano è attraversato da una trasformazione profonda che riguarda non soltanto l’organizzazione dei servizi, ma anche il ridisegno delle competenze professionali e dei flussi informativi che connettono i diversi attori della cura. In questo contesto, la farmacia sta progressivamente abbandonando il ruolo di mero dispensatore del farmaco prescritto per assumere quello di presidio clinico di prossimità, interlocutore privilegiato del paziente cronico, punto di raccolta e restituzione di informazioni terapeutiche di rilevanza clinica.

Lo strumento che più di ogni altro incarna questa trasformazione è il dossier farmaceutico: un insieme strutturato di dati relativi alla storia farmacologica del paziente — farmaci prescritti ed erogati, posologia, interazioni, controindicazioni, reazioni avverse — che si costruisce nel tempo in collegamento con il medico di medicina generale e con gli altri operatori sanitari, al fine di garantire continuità terapeutica, ridurre gli errori da politerapia e incrementare l’aderenza alle terapie prescritte. Quest’ultimo aspetto è di particolare rilievo epidemiologico: secondo i dati dell’Organizzazione Mondiale della Sanità, la scarsa aderenza terapeutica nelle malattie croniche è responsabile di un numero molto elevato di ricoveri evitabili e di costi sanitari aggiuntivi stimati in miliardi di euro a livello europeo.

Fino all’aggiornamento delle FAQ del maggio 2026, la dottrina e la prassi tendevano a ricostruire il dossier farmaceutico come un archivio proprio della farmacia, modellato sulla figura del “dossier sanitario” elaborata dal Garante per le strutture sanitarie. Le FAQ hanno invece consolidato una lettura diversa e più netta: il dossier farmaceutico è una sezione del FSE, che la farmacia alimenta al momento della consegna dei farmaci, con la finalità di migliorare la qualità del servizio e favorire il monitoraggio, l’appropriatezza nell’erogazione dei medicinali e l’aderenza alla terapia, contribuendo alla sicurezza del paziente.

Questa precisazione non riduce la complessità del quadro di compliance ma la sposta. La farmacia non è più — o non è più soltanto — il titolare di un proprio archivio sanitario, ma un nodo di un’infrastruttura pubblica nazionale, con responsabilità di correttezza, qualità e sicurezza del dato conferito, e resta al tempo stesso titolare autonomo dei trattamenti che effettua nei propri sistemi gestionali e nell’ambito della farmacia dei servizi. Distinguere con precisione questi due piani è oggi il primo e più importante esercizio di governance richiesto ai DPO del settore.

Sul piano giuridico, il dossier farmaceutico tratta dati sanitari, categoria per definizione “particolare” ai sensi dell’art. 9 GDPR, con tutte le implicazioni che ne derivano in termini di base giuridica, garanzie rafforzate, diritti dell’interessato e obblighi del titolare del trattamento. La farmacia — sia essa una farmacia privata convenzionata, una farmacia pubblica o una farmacia ospedaliera — si trova quindi a dover costruire un’architettura di compliance particolarmente rigorosa, in un contesto normativo che vede sovrapporsi disciplina europea, normativa nazionale, decreti attuativi, provvedimenti e FAQ del Garante e, sempre più, regole relative all’Ecosistema dati sanitari e ai servizi digitali in sanità.

L’obiettivo del presente contributo è offrire un’analisi giuridica sistematica del dossier farmaceutico nell’ottica della protezione dei dati personali, esaminando le basi giuridiche applicabili, la ripartizione dei ruoli privacy, i profili critici connessi all’interoperabilità con il FSE e con l’EDS, le misure tecnico-organizzative richieste dalla disciplina vigente e le implicazioni operative per i DPO e i responsabili della compliance nelle strutture farmaceutiche e sanitarie.

2. Il quadro normativo di riferimento

2.1. La disciplina europea: GDPR e il trattamento dei dati sanitari

Il punto di partenza obbligato è il Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio del 27 aprile 2016, che all’art. 9 qualifica i dati relativi alla salute come categoria speciale di dati personali, il cui trattamento è in linea di principio vietato salvo ricorra una delle condizioni tassativamente previste dal paragrafo 2. Nel contesto del dossier farmaceutico, le condizioni di maggiore interesse sono quelle di cui alle lettere a) (consenso esplicito dell’interessato), h) (trattamento necessario per finalità di medicina preventiva, diagnosi, assistenza o terapia sanitaria o sociale ovvero gestione dei sistemi e servizi sanitari o sociali) e i) (trattamento necessario per motivi di interesse pubblico nel settore della sanità pubblica).

La condizione di cui alla lett. h) è quella più frequentemente invocata nel contesto della cura della salute, ed è disciplinata con maggiore dettaglio dall’art. 9, par. 3, GDPR, che richiede che il trattamento sia effettuato da o sotto la responsabilità di un professionista soggetto al segreto professionale conformemente al diritto dell’Unione o degli Stati membri ovvero alle norme stabilite dagli organismi nazionali competenti, oppure da altra persona anch’essa soggetta a un obbligo di riservatezza. È utile sottolineare che, nell’architettura del FSE, la lett. h) opera congiuntamente alla lett. i) e all’art. 9, par. 2, lett. g), là dove il trattamento è imposto o consentito da norme nazionali per finalità di interesse pubblico rilevante: è proprio questa combinazione a spiegare perché l’alimentazione del Fascicolo non sia rimessa al consenso dell’assistito.

Il GDPR impone, in relazione a qualsiasi trattamento ma con particolare intensità per le categorie speciali, l’adozione di misure tecniche e organizzative adeguate ai sensi dell’art. 25 (protezione dei dati fin dalla progettazione e per impostazione predefinita) e dell’art. 32 (sicurezza del trattamento), nonché la valutazione d’impatto sulla protezione dei dati (DPIA) ai sensi dell’art. 35 ogniqualvolta il trattamento sia “suscettibile di presentare un rischio elevato per i diritti e le libertà delle persone fisiche”. Il Considerando 91 GDPR chiarisce che una DPIA è sempre appropriata, tra l’altro, quando si trattano su larga scala dati relativi alla salute.

Le linee guida in materia di DPIA elaborate in sede europea forniscono criteri interpretativi rilevanti: il trattamento sistematico su larga scala di dati sanitari da parte di una rete di farmacie, con funzionalità di profilazione terapeutica e monitoraggio dell’aderenza, risponde a più criteri che rendono la DPIA non solo opportuna ma doverosa.

2.2. La normativa nazionale: Codice Privacy, FSE 2.0, EDS e normativa farmaceutica

Sul piano nazionale, il d.lgs. 196/2003, come modificato dal d.lgs. 101/2018 di adeguamento al GDPR, disciplina il trattamento dei dati personali nell’ordinamento italiano. In materia sanitaria, l’art. 2-septies del Codice Privacy individua le misure di garanzia che il Garante adotta, sentito il Ministero della Salute, identificando le tipologie di dati trattabili, le operazioni eseguibili e le misure tecniche e di sicurezza adottabili.

Il fascicolo sanitario elettronico è disciplinato dal d.l. 179/2012, convertito dalla l. 221/2012, e dalle successive disposizioni attuative, tra cui il d.p.c.m. 178/2015 e, per il modello FSE 2.0, i decreti ministeriali di attuazione. Fra questi assumono oggi rilievo centrale due provvedimenti. Il primo è il d.m. 7 settembre 2023, relativo alla fase di attivazione e alle modalità operative del FSE 2.0, che definisce fra l’altro i profili autorizzativi differenziati in base alla figura professionale e alla finalità della consultazione. Il secondo è il d.m. 31 dicembre 2024, istitutivo dell’Ecosistema dati sanitari, componente del FSE alimentata con i dati e i documenti presenti nel Fascicolo — esclusi quelli oscurati dall’assistito — nonché con quelli resi disponibili dal Sistema Tessera Sanitaria.

Il PNRR ha accelerato la riforma del FSE verso un modello “2.0” che mira all’interoperabilità nazionale e all’integrazione di nuove tipologie documentali, tra cui, appunto, il dossier farmaceutico. La differenza concettuale tra FSE e dossier sanitario resta rilevante sul piano generale — il FSE è alimentato da più soggetti del sistema sanitario ed è accessibile al paziente e ai professionisti autorizzati nell’ambito del rapporto di cura, mentre il dossier sanitario nasce all’interno di una singola struttura — ma, come si dirà, per il dossier farmaceutico le FAQ del maggio 2026 hanno operato una collocazione espressa all’interno del Fascicolo.

Sul piano della disciplina farmaceutica, il d.lgs. 219/2006 di attuazione della direttiva europea sul codice comunitario relativo ai medicinali per uso umano, nonché il d.lgs. 153/2009 in materia di nuovi servizi delle farmacie, costituiscono il riferimento primario per la definizione del ruolo professionale del farmacista e delle attività che la farmacia è legittimata a svolgere. Il d.lgs. 153/2009, in particolare, ha introdotto la cosiddetta farmacia dei servizi, prevedendo che le farmacie possano erogare servizi di secondo livello tra cui la somministrazione di test diagnostici, la partecipazione ad attività di monitoraggio dell’aderenza terapeutica e la collaborazione con i medici di medicina generale nell’ambito delle cure primarie. È in questo quadro che il dossier farmaceutico trova la sua legittimazione funzionale, e in questo quadro si collocano anche i trattamenti che la farmacia effettua in proprio, distinti dall’alimentazione del Fascicolo.

2.3. I provvedimenti e le FAQ del Garante in materia sanitaria

Il Garante per la protezione dei dati personali ha nel tempo adottato numerosi provvedimenti generali e specifici in materia di trattamento di dati sanitari che costituiscono riferimento interpretativo imprescindibile. Tra questi assumono rilievo sistematico le Linee guida in materia di Fascicolo Sanitario Elettronico e di dossier sanitario del 2009 e le successive Linee guida sul dossier sanitario del 2015, nelle quali il Garante ha distinto il dossier sanitario — strumento idoneo a raccogliere le informazioni cliniche del paziente formatesi all’interno di una singola struttura sanitaria nel corso di più rapporti con il medesimo paziente — dal FSE, che ha invece portata multiprovider e valenza nazionale o regionale.

2.3.1. L’aggiornamento delle FAQ del 21 maggio 2026

Il 21 maggio 2026 il Garante ha pubblicato una revisione delle proprie FAQ sul Fascicolo sanitario elettronico, allineandole al d.m. 7 settembre 2023 e al d.m. 31 dicembre 2024. Le novità di maggiore impatto per il settore farmaceutico si collocano su cinque piani, tra loro strettamente connessi.

Il primo, e il più significativo sul piano sistematico, riguarda la qualificazione stessa del dossier farmaceutico. Le FAQ precisano che si tratta di una sezione del FSE aggiornata dalla farmacia al momento della consegna dei farmaci, le cui finalità dichiarate sono il miglioramento della qualità del servizio, il monitoraggio e l’appropriatezza nell’erogazione dei medicinali, l’aderenza alla terapia e, in ultima analisi, la sicurezza del paziente. La farmacia è dunque riconosciuta come nodo attivo della rete sanitaria digitale, non come mero soggetto passivo.

Il secondo piano attiene al consenso, e in particolare alla distinzione — decisiva sul piano operativo — tra alimentazione e consultazione del Fascicolo. Per la sola alimentazione non è richiesto alcun consenso: ogni professionista sanitario, pubblico o privato, che eroga una prestazione contribuisce ad alimentare il FSE in modo automatico, dalla ricetta al referto, dal verbale di pronto soccorso al certificato vaccinale. Per la consultazione, invece, il professionista sanitario che ha in cura il paziente deve aver ricevuto il consenso esplicito dell’assistito, che può essere espresso anche una sola volta. Il Garante chiarisce inoltre che il mancato consenso alla consultazione — o la sua revoca successiva — non pregiudica in alcun modo l’accesso alla prestazione sanitaria: l’unica conseguenza è l’impossibilità, per il personale sanitario, di visionare i dati presenti nel Fascicolo.

Il terzo piano è quello del diritto di oscuramento, che le FAQ definiscono come la garanzia data all’interessato di non rendere visibili i propri dati a tutti i soggetti che possono accedere al FSE per finalità di cura, ovvero soltanto ad alcuni di essi. L’oscuramento può riguardare singoli documenti o intere categorie di dati ed è esercitabile in qualsiasi momento. Per alcune informazioni particolarmente sensibili — sieropositività, uso di sostanze stupefacenti e dipendenze, interruzione volontaria di gravidanza, parto in anonimato — l’invisibilità ai terzi è impostata per impostazione predefinita, spettando all’assistito decidere se e quando renderle accessibili: si tratta di un’applicazione esemplare del principio di privacy by default di cui all’art. 25, par. 2, GDPR.

Il quarto piano concerne la platea dei soggetti abilitati all’accesso e, specularmente, di quelli che ne sono esclusi. L’accesso al FSE è riservato a categorie predeterminate di soggetti, con profili autorizzativi differenziati per figura professionale e finalità della consultazione, e con tracciamento sistematico degli accessi; il cittadino, dal canto suo, può consultare il proprio Fascicolo e sapere chi vi ha avuto accesso. Sono invece esclusi in modo assoluto i periti, le compagnie di assicurazione, i datori di lavoro, le associazioni scientifiche e gli organismi amministrativi anche se operanti in ambito sanitario, nonché il personale medico nell’esercizio di attività medico-legale, come l’accertamento dell’idoneità lavorativa.

Il quinto e ultimo piano riguarda l’Ecosistema dati sanitari, descritto come componente del FSE alimentata con i dati e i documenti presenti nel Fascicolo — esclusi quelli oscurati dall’assistito — nonché con quelli resi disponibili dal Sistema Tessera Sanitaria. Il dossier farmaceutico rientrerà tra i servizi offerti dall’EDS, che estrarrà dal FSE le informazioni relative alle prescrizioni e alle erogazioni farmaceutiche, sempre con esclusione di quelle oscurate dall’assistito. Su richiesta, l’EDS potrà fornire servizi di analisi ed elaborazione dei dati a cittadini, professionisti sanitari, Ministero della Salute, Agenas e Regioni, oltre a consentire l’utilizzo dei dati per finalità di prevenzione, controllo e gestione del sistema sanitario; in ambito di ricerca scientifica medica, biomedica ed epidemiologica, potrà inoltre rendere disponibili dati anonimizzati, accessibili esclusivamente al personale autorizzato del Ministero della Salute, di Agenas e delle Regioni o Province autonome. Il Garante ha peraltro chiarito, coerentemente con il proprio parere sull’EDS, che tali servizi saranno attivabili solo a seguito della completa attuazione del FSE 2.0, tuttora in corso.

2.3.2. Ciò che resta del modello “dossier sanitario”

La riqualificazione operata dalle FAQ non travolge l’intero impianto elaborato dal Garante per il dossier sanitario. I principi di minimizzazione ex art. 5, par. 1, lett. c) GDPR, di selettività delle informazioni raccolte, di granularità dei controlli di accesso e di affidabilità degli audit trail restano pienamente applicabili — e anzi si applicano tanto alla sezione farmaceutica del FSE quanto agli archivi che la farmacia gestisce in proprio.

Resta altresì fermo il principio, più volte ribadito dal Garante, secondo cui il trasferimento di dati sanitari tra strutture diverse — anche nell’ambito di reti di farmacie o di piattaforme di interoperabilità estranee al FSE — richiede una base giuridica autonoma e adeguata, non essendo sufficiente il consenso prestato in un contesto diverso.

2.4. Il contesto NIS2 e la sicurezza delle infrastrutture sanitarie

La Direttiva (UE) 2022/2555 (NIS2), recepita in Italia con il d.lgs. 138/2024, ha ampliato significativamente il perimetro dei soggetti obbligati alle misure di sicurezza informatica, includendo esplicitamente i soggetti operanti nel settore sanitario tra i soggetti essenziali o importanti a seconda delle dimensioni e del ruolo. Le farmacie ospedaliere e le strutture sanitarie di medie e grandi dimensioni che gestiscono sistemi informativi contenenti dati di salute su larga scala rientrano pertanto nell’ambito di applicazione della NIS2 e sono tenute ad adottare misure di gestione del rischio di cybersicurezza, a notificare gli incidenti significativi all’Agenzia per la Cybersicurezza Nazionale (ACN) e a rispettare i requisiti di sicurezza della catena di approvvigionamento digitale.

La collocazione del dossier farmaceutico all’interno del FSE accentua questo profilo: il gestionale di farmacia non è più un semplice registro delle transazioni, ma l’infrastruttura operativa attraverso la quale un’infrastruttura sanitaria nazionale viene alimentata. La compromissione di un gestionale può quindi tradursi in un rischio di integrità del dato conferito al Fascicolo, con effetti che si propagano ben oltre il perimetro della singola farmacia. La gestione del dossier farmaceutico su piattaforme digitali — in particolare se accessibili via cloud o integrate con sistemi di telemedicina e di prescrizione elettronica — è pertanto soggetta non soltanto agli obblighi GDPR di sicurezza del trattamento ma anche ai requisiti NIS2, creando un duplice livello di compliance che i titolari del trattamento e i loro DPO devono saper gestire in modo coordinato.

3. Analisi giuridica del dossier farmaceutico: struttura, basi giuridiche e governance del dato

3.1. Natura giuridica, ruoli privacy e perimetrazione dei trattamenti

Alla luce delle FAQ del maggio 2026, il dossier farmaceutico deve essere definito come la sezione del Fascicolo sanitario elettronico dedicata alla storia farmacologica dell’assistito, alimentata dalla farmacia al momento della consegna del medicinale e destinata a confluire tra i servizi dell’EDS. Esso raccoglie le informazioni relative alle prescrizioni e alle erogazioni farmaceutiche, con esclusione di quelle oscurate dall’assistito, e ha la funzione di supportare la continuità terapeutica, l’appropriatezza prescrittiva, il monitoraggio dell’aderenza e la sicurezza del paziente.

Questa qualificazione impone di distinguere con rigore tre distinti livelli di trattamento, ai quali corrispondono ruoli privacy e regimi giuridici differenti.

Il primo è quello dell’alimentazione del dossier farmaceutico nel FSE. In questo perimetro la farmacia non determina né le finalità né i mezzi essenziali del trattamento, che sono stabiliti dalla normativa primaria e dai decreti attuativi. La titolarità del FSE è ripartita, secondo il modello delineato dalla disciplina di settore, tra le Regioni e le Province autonome, il Ministero della Salute e gli altri soggetti istituzionali competenti per le rispettive componenti infrastrutturali, mentre la farmacia opera quale soggetto alimentatore, sul quale gravano obblighi di correttezza, esattezza e tempestività del conferimento, di sicurezza del canale di trasmissione e di rispetto delle regole tecniche. Il DPO deve evitare l’errore, tutt’altro che infrequente, di qualificare la farmacia come titolare del dossier farmaceutico tout court: si tratta di una qualificazione che espone a informative errate e a una gestione impropria delle istanze degli interessati, che per i dati del Fascicolo vanno indirizzate ai titolari competenti.

Il secondo attiene alla consultazione del FSE da parte del farmacista. Ove questi, quale professionista sanitario che ha in cura l’assistito, acceda al Fascicolo, opera all’interno del profilo autorizzativo definito dalla disciplina del FSE 2.0 e a condizione che l’assistito abbia prestato il consenso alla consultazione; l’accesso, per parte sua, è tracciato e visibile al cittadino. La farmacia deve garantire che gli accessi avvengano esclusivamente per finalità di cura, da parte di personale autorizzato e istruito ai sensi degli artt. 29 GDPR e 2-quaterdecies del Codice Privacy.

Il terzo, infine, è quello dei trattamenti propri della farmacia, che restano pienamente soggetti al regime ordinario del GDPR con la farmacia quale titolare del trattamento ai sensi dell’art. 4, n. 7. Vi rientrano gli schedari e le anagrafiche cliente, lo storico delle vendite nel gestionale, i programmi di aderenza terapeutica e di presa in carico del paziente cronico, i servizi di telemedicina e telemonitoraggio, le campagne di recall e reminder e i servizi erogati nell’ambito della farmacia dei servizi ex d.lgs. 153/2009. È qui — e non nel Fascicolo — che si collocano gli obblighi più impegnativi di individuazione della base giuridica, informativa, gestione del consenso, DPIA e definizione dei tempi di conservazione.

Qualora i trattamenti propri siano gestiti attraverso una piattaforma informatica di terzi — come avviene nella quasi totalità dei casi — il fornitore della piattaforma si configura come responsabile del trattamento ai sensi dell’art. 4, n. 8, GDPR, e il contratto che lo vincola alla farmacia deve rispettare i requisiti di cui all’art. 28 GDPR, con particolare riguardo alle istruzioni documentate del titolare, alle misure di sicurezza adottate, alla disciplina dei sub-responsabili e alle garanzie di riservatezza del personale autorizzato.

Nel caso di reti di farmacie che condividono dati per finalità proprie — ad esempio nell’ambito di catene nazionali o di programmi di aderenza gestiti a livello di gruppo — può configurarsi una situazione di contitolarità ai sensi dell’art. 26 GDPR, con conseguente obbligo di stipulare un accordo che definisca le rispettive responsabilità e il punto di contatto per l’esercizio dei diritti da parte degli interessati. È bene chiarire che tale contitolarità riguarda esclusivamente i trattamenti propri del gruppo e non si estende in alcun modo alla sezione farmaceutica del FSE, la cui titolarità è determinata dalla legge.

3.2. La base giuridica del trattamento

La determinazione della base giuridica è il primo e più delicato adempimento nella costruzione dell’architettura di compliance, e va condotta separatamente per ciascuno dei tre piani sopra individuati.

Per l’alimentazione del dossier farmaceutico nel FSE, la base giuridica non è il consenso. Il trattamento trova fondamento nelle disposizioni di legge e nei decreti attuativi che disciplinano il Fascicolo, e si colloca nel combinato disposto degli artt. 6, par. 1, lett. c) ed e), e 9, par. 2, lett. g), h) e i), GDPR. Le FAQ del Garante sono esplicite: per la sola alimentazione non è richiesto alcun consenso. Ne discende una conseguenza operativa di grande rilievo pratico, ossia che è scorretto, e potenzialmente fuorviante per il paziente, raccogliere in farmacia un “consenso all’inserimento dei dati nel dossier farmaceutico”. Una simile richiesta lascerebbe intendere l’esistenza di una facoltà di scelta che la normativa non prevede, in violazione dei principi di correttezza e trasparenza di cui all’art. 5, par. 1, lett. a), GDPR. Lo strumento che l’ordinamento riconosce all’assistito per governare la visibilità dei propri dati non è il consenso all’alimentazione, ma l’oscuramento.

Per la consultazione del FSE, il consenso esplicito dell’assistito è invece condizione necessaria, come chiarito dalle FAQ. Il consenso può essere espresso una sola volta ed è revocabile in qualsiasi momento; né il diniego né la revoca possono pregiudicare l’accesso alla prestazione sanitaria. La farmacia deve pertanto assicurarsi che il proprio gestionale non consenta la consultazione in assenza di consenso valido e che il personale sia formato sul divieto assoluto di accedere al Fascicolo al di fuori del rapporto di cura in atto.

Per i trattamenti propri della farmacia, infine, la base giuridica va individuata volta per volta. La condizione di cui all’art. 9, par. 2, lett. h) GDPR copre le attività riconducibili alla cura: il farmacista è professionista sanitario soggetto al segreto professionale ai sensi del codice deontologico della Federazione degli Ordini dei Farmacisti Italiani (FOFI) e delle norme di legge applicabili, e le attività di verifica delle interazioni farmacologiche, di controllo dell’aderenza terapeutica e di segnalazione delle reazioni avverse rientrano pienamente nell’esercizio delle sue attribuzioni professionali. Tuttavia, quando il trattamento eccede la gestione immediata del rapporto di cura — si pensi alla partecipazione a programmi di ricerca sull’aderenza, alla condivisione di dati con assicurazioni sanitarie, all’alimentazione di piattaforme di analisi dei consumi farmaceutici o a iniziative di marketing e fidelizzazione — occorre identificare una base giuridica autonoma per ciascuna finalità, che non può considerarsi compatibile con quella originaria di cura ai sensi dell’art. 6, par. 4, GDPR. In queste ipotesi il consenso esplicito ex art. 9, par. 2, lett. a) torna a essere lo strumento naturale, con i requisiti di libertà, specificità, informazione e inequivocabilità e con la garanzia della revocabilità senza pregiudizio nell’accesso alle cure.

Merita infine attenzione il richiamo delle FAQ all’esclusione assoluta di assicurazioni, datori di lavoro, periti e personale medico-legale dall’accesso al Fascicolo. Si tratta di un divieto che non è superabile mediante consenso dell’interessato e che la farmacia deve tenere presente anche nella gestione dei propri archivi: la circostanza che un dato sia stato legittimamente acquisito non abilita a condividerlo con soggetti che la normativa esclude dalla filiera della cura.

3.3. Il principio di accountability e la DPIA

Il trattamento dei dati nell’ambito del dossier farmaceutico richiede che il titolare sia in grado di dimostrare la conformità del trattamento alle norme del GDPR in ossequio al principio di accountability di cui agli artt. 5, par. 2, e 24 GDPR. Non è sufficiente adottare misure tecniche e organizzative adeguate: occorre documentarle, mantenerle aggiornate e sottoporle a revisione periodica.

L’obbligo di condurre una DPIA ai sensi dell’art. 35 GDPR va calibrato sui ruoli. Per il FSE e per l’EDS, le valutazioni d’impatto competono ai titolari istituzionali, e il Garante si è già espresso con propri pareri sui relativi schemi. La farmacia, in quanto soggetto alimentatore, non è tenuta a replicare quella valutazione, ma deve documentare le misure adottate a presidio della correttezza e della sicurezza del conferimento, nonché la gestione degli accessi in consultazione.

Per i trattamenti propri, invece, la DPIA è pienamente esigibile e spesso doverosa: il trattamento sistematico e su larga scala di dati relativi alla salute, la profilazione terapeutica dei pazienti, il monitoraggio dell’aderenza nel tempo e la potenziale condivisione dei dati con altri operatori sanitari sono tutti elementi che configurano un trattamento ad alto rischio. La DPIA deve essere condotta prima dell’avvio del trattamento, periodicamente aggiornata e condivisa con il DPO ai sensi dell’art. 35, par. 2, GDPR.

Il Garante ha pubblicato un elenco dei trattamenti per i quali è prescritta la DPIA ai sensi dell’art. 35, par. 4, GDPR, nel quale i trattamenti di dati sanitari su larga scala sono esplicitamente inclusi. La farmacia o la catena che gestisce programmi di aderenza per una platea significativa di pazienti — anche senza raggiungere le soglie che definiscono la “larga scala” in senso assoluto — è tenuta a valutare attentamente se il trattamento posto in essere presenti caratteristiche di rischio elevato che rendano necessaria la DPIA.

3.4. I diritti dell’interessato e il regime di oscuramento

Uno degli aspetti più delicati della governance del dossier farmaceutico riguarda la gestione dei diritti dell’interessato, e in particolare del diritto di accesso ex art. 15 GDPR, del diritto alla rettifica ex art. 16, del diritto alla cancellazione ex art. 17 e del diritto di opposizione ex art. 21.

Il primo adempimento è di ordine organizzativo e consiste nell’individuare correttamente il destinatario dell’istanza. Per i dati contenuti nel Fascicolo — inclusa la sezione farmaceutica — l’interessato deve rivolgersi ai titolari competenti secondo la disciplina del FSE, e la farmacia ha l’onere di indirizzarlo correttamente anziché rispondere nel merito su dati di cui non è titolare. Per i dati contenuti negli archivi propri della farmacia, l’istanza va invece gestita direttamente e nei termini dell’art. 12 GDPR.

Quanto all’oscuramento, le FAQ del maggio 2026 ne hanno precisato la portata in termini che vale la pena riprendere. Esso consiste nella garanzia data all’interessato di non rendere visibili i propri dati e documenti sanitari e socio-sanitari a tutti i soggetti che possono accedere al FSE per finalità di cura, ovvero soltanto ad alcuni di essi; può riguardare singoli documenti o intere categorie; è esercitabile in qualsiasi momento; ed è impostato per impostazione predefinita per le informazioni relative a sieropositività, dipendenze, interruzione volontaria di gravidanza e parto in anonimato.

L’oscuramento produce inoltre un effetto che le FAQ mettono in luce con chiarezza e che è centrale nell’architettura dell’EDS: i dati oscurati sono esclusi non soltanto dalla consultazione, ma anche dall’alimentazione dell’Ecosistema dati sanitari. La scelta del paziente si propaga dunque a valle, condizionando la disponibilità del dato per i servizi di analisi, per le finalità di programmazione e prevenzione e per la produzione di dataset anonimizzati destinati alla ricerca. Ne discende che il rispetto tecnico dell’oscuramento non è un adempimento formale ma il presidio che assicura la tenuta dell’intero sistema: un difetto di implementazione a monte si traduce in un trattamento illecito che si moltiplica a valle.

Sul piano operativo, la farmacia deve garantire che i propri sistemi non riproducano né rendano nuovamente visibili dati che l’assistito ha oscurato nel Fascicolo, e che l’oscuramento sia rispettato anche nei report, negli estratti e nelle funzionalità di analisi del gestionale. È inoltre opportuno che l’informativa e la formazione del personale chiariscano che l’esercizio dell’oscuramento da parte del paziente non è sindacabile né deve essere scoraggiato, e che un Fascicolo parzialmente oscurato va trattato con la consapevolezza clinica che la storia terapeutica visibile potrebbe non essere completa.

Il diritto alla cancellazione, nel contesto del dossier farmaceutico, si scontra con le esigenze di documentazione che derivano dagli obblighi legali di conservazione dei dati farmaceutici — la normativa vigente prevede periodi minimi di conservazione delle ricette e dei registri di dispensazione — e con le finalità di tutela della salute pubblica. L’art. 17, par. 3, lett. b) e c) GDPR prevede che il diritto alla cancellazione non si applichi nella misura in cui il trattamento sia necessario per l’adempimento di un obbligo legale o per motivi di interesse pubblico nel settore della sanità pubblica, fornendo una base normativa per il mantenimento di alcune informazioni anche a fronte della richiesta dell’interessato. Nel Fascicolo, del resto, lo strumento che consente all’assistito di governare la circolazione del dato non è la cancellazione ma, di nuovo, l’oscuramento.

4. Profili critici: interoperabilità, Ecosistema dati sanitari, intelligenza artificiale e rischi emergenti

4.1. L’integrazione con il FSE 2.0 e l’Ecosistema dati sanitari

Il PNRR ha destinato risorse significative al potenziamento e alla riforma del FSE, con l’obiettivo di costruire un sistema nazionale di documentazione sanitaria interoperabile che consenta a tutti gli operatori del sistema sanitario nazionale — incluse le farmacie — di accedere in modo controllato alle informazioni cliniche dei pazienti e di alimentare il Fascicolo con i propri contributi documentali.

Con le FAQ del maggio 2026 la questione non è più se il dossier farmaceutico debba essere integrato nel FSE, ma come debba essere governata la sua propagazione verso l’EDS. L’Ecosistema, istituito dal d.m. 31 dicembre 2024, è una componente del FSE alimentata con i dati e i documenti presenti nel Fascicolo — esclusi quelli oscurati — e con quelli resi disponibili dal Sistema Tessera Sanitaria. Esso estrarrà dal FSE le informazioni relative alle prescrizioni e alle erogazioni farmaceutiche e le renderà disponibili, su richiesta, per servizi di analisi ed elaborazione a beneficio di cittadini, professionisti sanitari, Ministero della Salute, Agenas e Regioni, oltre che per finalità di prevenzione, controllo e gestione del sistema sanitario. In ambito di ricerca scientifica medica, biomedica ed epidemiologica, l’EDS potrà mettere a disposizione dati anonimizzati, accessibili esclusivamente al personale autorizzato del Ministero della Salute, di Agenas e delle Regioni o Province autonome.

Su questa architettura restano aperte alcune questioni di rilievo.

Va, innanzitutto, segnalata la questione relativa alla “tenuta” dell’anonimizzazione. La qualificazione come “anonimizzati” dei dataset messi a disposizione per la ricerca è la chiave che sottrae quei trattamenti all’ambito di applicazione del GDPR. Si tratta però di una qualificazione da verificare in concreto: i dati di dispensazione farmaceutica sono ad altissima specificità, poiché combinazioni di principi attivi, dosaggi, frequenze e sequenze temporali possono risultare fortemente identificanti anche in assenza di identificativi diretti, specie per patologie rare o per terapie a bassa prevalenza. Il presidio non può essere la sola rimozione degli identificativi, ma richiede tecniche robuste di generalizzazione, soppressione e controllo del rischio di reidentificazione, oltre a misure organizzative sull’accesso ai dataset. È un punto su cui sarà opportuno un chiarimento tecnico ulteriore.

Il Garante si è poi focalizzato sulla sequenza attuativa, chiarendo che i servizi avanzati dell’EDS saranno attivabili solo dopo la completa attuazione del FSE 2.0. La compliance delle farmacie deve dunque essere costruita in modo incrementale e verificata a ogni avanzamento del percorso attuativo: informative, istruzioni al personale e configurazioni dei gestionali che oggi risultano adeguate potrebbero non esserlo al momento dell’attivazione dei servizi EDS.

Ulteriore profilo di rilievo concerne la catena delle responsabilità. In caso di accesso non autorizzato o di trattamento illecito dei dati farmaceutici confluiti nel FSE e poi nell’EDS, infatti, la catena delle responsabilità si allunga: la farmacia che ha alimentato il Fascicolo, la Regione che gestisce la componente regionale, il Ministero della Salute che gestisce l’infrastruttura nazionale, i fornitori tecnologici coinvolti. Ciascuno risponde nel perimetro del proprio ruolo, il che rende essenziale una documentazione puntuale delle rispettive attribuzioni — e, per la farmacia, la capacità di dimostrare la correttezza del proprio conferimento e la tracciabilità dei propri accessi.

Infine, la questione della dimensione europea. Il Regolamento sullo Spazio Europeo dei Dati Sanitari (EHDS) aggiunge un ulteriore livello, destinato a incidere tanto sull’uso primario quanto sull’uso secondario dei dati sanitari e a imporre un raccordo tra le infrastrutture nazionali e quelle europee. L’EDS, per come è concepito, rappresenta la naturale interfaccia italiana verso questo scenario, e le scelte tecniche che oggi vi vengono compiute — in particolare sulla propagazione dell’oscuramento e sulle metodologie di anonimizzazione — condizioneranno la conformità del sistema nazionale al quadro europeo.

4.2. L’impiego di algoritmi e intelligenza artificiale nel monitoraggio dell’aderenza

Le applicazioni più avanzate di farmacia clinica prevedono l’utilizzo di strumenti di intelligenza artificiale per l’analisi dei pattern di dispensazione, l’identificazione dei pazienti a rischio di scarsa aderenza terapeutica e la generazione di raccomandazioni personalizzate per i farmacisti. Questi strumenti trasformano il dato farmaceutico da semplice informazione di transazione in materia prima di una profilazione attiva del paziente.

È importante precisare la collocazione di questi trattamenti: essi si svolgono, di norma, sui sistemi propri della farmacia o su piattaforme di gruppo, e non sulla sezione farmaceutica del FSE, rispetto alla quale la farmacia non ha titolarità né facoltà di elaborazione ulteriore. Ove alimentati con dati acquisiti in consultazione del Fascicolo, essi configurerebbero un trattamento per finalità ulteriori rispetto a quella di cura, privo di base giuridica autonoma. Si tratta di un discrimine che i DPO devono presidiare con particolare attenzione nella configurazione dei gestionali.

Dal punto di vista del GDPR, l’impiego di algoritmi decisionali solleva la questione dell’applicabilità dell’art. 22, che disciplina il processo decisionale automatizzato inclusa la profilazione. La norma vieta in linea di principio le decisioni basate unicamente sul trattamento automatizzato che producono effetti giuridici o incidono in modo analogo significativamente sulla persona. Nel contesto farmaceutico, una raccomandazione algoritmica che porti il farmacista a modificare il proprio comportamento nei confronti del paziente — ad esempio invitandolo a contattare il medico o a soprassedere alla dispensazione di un farmaco — può configurare un effetto significativo e richiede la presenza di un intervento umano autentico nella catena decisionale.

L’AI Act europeo (Regolamento (UE) 2024/1689), entrato in vigore il 1° agosto 2024 con applicazione progressiva, classifica come sistemi ad alto rischio i sistemi di IA utilizzati nel campo della medicina e della farmacia per assistere o prendere decisioni che incidono sulla salute dei pazienti. I sistemi di IA per il monitoraggio dell’aderenza terapeutica e per l’elaborazione dei dati farmaceutici sono pertanto suscettibili di rientrare in questa categoria, con conseguente applicazione degli obblighi in materia di gestione del rischio, qualità dei dati, trasparenza, accuratezza, robustezza e cybersicurezza, supervisione umana, documentazione tecnica e registrazione nei database europei.

La sovrapposizione tra i requisiti GDPR e quelli dell’AI Act — che il Considerando 10 del medesimo regolamento chiarisce essere complementari e non alternativi — crea per i titolari del trattamento un sistema di compliance duale che richiede una gestione integrata e coordinata, idealmente attraverso un framework comune che copra sia i profili di protezione dei dati sia quelli di sicurezza e conformità dei sistemi di IA.

4.3. La sicurezza informatica del dossier farmaceutico: vulnerabilità e rischi

Il dossier farmaceutico, in quanto archivio di dati sanitari di valore elevato, rappresenta un bersaglio particolarmente attraente per gli attacchi informatici. I ransomware che colpiscono le strutture sanitarie — una delle tipologie di incidente più frequenti e gravi nel settore — possono rendere inaccessibile o compromettere l’integrità dei dati, con effetti potenzialmente gravi sulla continuità delle cure. Il furto di dati farmaceutici può essere utilizzato per finalità di discriminazione assicurativa, ricatto, frode o spionaggio industriale.

La collocazione del dossier farmaceutico nel FSE introduce un profilo di rischio ulteriore e specifico, ossia il rischio di integrità del dato conferito. Un gestionale compromesso può alimentare il Fascicolo con dati errati o manipolati, che si propagano al medico curante, agli altri professionisti e, in prospettiva, all’EDS. Rispetto a questo rischio, i controlli di integrità, la firma e la tracciabilità dei conferimenti, la segregazione delle credenziali di cooperazione applicativa e il monitoraggio delle anomalie di alimentazione assumono un rilievo pari, se non superiore, a quello dei controlli di riservatezza.

L’art. 32 GDPR impone al titolare del trattamento di adottare misure tecniche e organizzative adeguate a garantire un livello di sicurezza appropriato al rischio, tenendo conto dello stato dell’arte, dei costi di implementazione, della natura, dell’oggetto, del contesto e delle finalità del trattamento, nonché del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche. Nel contesto del dossier farmaceutico tali misure comprendono, senza pretesa di esaustività, la cifratura dei dati in transit e at rest, sistemi di autenticazione forte per l’accesso degli operatori, un controllo granulare degli accessi basato sul principio del need to know, registri degli accessi e audit trail conservati e periodicamente verificati, controlli automatici sul rispetto dell’oscuramento, procedure di backup e ripristino testate e piani di risposta agli incidenti.

La violazione dei dati personali deve essere notificata al Garante ai sensi dell’art. 33 GDPR entro 72 ore dal momento in cui il titolare ne viene a conoscenza, ove la violazione sia suscettibile di presentare un rischio per i diritti e le libertà delle persone fisiche. Qualora la violazione sia suscettibile di presentare un rischio elevato, è altresì necessaria la comunicazione agli interessati ai sensi dell’art. 34 GDPR. Le farmacie devono pertanto dotarsi di procedure di data breach management adeguate, che prevedano l’immediata escalation al DPO e ai vertici aziendali, la valutazione del rischio, la predisposizione della notifica e la comunicazione agli interessati. Nel caso di incidenti che coinvolgano l’interfaccia con il Fascicolo, la procedura deve includere anche la tempestiva informazione del titolare competente per il FSE, che potrebbe dover attivare a sua volta i propri obblighi di notifica.

4.4. Il ruolo del DPO nelle strutture farmaceutiche

La nomina del Responsabile della Protezione dei Dati (DPO) è obbligatoria per i soggetti che trattano dati sanitari su larga scala ai sensi dell’art. 37, par. 1, lett. c) GDPR. Le catene e le farmacie che gestiscono programmi strutturati di presa in carico e aderenza per una platea significativa di pazienti rientrano in questa categoria. Anche per le farmacie di medie dimensioni, la complessità del trattamento e la sensibilità dei dati rendono opportuna — anche se non sempre obbligatoria — la nomina di un DPO.

Il DPO delle strutture farmaceutiche deve possedere una conoscenza specialistica non solo della normativa sulla protezione dei dati, ma anche del settore farmaceutico e sanitario, della disciplina del FSE e dell’EDS, delle tecnologie informatiche impiegate nella gestione del dato e dei rischi specifici connessi. Alla luce delle FAQ del maggio 2026, il suo compito prioritario è la corretta perimetrazione dei ruoli: verificare che l’organizzazione non si attribuisca una titolarità che non ha sul Fascicolo, e che al contempo non trascuri quella, piena, che ha sui propri archivi e servizi.

5. Implicazioni operative per DPO e imprese

5.1. La mappatura dei trattamenti e il registro delle attività di trattamento

Il primo adempimento operativo è la mappatura completa dei trattamenti connessi al dato farmaceutico e la loro corretta registrazione nel Registro delle Attività di Trattamento (RAT) di cui all’art. 30 GDPR. Il RAT deve contenere, per ciascun trattamento, le finalità, le categorie di interessati e di dati trattati, le categorie di destinatari, i termini di conservazione e una descrizione generale delle misure di sicurezza adottate.

Alla luce dell’aggiornamento delle FAQ, la mappatura deve essere rivista strutturalmente, distinguendo almeno tre voci. La prima è l’alimentazione del dossier farmaceutico nel FSE, da registrare con indicazione della farmacia quale soggetto alimentatore e della base giuridica normativa. La seconda è la consultazione del FSE per finalità di cura, rispetto alla quale vanno dati evidenza il presupposto del consenso dell’assistito e le misure di tracciamento adottate. La terza, infine, raccoglie i trattamenti propri della farmacia, che vanno articolati per finalità — gestione della dispensazione, servizi di aderenza, telemedicina, farmacovigilanza, ricerca, gestione amministrativa, marketing — ciascuna con la propria base giuridica, le categorie di dati strettamente necessarie e i periodi di conservazione. La mappatura va tenuta aggiornata a ogni modifica rilevante del trattamento, della struttura organizzativa o del quadro attuativo del FSE 2.0.

5.2. La predisposizione delle informative

L’informativa ai sensi degli artt. 13 e 14 GDPR deve essere redatta in modo chiaro, semplice e comprensibile per il paziente, evitando il ricorso a un linguaggio tecnico-giuridico che rende di fatto incomprensibile la comunicazione. Il Garante ha più volte sanzionato titolari che adottavano informative generiche, incomplete o di difficile comprensione.

Le informative in uso presso le farmacie vanno riviste alla luce delle FAQ, con particolare attenzione a quattro profili. Occorre anzitutto distinguere con nettezza alimentazione e consultazione, spiegando che i dati della dispensazione alimentano la sezione farmaceutica del FSE in forza di legge e senza necessità di consenso, e che il consenso è invece richiesto perché i professionisti sanitari possano consultare il Fascicolo. Da ciò discende la necessità di eliminare i consensi impropri: vanno espunti i moduli che richiedono un “consenso al dossier farmaceutico” inteso come consenso all’alimentazione, che oltre a essere superfluo risulta fuorviante. Va poi dato adeguato spazio all’informazione sull’oscuramento, ponendo il paziente in condizione di conoscere il diritto di oscurare singoli documenti o intere categorie di dati, le modalità di esercizio, la revocabilità della scelta e l’esistenza di categorie oscurate per impostazione predefinita. Occorre infine descrivere la propagazione verso l’EDS, rendendo conto del fatto che i dati non oscurati potranno confluire nell’Ecosistema dati sanitari e delle finalità per le quali potranno essere utilizzati, inclusa la messa a disposizione di dataset anonimizzati per la ricerca.

Restano naturalmente necessarie le indicazioni ordinarie: finalità e basi giuridiche dei trattamenti propri, soggetti autorizzati all’accesso, periodi di conservazione, diritti dell’interessato e modalità di esercizio — con chiara indicazione di quali istanze vadano rivolte alla farmacia e quali ai titolari del FSE —, contatti del DPO e diritto di proporre reclamo al Garante.

5.3. La gestione del consenso e del registro dei consensi

Laddove il consenso sia richiesto — per la consultazione del Fascicolo o come base giuridica per trattamenti propri ulteriori rispetto alla cura — la farmacia deve predisporre un sistema di raccolta e gestione che ne garantisca la tracciabilità, la revocabilità in qualsiasi momento e la granularità rispetto alle diverse finalità. Il consenso deve essere distinto per ciascuna finalità e non può essere accorpato in un’unica dichiarazione onnicomprensiva che impedisca al paziente di distinguere le proprie scelte.

Il registro dei consensi deve consentire la verifica immediata, per ciascun paziente, delle finalità per le quali il consenso è stato prestato o revocato, della data e del canale di raccolta. Va inoltre presidiato — sul piano sia tecnico sia formativo — il principio, esplicitato dalle FAQ, secondo cui il diniego o la revoca del consenso alla consultazione non può in alcun modo pregiudicare l’erogazione della prestazione sanitaria: il gestionale non deve consentire di condizionare il servizio alla prestazione del consenso, e il personale deve essere istruito in tal senso.

5.4. La configurazione dei sistemi gestionali

Le FAQ pongono in capo alla farmacia un onere di configurazione dei propri sistemi che merita una trattazione autonoma. Il gestionale deve anzitutto impedire la consultazione del FSE in assenza di consenso valido e registrare ogni accesso in modo tracciabile e riconducibile all’operatore, applicando profili autorizzativi differenziati coerenti con il ruolo del singolo addetto ed evitando il ricorso a credenziali condivise. Deve inoltre rispettare integralmente l’oscuramento, evitando che dati oscurati nel Fascicolo siano visualizzati, esportati o riprodotti in report, estratti o cruscotti, e deve mantenere separati sul piano logico i dati acquisiti in consultazione del FSE — utilizzabili soltanto per la finalità di cura in atto — da quelli trattati per finalità proprie della farmacia. Sul versante opposto del flusso, deve infine garantire l’integrità e la tracciabilità dei conferimenti al Fascicolo, con controlli sulle anomalie di alimentazione.

Questi requisiti vanno tradotti in specifiche contrattuali verso il fornitore del gestionale e verificati in sede di collaudo e di audit periodico.

5.5. I contratti con i fornitori tecnologici

La farmacia che utilizza piattaforme di terzi deve verificare con attenzione che il contratto rispetti i requisiti dell’art. 28 GDPR. In particolare, il contratto deve prevedere che il responsabile del trattamento tratti i dati solo su istruzione documentata del titolare; garantisca che le persone autorizzate abbiano assunto obblighi di riservatezza; adotti tutte le misure di sicurezza richieste dall’art. 32 GDPR; rispetti le condizioni per il ricorso a sub-responsabili; assista il titolare nell’adempimento degli obblighi relativi alla sicurezza, alla notifica delle violazioni e alla conduzione delle DPIA; cancelli o restituisca tutti i dati personali al termine del contratto; e metta a disposizione del titolare tutte le informazioni necessarie a dimostrare il rispetto degli obblighi.

Alla luce del nuovo assetto, è opportuno integrare i contratti con clausole specifiche sul rispetto tecnico dell’oscuramento, sull’integrità dei conferimenti al FSE, sull’aggiornamento tempestivo del software a ogni evoluzione delle regole tecniche del FSE 2.0 e dell’EDS, e sugli obblighi di informazione reciproca in caso di incidenti che coinvolgano l’interfaccia con il Fascicolo.

La verifica della conformità dei fornitori non si esaurisce al momento della stipula, ma richiede audit periodici e la valutazione delle certificazioni di sicurezza (ISO/IEC 27001, ISO/IEC 27701, SOC 2 e standard equivalenti). Nel contesto NIS2, le farmacie che rientrano nell’ambito di applicazione della direttiva devono altresì garantire la sicurezza della catena di approvvigionamento digitale, il che implica una due diligence approfondita sui fornitori.

5.6. I piani di risposta agli incidenti e la gestione dei data breach

La farmacia deve dotarsi di un piano di risposta agli incidenti di sicurezza che preveda procedure chiare e testate per l’identificazione, il contenimento, la valutazione e la notifica delle violazioni dei dati personali. Il piano deve definire ruoli e responsabilità dei diversi attori coinvolti (DPO, responsabile IT, direzione, legale), i canali di comunicazione interni ed esterni e le tempistiche di intervento.

Particolare attenzione va prestata alla notifica al Garante entro 72 ore: la farmacia deve essere in grado di rilevare la violazione, valutarne la gravità e predisporre la notifica in tempi molto brevi, il che presuppone un sistema di monitoraggio degli eventi di sicurezza adeguato e procedure di escalation ben definite. La notifica tardiva è sanzionata autonomamente, indipendentemente dalla valutazione della violazione in sé. Ove l’incidente coinvolga l’interfaccia con il FSE, il piano deve prevedere l’informazione tempestiva del titolare competente e, per i soggetti in perimetro NIS2, la notifica all’ACN secondo le tempistiche proprie della direttiva.

6. Conclusioni

Il dossier farmaceutico rappresenta uno degli snodi più delicati e promettenti dell’evoluzione del sistema sanitario italiano verso modelli di cura integrata, continuità terapeutica e prevenzione basata sui dati. La sua capacità di ridurre gli errori farmacologici, migliorare l’aderenza terapeutica e valorizzare il ruolo professionale del farmacista lo rende uno strumento di indubbia utilità clinica e di salute pubblica.

L’aggiornamento delle FAQ del 21 maggio 2026 ha dato a questo strumento una collocazione sistematica chiara: il dossier farmaceutico è una sezione del Fascicolo sanitario elettronico, alimentata dalla farmacia all’atto della dispensazione e destinata a confluire tra i servizi dell’Ecosistema dati sanitari. È un chiarimento di grande valore, che dissipa una lunga ambiguità e riconosce alla farmacia un ruolo attivo nella rete sanitaria digitale. Ma è anche un chiarimento che ridistribuisce gli oneri di compliance in modo diverso da quanto molte organizzazioni avevano assunto: meno titolarità sul dato del Fascicolo, più responsabilità sulla qualità, sull’integrità e sulla correttezza del conferimento; meno spazio per il consenso, più centralità per l’oscuramento.

Il messaggio operativo che ne deriva è duplice. Da un lato, occorre correggere gli assetti costruiti sul presupposto di una titolarità piena della farmacia sul dossier farmaceutico: informative da riscrivere, consensi impropri da eliminare, registri dei trattamenti da rivedere, istanze degli interessati da instradare correttamente. Dall’altro, occorre presidiare con rigore tecnico ciò che la farmacia continua a governare in proprio: i sistemi gestionali, i programmi di aderenza, i servizi della farmacia dei servizi, le piattaforme di analisi. È in questo secondo perimetro che si concentrano oggi i rischi maggiori di non conformità.

Le questioni aperte restano numerose e di rilevanza crescente. Viene anzitutto in considerazione la sequenza attuativa, poiché i servizi avanzati dell’EDS saranno attivabili solo dopo il completamento del FSE 2.0, tuttora in corso: la compliance va dunque costruita come processo, non come adempimento una tantum, con verifiche a ogni avanzamento del percorso.

Vi è poi il tema della tenuta dell’anonimizzazione dei dataset destinati alla ricerca. I dati di dispensazione farmaceutica hanno un potenziale identificativo elevato, e la qualificazione di un dataset come anonimo — che ne determina l’uscita dall’ambito del GDPR — deve poggiare su metodologie robuste e verificabili, non su una semplice rimozione degli identificativi diretti. È un tema che meriterebbe un approfondimento tecnico dedicato da parte delle autorità competenti.

Strettamente connessa è la questione dell’effettività dell’oscuramento. La scelta del paziente di rendere invisibili determinati dati deve essere rispettata lungo tutta la catena — consultazione, alimentazione dell’EDS, elaborazioni e dataset di ricerca — e la sua implementazione tecnica è il presidio su cui si regge la fiducia dell’assistito nell’intero sistema. Un difetto a monte si moltiplica a valle.

Su un piano parzialmente diverso si colloca l’introduzione di strumenti di intelligenza artificiale nell’analisi dei dati farmaceutici, che richiede un’analisi sistematica dell’impatto di tali strumenti sui diritti dei pazienti, con particolare riguardo alla trasparenza, alla spiegabilità delle decisioni algoritmiche e alla supervisione umana autentica. L’applicazione progressiva dell’AI Act imporrà alle farmacie e ai loro fornitori un investimento significativo in governance algoritmica, documentazione tecnica e formazione.

Non meno urgente è il tema della sicurezza: la crescente esposizione delle strutture sanitarie agli attacchi informatici rende improcrastinabile un salto di qualità nella gestione della cybersicurezza delle infrastrutture farmaceutiche, in linea con gli obblighi NIS2. La collocazione del dossier farmaceutico all’interno di un’infrastruttura nazionale rende il gestionale di farmacia un componente critico di una catena più ampia, con una responsabilità corrispondentemente maggiore.

Da ultimo, la dimensione europea. Il Regolamento sullo Spazio Europeo dei Dati Sanitari (EHDS) aggiungerà un livello ulteriore di regole sull’uso primario e secondario dei dati sanitari, rispetto al quale l’EDS costituisce la naturale interfaccia italiana, e le scelte tecniche che oggi vengono compiute sull’architettura nazionale condizioneranno la conformità del sistema al quadro europeo.

Per i DPO e i giuristi d’impresa che operano nel settore farmaceutico e sanitario, il messaggio conclusivo è che la compliance in materia di dossier farmaceutico non può essere gestita come un adempimento formale, ma richiede un approccio integrato, sostanziale e continuativo, che tenga insieme la dimensione giuridica, quella tecnologica e quella organizzativa. La prospettiva più interessante, e forse più urgente, resta quella di un dialogo strutturato tra il legislatore, il Garante, l’ACN, le associazioni di categoria delle farmacie, i fornitori di software gestionale e i rappresentanti dei pazienti per la definizione di standard comuni di governance, che consentano di valorizzare le enormi potenzialità cliniche di questo strumento senza sacrificare i diritti fondamentali dei cittadini che ne sono i protagonisti.

L'articolo Dossier farmaceutico e protezione dei dati: governance, rischi e compliance GDPR proviene da 01magazine.

Il Regolamento (UE) 2024/1689 del Parlamento europeo e del Consiglio, pubblicato nella Gazzetta Ufficiale dell’Unione Europea il 12 luglio 2024 e comunemente noto come “AI Act”, ha introdotto un sistema stratificato di obblighi che si applicano secondo una scansione temporale precisa, articolata su più finestre di vigenza. In questo contesto, la proposta di regolamento denominata “Digital Omnibus” — formalmente il pacchetto di modifiche avanzato dalla Commissione europea nel corso del 2025 con l’obiettivo dichiarato di semplificare e razionalizzare gli oneri derivanti da alcune normative digitali — ha alimentato, nei circuiti professionali e nella stampa di settore, l’impressione che le imprese potessero beneficiare di un rinvio generalizzato degli obblighi derivanti dall’AI Act.

Tale impressione si rivela, ad un esame attento del testo normativo, parzialmente infondata e, per certi profili, potenzialmente dannosa. Il rinvio prospettato nel Digital Omnibus riguarda specificamente una categoria di obblighi — quelli relativi ai sistemi di IA ad alto rischio ai sensi dell’Allegato III del Regolamento — e non tocca in alcun modo l’obbligo di garantire un adeguato livello di “alfabetizzazione in materia di IA” (“AI literacy”), già pienamente vigente a partire dal 2 febbraio 2025 ai sensi dell’articolo 4 del Regolamento medesimo.

Il presente contributo si propone di chiarire la portata dell’obbligo di formazione già operativo, di distinguerlo dagli obblighi la cui applicazione è oggetto di discussione nel quadro del Digital Omnibus, di analizzare i profili di responsabilità connessi all’inadempimento e di fornire indicazioni operative per DPO, responsabili della compliance e giuristi d’impresa chiamati a strutturare programmi di conformità adeguati.

Il quadro normativo di riferimento

Il Regolamento (UE) 2024/1689: struttura e scansione temporale

Il Regolamento (UE) 2024/1689 — l’AI Act — è entrato in vigore il 1° agosto 2024. Il legislatore europeo ha scelto un approccio di “phased implementation”, vale a dire un’entrata in applicazione progressiva degli obblighi, articolata secondo la classificazione dei sistemi di IA in fasce di rischio.

La struttura temporale prevista dall’articolo 113 del Regolamento è la seguente. A partire dal 2 febbraio 2025 — decorsi sei mesi dall’entrata in vigore — sono divenuti applicabili i divieti relativi alle pratiche di IA inaccettabili (Capo II, articolo 5) e, per quanto qui interessa in via principale, l’articolo 4 sull’alfabetizzazione in materia di IA. A partire dal 2 agosto 2025 — decorsi dodici mesi — divengono applicabili le disposizioni relative ai modelli di IA per uso generale (GPAI), di cui al Capo V. A partire dal 2 agosto 2026 — decorsi ventiquattro mesi — entreranno in applicazione le disposizioni relative ai sistemi di IA ad alto rischio elencati nell’Allegato III. Ulteriori proroghe specifiche riguardano i sistemi di IA ad alto rischio integrati in prodotti soggetti a legislazione di armonizzazione dell’Unione (Allegato I), che avranno tempo sino al 2 agosto 2027.

È in questo contesto che si inserisce la discussione sul Digital Omnibus e sulla sua reale portata.

Il Digital Omnibus: natura, obiettivi e limiti dell’intervento proposto

Il cosiddetto “Digital Omnibus” — nella sua denominazione tecnica, l’Omnibus package proposto dalla Commissione europea nell’ambito della strategia di semplificazione normativa — persegue l’obiettivo di ridurre gli oneri amministrativi gravanti sulle imprese in relazione a una serie di normative digitali, tra cui l’AI Act, la Direttiva NIS2, il Data Governance Act e altri strumenti del “pacchetto digitale” europeo.

Con riferimento specifico all’AI Act, la proposta mira principalmente a prorogare o modulare gli obblighi relativi ai sistemi di IA ad alto rischio di cui all’Allegato III — vale a dire i sistemi che, pur non essendo integrati in prodotti fisici regolati da altra normativa europea, operano in settori sensibili come l’occupazione, l’istruzione, i servizi pubblici essenziali, l’applicazione della legge e la gestione dei processi migratori. Si tratta di una categoria rilevante, ma per l’appunto circoscritta.

Non si ha evidenza, sulla base dei testi ufficiali disponibili e delle comunicazioni della Commissione europea, che il Digital Omnibus incida sull’articolo 4 del Regolamento né sulle disposizioni del Capo II già in vigore dal 2 febbraio 2025. L’obbligo di alfabetizzazione in materia di IA rimane quindi pienamente operativo, indipendentemente dagli sviluppi del processo legislativo legato al pacchetto di semplificazione.

L’articolo 4 del Regolamento (UE) 2024/1689: il contenuto dell’obbligo di AI literacy

L’articolo 4 del Regolamento, rubricato “Alfabetizzazione in materia di IA”, costituisce la disposizione cardine ai fini del presente contributo. Il testo della norma stabilisce che i fornitori e i deployer di sistemi di IA adottano misure per garantire, nella misura del possibile, un sufficiente livello di alfabetizzazione in materia di IA da parte del loro personale e di altre persone che, a loro nome, si occupano del funzionamento e dell’uso di sistemi di IA.

In termini più pragmatici, l’articolo 4 richiede a tutti i soggetti che rientrano nelle definizioni di “fornitore” (“provider”) e di “deployer” — vale a dire coloro che mettono sul mercato sistemi di IA e coloro che li utilizzano nell’ambito della propria attività professionale — di assicurare che le persone coinvolte nell’utilizzo o nella gestione di tali sistemi dispongano di competenze adeguate per comprenderli, valutarli criticamente e utilizzarli in modo consapevole.

Va detto che la norma non definisce uno standard rigido e uniforme di formazione, né prescrive uno specifico numero di ore, un contenuto fisso o una certificazione obbligatoria. Essa adotta invece un approccio flessibile e proporzionale: le competenze richieste devono essere commisurate al livello tecnico, alle esperienze e al contesto in cui le persone interessate operano, tenendo conto anche del livello di rischio del sistema di IA utilizzato. Il richiamo alla proporzionalità non deve tuttavia essere letto come una clausola di esonero: l’assenza di qualsiasi misura concreta sarebbe difficilmente difendibile in sede di vigilanza o di ispezione.

Il considerando 20 del Regolamento offre ulteriori elementi interpretativi, chiarendo che l’alfabetizzazione in materia di IA dovrebbe consentire alle persone di fare un uso informato dei sistemi di IA, di comprenderne le capacità e i limiti, nonché di riconoscere i potenziali impatti — positivi e negativi — che tali sistemi possono avere a livello individuale, collettivo e sociale. Trattasi di una competenza trasversale che non si esaurisce nel know-how tecnico degli sviluppatori, ma che si estende a tutti coloro che, in qualsiasi ruolo, interagiscono con sistemi di IA.

Il rapporto con il GDPR e la disciplina sulla protezione dei dati personali

Il collegamento tra l’obbligo di AI literacy e la disciplina sulla protezione dei dati personali è diretto e merita una trattazione specifica, anche perché è proprio nell’orbita del GDPR che la maggior parte dei DPO si trova ad operare in via quotidiana.

I sistemi di IA trattano, nella quasi totalità dei casi, dati personali — nella fase di addestramento, in quella di validazione o in quella di deployment operativo. Di conseguenza, i deployer di sistemi di IA che trattano dati personali sono simultaneamente titolari del trattamento ai sensi dell’articolo 4, paragrafo 7, del Regolamento (UE) 2016/679 (GDPR) e deployer ai sensi dell’articolo 3, paragrafo 4, dell’AI Act. Questa sovrapposizione soggettiva determina un cumulo di obblighi che il DPO è chiamato a presidiare in modo coordinato.

In particolare, l’obbligo di formazione del personale che tratta dati personali — già previsto dall’articolo 29 e dall’articolo 32, paragrafo 4, del GDPR — si sovrappone e si integra con l’obbligo di AI literacy ai sensi dell’articolo 4 dell’AI Act. Il personale che utilizza sistemi di IA che trattano dati personali deve essere formato sia sulle regole del GDPR applicabili al trattamento specifico, sia sulle caratteristiche, i limiti e i rischi del sistema di IA utilizzato. Si tratta di piani distinti ma complementari, e una formazione efficace dovrà necessariamente coprire entrambi.

Oltre a ciò, la valutazione d’impatto sulla protezione dei dati (DPIA) ai sensi dell’articolo 35 GDPR rimane obbligatoria — e particolarmente rilevante — per i trattamenti svolti mediante sistemi di IA che presentano rischi elevati per i diritti e le libertà degli interessati. Il Garante per la protezione dei dati personali ha già fornito indicazioni in materia di IA nelle proprie comunicazioni istituzionali, e il tema è oggetto di attenzione crescente da parte dell’EDPB, che si è pronunciato sull’intersezione tra trattamento di dati personali e utilizzo di sistemi di IA con il Parere 28/2024 su taluni aspetti di protezione dei dati connessi al trattamento di dati personali nel contesto dei modelli di IA con particolare riguardo all’anonimizzazione rigorosa, le basi giuridiche e la gestione dei dati illeciti in fase di addestramento.

La disciplina NIS2 e il profilo della sicurezza dei sistemi di IA

Va considerato, sebbene possa apparire marginale rispetto al tema centrale, che la Direttiva (UE) 2022/2555 (NIS2), recepita in Italia con il Decreto Legislativo 4 settembre 2024, n. 138, introduce obblighi rilevanti anche con riferimento alla gestione del rischio derivante dall’utilizzo di sistemi di IA nei contesti delle infrastrutture critiche e dei soggetti essenziali e importanti. L’articolo 21 della Direttiva NIS2 — trasposto nell’ordinamento italiano — richiede l’adozione di misure tecniche e organizzative appropriate per la gestione dei rischi per la sicurezza dei sistemi informativi e di rete, tra le quali la formazione del personale occupa una posizione esplicita.

In termini più concreti, un’impresa che rientra nel perimetro NIS2 e che utilizza sistemi di IA nei propri processi operativi deve coniugare gli obblighi di formazione derivanti dall’AI Act con quelli derivanti dalla NIS2, costruendo un piano formativo integrato che copra sia la comprensione delle caratteristiche e dei rischi propri dei sistemi di IA (AI literacy), sia le procedure di gestione degli incidenti di sicurezza, le misure di resilienza e le politiche di continuità operativa.

La distinzione tra obblighi già vigenti e obblighi differiti: un’analisi sistematica

La confusione che si è generata nella comunicazione pubblica e anche nella prassi aziendale deriva principalmente dall’assenza di una chiara distinzione tra le diverse categorie di obblighi introdotte dall’AI Act e dai diversi tempi di applicazione previsti dall’articolo 113 del Regolamento.

Appare utile, pertanto, procedere a una ricostruzione sistematica che consenta di distinguere con precisione ciò che è già obbligatorio da ciò che è oggetto di potenziale rinvio.

Gli obblighi già pienamente vigenti a partire dal 2 febbraio 2025 comprendono, innanzitutto, i divieti assoluti relativi alle pratiche di IA inaccettabili. L’articolo 5 del Regolamento vieta, tra l’altro, i sistemi di IA che impiegano tecniche subliminali in grado di distorcere il comportamento umano, i sistemi di scoring sociale generalizzato, i sistemi di identificazione biometrica remota in tempo reale negli spazi pubblici al di fuori dei casi tassativamente previsti. Questi divieti sono immediatamente operativi e la loro violazione espone a sanzioni tra le più severe previste dal Regolamento.

L’obbligo di AI literacy di cui all’articolo 4, come si è detto, è anch’esso già in vigore dal 2 febbraio 2025. Non è quindi corretto — e potenzialmente foriero di responsabilità — l’atteggiamento di chi ritiene di poter attendere l’esito del percorso legislativo del Digital Omnibus prima di avviare qualsiasi iniziativa formativa.

Gli obblighi relativi ai modelli di IA per uso generale (GPAI) — in particolare gli obblighi di trasparenza, di documentazione tecnica e, per i modelli con rischio sistemico, di valutazione degli impatti e di adozione di misure di mitigazione — sono pienamente applicabili a partire dal 2 agosto 2025. Su questo fronte, il Digital Omnibus potrebbe portare alcune modifiche, ma alla data di redazione del presente contributo il processo è ancora in corso e non si ha evidenza di modifiche definitivamente adottate.

Gli obblighi relativi ai sistemi di IA ad alto rischio di cui all’Allegato III — i quali includono, tra gli altri, i sistemi utilizzati nel reclutamento e nella selezione del personale, nella valutazione delle prestazioni dei lavoratori, nell’accesso a servizi pubblici essenziali, nella gestione dei processi migratori — diventeranno applicabili a partire dal 2 agosto 2026. È su questa categoria che il Digital Omnibus intende operare, prospettando un ulteriore differimento o una modulazione degli obblighi. Tuttavia, anche in questo caso, si ritiene opportuno non attendere l’esito del processo legislativo per avviare un’analisi interna volta a mappare i sistemi di IA utilizzati dall’organizzazione e a valutarne la classificazione.

L’obbligo di AI literacy nel dettaglio: chi è obbligato, nei confronti di chi e con quale contenuto

I soggetti obbligati: provider e deployer

L’articolo 4 dell’AI Act si rivolge a due categorie di soggetti: i “fornitori” (“providers”) e i “deployer”. Le definizioni sono contenute nell’articolo 3 del Regolamento.

Il “fornitore” è il soggetto — persona fisica o giuridica, autorità pubblica, agenzia o altro organismo — che sviluppa un sistema di IA o che fa sviluppare un sistema di IA e lo immette sul mercato dell’Unione o lo mette in servizio con il proprio nome o marchio, a titolo oneroso o gratuito. In termini più pragmatici, il fornitore è chi produce o fa produrre il sistema di IA e lo commercializza o distribuisce.

Il “deployer” è il soggetto — persona fisica o giuridica, autorità pubblica, agenzia o altro organismo — che utilizza un sistema di IA sotto la propria responsabilità, salvo il caso in cui tale sistema sia utilizzato nel corso di un’attività personale non professionale. Il deployer è dunque l’impresa, l’ente, la pubblica amministrazione che adotta un sistema di IA sviluppato da terzi e lo integra nei propri processi operativi, decisionali o di servizio.

Va detto che la grande maggioranza delle imprese italiane — e, più in generale, delle organizzazioni di medie e grandi dimensioni che stanno integrando soluzioni di IA nelle proprie operazioni — si trova nella posizione di deployer nei confronti di sistemi sviluppati da fornitori terzi (tipicamente grandi player tecnologici statunitensi o europei). Questa qualificazione non le esonera dall’obbligo di AI literacy: al contrario, l’obbligo si impone con pienezza in ragione del fatto che è precisamente il deployer a dover garantire che il proprio personale utilizzi il sistema in modo consapevole e informato.

I destinatari della formazione

L’obbligo di AI literacy non si rivolge esclusivamente agli specialisti tecnici o agli addetti IT. L’articolo 4 fa riferimento al “personale” del fornitore o del deployer e alle “altre persone che, a loro nome, si occupano del funzionamento e dell’uso di sistemi di IA”. La formulazione è volutamente ampia e comprende, in astratto, qualsiasi soggetto che nella propria attività professionale interagisca con un sistema di IA — sia esso un responsabile delle risorse umane che utilizza un software di selezione del personale basato su IA, un medico che consulta un sistema di supporto diagnostico, un operatore di call center che lavora con un sistema di risposta automatizzata, o un dirigente che utilizza strumenti di analisi predittiva per le proprie decisioni strategiche.

La proporzionalità prevista dall’articolo 4 — l’obbligo si applica “nella misura del possibile” e tenuto conto del “livello tecnico, delle esperienze e del contesto” — introduce una differenziazione dei livelli formativi: non si richiede che tutti i dipendenti diventino esperti di machine learning, ma che ciascuno comprenda le caratteristiche del sistema che utilizza, i suoi limiti, i rischi connessi al suo utilizzo e le procedure da seguire in caso di anomalie o di output inattesi.

Il contenuto minimo della formazione

Non si ha evidenza, alla data di redazione del presente contributo, che la Commissione europea o gli organismi nazionali di supervisione abbiano adottato linee guida vincolanti che definiscano un contenuto minimo standardizzato per i programmi di AI literacy. L’ENISA — Agenzia dell’Unione europea per la sicurezza informatica — ha pubblicato materiali di riferimento sul tema, e l’AI Office — istituito in seno alla Commissione europea come organo di vigilanza centralizzata per i GPAI e di coordinamento generale — ha avviato attività di elaborazione di orientamenti interpretativi.

In assenza di standard vincolanti, si ritiene che un programma di AI literacy adeguato — e documentabile ai fini di una futura verifica di conformità — debba coprire, con un livello di approfondimento commisurato al ruolo e al rischio, almeno i seguenti elementi: la natura e il funzionamento di base dei sistemi di IA utilizzati dall’organizzazione; le capacità e i limiti di tali sistemi, inclusa la tendenza a produrre output errati o fuorvianti (c.d. “allucinazioni” nei sistemi di IA generativa); i rischi specifici connessi all’uso del sistema nel contesto operativo dell’organizzazione; le responsabilità del deployer e del singolo utilizzatore in caso di danno causato dall’utilizzo del sistema; le procedure interne applicabili in caso di output anomali, incidenti o malfunzionamenti; i diritti degli interessati e le norme applicabili in materia di protezione dei dati personali, ove il sistema tratti dati personali.

Profili di responsabilità e rischi di inadempimento

Il regime sanzionatorio dell’AI Act

L’AI Act prevede un sistema sanzionatorio articolato e significativamente severo, descritto agli articoli 99 e seguenti del Regolamento. La violazione dei divieti di cui all’articolo 5 (pratiche di IA inaccettabili) è punita con sanzioni amministrative fino a 35.000.000 euro o, se superiore, fino al 7% del fatturato mondiale annuo totale dell’esercizio precedente. La violazione degli obblighi elencati dall’articolo 99, paragrafo 4, è punita con sanzioni fino a 15.000.000 euro o, se superiore, fino al 3% del fatturato mondiale annuo totale dell’esercizio precedente; l’articolo 4 non figura tra le disposizioni per le quali il Regolamento fissa massimali specifici, sicché la sanzione dell’inadempimento all’obbligo di alfabetizzazione resta rimessa al regime nazionale di cui all’articolo 99, paragrafo 1.

Va detto che l’applicazione di queste sanzioni dipende dall’attivazione del sistema di supervisione nazionale, che in Italia è alquanto articolato e, a tratti, macchinoso, coinvolgendo l’ACN che ha in capo il potere ispettivo e l’autorità sanzionatoria per violazioni generali del Regolamento, il Garante per la protezione dei dati personali che emana direttamente le sanzioni quando la violazione dell’AI Act coinvolge contesti specificamente legati ai diritti fondamentali, alle attività di polizia (law enforcement) e alla gestione delle frontiere e della migrazione; le Autorità di Settore (Banca d’Italia, CONSOB, IVASS) se la violazione dell’AI Act avviene nell’utilizzo di sistemi di intelligenza artificiale integrati nei servizi finanziari, bancari o assicurativi.

Anche il regime sanzionatorio si applicherà con progressività analoga a quella dell’entrata in applicazione degli obblighi sostanziali. Tuttavia, la futura applicabilità delle sanzioni non deve indurre a sottovalutare il rischio presente: l’inadempimento all’obbligo di AI literacy è già oggi configurabile, e l’avvio di un sistema di vigilanza strutturato comporterà la valutazione di comportamenti tenuti nel periodo precedente.

Il profilo della responsabilità civile

Oltre al profilo sanzionatorio amministrativo, l’inadempimento all’obbligo di formazione del personale espone le organizzazioni a rischi di responsabilità civile, sia nei confronti dei terzi danneggiati dall’utilizzo di sistemi di IA da parte di personale non adeguatamente formato, sia nei confronti dei lavoratori stessi, ove l’utilizzo di sistemi di IA in assenza di formazione adeguata abbia causato danni alla loro salute, sicurezza o situazione professionale.

La proposta di Direttiva sulla responsabilità per danni causati dall’IA (AI Liability Directive), il cui ritiro è stato annunciato dalla Commissione europea nel programma di lavoro per il 2025, mirava a facilitare le azioni risarcitorie dei soggetti danneggiati da sistemi di IA, anche attraverso meccanismi di presunzione di nesso causale in presenza di determinate condizioni. [Nota redazionale: verificare lo stato della proposta di AI Liability Directive alla data di pubblicazione.] L’assenza di una formazione documentata del personale potrebbe costituire, in questo quadro, un elemento rilevante ai fini della valutazione della colpa del deployer.

Il rapporto con la responsabilità del DPO

Il DPO — figura prevista dagli articoli 37-39 del GDPR e la cui nomina è obbligatoria in determinate categorie di titolari e responsabili del trattamento — non è direttamente responsabile degli adempimenti sostanziali, che ricadono sul titolare del trattamento. Tuttavia, il DPO è tenuto, ai sensi dell’articolo 39 GDPR, a sorvegliare l’osservanza del Regolamento, a fornire consulenza in merito alle valutazioni d’impatto e a fare da punto di contatto con l’autorità di controllo.

In termini più pragmatici, il DPO che non abbia segnalato al titolare del trattamento la necessità di adottare misure di AI literacy — in presenza di sistemi di IA che trattano dati personali, per i quali l’obbligo formativo risulta dal combinato disposto degli articoli 29 e 32 GDPR e dell’articolo 4 dell’AI Act — potrebbe essere ritenuto inadempiente rispetto ai propri compiti di consulenza e sorveglianza. Si ritiene, pertanto, che il DPO abbia non soltanto l’interesse ma anche il dovere professionale di farsi promotore interno di programmi di AI literacy adeguati.

Implicazioni pratiche per l’analisi dei contratti con i fornitori di sistemi di IA

Un profilo spesso sottovalutato nella discussione sull’AI literacy riguarda le implicazioni contrattuali del rapporto tra deployer e provider. L’articolo 4 obbliga sia il fornitore che il deployer ad adottare misure di formazione, ma nella pratica — come si è detto — la maggior parte delle imprese si trova nella posizione di deployer rispetto a sistemi sviluppati da terzi.

In questo contesto, i contratti di fornitura di sistemi di IA — che si tratti di licenze software, di contratti SaaS o di accordi di integrazione di API — dovrebbero prevedere clausole specifiche che regolino la distribuzione degli obblighi di formazione tra le parti. In particolare, si ritiene opportuno che il contratto specifichi quali informazioni il fornitore è tenuto a mettere a disposizione del deployer in merito alle caratteristiche, ai limiti e ai rischi del sistema — informazioni che costituiscono il presupposto necessario perché il deployer possa costruire un programma di formazione adeguato per il proprio personale.

Oltre a ciò, i contratti dovrebbero prevedere meccanismi di aggiornamento delle informazioni in caso di modifiche rilevanti al sistema, nonché responsabilità specifiche in caso di danni causati da un utilizzo del sistema difforme dalle istruzioni fornite dal provider. Questi elementi contrattuali, attualmente spesso assenti o generici nei contratti standard dei grandi fornitori di IA, acquistano rilevanza sia ai fini della compliance all’AI Act sia ai fini dell’eventuale ripartizione della responsabilità civile.

Sezione operativa: adempimenti concreti per DPO e imprese

Di seguito si riportano gli adempimenti principali che le organizzazioni — con particolare attenzione al ruolo del DPO e del responsabile della compliance — devono avere già avviato o devono avviare con urgenza, alla luce dell’entrata in applicazione dell’articolo 4 dell’AI Act il 2 febbraio 2025.

La mappatura dei sistemi di IA in uso: condurre un inventario dei sistemi di IA attualmente utilizzati nell’organizzazione — inclusi i sistemi SaaS con componenti di IA incorporate, i chatbot, i sistemi di analisi predittiva, i motori di raccomandazione, i sistemi di scoring e qualsiasi altro strumento che risponda alla definizione di “sistema di IA” ai sensi dell’articolo 3, paragrafo 1, dell’AI Act. L’inventario deve identificare per ciascun sistema il fornitore, il contesto d’uso, le categorie di dati trattati e il personale coinvolto nell’utilizzo.

La classificazione del rischio dei sistemi censiti: per ciascun sistema identificato, procedere a una prima classificazione del livello di rischio secondo la tassonomia dell’AI Act — pratiche vietate, alto rischio, rischio limitato, rischio minimo. La classificazione richiede un’analisi del contesto d’uso: un sistema di valutazione delle prestazioni dei dipendenti, ad esempio, rientra tra i sistemi ad alto rischio ai sensi dell’Allegato III, punto 4, lettera b), dell’AI Act. Questa analisi è preliminare rispetto alla definizione del programma formativo, poiché il livello di rischio determina il livello di approfondimento richiesto dalla formazione.

La mappatura del personale destinatario della formazione: identificare, per ciascun sistema di IA censito, il personale che lo utilizza o ne supervisiona il funzionamento. La mappatura deve tenere conto delle diverse categorie di utenti — utenti operativi, supervisori, responsabili delle decisioni basate sull’output del sistema — e deve essere aggiornata in caso di variazioni organizzative o di introduzione di nuovi sistemi.

La progettazione del programma di AI literacy: sulla base delle analisi precedenti, progettare un programma formativo differenziato per livelli — che preveda almeno un modulo generale di sensibilizzazione per tutto il personale che interagisce con sistemi di IA, moduli approfonditi per gli utilizzatori di sistemi ad alto rischio e moduli specialistici per i referenti tecnici e i responsabili della compliance. Il programma deve essere documentato, con l’indicazione degli obiettivi formativi, dei contenuti, delle modalità di erogazione e delle modalità di verifica dell’apprendimento.

L’erogazione e la documentazione della formazione: procedere all’erogazione del programma formativo e documentarne l’avvenuta esecuzione — con registrazione dei partecipanti, delle date, dei contenuti erogati e degli eventuali strumenti di valutazione dell’apprendimento. La documentazione costituisce l’evidenza primaria di conformità all’articolo 4 dell’AI Act ed è destinata a essere prodotta in caso di verifica da parte dell’autorità di supervisione.

L’aggiornamento periodico del programma formativo: prevedere meccanismi di aggiornamento del programma formativo in corrispondenza di modifiche rilevanti ai sistemi di IA utilizzati, di variazioni normative, di incidenti o anomalie che abbiano evidenziato carenze nelle competenze del personale, o di variazioni organizzative che comportino il coinvolgimento di nuovo personale nell’utilizzo dei sistemi. La frequenza dell’aggiornamento dovrebbe essere stabilita nella documentazione del programma.

La revisione dei contratti con i fornitori di sistemi di IA: procedere a una revisione delle condizioni contrattuali applicabili ai sistemi di IA in uso, verificando la presenza di clausole relative alla documentazione tecnica del sistema, alle istruzioni per l’uso, agli aggiornamenti e alle modifiche, nonché alla distribuzione della responsabilità in caso di utilizzo non conforme. Ove le condizioni contrattuali vigenti risultino inadeguate, avviare negoziazioni per l’integrazione di previsioni specifiche.

L’integrazione con la DPIA e il Registro dei trattamenti: per i sistemi di IA che trattano dati personali, verificare che il Registro delle attività di trattamento ai sensi dell’articolo 30 GDPR sia aggiornato con le informazioni relative all’utilizzo del sistema di IA, e che sia stata condotta una DPIA ai sensi dell’articolo 35 GDPR ove richiesto. La DPIA relativa a sistemi di IA dovrebbe includere una valutazione specifica dei rischi connessi alle caratteristiche del sistema — incluse le possibilità di output errati, di discriminazioni algoritmiche o di deriva del modello — e delle misure adottate per mitigarli, tra cui per l’appunto la formazione del personale.

Il coinvolgimento del DPO nella governance dell’IA: assicurarsi che il DPO sia coinvolto fin dalle prime fasi di valutazione e adozione di nuovi sistemi di IA che trattano dati personali, analogamente a quanto già previsto per le nuove tecnologie di trattamento che richiedono una DPIA. Il DPO deve essere in grado di fornire consulenza sul rispetto dell’AI Act nella sua dimensione di protezione dei dati, segnalare potenziali violazioni e monitorare l’efficacia delle misure adottate.

Il monitoraggio degli sviluppi normativi: seguire gli sviluppi del Digital Omnibus e degli altri strumenti normativi in corso di adozione — incluse le linee guida dell’AI Office, le linee guida dell’EDPB sull’intersezione tra AI Act e GDPR, e i provvedimenti dell’autorità nazionale di supervisione, non appena questa sarà pienamente operativa — al fine di aggiornare tempestivamente il programma di conformità in risposta alle evoluzioni del quadro regolatorio.

| Adempimento | Norma di riferimento | Scadenza/Status | Evidenza documentale | |—|—|—|—| | Mappatura sistemi di IA | Art. 4 AI Act; Art. 30 GDPR | Già dovuto (dal 2.2.2025) | Inventario sistemi di IA | | Classificazione del rischio | Art. 5, 6, Allegato III AI Act | Già dovuto | Documento di classificazione | | Identificazione personale destinatario | Art. 4 AI Act | Già dovuto | Matrice ruoli/sistemi | | Progettazione programma formativo | Art. 4 AI Act | Già dovuto | Piano formativo documentato | | Erogazione e documentazione formazione | Art. 4 AI Act; Art. 29, 32(4) GDPR | Già dovuto | Registro partecipanti, materiali | | Revisione contratti fornitori IA | Art. 4 AI Act; Art. 28 GDPR (ove applicabile) | Urgente | Contratti aggiornati | | DPIA per sistemi IA ad alto rischio privacy | Art. 35 GDPR | Già dovuto (se non eseguita) | Report DPIA | | Monitoraggio obblighi GPAI | Capo V AI Act | Applicabile dal 2.8.2025 | Piano di conformità GPAI | | Conformità sistemi IA Allegato III | Art. 6, Allegato III AI Act | Applicabile dal 2.8.2026 | Audit di conformità | | Designazione autorità di supervisione (Italia) | Art. 70 AI Act | In corso [Nota redazionale: verificare lo stato della designazione alla luce della legge 23 settembre 2025, n. 132.] | Da monitorare |

Conclusioni

La vicenda del cosiddetto “rinvio” dell’AI Act offre uno spunto di riflessione che va ben al di là della questione specifica dell’alfabetizzazione in materia di IA. Essa evidenzia le difficoltà che le imprese incontrano nella lettura e nell’interpretazione di un quadro normativo europeo che si è fatto progressivamente più complesso, stratificato e — va riconosciuto — non sempre comunicato con chiarezza dagli stessi soggetti istituzionali.

Il rischio di affidarsi a interpretazioni semplificate o a comunicazioni di sintesi che non distinguono con precisione tra obblighi già vigenti, obblighi in prossima scadenza e obblighi oggetto di possibile modifica è un rischio concreto, che si traduce in scelte organizzative e di compliance potenzialmente errate. Nel caso specifico dell’AI literacy, confidare in un rinvio che non esiste — o che comunque non copre l’articolo 4 del Regolamento — espone le imprese a una situazione di inadempimento già oggi configurabile.

Restano aperte, in prospettiva, alcune questioni di significativo interesse per i pratici del settore.

In primo luogo, la questione dell’enforcement: la presenza di più soggetti istituzionali preposti all’irrogazione delle sanzioni rende difficile prevedere le modalità concrete di applicazione del Regolamento nel breve periodo.

In secondo luogo, la questione della standardizzazione dei programmi di AI literacy: in assenza di linee guida vincolanti che definiscano un contenuto minimo, le imprese si trovano a dover costruire programmi formativi in un contesto di incertezza interpretativa. L’AI Office ha avviato iniziative in questa direzione, ma si ritiene che un contributo più strutturato da parte dei regolatori nazionali e dell’EDPB — soprattutto in relazione all’intersezione con il GDPR — sarebbe di grande utilità per i pratici.

In terzo luogo, la questione dell’articolazione tra AI Act, GDPR e NIS2: la moltiplicazione degli strumenti normativi applicabili ai sistemi di IA sta generando una complessità regolamentare che richiede, da parte delle imprese, un approccio integrato e coordinato alla compliance digitale — un approccio che il solo DPO, nella sua configurazione tradizionale, non sempre è in grado di garantire senza il supporto di figure specialistiche aggiuntive o di strutture interdisciplinari.

Infine, la questione dell’evoluzione tecnologica: i sistemi di IA — in particolare quelli di IA generativa — evolvono a una velocità che rende difficile mantenere costantemente aggiornati i programmi formativi e, più in generale, i sistemi di governance dell’IA. La previsione di meccanismi di aggiornamento continuo — sia nei programmi formativi che nei sistemi di gestione del rischio — costituisce, secondo il parere di chi scrive, uno degli elementi più critici e al tempo stesso più trascurati nella progettazione dei sistemi di compliance all’AI Act.

L'articolo AI Act: l’obbligo di formazione del personale resta vigente dal 2 febbraio proviene da 01magazine.

Il tema dell’utilizzo di sistemi di Intelligenza Artificiale (IA) in ambito lavorativo è stato oggetto di previsione normativa da parte del legislatore comunitario, attraverso il REGOLAMENTO (UE) 2024/1689 del Parlamento Europeo e del Consiglio del 13 giugno 2024 che stabilisce regole armonizzate sull’intelligenza artificiale e modifica i regolamenti (CE) n. 300/2008, (UE) n. 167/2013, (UE) n. 168/2013, (UE) 2018/858, (UE) 2018/1139 e (UE) 2019/2144 e le direttive 2014/90/UE, (UE) 2016/797 e (UE) 2020/1828 (regolamento sull’intelligenza artificiale).

Di seguito di riportano le specifiche su tale argomento.

Il Considerando (9) ha stabilito l’opportunità che le norme armonizzate applicabili all’immissione sul mercato, alla messa in servizio e all’uso di sistemi di IA ad alto rischio dovrebbero applicarsi in tutti i settori e, in linea con il nuovo quadro legislativo, non dovrebbero pregiudicare il vigente diritto dell’Unione, in particolare in materia di occupazione e protezione dei lavoratori, al quale il presente regolamento è complementare[1].

Di conseguenza i sistemi di IA utilizzati in tutte o solo in alcune fasi che caratterizzano il rapporto di lavoro (sin dalla fase di avvio per arrivare alla gestione e terminare con la cessazione) rientrano nel novero dei sistemi ad alto rischio.

Inoltre, nel contesto dell’occupazione e della protezione dei lavoratori, il regolamento non dovrebbe pertanto incidere sul diritto dell’Unione in materia di politica sociale né sul diritto del lavoro nazionale, in conformità del diritto dell’Unione, per quanto riguarda le condizioni di impiego e le condizioni di lavoro, comprese la salute e la sicurezza sul luogo di lavoro, e il rapporto tra datori di lavoro e lavoratori.

Il regolamento non dovrebbe inoltre pregiudicare l’esercizio dei diritti fondamentali riconosciuti dagli Stati membri e a livello di Unione, compresi il diritto o la libertà di sciopero o il diritto o la libertà di intraprendere altre azioni contemplate dalla disciplina delle relazioni industriali negli Stati membri nonché il diritto di negoziare, concludere ed eseguire accordi collettivi, o di intraprendere azioni collettive in conformità del diritto nazionale. Il regolamento dovrebbe lasciare impregiudicate le disposizioni volte a migliorare le condizioni di lavoro nel lavoro mediante piattaforme digitali di cui alla direttiva del Parlamento europeo e del Consiglio relativa al miglioramento delle condizioni di lavoro nel lavoro mediante piattaforme digitali. Inoltre, il regolamento mira a rafforzare l’efficacia di tali diritti e mezzi di ricorso esistenti definendo requisiti e obblighi specifici, anche per quanto riguarda la trasparenza, la documentazione tecnica e la conservazione delle registrazioni dei sistemi di IA.

 Oltre a ciò, gli obblighi imposti a vari operatori coinvolti nella catena del valore dell’IA a norma del regolamento dovrebbero applicarsi senza pregiudizio del diritto nazionale, in conformità del diritto dell’Unione, e avere l’effetto di limitare l’uso di determinati sistemi di IA qualora tale diritto non rientri nell’ambito di applicazione del presente regolamento o persegua obiettivi legittimi di interesse pubblico diversi da quelli perseguiti dal presente regolamento. Ad esempio, il regolamento non dovrebbe incidere sulla normativa nazionale in materia di lavoro e sulla normativa in materia di protezione dei minori[2].

  Il Considerando (20) stabilisce che ai fini del regolamento la nozione di «spazio accessibile al pubblico» dovrebbe essere intesa come riferita a qualsiasi luogo fisico accessibile a un numero indeterminato di persone fisiche. I locali delle imprese e delle fabbriche, come pure gli uffici e i luoghi di lavoro destinati ad essere accessibili solo dai pertinenti dipendenti e prestatori di servizi, sono luoghi non accessibili al pubblico. L’ambito lavorativo viene preso in esame anche in tema di utilizzo di sistemi di IA volti a identificare o inferire emozioni, tra le principali carenze di tali sistemi figurano la limitata affidabilità, la mancanza di specificità e la limitata generalizzabilità. Pertanto, i sistemi di IA che identificano o inferiscono emozioni o intenzioni di persone fisiche sulla base dei loro dati biometrici possono portare a risultati discriminatori e possono essere invasivi dei diritti e delle libertà delle persone interessate. Considerando lo squilibrio di potere nel contesto del lavoro, combinato con la natura invasiva di tali sistemi, questi ultimi potrebbero determinare un trattamento pregiudizievole o sfavorevole di talune persone fisiche o di interi gruppi di persone fisiche. È pertanto opportuno vietare l’immissione sul mercato, la messa in servizio o l’uso di sistemi di IA destinati a essere utilizzati per rilevare lo stato emotivo delle persone in situazioni relative al luogo di lavoro. Considerando (44) Anche i sistemi di IA utilizzati nel settore dell’occupazione, nella gestione dei lavoratori e nell’accesso al lavoro autonomo, in particolare per l’assunzione e la selezione delle persone, per l’adozione di decisioni riguardanti le condizioni del rapporto di lavoro la promozione e la cessazione dei rapporti contrattuali di lavoro, per l’assegnazione dei compiti sulla base dei comportamenti individuali, dei tratti o delle caratteristiche personali e per il monitoraggio o la valutazione delle persone nei rapporti contrattuali legati al lavoro, dovrebbero essere classificati come sistemi ad alto rischio, in quanto tali sistemi possono avere un impatto significativo sul futuro di tali persone in termini di prospettive di carriera e sostentamento e di diritti dei lavoratori. I pertinenti rapporti contrattuali di lavoro dovrebbero coinvolgere, in modo significativo, i dipendenti e le persone che forniscono servizi tramite piattaforme, come indicato nel programma di lavoro annuale della Commissione per il 2021. Durante tutto il processo di assunzione, nonché ai fini della valutazione e della promozione delle persone o del proseguimento dei rapporti contrattuali legati al lavoro, tali sistemi possono perpetuare modelli storici di discriminazione, ad esempio nei confronti delle donne, di talune fasce di età, delle persone con disabilità o delle persone aventi determinate origini razziali o etniche o un determinato orientamento sessuale. I sistemi di IA utilizzati per monitorare le prestazioni e il comportamento di tali persone possono inoltre comprometterne i diritti fondamentali in materia di protezione dei dati e vita privata. Considerando (57) Per quanto attiene agli infortuni sul lavoro, il Considerando (58) sancisce che l’utilizzo dei sistemi di IA merita particolare attenzione per l’accesso ad alcuni servizi e prestazioni essenziali, pubblici e privati, necessari affinché le persone possano partecipare pienamente alla vita sociale o migliorare il proprio tenore di vita, e la fruizione di tali servizi. In particolare, le persone fisiche che chiedono o ricevono prestazioni e servizi essenziali di assistenza pubblica dalle autorità pubbliche, vale a dire prestazioni di sicurezza sociale, che forniscono protezione in casi quali gli infortuni sul lavoro, e la perdita di occupazione, sono di norma dipendenti da tali prestazioni e servizi e si trovano generalmente in una posizione vulnerabile rispetto alle autorità responsabili. I sistemi di IA, se utilizzati per determinare se tali prestazioni e servizi dovrebbero essere concessi, negati, ridotti, revocati o recuperati dalle autorità, compreso se i beneficiari hanno legittimamente diritto a tali prestazioni o servizi, possono avere un impatto significativo sul sostentamento delle persone e violare i loro diritti fondamentali, quali il diritto alla protezione sociale, alla non discriminazione, alla dignità umana o a un ricorso effettivo e dovrebbero pertanto essere classificati come sistemi ad alto rischio. Il regolamento – Considerando (92) -lascia impregiudicati gli obblighi dei datori di lavoro di informare o di informare e consultare i lavoratori o i loro rappresentanti a norma del diritto e delle prassi dell’Unione o nazionali, in merito alle decisioni di mettere in servizio o utilizzare sistemi di IA. Rimane necessario garantire che i lavoratori e i loro rappresentanti siano informati in merito alla diffusione programmata dei sistemi di IA ad alto rischio sul luogo di lavoro, qualora non siano soddisfatte le condizioni per tali obblighi di informazione o di informazione e co Riguardo all’ambito di applicazione – art. 2 – il regolamento non osta a che l’Unione o gli Stati membri mantengano o introducano disposizioni legislative, regolamentari o amministrative più favorevoli ai lavoratori in termini di tutela dei loro diritti in relazione all’uso dei sistemi di IA da parte dei datori di lavoro, o incoraggino o consentano l’applicazione di contratti collettivi più favorevoli ai lavoratori. Nel novero delle pratiche di IA vietate, l’art. 5, cita l’immissione sul mercato, la messa in servizio per tale finalità specifica o l’uso di sistemi di IA per inferire le emozioni di una persona fisica nell’ambito del luogo di lavoro, tranne laddove l’uso del sistema di IA sia destinato a essere messo in funzione o immesso sul mercato per motivi medici o di sicurezza Così come tra gli obblighi dei deployer dei sistemi di IA ad alto rischio (art. 26), essi prima di mettere in servizio o utilizzare un sistema di IA ad alto rischio sul luogo di lavoro, i deployer[3] che sono datori di lavoro informano i rappresentanti dei lavoratori e i lavoratori interessati che saranno soggetti all’uso del sistema di IA ad alto rischio. Tali informazioni sono fornite, se del caso, conformemente alle norme e alle procedure stabilite dal diritto e dalle prassi dell’Unione e nazionali in materia di informazione dei lavoratori e dei loro rappresentanti. L’ALLEGATO III del regolamento sulla IA richiama i Sistemi di IA ad alto rischio di cui all’articolo 6, paragrafo 2[4], annoverando tra questianche i sistemi di IA presenti nel settore  dell’occupazione, gestione dei lavoratori e accesso al lavoro autonomo: a) i sistemi di IA destinati a essere utilizzati per l’assunzione o la selezione di persone fisiche, in particolare per pubblicare annunci di lavoro mirati, analizzare o filtrare le candidature e valutare i candidati;   b) i sistemi di IA destinati a essere utilizzati per adottare decisioni riguardanti le condizioni dei rapporti di lavoro, la promozione o cessazione dei rapporti contrattuali di lavoro, per assegnare compiti sulla base del comportamento individuale o dei tratti e delle caratteristiche personali o per monitorare e valutare le prestazioni e il comportamento delle persone nell’ambito di tali rapporti di lavoro.

Adempimenti a carico dei datori di lavoro.

Come punto di partenza si suggerisce di non limitarsi a pensare che la IA è disciplinata esclusivamente dalla specifica normativa di settore; in realtà il Regolamento 2024/1689 va confrontato con tutta una serie di norme che in ambito lavorativo sono, in primis, quelle in materia di diritto del lavoro (L. n. 300/1970 e s.m.i.) senza tralasciare il ricorso al Regolamento 679/2016. Una volta chiarita l’impostazione e il metodo da seguire gli adempimenti in capo al datore di lavoro saranno, almeno, i seguenti:

1. Censimento dei sistemi di IA. A tale proposito vanno coinvolte tutte le funzioni aziendali al fine di arrivare ad una mappatura dei sistemi di IA presenti in azienda e per ciascun sistema vanno acquisiti i seguenti debiti informativi: nome del sistema, indicazioni e dati di contatto del Fornitore, standard di riferimento posseduti; se il sistema si interfaccia con altri sistemi e/o dispositivi; scheda tecnica del prodotto, le finalità sottese all’impiego e la relativa base giuridica, categorie di dati personali trattati, soggetti coinvolti, ecc.
2. Sottoposizione del sistema ad un’analisi dei rischi con successiva (obbligatoria) valutazione d’impatto ai sensi dell’art. 35 del GDPR.
3. Adozione del principio di IA by design per cui le funzioni aziendali, ciascuna per quanto di competenza (Responsabile protezione dati, responsabile legale, responsabile sistemi informativi, risk management, compliance, ecc.), intervengano fattivamente ed in maniera sinergica sin dalla fase di progettazione dell’acquisto di un sistema IA.
4. Prevedere che il sistema IA sia gestito in ultima analisi da un soggetto, persona fisica, in grado di utilizzarlo; ciò sta a significare che il cd “super administrator” – in grado di intervenire sul sistema – debba essere un umano.
5. Adottare una politica integrata di cybersicurezza e tutela dei dati personali da applicare anche nei confronti dei sistemi di IA, al fine di essere in grado di gestire gli scenari dei rischi di sicurezza: perdita o indisponibilità dei dati; distruzione non autorizzata dei dati; modifiche indesiderate o non autorizzate dei dati; divulgazione non autorizzata di dati personali; accesso illegittimo o non autorizzato ai dati.
6. Piena ed ampia disclosure verso i lavoratori, prevedendo anche il loro coinvolgimento, circa la presenza di sistemi di IA, indicando le finalità, il modello di funzionamento, le sue caratteristiche, ecc.

[1] Di conseguenza, restano impregiudicati e pienamente applicabili tutti i diritti e i mezzi di ricorso previsti da tali disposizioni di diritto dell’Unione a favore dei consumatori e delle altre persone su cui i sistemi di IA possono avere un impatto negativo, anche in relazione al risarcimento di eventuali danni a norma della direttiva 85/374/CEE del Consiglio.

[2] Ossia le persone di età inferiore ai 18 anni, tenendo conto del commento generale n,25 della Convenzione sui diritti dell’infanzia e dell’adolescenza (2021) sui diritti dei minori in relazione all’ambiente digitale, nella misura in cui esse non riguardino in modo specifico i sistemi di IA e perseguano altri obiettivi legittimi di interesse pubblico.

[3] Il deployer è  la “persona fisica o giuridica, autorità pubblica, agenzia o altro organismo che utilizza un sistema di IA sotto la propria autorità, tranne nel caso in cui il sistema di IA sia utilizzato nel corso di un’attività personale non professionale

[4] Articolo 6 Regole di classificazione per i sistemi di IA ad alto rischio 2. Oltre ai sistemi di IA ad alto rischio di cui al paragrafo 1, sono considerati ad alto rischio anche i sistemi di IA di cui all’allegato III.

L'articolo L’utilizzo di sistemi di Intelligenza Artificiale in ambito lavorativo. proviene da 01magazine.

Chi e è il Responsabile della conservazione digitale

L’articolo 44[1] del Codice dell’Amministrazione Digitale prevede i requisiti per la gestione e conservazione dei documenti informatici, individuando caratteristiche generali e prescrizioni peculiari espressamente destinate alle Pubbliche Amministrazioni. Tra le previsioni applicabili esclusivamente alle Pubbliche Amministrazioni rientra l’obbligo di nominare il Responsabile della gestione dei documenti informatici, “(…) che opera d’intesa con il dirigente dell’ufficio di cui all’articolo 17 del presente Codice, il responsabile del trattamento dei dati personali di cui all’articolo 29 del decreto legislativo 30 giugno 2003, n. 196, ove nominato, e con il responsabile del sistema della conservazione dei documenti informatici delle pubbliche amministrazioni, nella definizione e gestione delle attività di rispettiva competenza (…)” (art. 44, comma 1-bis del CAD).

Il ruolo del Responsabile della gestione documentale e del Responsabile della conservazione e i rispettivi compiti sono disciplinati nelle Linee guida AgID sulla formazione, gestione e conservazione dei documenti informatici, entrate in vigore il 1° gennaio 2022.

Il Regolamento sui criteri per la fornitura dei servizi di conservazione dei documenti informatici (AGID 2021).

Il Decreto Semplificazione (D.L. 76/2020), convertito con Legge n. 120/2020, ha apportato numerose modifiche al Codice dell’amministrazione digitale (CAD), tra cui alcune relative al servizio di conservazione dei documenti informatici. In particolare l’articolo 34, comma 1-bis, prevede che: “Le pubbliche amministrazioni possono procedere alla conservazione dei documenti informatici:

a) all’interno della propria struttura organizzativa;

b) affidandola, in modo totale o parziale, nel rispetto della disciplina vigente, ad altri soggetti, pubblici o privati che possiedono i requisiti di qualità, di sicurezza e organizzazione individuati, nel rispetto della disciplina europea, nelle Linee guida di cui all’art 71 relative alla formazione, gestione e conservazione dei documenti informatici nonché in un regolamento sui criteri per la fornitura dei servizi di conservazione dei documenti informatici emanato da AgID, avuto riguardo all’esigenza di assicurare la conformità dei documenti conservati agli originali nonché la qualità e la sicurezza del sistema di conservazione.”.

La conservazione dei documenti informatici per conto delle pubbliche amministrazioni da parte di soggetti esterni deve, quindi, uniformarsi – nel rispetto della disciplina europea – alle Linee guida sulla formazione, gestione e conservazione dei documenti informatici nonché ad un regolamento, adottati entrambi dall’Agenzia per l’Italia digitale (AgID), che segnano il superamento del precedente meccanismo di accreditamento dei conservatori.

Ai sensi degli artt. 34[2] e 44 del CAD, e in conformità alle Linee guida di AgID sulla formazione, gestione e conservazione del documento informatico, la conservazione dei documenti informatici deve avvenire in modo che:

a) il sistema di conservazione assicuri, per quanto in esso conservato, caratteristiche di autenticità, integrità, affidabilità, leggibilità, reperibilità;

b) i soggetti, pubblici o privati, che erogano il servizio di conservazione per conto delle pubbliche amministrazioni, offrano idonee garanzie organizzative, tecnologiche e di protezione dei dati personali e assicurino la conformità dei documenti conservati agli originali nonché la qualità e la sicurezza del sistema di conservazione.

I soggetti che intendono erogare il servizio di conservazione dei documenti informatici per conto delle pubbliche amministrazioni devono possedere i requisiti generali nonché i requisiti di qualità, di sicurezza e organizzazione specificati all’interno dell’allegato A al presente regolamento, denominato “Requisiti per l’erogazione del servizio di conservazione per conto delle pubbliche amministrazioni”

I soggetti, pubblici o privati, che intendono erogare il servizio di conservazione dei documenti informatici per conto delle pubbliche amministrazioni possono richiedere l’iscrizione al marketplace per i servizi di conservazione, che sarà istituito da AgID attraverso un’apposita piattaforma.[3]

La Circolare esplicativa licenziata da ANORC

La Circolare che si illustra mira a fornire alcune precisazioni in merito alla “entità” deputata a svolgere il ruolo di responsabile della conservazione, operando una distinzione tra soggetti pubblici e soggetti privati.[4]

Per i soggetti pubblici, il ruolo del Responsabile della conservazione deve essere previsto dall’organigramma del Titolare dell’oggetto di conservazione. Tale ruolo, nello specifico, deve essere assegnato a un dirigente o un funzionario interno formalmente designato, che sia in possesso di idonee competenze giuridiche, informatiche e archivistiche. Eventualmente il ruolo di Responsabile della conservazione può essere svolto dal Responsabile della gestione documentale o dal Coordinatore della gestione documentale, ove nominato.

Ai sensi dell’Allegato A al Regolamento sui criteri per la fornitura dei servizi di conservazione dei documenti informatici requisiti per l’erogazione del servizio di conservazione per conto delle pubbliche amministrazioni, il soggetto che intende erogare il servizio di conservazione per conto delle pubbliche amministrazioni deve avvalersi di un sistema di conservazione che assicuri e garantisca quanto previsto dalle Linee guida sulla formazione, gestione e conservazione dei documenti informatici e dall’art. 44, comma 1ter, del decreto legislativo 7 marzo 2005, n. 82, e successive modificazioni (Codice dell’Amministrazione Digitale – CAD). Chi intende fornire i servizi di conservazione in modalità cloud per conto delle pubbliche amministrazioni deve possedere, oltre ai requisiti prescritti nel presente allegato, anche la qualificazione prevista dall’art. 4 della Circolare AgID n. 3 del 9 aprile 2018. I requisiti individuati nel presente allegato devono essere posseduti per l’accesso e la permanenza nel marketplace dei servizi di conservazione o, per i conservatori non iscritti al marketplace, per la partecipazione alle procedure di affidamento.

Per i soggetti diversi dalla Pubblica Amministrazione, le Linee Guida, nel prevedere l’opportunità di esternalizzare la funzione, stabiliscono che il ruolo di Responsabile della conservazione possa essere assunto da un soggetto – si badi bene all’utilizzo del termine “soggetto” volutamente generico – esterno all’organizzazione, purché in possesso di idonee competenze (giuridiche, informatiche ed archivistiche) e purché terzo rispetto al Conservatore.  Diversamente da quanto avviene nel paragrafo dedicato al Responsabile della conservazione nella Pubblica Amministrazione, in questo caso non sono utilizzati termini che possano indicare la necessità di individuare una persona fisica, anziché una persona giuridica (es. dirigente, professionista, lavoratore, ecc.). E ciò che non è espressamente dichiarato come un limite, deve consentire un’interpretazione ampia, secondo quei principi costituzionali già in precedenza enunciati.

Il parere di ANORC

“Dalla lettura delle norme relative alla digitalizzazione in generale e alla formazione, gestione e conservazione dei documenti informatici, nello specifico, non si ravvisa alcun limite esplicito alla nomina di una persona giuridica come Responsabile della conservazione di un soggetto diverso dalla Pubblica Amministrazione.  A ulteriore sostegno di questa posizione potrebbe essere presa in considerazione la disciplina che regola la figura del Responsabile della protezione dei dati (c.d. RPD). Le similitudini tra le due professionalità consentono di attingere alla disciplina del RPD per colmare eventuali dubbi interpretativi legati al ruolo di Responsabile della conservazione.”

[1] Art. 44 – Requisiti per la gestione e conservazione dei documenti informatici.  vigente dal 17.07.20201. Il sistema di gestione informatica dei documenti delle pubbliche amministrazioni, di cui all’articolo 52 del decreto del Presidente della Repubblica 28 dicembre 2000, n. 445, è organizzato e gestito, anche in modo da assicurare l’indicizzazione e la ricerca dei documenti e fascicoli informatici attraverso il sistema di cui all’articolo 40-ter nel rispetto delle Linee guida. 1-bis. Il sistema di gestione dei documenti informatici delle pubbliche amministrazioni è gestito da un responsabile che opera d’intesa con il dirigente dell’ufficio di cui all’articolo 17 del presente Codice, il responsabile del trattamento dei dati personali di cui all’articolo 29 del decreto legislativo 30 giugno 2003, n. 196, ove nominato, e con il responsabile del sistema della conservazione dei documenti informatici delle pubbliche amministrazioni, nella definizione e gestione delle attività di rispettiva competenza. Almeno una volta all’anno il responsabile della gestione dei documenti informatici provvede a trasmettere al sistema di conservazione i fascicoli e le serie documentarie anche relative a procedimenti non conclusi. 1-ter. In tutti i casi in cui la legge prescrive obblighi di conservazione, anche a carico di soggetti privati, il sistema di conservazione dei documenti informatici assicura, per quanto in esso conservato, caratteristiche di autenticità, integrità, affidabilità, leggibilità, reperibilità, secondo le modalità indicate nelle Linee guida. 1-quater. Il responsabile della conservazione, che opera d’intesa con il responsabile del trattamento dei dati personali, con il responsabile della sicurezza e con il responsabile dei sistemi informativi, può affidare, ai sensi dell’articolo 34, comma 1-bis, lettera b), la conservazione dei documenti informatici ad altri soggetti, pubblici o privati, che offrono idonee garanzie organizzative, e tecnologiche e di protezione dei dati personali. Il responsabile della conservazione della pubblica amministrazione, che opera d’intesa, oltre che con i responsabili di cui al comma 1-bis, anche con il responsabile della gestione documentale, effettua la conservazione dei documenti informatici secondo quanto previsto all’articolo 34, comma 1-bis.

[2] Art. 34 Norme particolari per le pubbliche amministrazioni 1. Ai fini della sottoscrizione, ove prevista, di documenti informatici di rilevanza esterna, le pubbliche amministrazioni:a) possono svolgere direttamente l’attività di rilascio dei certificati qualificati avendo a tale fine l’obbligo di qualificarsi ai sensi dell’articolo 29; tale attività può essere svolta esclusivamente nei confronti dei propri organi ed uffici, nonché di categorie di terzi, pubblici o privati. PERIODO SOPPRESSO DAL D.LGS. 26 AGOSTO 2016, N. 179; b) possono rivolgersi a prestatori di servizi di firma digitale o di altra firma elettronica qualificata,  secondo la vigente normativa in materia di contratti pubblici. 1-bis. Le pubbliche amministrazioni possono procedere alla conservazione dei documenti informatici: a) all’interno della propria struttura organizzativa; b) affidandola, in modo totale o parziale, nel rispetto della disciplina vigente, ad altri soggetti, pubblici o privati  ((che possiedono i requisiti di qualità, di sicurezza e organizzazione individuati, nel rispetto della disciplina europea, nelle Linee guida di cui all’art 71 relative alla formazione, gestione e conservazione dei documenti informatici nonché in un regolamento sui criteri per la fornitura dei servizi di conservazione dei documenti informatici emanato da AgID, avuto riguardo all’esigenza di assicurare la conformità dei documenti conservati agli originali nonché la qualità e la sicurezza del sistema di conservazione.)) 2. COMMA ABROGATO DAL D.LGS. 13 DICEMBRE 2017, N. 217.3. COMMA ABROGATO DAL D.LGS. 26 AGOSTO 2016, N. 179.4. COMMA ABROGATO DAL D.LGS. 26 AGOSTO 2016, N. 179.5. COMMA ABROGATO DAL D.LGS. 26 AGOSTO 2016, N. 179.

[3] Limitatamente alla formazione, gestione e conservazione dei documenti informatici, senza pretesa di esaustività, si riporta il seguente cronoprogramma: Target 2025 – Il 100% delle amministrazioni devono avere adottato il Manuale di gestione documentale, nominato il Responsabile della gestione documentale per ciascuna Area Organizzativa Omogenea (AOO) e, qualora siano presenti più AOO, nominato anche il Coordinatore della gestione documentale, pubblicando gli atti in “Amministrazione trasparente”Giugno 2025 – Le PA devono verificare che in “Amministrazione trasparente” sia pubblicato il Manuale di gestione documentale, la nomina del Responsabile della gestione documentale per ciascuna AOO e, qualora siano presenti più AOO, la nomina del Coordinatore della gestione documentale – CAP3.PA.17

[4] ANORC (Associazione Nazionale per Operatori e Responsabili della Custodia dei contenuti digitali- www.anorc.eu) è una realtà senza scopo di lucro – già iscritta all’elenco dei portatori di interesse presso la Camera dei Deputati, il Ministero per lo Sviluppo Economico e il Ministero del Lavoro – che dal 2007 mette in comunicazione e canalizza le conoscenze e i bisogni di aziende, enti pubblici, professionisti ed esperti che operano con diversi ruoli Allegato A Al Regolamento sui criteri per la fornitura dei servizi di conservazione dei documenti informatici REQUISITI PER L’EROGAZIONE DEL SERVIZIO DI CONSERVAZIONE PER CONTO DELLE PUBBLICHE AMMINISTRAZIONInei settori della digitalizzazione e della protezione dei dati.

L'articolo Il Responsabile della Conservazione Digitale: gli obblighi in capo agli enti pubblici ed ai soggetti privati. proviene da 01magazine.