Multiutility italiane nel labirinto normativo: tra GDPR, NIS2, CRA e AI Act
📣 ATTENZIONE, ARTICOLO LUNGO. Non perché mi sia lasciato prendere dalla grafomania… ma perché quando si parla di #multiutility, #GDPR, #NIS2, #CRA, #AIAct e normative italiane assortite (🌪️) tocca per forza fare ordine nel caos normativo, anche a costo di sacrificare qualche polpastrello sulla tastiera. 😅✍️
👉 L’ho fatto perché troppi “esperti” del settore si concentrano solo sul proprio pezzetto (energia! gas! idrico! rifiuti! 🍝), ignorando che viviamo in un mondo interconnesso dove cybersecurity, privacy, AI, e responsabilità sui dispositivi digitali NON si possono affrontare a compartimenti stagni.
E poi, diciamolo: in Italia abbiamo una certa propensione a correre ai ripari dopo il disastro, più che a impostare strategie lungimiranti. Così, tra una norma UNI aggiornata nel 1998, un regolamento europeo con acronimo minaccioso e una delibera ARERA che spunta il venerdì alle 19:00, il rischio è che le piccole e medie multiutility vengano colte in fallo… o in blackout.
🧐 Nell’articolo (sì, lungo, ma strutturato per sopravvivere alla lettura), analizzo:
Quali normative si sovrappongono e si ignorano a vicenda;
Perché la compliance non può essere fatta a compartimenti stagni;
Se contatori intelligenti, app per l’utente e sistemi SCADA hanno un destino (cyber) segnato;
E perché il GDPR non è un mostro, ma neanche un peluche 🧸.
🚀 Per chi lavora nel settore o ci ruota attorno, è il momento di smettere di “tamponare” e cominciare a pensare strategicamente, anche nella compliance.
👇 L’articolo è qui. Leggetelo, condividetelo, insultatelo. Ma non ignoratelo, che poi tocca fare tutto di corsa (e male).
Introduzione
Gestire energia elettrica, gas, acqua e rifiuti è già di per sé complesso – ma provate a farlo districandovi in un labirinto di norme europee in continua espansione. Le multiutility italiane, specialmente di piccola e media dimensione, si trovano a navigare un panorama regolatorio che potrebbe far impallidire un giurista esperto. Dal GDPR (privacy) alla direttiva NIS2 (cybersicurezza), dal futuro Cyber Resilience Act (CRA) fino all’AI Act sull’intelligenza artificiale, ogni aspetto tecnologico e operativo sembra cadere sotto una lente normativa diversa. Il tono di questo articolo è ironico e pungente, ma il tema è dannatamente serio: come assicurare la conformità a tutte queste norme, evitando sovrapposizioni, ridondanze e magari qualche crisi di nervi?
Immaginate il responsabile IT di una piccola multiutility locale che, oltre a preoccuparsi di tubature e cavi, deve anche interpretare regolamenti europei dalle sigle esoteriche. Un giorno è il GDPR che bussa alla porta chiedendo “Hai informato gli utenti di come usi i loro dati?”. Il giorno dopo è NIS2 che intima “Metti in sicurezza i tuoi server… o else”. Nel frattempo, il nuovo CRA scalpita all’orizzonte: “Quell’app per i clienti è abbastanza cyber-resiliente da meritare il marchio CE?”. E come se non bastasse, ecco l’AI Act: “State mica usando un algoritmo intelligente senza controllo, vero?”. Il risultato è un mosaico normativo in cui ogni tessera sembra fatta apposta per sovrapporsi alle altre, mettendo a dura prova le risorse (e la pazienza) delle imprese.
In questo articolo affronteremo con rigore tecnico-legale – e un filo di sarcasmo – le principali problematiche normative per le multiutility italiane. Vedremo:
- Come districarsi tra GDPR, NIS2, CRA, AI Act e altri regolamenti europei, specialmente quelli che influenzano il rapporto con l’utente finale.
- Dove queste normative si sovrappongono o addirittura fanno a pugni tra loro, nel contesto tecnologico-operativo delle multiutility.
- Perché è fondamentale passare da un’approccio frammentato (dove ogni dipartimento pensa alla “sua” norma) a una gestione integrata della compliance, più omogenea ed efficiente.
- Alcuni esempi pratici (e paradossali) – dal contatore intelligente all’app per l’acqua – che illustrano quanto possa diventare surreale applicare tutte le regole contemporaneamente.
- Domande provocatorie lungo il percorso, del tipo: “I meter intelligenti dovranno diventare filosofi per capire se devono rispondere al GDPR o al CRA prima?” o “L’app dell’acqua deve chiedere il consenso per ogni goccia tracciata?”, giusto per sottolineare con un sorriso amaro le complessità cui stiamo andando incontro.
Pronti a esplorare questo “gioco ad incastri” normativo? Indossiamo allora l’elmetto da cantiere (normativo) e addentriamoci nelle regole del gioco, con l’obiettivo di capire come uscirne vivi – e compliant – senza impazzire.
GDPR: il guardiano dei dati (anche nelle bollette)
Parliamo anzitutto del GDPR, il Regolamento Generale sulla Protezione dei Dati (UE 2016/679), in vigore dal 2018 e ormai ben noto anche ai muri. Per una multiutility, il GDPR è l’onnipresente “guardiano” che veglia su ogni informazione personale degli utenti: dai dati anagrafici nel contratto di fornitura, ai consumi registrati dal contatore intelligente, fino al numero di targa registrato all’ecocentro rifiuti. Ogni volta che si tocca un dato personale, scatta l’obbligo di rispettare i principi fondamentali: liceità, correttezza, trasparenza, minimizzazione, esattezza, integrità, riservatezza velevo.blog. In altre parole, usare i dati solo per scopi legittimi e noti all’utente, ridurre al minimo indispensabile le informazioni raccolte, tenerle sicure e dare alle persone controllo sui propri dati.
Facile a dirsi, ma in pratica? Prendiamo l’esempio di un’app mobile che la multiutility offre ai clienti per monitorare i consumi idrici. Questa app raccoglie dati di utilizzo dell’acqua in tempo reale: quante docce, quanti litri, quante “gocce” digitali vengono registrate. Secondo il GDPR, l’utente dev’essere informato chiaramente di quali dati vengono raccolti e perché (es. per mostrargli statistiche, per migliorare il servizio, magari per campagne di sensibilizzazione al risparmio idrico) e bisogna trovare una base giuridica per trattare tali dati (il contratto di fornitura può coprire i dati necessari alla fatturazione, il legittimo interesse potrebbe coprire qualche elaborazione in più, oppure si chiede il consenso esplicito per funzionalità extra). Ed ecco spuntare la prima domanda provocatoria: l’app dell’acqua deve chiedere il consenso per ogni goccia tracciata? Ovviamente no – sarebbe una follia dover cliccare “Accetto” ad ogni litro consumato – ma la provocazione evidenzia un punto reale: capire dove finisce il dato necessario e dove inizia l’uso “extra” che richiede magari un consenso aggiuntivo non è banale. Se l’app volesse ad esempio profilare le abitudini d’uso dell’acqua per suggerire comportamenti virtuosi, quel trattamento potrebbe andare oltre la “necessità contrattuale” e richiedere il consenso dell’utente (o quantomeno un’opzione di opt-out). Il GDPR impone finezze del genere, e guai a sbagliare: le sanzioni arrivano fino a 20 milioni di euro o il 4% del fatturato mondiale velevo.blog, niente male per un rubinetto lasciato aperto.
Un altro aspetto cruciale è la sicurezza dei dati personali. L’art. 32 GDPR impone misure tecniche e organizzative adeguate per garantire la sicurezza dei dati, prevenire accessi non autorizzati, perdite o distruzione velevo.blog. In pratica, per la multiutility significa proteggere i database clienti, cifrare magari le comunicazioni dei smart meter, controllare gli accessi al CRM, fare backup sicuri delle bollette digitali, e così via. Qui già intravediamo una sovrapposizione: quello che il GDPR chiama sicurezza dei dati coincide in gran parte con la sicurezza informatica generale dell’azienda – ponte diretto verso NIS2, di cui parleremo tra poco. Ma attenzione: il GDPR inquadra la sicurezza come un mezzo per tutelare i diritti degli interessati (gli utenti), dunque sempre dal punto di vista della privacy. Ad esempio, se un cyber attacco buca il sistema e ruba dati personali, scatta l’obbligo di notifica della violazione al Garante Privacy entro 72 ore velevo.blog e possibilmente anche di avvisare gli utenti coinvolti (se il rischio per loro è elevato). Questo obbligo di data breach notification è diventato uno degli incubi ricorrenti dei responsabili IT: immaginate di dover comunicare ai clienti che i loro dati sono finiti chissà dove – un colpo all’immagine oltre che all’obbligo legale.
Il GDPR tocca anche il rapporto col consumatore in termini di diritti: diritto di accesso ai propri dati, rettifica, cancellazione (il famoso diritto all’oblio), portabilità dei dati, opposizione a trattamenti automatizzati, etc. Per una multiutility ciò significa predisporre procedure per rispondere se un utente chiede “Voglio sapere tutto ciò che avete su di me nel vostro database” oppure “Cancella i miei dati perché non sono più vostro cliente”. E anche se molte PMI temevano un assalto di richieste, nella pratica queste istanze vanno gestite caso per caso, ma la compliance va predisposta (pena sanzioni). Aggiungiamo poi che spesso le utility offrono servizi online e app, quindi devono fare i conti pure con la direttiva ePrivacy (d.lgs. 196/03 e successive modifiche, in attesa di un regolamento UE che la sostituirà): cookie e tracciatori sul portale web, eventuali email promozionali (da inviare solo con consenso o comunque in linea col GDPR), la riservatezza delle comunicazioni se l’app invia notifiche o messaggi. Insomma, l’utente finale dev’essere tutelato a 360 gradi: non basta erogargli acqua pulita, bisogna anche maneggiare con cura i suoi dati e non invadere la sua privacy digitale.
Prima di passare al prossimo capitolo, val la pena sottolineare con un riferimento un po’ poetico che lo stesso GDPR, nel suo Considerando 4, dichiara che il trattamento dei dati personali dovrebbe essere “al servizio dell’uomo” gdpr-text.com. Una frase nobile, quasi filosofica: la tecnologia deve rispettare la dignità umana. Ebbene, teniamolo a mente: nel grande affresco della compliance, il GDPR ci ricorda che dietro numeri e codici cliente ci sono persone in carne e ossa. Persone che hanno diritto a non essere monitorate e profilate senza controllo, neppure dalla loro azienda fornitrice di acqua o luce. Un principio sacrosanto… anche se a volte, per rispettarlo, si finisce per chiedere all’utente il permesso pure di analizzare quanta acqua consuma innaffiando il giardino!
Direttiva NIS2: sicurezza cibernetica per servizi essenziali
Se il GDPR guarda principalmente alla tutela dei dati personali, la Direttiva NIS2 (Direttiva (UE) 2022/2555) guarda alla tutela dei sistemi e della continuità operativa. Pubblicata a fine 2022, NIS2 è l’erede potenziata della prima direttiva NIS del 2016, e stabilisce regole comuni di cybersicurezza per un ampio ventaglio di settori critici. Indovinate un po’? Le nostre multiutility sono proprio in mezzo al bersaglio. Tra i settori di alta criticità elencati in NIS2 ci sono infatti l’Energia (elettricità, gas, teleriscaldamento, petrolio, ecc.), il Settore Idrico (acqua potabile e acque reflue) e il settore dei Servizi digitali correlati
Una multiutility tipicamente fornisce elettricità/gas, acqua, e spesso gestisce rifiuti (che, anche se non menzionati esplicitamente, rientrano nel concetto ampio di servizi essenziali urbani). Dunque è chiaro: queste aziende sono considerate “essential entities” ai sensi di NIS2, ovvero entità essenziali per la società, e come tali devono rispettare requisiti stringenti di sicurezza informatica.
Ma NIS2 vale per tutte le multiutility, anche piccole? La direttiva adotta un criterio dimensionale: in generale si applica a tutte le entità di medie e grandi dimensioni nei settori critici
Ciò significa che se un’azienda rientra in quei settori ed ha almeno 50 dipendenti o 10 milioni di fatturato (definizione UE di PMI), allora è dentro NIS2. Tuttavia, attenzione: gli Stati membri possono identificare come essenziali anche entità più piccole, specie se uniche fornitrici di un certo servizio in un’area eur-lex.europa.eu.
Tradotto: se in un dato territorio l’acquedotto è gestito da una piccola società, lo Stato (o meglio le autorità competenti) potrebbe comunque assoggettarla a NIS2 perché da essa dipende l’acqua di migliaia di cittadini. Insomma, “se sei piccolo ma critico, NIS2 ti prende lo stesso”. In Italia il recepimento di NIS2 (delegato all’inizio del 2024) definirà esattamente criteri e autorità di controllo; ipotizziamo che molte multiutility locali, pur non gigantesche, finiranno nell’elenco delle entità NIS2 importanti o essenziali a seconda dei casi.
Cosa chiede in concreto NIS2? In breve, di fare sul serio con la cybersecurity. Le aziende coperte dovranno adottare misure di gestione del rischio informatico adeguate e documentarle. La direttiva elenca vari ambiti: controllo degli accessi, utilizzo di crittografia, sicurezza della catena di fornitura ICT, politiche di backup e disaster recovery, gestione delle vulnerabilità e aggiornamenti di sicurezza, formazione del personale, e via dicendo. Suona familiare? Molto – perché sono concetti che un bravo CISO (Chief Information Security Officer) già promuove e che spesso si ispirano a standard come ISO/IEC 27001. NIS2 di fatto obbliga le aziende critiche a dotarsi di un sistema di sicurezza equivalente alle best practice internazionali, trasformando ciò che era volontario (o dettato dal buon senso) in un dovere giuridico. Ad esempio, se un malware colpisce i sistemi di telecontrollo di una rete idrica, l’azienda non potrà più scrollare le spalle: verrà chiesto se aveva segmentato la rete, se i server erano aggiornati, se c’erano antivirus e monitoraggi – in sintesi, se aveva fatto tutto il possibile per prevenire l’incidente. La trasparenza regolatoria sale: ci si aspetta che le entità essenziali tengano traccia delle misure adottate e siano pronte a esibire documentazione e report in caso di ispezioni o audit da parte delle autorità competenti.
Una novità “traumatica” introdotta da NIS2 è poi il regime di notifica degli incidenti. Mentre prima solo alcune infrastrutture dovevano notificare incidenti gravi, ora tutte le entità NIS2 dovranno segnalare ogni “incidente significativo” (significant incident) secondo un iter preciso: entro 24 ore da quando ne vengono a conoscenza va inviata un’early warning (allarme preliminare) al CSIRT nazionale o altra autorità designata, con le info basilari disponibili eur-lex.europa.eu;
entro 72 ore dovranno inviare una notifica completa con informazioni più dettagliate e una prima analisi dell’impatto eur-lex.europa.eu;
infine, entro un mese dall’incidente dovranno produrre un report finale con le risultanze definitive eur-lex.europa.eu.
Il tutto “without undue delay”, cioè senza indugio. Vi suona familiare il numero 72 ore? Eh già, è lo stesso termine del GDPR per i data breach, ma NIS2 rincara la dose aggiungendo il preavviso a 24 ore e il rapporto finale a 1 mese. Due normative, tre scadenze, tanti grattacapi. Immaginate di essere sotto attacco ransomware: sistemi bloccati, tecnici nel panico… e intanto entro 24 ore qualcuno deve pure scrivere all’ACN (Agenzia per la Cybersicurezza) che siete sotto attacco!
Un incubo? Sì, ma con una logica: le autorità vogliono poter offrire supporto tempestivo e soprattutto monitorare in tempo reale la situazione per evitare effetti domino. Certo, per una PMI dover sottomettere modulistica entro 24 ore durante un’emergenza è dura. Non a caso la direttiva invita a fare in modo che queste notifiche non sovraccarichino le imprese durante la gestione dell’incidente eur-lex.europa.eu.
NIS2 inoltre prevede sanzioni pesanti per chi non si adegua. Gli Stati dovranno fissare multe che, per le entità essenziali, arrivino almeno a 10 milioni di euro o al 2% del fatturato annuo mondiale (qualunque sia maggiore)
Quindi, se una multiutility ignora gli obblighi di sicurezza o non notifica un incidente grave, rischia botte quasi paragonabili a quelle del GDPR. Non parliamo più di “consigli”, ma di imperativi legali con i denti.
Un aspetto interessante per le multiutility è che NIS2 allarga il perimetro oltre l’azienda stessa, richiedendo attenzione anche ai fornitori e partner ICT (supply chain). Molti servizi essenziali si appoggiano a sistemi forniti da terzi (basti pensare a software gestionali, sensori IoT per le reti, servizi cloud per archiviare dati). La direttiva sottolinea che le entità essenziali devono tenere conto dei rischi nella catena di approvvigionamento e, se necessario, imporre requisiti di sicurezza ai fornitori
In pratica, la nostra multiutility dovrebbe scegliere fornitori ICT affidabili, magari certificati, e inserire nei contratti clausole che li obblighino a standard di sicurezza elevati. Non è fantascienza: già oggi alcune aziende chiedono ai vendor certificazioni o audit (es: compliance ISO 27001, pen test annuali, ecc.). NIS2 spingerà questa prassi rendendola comune anche per acqua, luce e gas. Il piccolo gestore idrico che compra un software di telelettura contatori dovrà iniziare a chiedersi: “Questo software è sicuro? Il fornitore come gestisce gli aggiornamenti e le vulnerabilità?”. Già, le vulnerabilità: la direttiva menziona anche l’importanza di avere procedure per gestire le falle di sicurezza note – ad esempio applicare le patch appena disponibili, o avere un canale per ricevere segnalazioni di bug (famoso vulnerability disclosure). Se un ricercatore scopre un buco in un sistema di smart metering, l’azienda dovrebbe essere in grado di ricevere l’informazione e correre ai ripari, invece di scoprirlo dai giornali.
Prima di proseguire, una nota “sociale”: i considerando di NIS2 riconoscono esplicitamente che la digitalizzazione di utility urbane (smart cities, reti idriche intelligenti, ecc.) le rende vulnerabili e che un attacco potrebbe colpire i cittadini su larga scala
Sottolineano anche che le PMI affrontano sfide particolari in cybersicurezza (costi, consapevolezza bassa, ecc.) e vanno aiutate dagli Stati
Insomma, l’UE sa che chiedere a un’azienda di 60 dipendenti di avere una sicurezza “da banca” è oneroso; perciò auspica supporto e magari risorse ad hoc. Ma la direzione è tracciata: utilities digitali = infrastrutture da blindare. E se GDPR voleva che i dati servissero l’uomo, NIS2 vuole che la tecnologia non tradisca l’uomo nel momento del bisogno. In concreto, per una multiutility significa far sì che non saltino le luci, non resti a secco l’acqua e non si blocchi la raccolta rifiuti a causa di un hacker. Un obiettivo nobile anche questo, ma che richiede investimenti, competenze e… tanta, tanta compliance documentale.
Cyber Resilience Act: prodotti smart sotto la lente
All’orizzonte regolatorio europeo spunta un altro acronimo che promette di dare filo da torcere ai dipartimenti tecnici: il Cyber Resilience Act (CRA). Si tratta di un regolamento proposto dalla Commissione UE a fine 2022 e approvato in via definitiva nel 2024, che introdurrà (entro un paio d’anni dall’adozione) requisiti di sicurezza informatica obbligatori per tutti i prodotti con elementi digitali immessi sul mercato europeo
digital-strategy.ec.europa.eu.
In parole povere: qualsiasi dispositivo hardware o software “intelligente” dovrà rispettare degli standard di cybersecurity dalla progettazione in poi, e chi lo immette sul mercato dovrà certificarne la conformità con il marchio CE (sì, proprio come avviene per la sicurezza elettrica o la compatibilità elettromagnetica). È un cambio di paradigma: finora realizzare prodotti sicuri era buona pratica, ma non sempre obbligatorio per legge a livello generico. Con il CRA, se un prodotto digitale non è cyber sicuro, sarà considerato non conforme e potrà essere ritirato dal mercato, con sanzioni fino a 15 milioni di euro o 2,5% del fatturato per i fabbricanti inadempienti (dati della proposta originaria). Lo scopo dichiarato? Proteggere consumatori e imprese da prodotti insicuri, aumentando la fiducia nel mondo IoT e software
digital-strategy.ec.europa.eu.
Okay, ma cosa c’entra questo con le multiutility? Beh, pensate alla miriade di dispositivi smart che queste aziende utilizzano o forniscono: contatori intelligenti (smart meter) per luce, gas, acqua; centraline IoT nei quartieri per monitorare perdite idriche; sensori nei cassonetti “intelligenti” per l’immondizia; gateway di rete che trasmettono i dati dei contatori; senza contare le app mobile o desktop che le multiutility offrono ai clienti (che sono a tutti gli effetti software). Ebbene, tutti questi sono prodotti con elementi digitali. Il smart meter in particolare è emblematico: è un device elettronico connesso che raccoglie dati e li invia – quindi ha un potenziale impatto sia sulla privacy (GDPR) sia sulla sicurezza di rete (NIS2). Il CRA aggiunge un ulteriore livello: la sicurezza intrinseca del prodotto stesso. Ad esempio, il contatore intelligente dovrà soddisfare requisiti minimi di robustezza contro attacchi, non avere password di default banali, ricevere aggiornamenti di sicurezza per un periodo definito dopo la vendita, ecc. Sarà il produttore del contatore (tipicamente aziende specializzate che forniscono gli apparati alle utility) a dover garantire e dichiarare la conformità. E infatti nell’allegato del regolamento CRA i “smart meter gateways” – dispositivi di comunicazione per contatori intelligenti – sono espressamente citati come prodotti critici che richiedono requisiti elevati
Ma attenzione: anche la multiutility stessa potrebbe trovarsi coinvolta direttamente. Immaginiamo il caso in cui l’azienda sviluppi in-house un’app per i clienti o un software per la gestione dei servizi: in quel caso, l’azienda diventa essa stessa “fornitore di prodotto digitale” e quindi soggetta al CRA. In altri termini, se Acea, A2A o la piccola Multiutility XYZ producono un’app e la distribuiscono agli utenti, dovranno assicurarsi che rispetti i requisiti di sicurezza del CRA (ad esempio, che non abbia vulnerabilità note, che gli sviluppatori abbiano seguito pratiche sicure, ecc.) prima di “immetterla sul mercato” (o renderla disponibile ai clienti). Si prospetta dunque un futuro in cui le multiutility, oltre a chiedere il certificato CE sui dispositivi che comprano dai fornitori, dovranno certificare i propri prodotti software.
Il CRA porta con sé documentazione e verifiche: i produttori dovranno stilare un fascicolo tecnico sulla cybersecurity del prodotto, fare valutazioni dei rischi, e a seconda della criticità, potenzialmente sottoporsi a conformity assessment (valutazione di conformità) da parte di organismi notificati esterni. Per uno smart meter gateway, ad esempio, potrebbe essere richiesto un audit di terza parte in quanto rientrante tra i prodotti critici (Classe II). Questo scenario ricorda molto da vicino i meccanismi della marcatura CE tradizionale: insomma, l’IoT di casa (o di città) sarà trattato alla stregua di un giocattolo o di un dispositivo medico quanto a iter di certificazione. Una sovrapposizione con NIS2 appare chiara: NIS2 chiede alle utility di gestire la sicurezza dei propri sistemi, e parte di ciò include assicurarsi che i dispositivi usati siano sicuri; il CRA obbliga i produttori di quei dispositivi a costruirli sicuri fin dall’origine. In teoria, sono due pezzi dello stesso puzzle che si incastrano bene – in pratica, una multiutility si troverà nel mezzo: da utilizzatore di dispositivi, dovrà pretendere dai fornitori la conformità CRA (magari inserendo clausole nei contratti di fornitura: “il dispositivo XYZ deve essere marcato CE ai sensi del CRA e rispettare l’allegato I del regolamento”); da fornitore di servizi, beneficerà di un mercato con prodotti più sicuri (sperando). Ma non finisce qui: se la multiutility è essa stessa sviluppatore o integratore di soluzioni digitali (pensiamo a customizzazioni software o portali web complessi), dovrà allinearsi internamente alle richieste del CRA. Questo significa, ad esempio, predisporre processi di sviluppo sicuri (secure by design), test di penetrazione sui propri sistemi prima del rilascio, gestione delle vulnerabilità con patch regolari per le proprie applicazioni utente.
Una provocazione che circola tra gli addetti ai lavori: “i meter intelligenti dovranno diventare filosofi per capire se devono rispondere al GDPR o al CRA prima?”. Dietro l’iperbole c’è una verità: dispositivi come i contatori smart si trovano all’intersezione di più normative. Da un lato “rispondono” al GDPR perché raccolgono dati personali (chi consuma cosa e quando è un’informazione personale, eccome); dall’altro “rispondono” al CRA perché sono prodotti tecnologici che devono essere cyber-resilienti. Senza contare che “rispondono” anche a NIS2, in capo all’azienda che li gestisce. Chi prevale? In caso di incidente, il contatore deve “decidere” se è peggio violare la privacy dell’utente o lasciare che un attacco prenda piede? Ovviamente non è il contatore in sé a decidere, ma l’azienda dietro – e questa dovrà orchestrare la compliance in modo da rispettare sia la privacy sia la sicurezza. Questo a volte crea dilemmi pratici: ad esempio, se per sicurezza servirebbe conservare certi log tecnici dettagliati sul funzionamento del meter, ma quei log contengono dati personali, il GDPR impone restrizioni di conservazione. D’altro canto, se per privacy si anonimizzano o cancellano troppo presto i dati, si rischia di perdere tracce utili per la sicurezza. Trovare il bilanciamento sarà un’arte. Il CRA, almeno, gioca d’anticipo: imponendo sicurezza “by design” nel prodotto, cerca di prevenire incidenti che metterebbero in conflitto privacy e sicurezza. Un dispositivo ben costruito infatti dovrebbe minimizzare sia i rischi di data breach (buono per la privacy) sia i rischi di compromissione funzionale (buono per la continuità del servizio). Ma tra teoria e realtà ci sono in mezzo i budget e le capacità dei fornitori: non tutti i dispositivi saranno perfetti, e le multiutility dovranno vigilare.
Un ulteriore effetto del CRA sarà spingere verso una maggiore omogeneità di standard: ad esempio, potrebbero divenire comuni schemi di certificazione volontaria oggi poco diffusi. L’UE menziona spesso la volontà di sfruttare schemi EU di cyber-security certification (quelli previsti dal Regolamento Cybersecurity Act 2019) e standard armonizzati. In pratica, per dichiarare un prodotto conforme al CRA, un produttore potrebbe appoggiarsi a standard tipo IEC 62443 (per dispositivi industriali) o ISO 27001/ISA per processi di sviluppo. Le multiutility medio-grandi potrebbero quindi trovarsi ad aggiornare i propri capitolati tecnici: nelle gare per nuovi contatori o sistemi, inserire requisiti conformi al CRA, chiedere certificazioni, ecc. Un aggravio burocratico? Forse, ma anche un’opportunità per fare pulizia di prodotti scadenti. Quante volte in passato dispositivi IoT economici sono stati backdoor per attacchi informatici? Il classico esempio sono le videocamere IP insicure usate per botnet. Nel contesto utility, un contatore smart insicuro potrebbe diventare un punto d’ingresso per hacker nella rete aziendale o essere manipolato per frodi sui consumi. Garantire che ogni device immesso sul campo segua certe regole di sicurezza aiuterà anche le utility a dormire sonni più tranquilli.
Riassumendo, il CRA aggiungerà un tassello importante: compliance sull’oggetto tecnologico. Se GDPR è compliance sul dato, e NIS2 è compliance sull’organizzazione, il CRA è compliance sul prodotto. Per le multiutility italiane questo significa coinvolgere nei discorsi di conformità anche i reparti acquisti e i fornitori tecnici: il legale e l’IT dovranno capire insieme se un apparecchio rispetta il nuovo regolamento, leggere dichiarazioni di conformità, forse testare prodotti. Un cambio non da poco rispetto a quando bastava collegare il contatore alla rete e vedere se funzionava: ora bisognerà anche chiedersi se è “a prova di hacker” secondo la legge UE. Il filosofo qui non è il meter, ma l’ufficio tecnico che deve interrogarsi su questioni quasi metafisiche: “questo dispositivo può compromettere la protezione dei dati o la continuità del servizio? come lo rendo sicuro ab origine?”. Non stupisce che qualcuno l’abbia definita una rivoluzione copernicana nel mondo della marcatura CE dei prodotti digitali
E, come ogni rivoluzione, porterà inizialmente scompiglio, soprattutto alle PMI.
AI Act: l’intelligenza artificiale sotto controllo (anche nelle utility)
Ultimo – ma non per importanza – il Regolamento sull’Intelligenza Artificiale, comunemente detto AI Act, attualmente in fase finale di approvazione (previsto nel 2024 con applicazione nel 2025-2026). Questo regolamento mira a disciplinare l’uso dell’Intelligenza Artificiale ponendo divieti per usi inaccettabili e obblighi rigorosi per gli “AI ad alto rischio”, il tutto per assicurare che l’AI sia “sicura, trasparente, etica e al servizio dell’uomo”. Sì, di nuovo torna la frase “al servizio dell’uomo” – non a caso, il Considerando 6 dell’AI Act ribadisce che l’AI deve essere centrata sull’uomo e aumentare il benessere umano
Bellissimi propositi, ma veniamo al concreto: perché una multiutility dovrebbe preoccuparsene? Utilizzano forse chissà quali AI queste aziende? In realtà, è molto probabile che anche utilities medio-piccole inizino (o abbiano già iniziato) a usare soluzioni di intelligenza artificiale in vari ambiti, ad esempio:
- Ottimizzazione delle reti: algoritmi che prevedono i picchi di consumo elettrico o idrico e aiutano a gestire carichi (smart grid).
- Manutenzione predittiva: AI che analizza i dati di sensori sulle condotte o sugli impianti per prevedere guasti o perdite (ad esempio, individuare pattern di pressione dell’acqua che indicano una rottura imminente).
- Servizio clienti: chatbot o voicebot che rispondono alle domande degli utenti, o sistemi che smistano automaticamente le segnalazioni guasti.
- Fatturazione e analisi: algoritmi per stimare consumi, per proporre tariffazioni personalizzate, o per individuare anomalie (es. possibili consumi fraudolenti o errori di misura).
- Videosorveglianza e sicurezza fisica: se la multiutility gestisce infrastrutture critiche, potrebbe usare AI per analisi video, riconoscimento di intrusioni, ecc.
Ora, l’AI Act classifica come “alto rischio” diversi utilizzi di AI, in particolare quelli legati a infrastrutture critiche e servizi essenziali. Tra le categorie di high-risk AI elencate (Allegato III del regolamento) troviamo infatti: “AI usati come componenti di sicurezza nella gestione e funzionamento di infrastrutture critiche, ad esempio traffico stradale, fornitura di acqua, gas, elettricità, riscaldamento”
Tradotto: se una multiutility utilizza un sistema di AI che ha impatto sulla distribuzione di elettricità, acqua, gas (cioè può influenzare operativamente l’erogazione di quei servizi), quell’AI è considerata ad alto rischio. Anche senza entrare nel dettaglio legale, il buon senso lo conferma: un errore di un’AI in questi contesti può causare danni seri (blackout, mancanza d’acqua, incidenti). Pertanto, tali sistemi saranno soggetti a obblighi stringenti. Attenzione: l’AI Act distingue l’utilizzatore dell’AI dal fornitore dell’AI. Se la multiutility compra una soluzione AI da un vendor, sarà il vendor a doverla certificare come conforme (in quanto provider), ma l’azienda che la usa avrà comunque alcuni doveri (i deployer devono ad es. monitorarne l’uso e riscontrare eventuali problemi, nonché fornire istruzioni agli operatori umani, ecc.). Se invece la multiutility sviluppa internamente un sistema AI (scenario meno comune ma possibile per quelle più grandi), allora si assume gli obblighi del provider, dovendo fare l’iter di conformità completo.
Quali sono questi obblighi? Per un’AI ad alto rischio, l’AI Act richiede: gestione dei rischi dell’AI (analisi e mitigazione dei possibili impatti negativi), alta qualità dei dataset usati per addestrare il modello (per evitare bias o errori sistematici), documentazione tecnica dettagliata e registri delle attività dell’AI, trasparenza verso gli utenti (dev’essere noto che si sta interagendo con un sistema AI se rilevante) e, in certi casi, interfacce umane di controllo (human oversight) per poter correggere o annullare decisioni automatizzate
Inoltre, il sistema AI dovrà essere certificato CE prima di entrare in uso: ciò implica una valutazione di conformità (in molti casi autocertificazione del fornitore, in altri casi con audit esterno) e l’iscrizione in un registro UE degli AI ad alto rischio. Ad esempio, supponiamo che una multiutility implementi un algoritmo che, in automatico, stacca carichi elettrici non prioritari in caso di sovraccarico (demand response intelligente): questo tocca la gestione di infrastruttura critica (rete elettrica), quindi la soluzione AI dovrà essere conforme all’AI Act. Il fornitore dovrà attestare che ha addestrato e testato l’AI con dati appropriati (ad es. dati storici di carico), che l’AI non farà scelte “pazze” fuori dai parametri, che c’è sempre la possibilità di intervento manuale, e così via.
Un altro scenario nelle utility riguarda i sistemi decisionali sui consumatori. Immaginiamo un’AI che analizzi i consumi di un cliente e automaticamente limiti la potenza erogata se rileva un comportamento anomalo (tipo un consumo eccessivo che suggerisce un allaccio abusivo, quindi scatta la riduzione). Questa sarebbe una decisione automatizzata con impatto significativo sull’utente – qui oltre all’AI Act (se considerato servizio essenziale) entra in gioco pure il GDPR, art.22, che tutela dall’essere soggetti a decisioni totalmente automatizzate senza possibilità di contestazione. Ecco un’altra sovrapposizione normativa: il GDPR già prevede diritti contro le decisioni automatizzate (ad es. il diritto di ottenere intervento umano, di esprimere la propria opinione e contestare la decisione), mentre l’AI Act imporrà requisiti di trasparenza e spiegabilità per i sistemi ad alto rischio che prendono decisioni su persone. Le multiutility dovranno quindi stare attente: se usano AI per determinare qualcosa che incide sugli utenti (bollette, servizi erogati, agevolazioni, ecc.), devono prevenire discriminazioni o errori ingiusti. Un esempio concreto: mettiamo che un algoritmo suggerisca che certi utenti hanno perdite idriche occulte e li segnali per un controllo. Se l’algoritmo avesse bias (perché magari è stato addestrato su dati non rappresentativi), potrebbe segnalare più spesso certe zone o certi profili di utenti, causando trattamenti ingiusti. L’AI Act spingerà per analizzare questi rischi e correggerli prima che il sistema sia attivo, e mantenere monitorato il suo output.
Dal punto di vista pratico, per molte PMI utility l’AI Act potrebbe sembrare lontano (“noi non facciamo mica guida autonoma o riconoscimento facciale!”). Ma attenzione: basta anche usare un servizio cloud di terze parti che incorpora AI – ad esempio un sistema di videoanalisi per il perimetro di una centrale idroelettrica – per ricadere nel campo. Quel sistema di videoanalisi se fa rilevamento automatico di intrusi è AI in ambito sicurezza, potenzialmente ad alto rischio (sarebbe nell’ambito “sicurezza pubblica / applicazione della legge”? Forse no se è uso privato; ma se interagisce con forze dell’ordine magari sì). In ogni caso, l’impatto culturale dell’AI Act sarà far entrare il tema “AI responsabile” nei consigli di amministrazione di tutte le aziende. Una multiutility che vorrà innovare usando AI dovrà passare per una sorta di “valutazione di impatto AI” simile a quella privacy (DPIA). Non a caso, c’è chi suggerisce che andrà integrata una AI Impact Assessment nei processi aziendali, parallelamente alle DPIA GDPR
Le sovrapposizioni normative qui diventano una matassa intricata: AI Act e GDPR si intersecano su trasparenza, fairness e diritto a non subire decisioni automatizzate ingiuste; AI Act e NIS2/CRA si sfiorano sulla questione sicurezza (un’AI manomessa può diventare essa stessa vettore di attacco o causare malfunzionamenti gravi). Inoltre, l’AI Act prevede obblighi di registrazione e monitoraggio continuo: se un sistema AI ad alto rischio viene implementato, bisognerà mantenerlo sotto osservazione, loggare il suo funzionamento (ad es. tenere registri delle decisioni prese) e, se emergono problemi, ritirarlo o aggiornarlo. Immaginiamo una utility che usa un’AI per assegnare priorità di intervento sui guasti segnalati dai cittadini. Se ci si accorge che l’AI sbaglia spesso o penalizza certe segnalazioni, l’azienda ha il dovere di aggiustare il tiro – magari aggiornando il modello o sospendendolo – altrimenti rischia di violare il regolamento.
Le sanzioni? Anche l’AI Act conterrà un regime sanzionatorio robusto: fino a 30 milioni o 6% del fatturato per violazioni gravissime (es: usare AI proibite tipo social scoring di massa), e percentuali minori (2-4%) per altri inadempimenti come mancanza di conformità di un AI ad alto rischio. Di nuovo cifre teoricamente capaci di affondare chiunque, segno che l’UE prende sul serio la materia.
Riassumendo per le multiutility: l’AI Act potrebbe sembrare futuristico, ma in realtà colpisce esattamente i settori tradizionali che iniziano a usare l’AI per efficienza. Dovranno vigilare su come i sistemi automatici prendono decisioni. Non basterà dire “ha deciso l’algoritmo” – bisognerà poter spiegare perché, assicurarsi che non discrimini utenti o comprometta la sicurezza, e mantenere sempre un controllo umano sulle scelte più critiche (specialmente se incidono su persone o su infrastrutture vitali). È un nuovo genere di compliance, più “intellettuale” se vogliamo, perché tocca logiche di modelli matematici e principi etici. In una PMI multiutility, probabilmente nessuno ha in organico specialisti di etica dell’AI; servirà dunque formarsi o appoggiarsi a consulenti. C’è il rischio concreto che alcuni, per evitare grane, decidano di non adottare affatto AI innovative pur di non entrare nel perimetro dell’AI Act. Sarebbe un peccato, perché significherebbe rinunciare a miglioramenti tecnologici (ad esempio nel risparmio energetico o nel customer service) per paura della burocrazia. La sfida sarà trovare il modo di innovare in modo conforme, che in fondo è l’obiettivo dichiarato del regolamento: favorire lo sviluppo di un’AI affidabile e di valore per la società
Sovrapposizioni, ridondanze e possibili contrasti tra norme
Dopo aver passato in rassegna i principali pilastri normativi (privacy, sicurezza informatica, sicurezza dei prodotti e AI), torniamo al problema centrale: come convivono tutte queste norme tra loro? Purtroppo la risposta, almeno finora, è “non benissimo”. Ognuna è stata concepita separatamente, con obiettivi propri, e le imprese multiutility si trovano al crocevia, dove gli obblighi si sommano e talvolta confliggono. Vediamo alcune aree critiche di sovrapposizione.
- Sicurezza informatica vs. protezione dei dati (NIS2 ↔ GDPR): Come già accennato, sia GDPR che NIS2 impongono misure di sicurezza, ma con scope diverso. Risultato? Doppio lavoro se non si sta attenti. Ad esempio, il GDPR richiede di tenere un registro dei trattamenti e delle relative misure di sicurezza, NIS2 richiederà probabilmente un registro dei rischi cyber e delle misure di mitigazione. Sarebbe assurdo fare due documenti separati se parlano delle stesse reti e sistemi – e infatti la soluzione è integrarli. Un incidente di sicurezza che coinvolge dati personali deve essere notificato al Garante Privacy entro 72 ore e al CSIRT entro 24 ore (early warning) + 72 ore (report) eur-lex.europa.eu. Ciò implica predisporre procedure coordinate: non si può avere il DPO (Data Protection Officer) che manda la notifica privacy mentre il CISO manda quella cyber separatamente senza nemmeno parlarsi. Idealmente, bisogna scrivere un’unica procedura di incident response che copra entrambi i canali. Lo stesso vale per la gestione delle vulnerabilità: GDPR non lo dice esplicitamente, ma se una vulnerabilità minaccia i dati personali va risolta; NIS2 lo dice esplicitamente. Una risoluzione tardiva può portare sanzioni da entrambi i fronti (violazione dell’art.32 GDPR e degli obblighi NIS2).
- Documentazione e valutazioni di impatto: pensiamo a quante “carte” differenti potrebbero generarsi. Il GDPR prevede la DPIA (Data Protection Impact Assessment) per trattamenti di dati ad alto rischio privacy. L’AI Act richiederà l’AI risk assessment per sistemi ad alto rischio AI. NIS2 impone un risk assessment cyber globale dell’azienda. Il CRA richiede analisi dei rischi e fascicolo tecnico per ogni prodotto digitale. Se sfortunatamente una multiutility lanciasse un nuovo progetto innovativo che coinvolge tutti questi aspetti – per esempio, installare smart meter (CRA) che raccolgono dati personali (GDPR) analizzati da un’AI per ottimizzare la rete (AI Act) e il tutto integrato nei sistemi critici dell’azienda (NIS2) – rischia di dover produrre quattro analisi di rischio separate per lo stesso progetto, ognuna focalizzata su un aspetto. Un delirio! Invece servirebbe una valutazione unica o coordinata, che affronti privacy, sicurezza, AI in un colpo solo. Purtroppo le normative sono nate in tempi diversi e non sempre “parlano” tra loro. Qualche spiraglio c’è: NIS2 (Considerando 106) incoraggia gli Stati a creare un single entry point per notifiche di incidenti che valga anche per GDPR ed ePrivacy eur-lex.europa.eu e eur-lex.europa.eu, così da evitare doppie segnalazioni. È un segnale: i legislatori sanno che le aziende oggi devono notificare lo stesso evento a più autorità e cercano di semplificare almeno il canale di comunicazione. Analogamente, linee guida congiunte potrebbero unire DPIA e AI Assessment, dato che spesso un sistema AI che impatta individui richiederà sia DPIA (per privacy) sia analisi AI. Ad oggi però, sta alle aziende anticipare queste integrazioni, con buon senso.
- Ruoli organizzativi in potenziale conflitto: molte aziende hanno o avranno figure dedicate: il DPO per la privacy, il CISO/Responsabile Cybersecurity per NIS2, magari un Product Security Officer per seguire il CRA sui prodotti, e in futuro forse un AI Compliance Officer. Se ognuno di questi lavora a compartimenti stagni, sono guai. Ad esempio, il DPO potrebbe dire: “Questi log di sistema vanno cancellati dopo 1 mese per policy GDPR”, mentre il CISO potrebbe replicare: “No, per NIS2 devo conservarli 1 anno per indagini forensi sugli incidenti”. Chi ha ragione? Probabilmente nessuno dei due in assoluto: bisogna trovare un compromesso basato sul rischio e su ciò che le leggi effettivamente permettono (il GDPR consente eccezioni se i dati servono per obblighi di sicurezza? Sì, la base giuridica potrebbe essere l’obbligo legale di NIS2 stesso o il legittimo interesse alla sicurezza). Questo esempio mostra un potenziale conflitto apparente tra norme: privacy vs security. In teoria GDPR e NIS2 dovrebbero andare a braccetto (entrambe promuovono sicurezza, e GDPR stesso dice che il diritto alla protezione dati va bilanciato con altri interessi pubblici gdpr-text.com), ma nella pratica quotidiana i team devono comunicare costantemente per non prendere decisioni contrastanti. Lo stesso potrebbe valere tra chi si occupa di compliance prodotto e chi di sicurezza IT: il primo potrebbe dire “dobbiamo aggiornare subito il firmware di tutti i contatori perché lo chiede il fornitore per conformità CRA”, il secondo potrebbe ribattere “non posso aggiornare 10.000 dispositivi in un colpo solo senza test, rischio disservizi”. Un classico caso di sicurezza vs operatività: il CRA spinge per patch rapide, ma NIS2 e il buon senso operativo spingono per gestione del cambiamento controllata. Serve una strategia comune per decidere priorità e modi, senza farsi schiacciare da un obbligo a discapito di un altro.
- Ambiti non coperti e incertezza: paradossalmente, con tutte queste norme resta ancora qualche zona d’ombra. Ad esempio, il settore raccolta rifiuti (solidi) non è esplicitamente elencato in NIS2 come essenziale (lo sono acqua ed energia, ma i rifiuti urbani? Si potrebbe considerarli parte dei servizi pubblici critici ma non sono nominati). Tuttavia, i sistemi digitali di raccolta rifiuti (es. cassonetti intelligenti, o dati sui conferimenti) trattano dati personali e potrebbero essere vitali per una città pulita. Quindi il GDPR si applica sicuramente, NIS2 forse no (a meno che l’Italia non li includa nella sua attuazione), il CRA si applicherebbe ai dispositivi se connessi. Insomma, alcune multiutility avranno sottosistemi non chiaramente normati da NIS2 ma comunque importanti: in questi casi conviene applicare volontariamente certe misure di sicurezza, perché un attacco ai sistemi rifiuti potrebbe comunque avere impatti notevoli (pensiamo a blocco raccolta con scioperi digitali…). Ci troviamo con normative “a macchia di leopardo” e perimetri leggermente diversi: un sistema di illuminazione pubblica smart sarebbe coperto da NIS2 (energia), ma uno di irrigazione parchi smart forse no; eppure tecnicamente sono simili. Questo può portare confusione su dove investire risorse di compliance e dove si potrebbe soprassedere. La prudenza suggerisce: meglio elevare il livello generale e non fare troppo affidamento sulle scappatoie.
In sintesi, le ridondanze ci sono (esempi: piani di sicurezza duplicati, notifiche multiple, controlli che si sommano) e anche possibili contrasti (esempi: tempi di conservazione dati vs necessità di analisi, patch immediate vs stabilità del servizio). Il rischio per le aziende è di essere travolte da un overload burocratico: compliance fatigue, la fatica da adempimento. Specialmente le PMI possono viverla malissimo, percependo queste regole come un incessante susseguirsi di “cose da fare” spesso incomprensibili.
E qui arriva la domanda chiave: come evitare che la compliance diventi essa stessa un “malfunzionamento” dell’organizzazione? La risposta sta nel prossimo punto: cambiare approccio, passando dalla gestione dipartimentale e reattiva delle norme a un modello integrato e proattivo. Perché se c’è una cosa peggiore di avere molte normative, è applicarle una alla volta come se le altre non esistessero: si finisce con procedure confliggenti, costi duplicati e maggiore rischio di errori. Vediamo dunque come le multiutility possono provare a riorganizzare la propria compliance in modo intelligente (e magari più sereno).
Compliance integrata: dal caos multi-norma a un approccio omogeneo
Nel marasma di sigle e requisiti, la salvezza (o quantomeno un po’ di sollievo) può venire da un concetto semplice: integrare la gestione della compliance. Significa abbattere i “silos” aziendali e far lavorare insieme le funzioni legali, IT, security, operations, prodotto e chi più ne ha più ne metta, per impostare un sistema unico di gestione delle normative. Questo non vuol dire che GDPR, NIS2, CRA, AI Act diventino magicamente un’unica legge (magari!); vuol dire però trattarli come parti di un unico quadro di riferimento interno, evitando duplicazioni e conflitti.
Le multiutility di piccole-medie dimensioni, in particolare, spesso non hanno il lusso di reparti separati con decine di specialisti. Capita anzi che “i soliti noti” si trovino a indossare più cappelli: l’IT manager fa anche da responsabile sicurezza, il responsabile qualità si improvvisa DPO, e così via. Questo può essere un vantaggio mascherato: una stessa persona con più ruoli tende naturalmente a coordinare le esigenze. Se invece l’organizzazione è più strutturata (DPO nominato, CISO assunto, ecc.), bisogna creare momenti e strumenti di coordinamento. Ad esempio: istituire un tavolo di compliance periodico dove DPO, CISO, responsabile qualità, responsabili di servizio si confrontano sulle iniziative e sui rischi emergenti. Un caso pratico: l’azienda decide di lanciare un nuovo portale per i clienti dove possono vedere consumi in tempo reale (un bel progetto digitale). Invece di far muovere separatamente IT (per la parte tecnica), marketing (per l’UX), legale (per le condizioni contrattuali) e DPO (per la privacy), si convoca un meeting con rappresentanti di tutte queste funzioni prima di partire. Sul tavolo si mettono tutte le checklist normative contemporaneamente: privacy (serve informativa? serve consenso? DPIA?), sicurezza (come autentichiamo gli utenti? mettiamo MFA? protezione DDoS?), eventuale AI (c’è un algoritmo di consigli che rientra nell’AI Act?), aspetti di accessibilità (eh sì, dal 2025 c’è anche l’Accessibility Act, altra norma orizzontale, ma fermiamoci…), ecc. Così, già in fase di progettazione, si individuano i requisiti da soddisfare per ognuna e si cerca di soddisfarli in modo coerente. Magari la soluzione a tanti problemi è implementare da subito un certo accorgimento: es., se sappiamo che quell’app farà profilazione, prevediamo già un toggle per il consenso all’analisi avanzata, così l’UI/UX è fatta una volta sola correttamente. Questo approccio integrato è più efficiente – anche se all’inizio richiede mettere attorno al tavolo più persone e sembra rallentare, in realtà evita rework e rattoppi successivi quando qualcuno solleva un problema tardi.
Un altro elemento chiave è sviluppare internamente una sorta di framework unificato di controllo. Molte aziende stanno cercando di farlo tramite l’adozione di standard internazionali che coprano vari aspetti. Ad esempio, ISO/IEC 27001 (sistema di gestione della sicurezza delle informazioni) può fungere da impalcatura che copre gran parte dei requisiti NIS2 e in parte anche GDPR (sul lato sicurezza) velevo.blog.
Aggiungendo l’estensione ISO/IEC 27701 si ingloba il sistema di gestione privacy (GDPR compliance). Ci sono standard emergenti per l’AI (es. ISO/IEC 42001, futura norma sui sistemi di gestione dell’AI) che potrebbero aiutare con l’AI Act, e schemi come IEC 62443 per la sicurezza dei prodotti industriali che possono mappare sul CRA. Certo, non tutte le PMI possono certificarsi ISO – ma adottarne i principi internamente sì. Un beneficio di queste cornici unificanti è che promuovono la documentazione centralizzata: un unico manuale di sicurezza/Privacy, un unico registro rischi, ecc., con sezioni dedicate ai vari obblighi. L’obiettivo finale? Che quando arriva un auditor, sia esso del Garante, di ACN per NIS2, o un cliente importante che chiede evidenze, l’azienda possa aprire lo stesso armadio di documenti e trovare tutto: politiche, procedure, registri, analisi, piani. E che questi documenti non si contraddicano l’un l’altro.
Va detto che l’integrazione non è solo interna all’azienda, ma anche esterna: significa dialogare con le autorità e stakeholders in modo coordinato. Se capita un incidente, idealmente si dovrebbe poter mandare un unico report che soddisfi sia il Garante Privacy che l’ACN, invece di due relazioni diverse. Su questo, come visto, la NIS2 incoraggia i governi a creare sportelli unici eur-lex.europa.eu.
Sarebbe fantastico avere un portale nazionale dove inviare una sola notifica che poi viene smistata a chi di dovere (privacy, cyber, magari anche Agcom se di mezzo c’è una violazione di servizi telecom, ecc.). In mancanza, l’azienda può però predisporre template interni uniformati, così che quando deve notificare scrive un documento completo e poi ne deriva le comunicazioni verso i vari enti, assicurando coerenza. Un coordinamento esterno importante riguarda anche i fornitori: come dicevamo, molte compliance passano per la supply chain. Anche lì conviene evitare 10 questionnaire diversi per 10 fornitori sugli stessi punti (uno per privacy, uno per sicurezza, uno per qualità…). Meglio crearne uno integrato, da usare nelle due diligence o negli onboarding di nuovi partner, che tocchi tutti i requisiti: “Caro fornitore, hai misure di sicurezza X? Come gestisci i dati personali nostri che tratterai? Il tuo prodotto è certificato CRA? Usi AI nei servizi che ci dai e se sì è compliant AI Act?”. Sembra un interrogatorio? In parte lo è, ma almeno è uno solo e non frammentato.
Un’altra best practice è la formazione unificata del personale. Invece di fare sessioni separate di training: una sulla privacy, una sulla cyber, una sull’uso etico dell’AI, se ne può fare una combinata che spieghi ai dipendenti il concetto di responsabilità digitale a 360°. Ad esempio, raccontare uno scenario pratico: “Arriva una email di phishing, se ci clicchi possono rubare dati di clienti (violazione GDPR) e installare malware (incidente NIS2). Ecco perché devi stare attento e segnalare (compliance con entrambe le norme)”. Oppure: “Stiamo introducendo un nuovo strumento di analisi AI: se notate qualcosa di strano nei suoi risultati, ditelo, perché non dobbiamo prendere decisioni ingiuste (AI Act) né trattare male i clienti (principi generali)”. Così l’impiegato medio capisce non “il GDPR dice questo” ma “perché devo fare questa cosa che in fondo tutela sia i dati che la sicurezza e la correttezza verso le persone”. Un messaggio coerente è più facile da recepire che tante istruzioni sconnesse.
Da un punto di vista strategico, potrebbe valer la pena che le multiutility nominino un responsabile unico della compliance normativa (a livello direzionale) che supervisioni tutti questi ambiti, o creino una unità trasversale. Alcune grandi aziende hanno già il Chief Compliance Officer, che tipicamente copre ambiti regolatori multipli (es. finanziari, privacy, sicurezza). In una PMI non sarà un ruolo a tempo pieno, ma si può assegnare la responsabilità al dirigente qualità o legale, facendogli però avere sotto mano tutte le competenze (anche tecniche) necessarie tramite un team interfunzionale. Insomma, formalizzare che “compliance normativa” è essa stessa una materia unificata, con tanti sotto-temi.
Un segnale incoraggiante: stiamo vedendo anche a livello UE/nazionale approcci più olistici. Ad esempio, in Italia l’ACN (Agenzia Cyber) e il Garante Privacy hanno iniziato a collaborare su alcuni fronti, riconoscendo che sicurezza e privacy vanno a braccetto. L’Europa stessa, come citato, suggerisce template unici di notifica eur-lex.europa.eu.
Si parla di “compliance by design” intendendo quella mentalità di incorporare i requisiti regolatori fin dall’inizio nei progetti (concetto preso dalla privacy by design e ora esteso). C’è quindi speranza che la giungla normativa diventi un giardino più curato col tempo, ma intanto tocca alle imprese trovare sentieri praticabili.
Vorremmo poter dire che esiste uno strumento magico o un software che risolve tutto. In realtà, l’approccio integrato è più un cambio di mentalità e di processi che di tool. Certo, esistono piattaforme GRC (Governance, Risk & Compliance) che aiutano a mappare requisiti e controlli, ma se manca la volontà interna di collaborare, nessun software farà miracoli. Al contrario, anche con semplici fogli di calcolo e checklist condivise, ma con una squadra affiatata, si possono raggiungere ottimi risultati di compliance centralizzata.
Un ultimo vantaggio da sottolineare: la gestione unificata consente di trovare sinergie e magari coprire più norme con un’unica azione. Esempio: adottare la cifratura end-to-end in un sistema di telelettura contatori. Questa singola scelta tecnologica migliora la privacy dei dati (GDPR), la sicurezza contro attacchi (NIS2), e se implementata nel prodotto risponde ai requisiti di progettazione sicura (CRA). Tre piccioni con una fava. Oppure: dotarsi di un registro centralizzato degli asset digitali con relative valutazioni di rischio. Serve per NIS2 (sapere quali sistemi critici hai e i rischi associati) ma è utilissimo per il DPO per capire dove risiedono i dati personali (GDPR) e per il responsabile di prodotto per valutare l’esposizione dei dispositivi (CRA). Insomma, unire i puntini può creare efficienze. Questo non vuol dire che magicamente il lavoro si dimezza, ma almeno evitare di rifarlo da capo quattro volte, quello sì.
In conclusione di questa sezione, potremmo dire che integrare la compliance è un po’ come orchestrare una sinfonia: ci sono violini (privacy), viole (cybersecurity), violoncelli (AI), flauti (product security)… se ognuno va a tempo suo ne esce una cacofonia, ma con uno spartito comune e un direttore d’orchestra si può produrre qualcosa di armonioso. E magari – perché no – trasformare la compliance da peso burocratico a elemento di valore: un’azienda che gestisce bene questi aspetti lo può comunicare ai clienti come indice di affidabilità e serietà. Nel settore utility, dove il rapporto con l’utente è anche fiduciario (ci fidiamo che l’acqua sia potabile, che la luce arrivi, che i nostri dati siano al sicuro), essere compliant e saperlo dimostrare è ormai parte integrante della qualità del servizio.
Esempi (iper)pratici: dal contatore filosofo all’app assetata di consensi
Per stemperare la teoria, chiudiamo con qualche esempio ipotetico ma non troppo di situazioni che una multiutility italiana potrebbe trovarsi ad affrontare, e di come le diverse normative interagiscono (o interferiscono). L’ironia ci aiuterà a illustrare i punti chiave.
Esempio 1: Il contatore intelligente “filosofo”
Immaginiamo la Piccola Multiutility Alfa, che decide di installare nuovi smart meter gas ed energia presso i suoi clienti. Questi contatori misurano i consumi in tempo reale e li trasmettono via rete cellulare a un sistema centrale. Alfa vuole fare le cose in grande: i dati dei contatori saranno usati non solo per le bollette, ma anche per sviluppare un algoritmo AI che prevede i consumi e ottimizza la distribuzione (ad esempio abbassando la pressione sulla rete gas nelle ore di minor uso). Scenario futuristico? In realtà è dietro l’angolo con le smart grid. Ora, vediamo la valanga di compliance:
- GDPR: i dati di consumo per utente sono dati personali. Alfa deve informare i clienti che il loro contatore “parla” e invia dati dettagliati. Base giuridica? Probabilmente il contratto copre la fatturazione, ma l’uso per ottimizzazione di rete potrebbe richiedere legittimo interesse o consenso. Meglio fare magari un’integrazione contrattuale spiegando che i dati saranno usati in forma aggregata per migliorare il servizio (e assicurarsi che sia davvero aggregata/anomizzata abbastanza da non richiedere consenso). Visto che c’è di mezzo un’AI che prende decisioni sui flussi, niente decisioni individuali automatiche contro l’utente, altrimenti art.22 GDPR potrebbe suonare (non staccheremo mai individualmente un utente via AI senza intervento uman, per intenderci). DPIA quasi sicuramente necessaria, perché è un trattamento nuovo, massivo e un po’ invasivo (profilazione di consumi domestici).
- NIS2: il sistema rientra in infrastrutture energetiche essenziali. Alfa deve assicurarsi che i contatori e la rete di comunicazione siano sicuri: autenticazione dei dispositivi, crittografia dei dati trasmessi, segmentazione della rete IT/OT (la rete di telelettura separata dal resto). Deve anche aggiornare il piano di gestione incidenti: se domani un attacco colpisce i contatori (esempio realistico: malware che li manda in tilt), si ha un “significant incident”? Probabile sì, se un numero rilevante di utenti viene impattato. Quindi pronta la procedura di notifica entro 24h all’ACN. Alfa dovrà chiedere anche ai fornitori dei contatori quali misure di sicurezza hanno implementato (supply chain risk). Magari effettuare un penetration test sul sistema prima del go-live per scovare falle.
- CRA: i contatori stessi, se immessi sul mercato dopo l’entrata in vigore del CRA, dovranno avere marcatura CE per la cybersecurity. Alfa nel capitolato di acquisto dovrà richiedere che il prodotto sia conforme al CRA e verificare la dichiarazione del fabbricante eur-lex.europa.eu. Non solo: Alfa sta sviluppando l’algoritmo AI in-house, quindi quell’algoritmo più la piattaforma centrale costituisce un product with digital elements forse (se Alfa volesse venderlo ad altre utility lo sarebbe di sicuro; se è solo uso interno potrebbe non ricadere in CRA come prodotto commerciale, ma attenzione: se c’è un’app per i tecnici, è software destinato a utenti → prodotto). Qui entriamo un po’ nel grigio: diciamo che se Alfa sviluppa solo per sé, CRA non si applica direttamente, ma se l’app dei tecnici per monitorare i contatori fosse distribuita su store, diventerebbe prodotto. Comunque, in ottica CRA, conviene seguire standard di sviluppo sicuro. Alfa prepara documentazione tecnica come se dovesse certificare il sistema, così sta tranquilla.
- AI Act: l’algoritmo di ottimizzazione rete è AI su infrastruttura critica, bingo, alto rischio eur-lex.europa.eu. Alfa quindi deve: usare dati di training affidabili (prenderà storici consumi, attenzione a non includere bias stagionali), valutare i rischi (cosa succede se l’AI sbaglia di grosso? Mettiamo sempre un limite e un controllo umano: l’AI può suggerire di abbassare pressione gas, ma un operatore deve approvare, cosicché la decisione finale non sia mai totalmente automatica su qualcosa di così delicato). Documentare tutto: algoritmi, test, risultati attesi. E registrare il sistema nel database UE quando uscirà. Forse Alfa si affiderà a un fornitore esterno per l’AI; in tal caso buona parte di questi obblighi li soddisfa il fornitore, ma Alfa come utilizzatore dovrà monitorare performance e segnalare eventuali malfunzionamenti seri, oltre a istruire bene gli operatori sul corretto uso e limiti dell’AI.
Immaginate il project manager di Alfa che gestisce questa innovazione: a un certo punto esclamerà “Ma qui serve un filosofo più che un ingegnere!”. Deve cioè conciliare privacy degli utenti, sicurezza delle reti, requisiti tecnici dei prodotti e perfino aspetti etici dell’AI. Un contatore “filosofo” che si interroga su quale legge applicare prima è ovviamente uno scherzo, ma rappresenta l’azienda che deve farsi domande continue: posso fare X o violerei qualche regola?, se succede Y a chi devo dirlo?, il mio sistema rispetta il principio Z?. Fin troppo spesso in passato la tecnologia veniva implementata e solo dopo ci si chiedeva delle conseguenze; ora il legislatore impone di pensarci prima. Il contatore filosofo, in fondo, siamo noi – i responsabili del progetto – chiamati a una consapevolezza maggiore.
Esempio 2: L’app “assetata” di consensi
Consideriamo ora la Piccola Multiutility Beta, che fornisce il servizio idrico in una provincia. Beta lancia una nuova app mobile per i cittadini: attraverso l’app si può controllare il consumo d’acqua giornaliero, segnalare perdite o disservizi, ricevere comunicazioni (es. allerta qualità dell’acqua, lavori in corso). Un bel passo avanti in termini di trasparenza e coinvolgimento dell’utente. Ma con quali sfide normative?
- GDPR/ePrivacy: L’app richiede ovviamente un account utente legato al contratto idrico, quindi tratta dati personali (nome, codice cliente, consumi). Beta predisporrà una privacy policy chiara nell’app spiegando tutti i trattamenti. Qui si pone la questione del consenso: per usare l’app in sé, il consenso non serve perché il trattamento dati è necessario per il servizio richiesto dall’utente (monitorare i suoi consumi su sua richiesta). Però l’app magari vuole fare di più: ad esempio, inviare notifiche push di promozioni (tipo “Hai consumato meno della media, bravo! Partecipa al concorso Green!”) – per queste finalità promozionali, servirà il consenso marketing, esattamente come per le newsletter. Inoltre, se l’app traccia la posizione dell’utente per indicizzare le segnalazioni geograficamente, sarà necessario il permesso GPS e informare bene l’utente (qui entra anche la dimensione ePrivacy: geolocalizzazione = dato personale delicato). E poi l’annoso tema cookie/analytics: l’app mobile potrebbe usare strumenti di analisi utilizzo (telemetria, Crashlytics, ecc.) – molti di questi rientrano nelle tecnologie di tracciamento che richiedono consenso informato se non sono strettamente necessarie. Quanti consensi deve chiedere quest’app? Idealmente Beta cerca di limitarli: per funzionamento base niente consenso (solo informativa), per notifiche promozionali sì, per analytics cerca di usare dati aggregati o anonimi così da non dover chiedere nulla. Ma se usa ad esempio Google Firebase Analytics, di fatto sta inviando dati a terzi e profilando, quindi deve chiedere opt-in. Ecco che la UX potrebbe rischiare di diventare un incubo di popup: “Accetti i termini? Accetti l’uso dei tuoi dati per migliorare il servizio? Consenti all’app di usare i tuoi dati di consumo per consigli personalizzati? [Consenti] [Nega]”. Da qui la battuta: l’app dell’acqua deve chiedere il consenso per ogni goccia tracciata? Ovviamente Beta cercherà di raggruppare consensi in maniera sensata e soprattutto di progettare l’app in modo da non dover chiedere consensi inutili. Ad esempio, molte statistiche possono essere fatte on-device senza inviare dati a terzi, evitando la necessità di consenso per analytics di terza parte. Rimane obbligatoria però la trasparenza: l’utente va informato chiaramente e non sommerso di richieste oscure.
- Sicurezza (NIS2): Beta, essendo gestore idrico, è entità essenziale. L’app ora diventa un nuovo punto di accesso al sistema: potenzialmente, se male sviluppata, un hacker potrebbe sfruttare l’app per entrare nei database (ad es. attraverso vulnerabilità API). Quindi Beta deve coinvolgere il team sicurezza per test di penetrazione sull’app e l’infrastruttura backend. Inoltre, attraverso l’app passano comunicazioni forse critiche (se include avvisi di qualità dell’acqua, tocca safety pubblica). NIS2 impone di valutare questi rischi: Beta implementa autenticazione robusta (magari SPID/CIE per verificare l’utente? O almeno MFA se possibile), cifratura dei dati, e prepara un piano nel caso l’app subisca un attacco (ad es. injection di messaggi falsi agli utenti: scenario in cui un attore malevolo invia via app un’allerta “Acqua contaminata, non bevetela” creando panico – sembra paranoico ma con IoT e sistemi integrati anche queste comunicazioni rientrano nel perimetro di sicurezza). Beta potrebbe decidere di certificare l’app ISO27001 o seguire linee guida OWASP per applicazioni sicure. Tutto questo per dire: la compliance NIS2 spingerà Beta a considerare l’app non solo un gingillo marketing, ma un elemento IT critico da proteggere seriamente.
- CRA: supponiamo che Beta si sia fatta sviluppare l’app da una software house e la distribuisce sugli store Android/iOS come “WaterBeta – L’acqua smart”. Ebbene, Beta diventa in pratica il fornitore di un prodotto software al pubblico. Quando il CRA sarà effettivo, quell’app rientra tra i prodotti digitali e Beta dovrà garantirne la conformità in termini di cybersecurity. Probabilmente l’app sarà classificata a basso rischio (non credo rientri tra i “critical products” a meno di non integrarsi con cose tipo meter gateways, ma in sé no). Tuttavia Beta dovrà assicurare, ad esempio, che l’app non abbia vulnerabilità note al momento del rilascio, che ci sia un modo per segnalare falle (un contatto security@…), e dovrà fornire aggiornamenti di sicurezza se emergono problemi. Inoltre, dovrà dichiarare la conformità CE. Questo è nuovo per Beta: finora pensava alle app come a un progetto IT, ora dovrà trattarle con la stessa attenzione di un dispositivo fisico in termini di marcatura CE. È probabile che Beta deleghi la cosa al fornitore (contrattualmente: “lo sviluppatore garantisce che l’app soddisfa CRA e mi fornisce documentazione”), ma la responsabilità legale in quanto brand owner dell’app rimane anche sua. Quindi Beta dovrà un minimo entrare nei dettagli tecnici.
- AI Act: l’app in sé forse non ha AI (a meno che Beta non integri un chatbot di supporto AI per rispondere alle domande frequenti, cosa plausibile). Se integrasse un chatbot generativo per aiutare gli utenti (“Perché la mia bolletta è alta questo mese?” risponde l’AI), quel chatbot rientra nei sistemi interattivi generici non per forza alto rischio (non è decisivo su diritti, è un supporto). Però Beta dovrebbe comunque etichettarlo: far capire all’utente che sta parlando con un AI e non con un operatore umano, per trasparenza (l’AI Act impone questa trasparenza per i sistemi che generano testi indistinguibili da umani). Immaginiamo la chat nell’app con un disclaimer “Sei assistito da un agente virtuale intelligente. Fai clic qui per avere un operatore umano in qualsiasi momento.”. Anche questa è compliance user-centric. Se l’AI dovesse consigliare all’utente comportamenti (tipo: “vedo che consumi 150L/giorno, dovresti ridurre”), Beta dovrebbe vigilare che siano consigli appropriati e non ledano diritti (es: non colpevolizzare eccessivamente, o non fare profiling illecito – anche qui privacy e AI se toccano le persone si mescolano).
Da questo secondo esempio si capisce che anche un’iniziativa relativamente semplice come un’app consumer porta con sé implicazioni multi-norma. La battuta sul chiedere il consenso per ogni goccia evidenzia il rischio di un’eccessiva frammentazione dell’esperienza utente a causa dei requisiti normativi. L’arte sta nel disegnare esperienze compliance-friendly: Beta potrebbe, ad esempio, presentare un unico onboarding iniziale chiaro in cui raccoglie tutti i consensi necessari in modo granulare ma non assillante, spiegando i benefici (“Ti mandiamo consigli per risparmiare – vuoi riceverli?”) invece di meri legalese. Dal lato sicurezza, Beta potrebbe comunicare agli utenti che l’app è certificata sicura e che i dati viaggiano criptati (costruendo fiducia). Insomma, trasformare la compliance in un vantaggio competitivo: “Usa la nostra app: è comoda, e i tuoi dati sono protetti secondo i migliori standard europei”. Non suona male come slogan, no?
Conclusioni
Siamo arrivati al termine di questo viaggio ironico-serio attraverso le sfide normative delle multiutility italiane. Abbiamo visto come un’azienda che fornisce servizi essenziali debba destreggiarsi tra una molteplicità di regolamenti europei: proteggere i dati personali dei clienti (GDPR), assicurare la sicurezza informatica delle reti e dei servizi (NIS2), garantire la robustezza dei prodotti tecnologici usati (CRA) e persino controllare lo sviluppo e l’uso di algoritmi intelligenti (AI Act). Il tutto senza perdere di vista la propria missione primaria: erogare acqua, luce, gas, raccogliere rifiuti in modo efficiente e affidabile.
È evidente che le normative, per quanto necessarie e importanti, rischiano di diventare un carico pesante soprattutto per le piccole e medie imprese del settore. La burocrazia tecnica-legale può togliere energie che invece sarebbero preziose per l’innovazione e il miglioramento del servizio. Ed ecco il paradosso: norme pensate per promuovere fiducia e innovazione possono, se gestite male, trasformarsi in freni e paure. Il nostro tono ironico ha messo in luce proprio questi possibili cortocircuiti: il contatore che deve “meditare” sulle leggi, l’app sommersa di consensi. Sono caricature, certo, ma non lontanissime da ciò che potrebbe accadere se si applicassero le regole in modo miope o burocratico.
Qual è dunque il messaggio finale? Conoscere e capire le norme è il primo passo (e speriamo che questo articolo abbia contribuito a chiarire qualche dubbio, magari strappando un sorriso). Il secondo passo, fondamentale, è adottare un approccio strategico integrato: fare della compliance non un male necessario da subire passivamente, ma una componente organica della gestione aziendale. Le multiutility, per loro natura, sono già abituate a integrare discipline diverse – ingegneria, aspetti ambientali, relazioni con la comunità. Aggiungere la componente normativa-tech a questo mosaico è una sfida, ma non una missione impossibile. Significa investire in competenze (formare il personale, coinvolgere esperti quando serve), rivedere processi interni per abbattere i silos, dialogare con i fornitori e magari con altre utility per scambiarsi buone pratiche (perché scommettiamo che tutte stanno affrontando problemi simili: l’unione potrebbe fare la forza anche nel capire come rispondere a certi requisiti).
Va detto che il legislatore europeo non ha come obiettivo affossare le aziende con oneri inutili – al contrario, cerca di creare un mercato più armonizzato e resiliente. Se una multiutility riesce a conformarsi a GDPR, NIS2, CRA, AI Act, si ritroverà con processi più solidi, sistemi più sicuri, dati più accurati. Tutto ciò può tradursi in meno incidenti, meno sprechi, più efficienza a lungo termine. Ad esempio, investire in cybersecurity riduce il rischio di costosi fermi impianto; investire in governance dei dati migliora la qualità delle informazioni su cui si basano le decisioni aziendali. Dunque, la compliance vista non come costo puro, ma come investimento. Certo, questo non toglie che nell’immediato vada gestito l’impatto di adeguamento: serviranno risorse, budget, priorità di management. È qui che le PMI potrebbero avere bisogno di supporto da associazioni di categoria o istituzioni: linee guida semplificate, tool gratuiti, finanziamenti per la digitalizzazione sicura. Non sarebbe male vedere programmi pubblici che aiutino le piccole utility a dotarsi, ad esempio, di sistemi di cybersecurity base o consulenza per DPIA/AI senza costi proibitivi.
Chiudiamo dunque immaginando il futuro prossimo: l’amministratore di una multiutility locale sfoglia questo articolo e, invece di disperarsi per le troppe regole, decide di farne il tema di una riunione strategica. Coinvolge IT, legale, operations e dice: “Bene, come facciamo a trasformare la nostra azienda in un modello di compliance integrata? Quali passi concreti da domani mattina?”. Se questo succederà, anche solo in una realtà, avremo raggiunto lo scopo. Perché l’obiettivo finale non è spaventare con lo spettro delle sanzioni, ma incentivare un cambio di passo culturale. In un mondo sempre più interconnesso e digitale, privacy, sicurezza, affidabilità tecnologica e uso etico dell’AI non sono concetti astratti: sono ingredienti della fiducia che utenti e comunità ripongono nei servizi pubblici. E le multiutility, gestendo beni primari, di quella fiducia vivono.
Dunque, la prossima volta che aprirete il rubinetto o accenderete la luce, pensate per un attimo che dietro quel gesto semplice c’è (anche) tutto un universo di compliance al lavoro per voi: dalla protezione dei vostri dati di consumo, alla difesa dalle cyberminacce, alla garanzia che i dispositivi funzionino in modo sicuro, fino al monitoraggio intelligente delle reti. Se tutto questo funziona in silenzio, senza che ve ne accorgiate, significa che la multiutility ha fatto un ottimo lavoro. E probabilmente, in qualche ufficio, un “contatore filosofo” starà sorridendo, soddisfatto di aver trovato la sua risposta alla domanda iniziale: GDPR o CRA? – la risposta è: entrambi, caro contatore, e anche NIS2 e AI Act, perché alla fine servono tutti a una cosa sola: migliorare e proteggere il servizio che dai agli esseri umani.
Fonti:
- Regolamento (UE) 2016/679 (GDPR) – Principi di trattamento e sicurezza dei dati (artt. 5, 32) velevo.blog.
- Direttiva (UE) 2022/2555 (NIS2) – Considerando (53) sulle utility digitali e rischi per i cittadini eur-lex.europa.eu; Allegato I (settori essenziali: energia, acqua) eur-lex.europa.eu; Obblighi di notifica incidenti (Considerando 102) eur-lex.europa.eu.
- Proposal Cyber Resilience Act – Allegato IV, prodotti critici (inclusi smart meter gateways) eur-lex.europa.eu .
- Proposal AI Act – Allegato III, Sistemi AI ad alto rischio in infrastrutture critiche (es. fornitura acqua, gas, elettricità) eur-lex.europa.eu.
- Blog Velevo – “NIS2 and GDPR: overlaps in security and data protection” (common obligations e sanzioni) velevo.blog e velevo.blog.
- Medium @martino.agostini – “NIS2 and GDPR in Italy: imperative for cybersecurity and data protection” (importanza strategia coesa e allineamento IT-legale) medium.com.
- Direttiva NIS2 – Considerando (106): incoraggiato sportello unico per notifiche multi-norma (GDPR, ePrivacy) eur-lex.europa.eu.
Appendice: e le altre norme?
Di seguito una panoramica (non esaustiva) di alcune normative tecniche italiane che possono riguardare da vicino le multiutility nei quattro ambiti principali (elettricità, gas, acqua, rifiuti), con particolare riferimento alle norme UNI e ad altri riferimenti nazionali di carattere obbligatorio o “quasi obbligatorio” (per esempio perché richiamati da leggi, regolamenti o delibere ARERA). Evidenzieremo anche possibili sinergie e potenziali “frizioni” con la cornice UE (GDPR, NIS2, CRA, ecc.) già citata.
1. Normative generali di settore (ARERA & Testo Unico Ambientale)
ARERA (Autorità di Regolazione per Energia Reti e Ambiente) Le delibere e i regolamenti di ARERA costituiscono un insieme di obblighi che le multiutility (specie quelle che erogano energia elettrica, gas, servizio idrico integrato e, in parte, rifiuti) devono osservare. Riguardano:
- Standard di continuità e qualità del servizio (es. la Delibera 566/2019/R/gas per la qualità del gas; la Delibera 569/2019/R/eel per l’elettricità; i Testi integrati TIVG, TIQE, RQTI, ecc.).
- Regolazione tariffaria (determinazione e trasparenza delle tariffe, copertura costi di investimento, ecc.).
- Servizio Idrico Integrato (Delibere specifiche su qualità contrattuale, indicatori di performance, ecc.).
- Gestione rifiuti: ARERA ha assunto poteri regolatori anche nel settore rifiuti urbani e assimilati (ad es. Delibera 443/2019/R/rif e il TQRIF – Testo unico per la Qualità del servizio Rifiuti).
Sebbene si tratti di regolazione nazionale, essa può creare sinergie con i temi europei di NIS2 e GDPR, in quanto la trasparenza verso l’utente, la definizione di procedure standard, la raccolta dati di servizio e la continuità dell’erogazione sono principi che vanno di pari passo con la sicurezza informatica e la protezione dei dati personali. Tuttavia, alcuni obblighi ARERA potrebbero implicare la conservazione di dati di utenza (per finalità di controllo e fatturazione) per periodi lunghi, potenzialmente entrando in “frizione apparente” con il principio di minimizzazione GDPR (art. 5). In questi casi, occorre bilanciare le due esigenze e documentare il tutto in apposite DPIA o policy privacy.
Testo Unico Ambientale (D.Lgs. 152/2006) Regola gli scarichi idrici, la gestione delle risorse idriche e i rifiuti (Parte IV del TUA). Sebbene sia più di natura ambientale che tecnico-impiantistica, è importantissimo per le multiutility idriche e di igiene urbana, perché vincola le modalità di gestione operativa (scarichi, smaltimenti, limiti di emissione). Anche qui possono emergere problemi di interoperabilità con le normative UE su sicurezza (NIS2) o su dispositivi (CRA) quando si introducono sistemi di monitoraggio IoT, telecontrollo degli impianti di depurazione o tracciamento dei rifiuti (MUD e registri elettronici), che trattano dati e richiedono misure di sicurezza adeguate.
2. Norme UNI e CEI specifiche per i singoli servizi
2.1 Settore elettrico
- CEI 0-16 (evoluzione di CEI 11-20) e CEI 0-21: regole tecniche di riferimento per allacciamenti e distribuzione in media e bassa tensione. Riguardano sia gli aspetti di sicurezza sia quelli di interfaccia e protezione delle reti elettriche. Non sono “UNI” bensì “CEI”, ma hanno valore quasi cogente perché richiamate da provvedimenti ARERA.
- CEI EN 50110 (Sicurezza negli impianti elettrici): prescrive misure e procedure per operare in sicurezza sui sistemi elettrici in esercizio.
- CEI 11-27: definisce i requisiti di sicurezza per i lavori su impianti elettrici (competenze PES/PAV, ecc.).
Sotto il profilo “GDPR / NIS2”:
- La continuità del servizio elettrico impone standard di sicurezza (anche informatica) – c’è dunque sinergia con NIS2, che richiede la protezione delle infrastrutture IT/OT.
- Alcune norme CEI prescrivono registrazioni e monitoraggi di parametri di rete che possono (in parte) includere dati di utenti o fornitori, il che tocca la privacy.
2.2 Settore gas
- UNI 7129 (installazioni domestiche e similari): disciplina la progettazione, l’installazione e la manutenzione degli impianti a gas combustibile per uso civile.
- UNI 7131 (impianti a GPL non alimentati da rete di distribuzione): regole per l’installazione e l’esercizio di serbatoi fissi di GPL.
- Altre norme UNI/TS (specifiche tecniche) legate ai materiali e alla posa delle reti di distribuzione gas (ad es. UNI 9860 e simili), spesso richiamate nei capitolati pubblici e nei regolamenti edilizi.
Molte di queste norme riguardano la sicurezza “fisica” dell’impianto (antincendio, dispersioni, ecc.). Tuttavia, con l’introduzione di smart meter gas e sistemi di telelettura, si inserisce un elemento digitale che potrebbe cadere sotto CRA (per la sicurezza del dispositivo) e sotto NIS2 (essendo infrastruttura critica). Qui potrebbe esserci frizione tra le tempistiche di aggiornamento delle norme UNI (spesso lente) e la rapidità delle imposizioni europee in materia di cybersecurity.
2.3 Settore idrico
- UNI EN 805: requisiti per la progettazione e la costruzione di reti di alimentazione d’acqua per uso umano.
- UNI EN 1717: protezione contro l’inquinamento dell’acqua potabile e requisiti generali dei dispositivi di protezione contro il riflusso.
- UNI 10779, pur essendo focalizzata sugli impianti antincendio a idranti, a volte si intreccia con le competenze dei gestori idrici (ad es. per l’alimentazione di reti di emergenza).
- Norme specifiche sulla misurazione (UNI EN 14154 per i contatori d’acqua fredda, UNI EN ISO 4064) che diventano cogenti quando vengono incorporate nei requisiti di fornitura ai sensi delle delibere ARERA e delle normative metrologiche nazionali.
L’aspetto “digitale” emerge negli smart meter idrici e nel telecontrollo delle reti (SCADA). Anche in questo ambito, la sinergia/frizione con GDPR, NIS2 e CRA è simile: le norme UNI/EN a volte non disciplinano in dettaglio la sicurezza informatica dei dispositivi, lasciando il gestore di rete a dover integrare standard di cybersecurity (es. IEC 62443, ISO 27001) per ottemperare a NIS2, e richiedendo ai fornitori di meter la conformità CRA (quando in vigore). Potrebbe dunque esserci un gap tra la conformità tecnica “tradizionale” (UNI/EN 805) e la compliance cybersecurity/DP che l’UE chiede.
2.4 Settore rifiuti
- Le norme UNI di riferimento per i rifiuti non sono numerose quanto in altri campi, ma ne esistono diverse sulle metodologie di campionamento, classificazione e gestione di specifiche tipologie di rifiuto (es. UNI 10802 per campionamento e analisi dei rifiuti).
- UNI 11686 (definizioni e princìpi di “end of waste”) è un esempio di norma tecnica che si intreccia con la legislazione ambientale.
- Spesso si fa riferimento a manuali e linee guida dell’ISPRA, più che a vere e proprie norme UNI, per la gestione operativa (registri, MUD, tracciabilità).
In quest’ambito l’obbligatorietà a livello IT (telematica di tracciamento, piattaforme di gestione) è in evoluzione, e la norma NIS2 potrebbe (in futuro) essere estesa o recepita in modo da coprire meglio le infrastrutture digitali del ciclo rifiuti, specie se considerati “essenziali” in determinate aree. Ad oggi, l’impatto di GDPR è chiaro se si raccolgono dati personali (utenze domestiche, targhe agli ecocentri, etc.), mentre la cybersicurezza non ha disposizioni UNI specifiche e dipende dalle regole generali o dai contratti di fornitura.
3. Altre norme UNI trasversali (qualità, sicurezza, gestione dell’energia)
Oltre alle norme “di prodotto” o “di impianto”, le multiutility potrebbero trovarsi obbligate (o spinte da appalti o regolamenti) a seguire norme di sistema:
- UNI EN ISO 9001 (Sistema di Gestione per la Qualità): spesso richiesto nei bandi o nei contratti di servizio con enti pubblici.
- UNI EN ISO 14001 (Gestione Ambientale) e UNI EN ISO 45001 (Sicurezza sul Lavoro): non sempre obbligatorie per legge, ma fortemente consigliate o talvolta rese obbligatorie da capitolati di gara.
- UNI CEI EN ISO/IEC 27001 (Sicurezza delle Informazioni): con l’avvento di NIS2, è quasi una scelta obbligata per le grandi e medie utility se vogliono dimostrare conformità a requisiti di sicurezza. Anche se la 27001 non è “UNI pura” ma uno standard ISO/IEC recepito come UNI CEI, in Italia ha comunque valore di norma tecnica riconosciuta.
- UNI 11352 (ESCO – Energy Service Company): non riguarda direttamente la distribuzione energetica, ma può coinvolgere le multiutility che offrono servizi di efficienza energetica ai clienti.
Queste norme di sistema possono facilitare la gestione coordinata delle prescrizioni europee (GDPR, NIS2, CRA, ecc.) perché forniscono procedure e controlli in cui integrare agevolmente anche le necessità di privacy e cybersecurity. In altre parole, una multiutility certificata ISO 27001 o ISO 9001/14001 può trovare più facile documentare e dimostrare le misure adottate per NIS2 o per la protezione dei dati personali, creando una sinergia tra gli standard tecnici nazionali e i regolamenti UE.
4. Possibili sinergie e frizioni con le normative europee
- Sinergie Le norme UNI/CEI fissano requisiti tecnici e di sicurezza “fisica” su impianti e dispositivi. Integrare in questi requisiti anche le misure di cybersecurity (richieste da NIS2 e/o CRA) crea un “mix virtuoso”: non si progetterà più il solo impianto a gas sicuro contro fughe, ma lo si doterà anche di meccanismi di protezione contro intrusioni digitali se esso è smart. Gli schemi di gestione (ISO 9001, 14001, 27001) agevolano la conformità trasversale, potendo contenere procedure per la privacy (GDPR), la sicurezza informatica (NIS2) e l’analisi del ciclo di vita dei prodotti (CRA).
- Fricioni/Contrasti Tempi di aggiornamento delle norme UNI: spesso una UNI resta invariata per anni, mentre la tecnologia evolve e le normative UE (es. cybersicurezza) si aggiornano più rapidamente. Questo può creare vuoti normativi in cui le aziende devono arrangiarsi con linee guida internazionali o best practice. Conservazione e trattamento dei dati: alcune norme UNI o regolamenti ARERA impongono di conservare informazioni tecniche o contabili (es. misure dei consumi) per un certo periodo; il GDPR richiede di non conservare i dati oltre lo scopo necessario. In teoria non c’è incompatibilità (il GDPR consente l’adempimento di obblighi legali), ma si crea complessità gestionale: occorre definire con precisione la base giuridica e la durata di ciascun trattamento, evitando il classico “tengo tutto per sempre perché lo dice la norma UNI (o ARERA)”. Responsabilità nei prodotti smart: in caso di dispositivi normati (es. contatori acqua/gas secondo le norme UNI EN), la responsabilità sulle funzionalità “meccaniche” è ben definita, ma chi risponde degli aspetti di sicurezza digitale (CRA)? Il costruttore del dispositivo? L’integratore? L’utility che lo distribuisce? Se la norma UNI non affronta gli aspetti cyber, si rischia un vuoto che va colmato contrattualmente. Verifiche e ispezioni: in Italia, le verifiche su sicurezza impianti (ad es. INAIL/ASL) seguono norme tecniche nazionali; parallelamente, potremmo avere controlli di conformità NIS2 (ACN) o del Garante Privacy. Se non ci sono protocolli unificati, l’azienda deve subire più procedure di audit separate con rischio duplicazioni.
Conclusioni bis
Le multiutility italiane, oltre alle grandi cornici europee (GDPR, NIS2, CRA, AI Act), devono spesso rispondere a un ventaglio di normative nazionali e standard UNI/CEI che disciplinano le caratteristiche tecniche degli impianti, la sicurezza, la qualità del servizio, l’ambiente e il lavoro. Molte di queste norme sono “volontarie” in teoria, ma diventano di fatto obbligatorie quando sono:
- Richiamate in leggi, decreti o delibere ARERA;
- Inserite in capitolati di gara pubblici;
- Richieste come prerequisito per ottenere determinate autorizzazioni o certificazioni.
In prospettiva, i vincoli imposti da GDPR e NIS2 su trattamento dati e cybersicurezza spingeranno (e in parte stanno già spingendo) alla revisione di alcune norme UNI/CEI per integrare l’aspetto digitale, finora non sempre contemplato. Le imprese multiutility si troveranno ancora una volta nel ruolo di dover armonizzare obblighi tradizionali (UNI per impianti) con i nuovi obblighi europei (cyber e data protection), idealmente sfruttando standard di gestione unificati (es. ISO 27001, 9001, 14001) per guadagnare efficienza nella compliance ed evitare contraddizioni o ridondanze.
Insomma, l’elenco di norme nazionali e UNI di settore è già ricco e in costante evoluzione, e – nel gioco di incastri con i regolamenti UE – può generare qualche cortocircuito. Per uscirne, vale sempre la regola aurea: approccio integrato alla compliance, con procedure e controlli unici (o fortemente coordinati) che coprano sia le componenti tecniche (UNI, CEI) sia gli aspetti privacy e sicurezza (GDPR, NIS2, CRA). Il risultato finale è un’azienda più affidabile, sicura e pronta alle sfide di un mondo sempre più “intelligente” e connesso.
Nessun commento:
Posta un commento