La Commissione europea ha appena pubblicato la bozza della sua guida ufficiale all’applicazione del Cyber Resilience Act (Regolamento UE 2024/2847 – di seguito anche “CRA”). Non è un documento di facciata: 230 paragrafi, decine di esempi pratici, chiarimenti attesi da oltre un anno.

Per produttori di software, hardware connesso, integratori di sistemi e chiunque operi nell’economia digitale europea, ignorarne i contenuti significa navigare a vista in un contesto normativo che – a differenza di quanto si creda – è già operativo.

Una selezione di alcuni punti, prevedibilmente più critici, può aiutare.

Il Cyber Resilience Act in due parole

Riepiloghiamo i fondamentali: il Cyber Resilience Act è entrato in vigore il 10 dicembre 2024 e si applicherà pienamente dall’11 dicembre 2027.

È la prima normativa europea orizzontale dedicata ai requisiti di cyber security dei prodotti con elementi digitali: si applica trasversalmente a qualsiasi prodotto – hardware o software – che abbia una connessione dati diretta o indiretta a un dispositivo o a una rete, e che sia immesso sul mercato UE nel corso di un’attività commerciale.

L’obiettivo dichiarato è duplice: garantire che i prodotti digitali raggiungano il mercato con un livello adeguato di sicurezza informatica, e assicurare che quel livello sia mantenuto per tutta la durata del ciclo di vita del prodotto attraverso obblighi di gestione delle vulnerabilità, notifica degli incidenti e aggiornamenti di sicurezza.

A differenza di normative come il GDPR – che proteggono un diritto fondamentale della persona – il Cyber Resilience Act opera su una logica di sicurezza del prodotto: è più vicino alla direttiva sulla responsabilità del prodotto o al regolamento macchine che al diritto della protezione dei dati personali, per intendersi.

Ora la guida della Commissione – attesa da mesi e frutto di un’ampia consultazione con il gruppo di esperti cybersec e con gli stakeholder del settore – tenta di fare chiarezza su alcuni dei nodi interpretativi più spinosi, con un occhio di riguardo alle microimprese e alle PMI (esplicitamente menzionate dall’art. 26.1 CRA come destinatarie privilegiate di questo sforzo di semplificazione).

Non si tratta, va precisato, di un documento vincolante: è noto che solo la Corte di Giustizia dell’Unione Europea può fornire un’interpretazione autoritativa del Cyber Resilience Act e delle altre normative unionali. Rappresenta tuttavia la posizione ufficiale della Commissione, e come tale orienterà il comportamento delle autorità nazionali di sorveglianza del mercato nei 27 Stati membri.

Non sarà nemmeno l’ultima parola della Commissione: il Cyber Resilience Act prevede che possa emettere ulteriori guidance tematiche. Già annunciate per es. quelle sull’interplay tra il CRA e l’AI Act (Regolamento UE 2024/1689) e tra il CRA e DORA (il Regolamento UE 2022/2554 sulla resilienza operativa digitale del settore finanziario).

Sul fronte degli atti di esecuzione la Commissione dovrà inoltre adottare specifiche tecniche e standard armonizzati, mentre ENISA è chiamata a svolgere un ruolo centrale nel supporto agli operatori economici e agli Stati membri. Il quadro regolatorio, insomma, è in via di rapida integrazione.

Il CRA non è solo hardware: chi è davvero nel perimetro

Come già ricordato, il regolamento si applica ai “prodotti con elementi digitali” immessi sul mercato UE. Chiunque abbia letto questa definizione sarebbe tentato di fermarsi qui, immaginando che riguardi principalmente dispositivi IoT, router, smartwatch e simili. Comodo ma incompleto.

La Commissione chiarisce che il perimetro infatti comprende:

1. app e programmi software standalone;
2. hardware con software integrato (IoT);
3. hardware standalone come circuiti integrati e schede madri;
4. qualsiasi combinazione di hardware e software forniti separatamente ma progettati per operare insieme.

Il criterio discriminante da soppesare ulteriormente è la capacità del prodotto di scambiare informazioni digitali – ovvero l’esistenza di una connessione dati, diretta o indiretta, logica o fisica, a un dispositivo o a una rete.

La guida si preoccupa di tracciare un confine preciso su questo punto: non si tratta di considerare ogni segnale elettrico come una “connessione dati”, commutare un output tra 0 e 1 non è di per sé una connessione dati se quegli stati non sono intesi a rappresentare un’informazione.

Per parlare di data connection – e quindi di Cyber Resilience Act – serve che i segnali siano deliberatamente codificati come informazione da una sorgente e decodificati come tale dalla destinazione. I prodotti che usano segnali elettrici solo per attivare o alimentare una funzione, senza veicolare informazione digitalmente codificata, ne restano fuori.

Tradotto in pratica: un termostato basilare, che apre o chiude un circuito, è fuori perimetro. Lo stesso termostato che comunica con un’app via Wi-Fi è dentro. Una valvola industriale comandata da un relè fisico è probabilmente fuori. La stessa valvola controllata via protocollo di rete è quasi certamente dentro il perimetro.

Il software standalone: quando si considera “immesso sul mercato”?

Uno dei chiarimenti più attesi e impattanti riguarda il software standalone. A differenza dei prodotti fisici il software distribuito via canali digitali non ha stock, non ha produzione fisica, non ha logistica o altro: ogni download genera una copia identica al file di partenza. Quando considerarlo “immesso sul mercato”?

La Commissione offre una risposta netta: il software standalone si considera immesso sul mercato nel momento in cui il produttore lo rende per la prima volta disponibile per distribuzione o uso sul mercato UE, nel corso di un’attività commerciale. Da quel momento si considera che il produttore abbia immesso sul mercato un numero virtualmente infinito di copie dello stesso prodotto simultaneamente.

Implicazione concreta: due clienti che acquistano la versione 1.0.0 dello stesso software in date diverse (per es. 1° e 15 gennaio 2028) hanno entrambi un prodotto immesso sul mercato in data 1° gennaio 2028. È la data del primo rilascio che conta.

Diverso il caso degli aggiornamenti successivi: se la versione 1.0.1 non costituisce una modifica sostanziale rispetto alla 1.0.0, la data di immissione sul mercato non cambia. Solo le iterazioni che integrano una modifica sostanziale vengono considerate un nuovo prodotto, con una nuova data di immissione e un nuovo obbligo di valutazione della conformità.

Da questa distinzione dipende l’intero regime di conformità applicabile, come si vedrà nella sezione successiva.

Il principio vale esclusivamente per software standalone distribuito via canali digitali – se il software è fornito su supporto fisico (per es. chiavetta USB) o è abbinato a hardware, allora si applicano regole diverse.

Nel primo caso è il supporto fisico a costituire il prodotto immesso sul mercato, con la conseguenza che la data di immissione coincide con quella di ciascuna unità fisica distribuita, non con un unico momento di primo rilascio.

Nel secondo caso – hardware e software forniti separatamente ma progettati per operare insieme – la guida chiarisce che il criterio discriminante non è il canale o il momento di consegna del software, ma se quel software sia necessario al dispositivo per svolgere le proprie funzioni: se lo è, hardware e software costituiscono insieme un unico prodotto ai fini del Cyber Resilience Act, indipendentemente dal fatto che il software venga scaricato in un secondo momento da un app store, da un link dedicato o da qualsiasi altro canale digitale.

Il caso del firmware scaricabile per una stampante di rete o dell’app companion di un wearable fitness – entrambi gli esempi sono esplicitamente riportati nella guida – illustra bene come la frammentazione dei canali distributivi non spezzi l’unitarietà del prodotto agli occhi della normativa.

Il nodo del FOSS: open source non significa automaticamente fuori dal CRA

Questo è probabilmente il punto dove si concentreranno molte incomprensioni nell’ecosistema tecnologico. La percezione diffusa – e ancora errata – è che il software libero e open source sia per definizione escluso dal Cyber Resilience Act. Non è così.

La Commissione distingue con precisione: il CRA si applica ai prodotti immessi sul mercato nel corso di un’attività commerciale. Un FOSS, quindi open source, non è considerato immesso sul mercato quando il suo sviluppatore lo pubblica su un repository pubblico senza monetizzarlo in alcun modo. Ma attenzione: la monetizzazione – facendo scattare l’attività commerciale – può assumere forme non immediatamente evidenti.

Secondo la guida un FOSS è da considerarsi “immesso sul mercato” quando il soggetto che lo pubblica:

1. addebita un prezzo per il suo utilizzo (anche solo per alcune funzionalità);
2. lo distribuisce attraverso una piattaforma tramite cui monetizza altri prodotti o servizi (per es. un marketplace gratuito che genera ricavi sulle transazioni);
3. condiziona l’accesso alla raccolta di dati personali per finalità diverse dalla sicurezza, compatibilità o interoperabilità del software;
4. offre accesso a versioni specifiche con benefici aggiuntivi (assistenza tecnica, ottimizzazione delle prestazioni ecc.) su base remunerativa — anche quando una versione equivalente è disponibile gratuitamente.

Quanto all’ambiguo tema delle donazioni la Commissione adotta un approccio pragmatico: il semplice fatto di includere un link a una piattaforma di raccolta donazioni non configura di per sé un’attività commerciale, anche se le donazioni ricevute superano i costi effettivi.

Le donazioni per loro natura fluttuano nel tempo e non implicano, necessariamente, un’intenzione di fare profitto.

Tuttavia, le donazioni possono assimilarsi al pagamento di un prezzo – e quindi far scattare il Cyber Resilience Act – quando l’accesso al software, alle funzionalità essenziali o agli aggiornamenti è condizionato in pratica al versamento di una donazione, oppure quando la struttura delle donazioni tradisce un’intenzione sistematica di generare profitto.

Un esempio chiarisce la distinzione: una repository pubblica, liberamente accessibile con un link “Donate se lo trovate utile” resta quasi certamente fuori dal Cyber Resilience Act. Lo stesso software che fornisce le release compilate e le patch di sicurezza solo a chi ha donato è quasi certamente dentro. Di seguito si veda anche un workflow tratto dalla guida, per orientare l’analisi dei software open source.

Chi è “steward” e chi “produttore” per il Cyber Resilience Act

Il Cyber Resilience Act introduce, tra l’altro, una figura normativamente inedita: l’open-source software steward, cioè una persona giuridica che sistematicamente fornisce supporto continuato allo sviluppo di FOSS destinato ad attività commerciali, garantendone la vitalità, senza però immetterlo sul mercato nel senso del CRA.

La distinzione tra steward e produttore genera obblighi radicalmente diversi. Il produttore deve adempiere in toto agli obblighi del CRA (valutazione dei rischi, documentazione tecnica, dichiarazione di conformità, marcatura CE, gestione delle vulnerabilità, notifica degli incidenti ecc.).

Lo steward soggiace a obblighi più leggeri, definiti dall’art. 24 CRA (ovvero: adottare e documentare una politica di cybersecurity per la gestione coordinata delle vulnerabilità dei prodotti FOSS di cui garantisce il supporto; cooperare con le autorità di sorveglianza del mercato ove richiesto; e – in funzione del tipo di supporto concretamente fornito al progetto – notificare all’ENISA e ai CSIRT gli incidenti gravi che impattano la sicurezza dei prodotti, segnalare le vulnerabilità attivamente sfruttate di cui vengono a conoscenza, informando gli utenti impattati).

La Commissione chiarisce che la stessa persona giuridica può essere simultaneamente produttore per un determinato FOSS (quello che monetizza) e steward per un altro (quello che mantiene pubblicamente senza monetizzarlo). Anzi l’esempio più comune è proprio quello dell’azienda che pubblica una versione community gratuita e una versione Enterprise a pagamento dello stesso software: è produttore per la versione a pagamento e steward per la versione gratuita.

La guida precisa, inoltre, i diversi gradi di obblighi per gli steward in base al tipo di supporto fornito: uno steward che offre solo supporto non tecnico (branding, governance della community ecc.) non è coinvolto nello sviluppo del prodotto e non è tenuto a notificare vulnerabilità attivamente sfruttate all’ENISA.

Uno steward che fornisce l’infrastruttura IT (hosting del codice sorgente, sistemi di version control ecc.) è invece tenuto a notificare gli incidenti gravi. Uno steward che dovesse contribuire anche con risorse ingegneristiche (come gli sviluppatori) dovrebbe pure notificare le vulnerabilità attivamente sfruttate di cui viene a conoscenza.

“Modifica sostanziale”: come trasformare un aggiornamento in un nuovo prodotto

La modifica sostanziale è uno dei concetti più rilevanti – e più sottovalutati – dell’intero Cyber Resilience Act. Se una modifica a un prodotto già immesso sul mercato è qualificata come “sostanziale” allora quel prodotto modificato è trattato come un nuovo prodotto, soggetto a una nuova valutazione della conformità.

L’art. 3.30 CRA definisce “sostanziale” la modifica che:

1. incide sulla conformità del prodotto ai requisiti essenziali di cybersecurity, oppure
2. modifica la finalità d’uso per cui il prodotto era stato valutato.

La Commissione aiuta fornendo una griglia di criteri pratici. Una modifica software è (probabilmente) sostanziale quando:

1. introduce nuovi vettori di minaccia: interfacce aggiuntive, canali di comunicazione, ambienti di esecuzione, dipendenze esterne attraverso cui le minacce potrebbero materializzarsi;
2. abilita nuovi scenari di attacco: nuove modalità in cui potrebbe verificarsi accesso non autorizzato, manipolazione, interferenza o uso improprio;
3. aumenta la probabilità di scenari già identificati (abbassando le competenze richieste per sfruttarli, aumentando l’esposizione ad attori non fidati, indebolendo le salvaguardie esistenti);
4. aumenta l’impatto potenziale degli scenari esistenti (ampliando i dati o le funzioni coinvolte, aggravando le conseguenze operative).

Viceversa, un aggiornamento di sicurezza che non introduce nuove funzionalità, finalità d’uso e non aggiunge nuovi rischi allora non è, in linea generale, una modifica sostanziale – anche se limita o modifica alcune funzionalità per mitigare vulnerabilità note.

Con un esempio tratto dalla guida, e che vale la pena citare direttamente: si prenda una dashboard di monitoraggio industriale che in un aggiornamento acquisisce la capacità di controllare attivamente le macchine (e non solo di visualizzarne i dati). Trattasi di modifica sostanziale perché la finalità d’uso si trasforma radicalmente.

Per la commissione un indice deve farla da padrone: calibrando il suo effetto sul profilo di rischio di cyber security del prodotto – non può basarsi sulla scala o complessità del cambiamento. Piccole modifiche possono essere sostanziali, impegnativi aggiornamenti di sicurezza possono non esserlo.

Periodo di supporto cybersec: cinque anni per tutti?

Il Cyber Resilience Act richiede ai produttori di determinare un periodo di supporto durante il quale gestire efficacemente le vulnerabilità del prodotto. È diffusa la convinzione che “cinque anni” sia il periodo standard, perché citato nello stesso testo del CRA, ma non è così.

La Commissione è esplicita: cinque anni è il minimo (pur previsto dalla norma), non il periodo di default. Il produttore è tenuto a determinare il periodo di supporto appropriato sulla base di una serie di criteri (indicati all’art. 13.8 CRA – tra cui la natura del prodotto o il suo ciclo di vita atteso ecc.).

I prodotti ragionevolmente destinati a essere in uso per più di cinque anni devono avere periodi di supporto corrispondentemente più estesi. Un prodotto industriale con ciclo di vita ventennale non può legittimamente dichiarare cinque anni di supporto dunque.

Per il software iterativo – dove versioni sostanzialmente modificate vengono rilasciate con frequenza – il quadro è più articolato: ogni versione sostanzialmente modificata immessa sul mercato deve avere il proprio periodo di supporto dichiarato.

Tuttavia, il CRA consente ai produttori (art. 13.10 CRA) di interrompere la gestione delle vulnerabilità per le versioni precedenti, a condizione che gli utenti possano aggiornarsi gratuitamente alla versione più recente senza sostenere costi aggiuntivi.

La Commissione chiarisce cosa si intende per “costi aggiuntivi“: non include il ragionevole sforzo operativo (test, aggiustamenti di configurazione ecc.), riferendosi a oneri straordinari come l’acquisto di nuovo hardware o cambiamenti fondamentali all’infrastruttura.

Prodotti importanti e critici: come si determina la “core functionality”

Il CRA classifica i prodotti con elementi digitali in tre categorie: “default”, “importanti” (classe I e II) e “critici”. La classificazione determina il regime di valutazione della conformità applicabile — con significative implicazioni in termini di procedura e costi.

I prodotti “default” possono sempre ricorrere all’auto-valutazione (modulo A allegato al CRA). I prodotti importanti di classe II e i prodotti critici richiedono obbligatoriamente il coinvolgimento di un organismo notificato di terza parte, un certificatore indipendente insomma.

Il criterio di classificazione è la “core functionality”: le caratteristiche e capacità tecniche principali del prodotto, senza le quali non potrebbe soddisfare la sua finalità d’uso. Un prodotto ha la funzionalità di un sistema operativo per es. se gestisce l’esecuzione di componenti software.

Lo stesso prodotto che integra un sistema operativo (come uno smartphone) non ha, per questo, la core functionality di un sistema operativo perchè ha una finalità d’uso difforme (come comunicare, accedere a informazioni ecc.).

La Commissione mette in guardia da due errori opposti: sovrastimare la core functionality (per “scendere” di categoria) o sottostimarla (per “salire” e affrontare obblighi più stringenti). Entrambe le manipolazioni sono vietate e sanzionabili. Come potrebbe emergere tale aspetto? Si potrebbe desumere dall’incoerenza tra materiali promozionali, istruzioni per l’uso e documentazione tecnica, in quanto segnale d’allarme per le autorità di sorveglianza del mercato.

Un prodotto con funzionalità superiori a quelle della categoria importante o critica di riferimento non ricade necessariamente in quella categoria. Un software SOAR (Security Orchestration, Automation and Response), per dare un esempio contestualizzato, è in grado di svolgere le funzioni di un SIEM (raccogliere dati da più fonti, analizzarli, correlarli).

Però la sua core functionality va ben oltre: include anche incident response e automazione. Non può quindi essere classificato semplicemente come SIEM.

Remote Data Processing Solutions: il cloud che non ti aspetti

Forse il capitolo più tecnico e allo stesso tempo più impattante per l’economia digitale riguarda le Remote Data Processing Solutions (RDPS). Difatti il CRA include nel concetto di “prodotto” anche le soluzioni di elaborazione remota dei dati che ne fanno parte.

La logica è comprensibile: un prodotto deve essere adeguatamente protetto nella sua interezza, indipendentemente da dove vengono elaborati i dati – localmente sul dispositivo dell’utente o da remoto da parte del produttore.

Tre sono le condizioni cumulative che definiscono una RDPS:

1. l’elaborazione avviene “a distanza” (tipicamente fuori dall’ambiente dell’utente, incluso il cloud, anche il private cloud on-premises del produttore);
2. l’assenza di tale elaborazione impedirebbe al prodotto di svolgere una delle sue funzioni;
3. il software è progettato e sviluppato dal produttore, o sotto la sua responsabilità.

Il terzo criterio è forse quello davvero decisivo, per poter distinguere tra RDPS e componenti di terze parti. La Commissione chiarisce il confine rispetto ai modelli cloud più comuni:

• IaaS: il software che il produttore sviluppa e distribuisce sull’infrastruttura IaaS di terzi è RDPS (se soddisfa gli altri criteri), l’infrastruttura sottostante non lo è;
• PaaS: l’applicazione sviluppata dal produttore e distribuita sull’ambiente PaaS di terzi è RDPS, l’ambiente PaaS in sé non lo è;
• SaaS: un’applicazione completamente sviluppata e offerta da un fornitore terzo non è considerata RDPS — non è progettata dal produttore né sotto la sua responsabilità.

Il caso pratico di un termostato smart chiarisce bene la logica: il software di elaborazione remota che permette al termostato di ricevere comandi dall’app e sincronizzare le preferenze dell’utente è stato sviluppato sotto la responsabilità del produttore, la sua assenza impedirebbe al prodotto di funzionare.

È dunque un RDPS. L’infrastruttura IaaS di terzi su cui gira, invece, no. Deve comunque essere coperta dalla valutazione del rischio e il produttore è tenuto a esercitare la dovuta diligenza nei confronti del fornitore.

Obblighi di segnalazione: quando scatta la “consapevolezza”

Parlando di cybersec possono mancare i temi di incident management? Il CRA impone ai produttori di notificare simultaneamente al CSIRT coordinatore e all’ENISA le vulnerabilità attivamente sfruttate e gli incidenti gravi che impattano la sicurezza del prodotto.

La tempistica di notifica è serrata: early warning entro 24 ore, notifica completa entro 72 ore, report finale entro 14 giorni (per vulnerabilità sfruttate) o un mese (per incidenti gravi).

Il nodo interpretativo affrontato dalla Commissione nella guida è questo: da quando decorre questo termine? La risposta è: dalla “consapevolezza” acquisita dal produttore. La Commissione allinea la propria interpretazione a quella già consolidata nel contesto del GDPR (vedi le Linee guida 9/2022 sull’obbligo di notifica delle violazioni dei dati dell’EDPB) e del Regolamento delegato NIS 2: il produttore è da considerarsi “consapevole” quando, dopo una valutazione iniziale, ha un ragionevole grado di certezza che una vulnerabilità nel suo prodotto sia attivamente sfruttata, o che un incidente grave abbia compromesso la sicurezza del prodotto.

Ciò implica che la ricezione di una segnalazione esterna (da un ricercatore di sicurezza, da un cliente, da un’autorità) non fa scattare immediatamente il termine: serve un’analisi preliminare.

L’enfasi è sulla prontezza: quella valutazione iniziale deve essere condotta immediatamente, specialmente se la vulnerabilità potrebbe rappresentare un rischio significativo.

Interplay con altre normative: veicoli, RED, Machinery Regulation

Un aspetto importante e spesso trascurato riguarda i rapporti tra il CRA e altre normative di armonizzazione UE. La guida chiarisce vari casi, vediamo quella del Regolamento Macchine (ovvero Regolamento UE 2023/1230, pienamente applicabile dal 20 gennaio 2027): si utilizza lo stesso schema.

Cioè i certificati rilasciati ai sensi del Regolamento Macchine per i requisiti di cybersecurity relativi alla protezione dei sistemi di controllo – in particolare gli aspetti di protezione contro la corruzione e di sicurezza e affidabilità dei sistemi di controllo di dell’Allegato III – restano validi per quei rischi specifici. Per tutto il resto il CRA si applica integralmente. Trattasi di complementarità e parziale sovrapposizione.

Il messaggio della guida è chiaro: i certificati esistenti consentono di riutilizzare le evidenze già prodotte per i rischi già coperti, evitando duplicazioni inutili – però attenzione, non esentano dal condurre una valutazione completa ai sensi del CRA per i rischi residui non coperti dalla certificazione Machinery – come la gestione delle vulnerabilità, la minimizzazione dei dati, la riduzione della superficie di attacco o altri aspetti di sicurezza specifici del prodotto.

Per molte imprese industriali già in possesso di certificazioni Machinery questo può tradursi in un percorso di conformità al CRA significativamente più breve di quanto temuto – a condizione di mappare con precisione la copertura effettiva dei certificati esistenti, senza sopravvalutarla.

Verso la conformità al Cyber Resilience Act

La guida non può ovviamente risolvere tutte le ambiguità – se dobbiamo pensare ad aspetti ancora oscuri o critici.

Per es. non definisce soglie quantitative per distinguere donazioni “fisiologiche” da donazioni che configurano un’attività commerciale, lasciando gli sviluppatori FOSS in una zona grigia difficile da navigare senza consulenza legale caso per caso.

Inoltre, non chiarisce come si determina in concreto il confine tra un’iterazione software che “anticipa funzionalità già coperte dal risk assessment originario” e una che invece lo supera, aprendo margini interpretativi significativi proprio sul tema più delicato – quello delle modifiche sostanziali.

Non affronta, oltretutto, il tema della responsabilità nella catena di fornitura quando più soggetti contribuiscono in modo rilevante allo stesso prodotto senza che nessuno assuma formalmente il ruolo di produttore principale.

Tace quasi completamente sul trattamento dei prodotti legacy – quelli progettati anni fa, magari con architetture non aggiornabili – per i quali la dimostrazione di conformità ai requisiti essenziali rischia di essere un esercizio formale più che sostanziale.

E lascia irrisolto il coordinamento pratico tra gli obblighi di notifica del CRA e quelli già esistenti in capo agli stessi operatori in virtù di NIS 2 e DORA, rinviando a una futura guidance specifica. Segno che il cantiere normativo è ancora aperto, e che affidarsi oggi a una lettura statica del testo rischia di essere, già domani, insufficiente.

Il quadro di riferimento, dopo mesi di incertezza, è comunque ora un po’ più nitido.

Anche considerato che il CRA entra in piena applicazione l’11 dicembre 2027 – non è lontano quanto può sembrare, quante aziende ci stanno davvero già lavorando?