Il consenso non è una casella di controllo: l’Articolo 71 dell’EHDS lo ha reso legge. Noi lo abbiamo reso possibile.

Tre transazioni sono state concluse nel primo trimestre del 2026. Insieme ammontano a USD 69 milioni e a qualcosa di più consequenziale: una prova strutturale di fallimento.

Kaiser Permanente ha concluso per USD 47,5 milioni. Sutter Health ha concluso per USD 21,5 milioni. ING Bank Śląski ha concluso per EUR 4.375 milioni. Nel settore sanitario e finanziario, in tre diverse giurisdizioni. Ogni organizzazione aveva scritto politiche sulla privacy. Ogni aveva una dashboard di consenso funzionante. Gli utenti potevano accedere, attivare le preferenze, aggiornare i loro dati. L’infrastruttura di consenso era, nel senso convenzionale, presente e funzionale.

Eppure ogni organizzazione ha perso la capacità di onorare il consenso nel momento in cui i dati hanno attraversato un confine istituzionale.

Il caso Kaiser documenta la sequenza precisamente: un opt-out di uso secondario di un paziente è stato registrato nel sistema di gestione del consenso, riconosciuto dal fornitore di cure primarie, e quindi silenziosamente scartato quando il record è stato trasferito a valle a un aggregatore di ricerca. L’opt-out non è stato annullato. Non è stato ignorato. È stato semplicemente invisibile al controller a valle — architettonicamente inaccessibile. Lo stesso schema ricorre nei fascicoli Sutter e ING. Una preferenza di consenso che esiste in un sistema non può essere letta da un altro sistema che ha già ricevuto i dati.

Questo non è un fallimento di policy. È un fallimento di architettura. E spiega perché gli accordi del 2026 hanno questo aspetto.

La trappola che l’Articolo 71(8) ha teso

L’Articolo 71 dell’EHDS è entrato in vigore il 26 marzo 2025, secondo il Reg. (UE) 2025/327. Rende l’opt-out di uso secondario un diritto legale, non una funzione di cortesia. Una persona può ritirare il consenso all’uso dei suoi dati sanitari per ricerca, statistiche o formazione — in qualsiasi momento, con il ritiro vincolante per ogni controller che detiene i suoi dati.

La risposta ingegneristica ovvia è un elenco centralizzato: mantenere un registro degli identificatori esclusi, verificare ogni uso a valle rispetto all’elenco, bloccare in caso di corrispondenza. Veloce, verificabile, gestibile.

L’Articolo 71(8) chiude quella porta. Vieta esplicitamente i registri di re-identificazione — il meccanismo stesso che rende fattibile un elenco centralizzato di opt-out. La logica dietro il divieto è solida: un elenco di identificatori correlati a decisioni di opt-out è esso stesso un dataset sensibile. La sua esistenza crea rischio di re-identificazione. La normativa è stata scritta per prevenire esattamente quel rischio, quindi non può consentire il percorso di implementazione più ovvio per onorare il diritto che crea.

Questa è la trappola. Il controller non può mantenere un elenco di chi ha rinunciato senza ricreare il danno che la normativa è stata scritta per prevenire. L’Articolo 71 crea un obbligo legale di onorare l’opt-out attraverso i confini istituzionali. L’Articolo 71(8) impedisce l’approccio architettonico che renderebbe fattibile per l’infrastruttura centralizzata. Il Considerando 54 aggiunge che l’opt-out deve essere reversibile e liberamente esercitabile — senza attrito, senza re-registrazione, senza periodo di attesa.

La normativa è precisa. L’implicazione architettonica è radicale.

Cinque invarianti. Zero architetture che le soddisfano tutte — fino ad ora.

Spogliate il linguaggio legale e leggete cosa richiedono effettivamente i regolatori. Nell’Articolo 71 dell’EHDS, negli Articoli 7(3) e 17(2) del GDPR, e nell’Articolo 5a dell’eIDAS 2.0, emergono cinque invarianti ingegneristiche:

Identificatori con ambito persona. L’opt-out deve essere attribuibile a una persona specifica, non a una sessione, un dispositivo o un account. L’identificatore deve sopravvivere ai confini istituzionali.

Opt-out con timestamp verificabile. Un controller deve essere in grado di provare quando l’opt-out è stato registrato e che non è stato alterato. I log auto-riferiti sono insufficienti; sono richieste prove crittografiche.

Reversibilità senza re-identificazione. L’Articolo 71(8) dell’EHDS lo nomina esplicitamente. La persona può invertire il suo opt-out senza che l’inversione richieda la creazione di un record di identità collegabile.

Propagazione tra controller. L’Articolo 17(2) del GDPR richiede che un ritiro del consenso raggiunga ogni processore a valle. L’obbligo non si ferma al controller che ha ricevuto il consenso originale.

Non-collegabilità. L’Articolo 5a(16)(b) dell’eIDAS 2.0 richiede che le interazioni di identità siano non-collegabili attraverso i contesti, affinché l’opt-out non possa essere sfruttato per costruire un profilo inter-istituzionale.

Questi cinque invarianti sono nominati nella legge primaria. Non sono posizioni interpretative. E creano un test preciso per qualsiasi architettura di consenso: soddisfa tutti e cinque?

X.509 PKI ne soddisfa zero. Una catena di certificati può confermare l’identità di un server, ma non fornisce alcun meccanismo per identificatori con ambito persona che sopravvivono ai confini istituzionali, nessun record di opt-out crittografico indipendente dai log del controller stesso, e nessuna non-collegabilità — per design, X.509 si affida al fatto che la CA conosca chi sei.

L’identità federata soddisfa la propagazione — quando un provider federato riceve un opt-out, può propagarlo ai relying party. Ma soddisfa la propagazione solo violando la non-collegabilità. Il provider della federazione ha una visione completa di quale persona ha interagito con quale istituzione. Quella collegabilità è ciò che rende possibile la propagazione. È anche ciò che l’Articolo 5a(16)(b) vieta.

DKMS soddisfa tutti e cinque.

Perché DKMS è la risposta — e cosa significa in pratica

Decentralized Key Management è la prima base strutturalmente solida per onorare l’opt-out end-to-end in condizioni cross-organizzazionali, post-divulgazione, controllate dal regolatore. La frase qualificante conta. Nei carichi di lavoro single-tenant, all’interno del perimetro di una singola istituzione, gli approcci più semplici sono adeguati. Il problema strutturale appare solo quando i dati hanno attraversato un confine — quando la persona che esercita il suo opt-out non sta più interagendo con il primo controller.

Il meccanismo funziona nel seguente modo. Ogni persona possiede un identificatore auto-certificante — un Autonomous Identifier, o AID — che funge da radice crittografica delle loro autorizzazioni di consenso. Questo AID non è registrato con alcuna autorità centrale. È auto-generato e controllato interamente dalla persona che lo detiene. DKMS è costruito su KERI, una specifica open della Trust over IP Foundation, che definisce come questi identificatori funzionano e come le modifiche si propagano.

Accanto all’AID si trova un Key Event Log — un record tamper-evident, crittograficamente concatenato, di ogni autorizzazione e ritiro. Quando una persona rinuncia all’uso secondario, quel ritiro è registrato come un evento chiave: con timestamp, firmato e aggiunto al log. Qualsiasi controller a valle che detiene i dati della persona può verificare lo stato attuale dell’autorizzazione leggendo il log direttamente — nessun registro centrale, nessuna chiamata a un database condiviso, nessuna re-identificazione.

Quando una persona inverte il suo opt-out, anche quell’inversione è un evento chiave. Il soggetto guida la rotazione. L’obbligo del controller è verificare, non mantenere la propria interpretazione dello stato.

La propagazione tra controller deriva dalla struttura del log. L’Istituzione B, che ha ricevuto dati dall’Istituzione A, non ha bisogno di ricevere una notifica dall’Istituzione A. Può leggere il log da sola. La propagazione è pull-based e audit-ready.

Dove DKMS non consegna

L’onestà sul perimetro è ciò che rende la tesi difendibile.

I dati che sono stati utilizzati per addestrare un modello non possono essere disimparati da una rotazione di chiave. Un dataset derivato — un aggregato, un sottoinsieme anonimizzato, un artefatto statistico — non mantiene alcuna connessione all’AID della persona originale. L’opt-out non può raggiungere indietro in questi derivati. DKMS può fornire rilevamento forense di quando i dati sono stati utilizzati prima che l’opt-out fosse registrato; non può annullare l’uso.

I backup effettuati prima dell’opt-out sono soggetti agli stessi limiti. Il backup esiste al di fuori della catena di autorizzazione. Raggiungerlo richiede una decisione di policy separata, che DKMS può informare ma non far rispettare autonomamente.

Una singola controparte disonesta può ignorare il log. DKMS non è una funzione di forcing per la conformità per gli attori che scelgono di violare i loro obblighi legali. Quello che fornisce è un record verificabile che rende la violazione visibile e provabile — che è esattamente ciò di cui i regolatori e i tribunali hanno bisogno per assegnare la responsabilità. Gli accordi del 2026 erano difficili da risolvere proprio perché lo stato del consenso era ambiguo ad ogni confine istituzionale. DKMS rimuove quell’ambiguità.

I carichi di lavoro single-tenant all’interno del perimetro di una singola istituzione non hanno bisogno di DKMS per l’applicazione del consenso. I sistemi di gestione del consenso esistenti funzionano adeguatamente quando i dati non attraversano mai un confine. Il requisito strutturale inizia al confine.

Dirlo in anticipo non è debolezza. È ciò che distingue un argomento architettonico da un’affermazione di prodotto.

In produzione

Il deployment di Vereign con Health Info Net AG della Svizzera gestisce 800.000+ messaggi verificati al mese. Questa cifra rappresenta le comunicazioni elaborate da SEAL — il sistema di consegna dello sciame crittografato che serve come canale sicuro di HIN ai destinatari al di fuori della rete professionale. È la prova di produzione che l’architettura sottostante si scala ai carichi di lavoro istituzionali nell’healthcare.

Stargate — l’infrastruttura di trust completa che aggiunge identità decentralizzata, livelli di autorizzazione, e tracce di audit crittografiche sopra quel canale sicuro — è entrato nella produzione iniziale da giugno 2026. La narrativa di roll-out di massa sarà disponibile dopo l’estate 2026 mentre il deployment si allarga.

FHIR-over-Stargate è architetturale — il deployment di produzione dipende dall’onboarding ospedaliero; il più presto plausibile settembre 2026. Lo scambio di dati clinici via FHIR con il livello di applicazione del consenso di Stargate inline è l’architettura target per la conformità all’Articolo 71 dell’EHDS. I pezzi sono in posizione. La timeline dipende dall’onboarding istituzione per istituzione, non da ulteriori ingegneria.

Questo è il quadro onesto. L’architettura è solida. Il baseline di produzione esiste. Il percorso dalla produzione attuale alla conformità completa all’Articolo 71 dell’EHDS è definito e in corso.

La review dell’architettura di consenso

La tesi tecnica completa — cinque invarianti, dettaglio del meccanismo, citazioni normative, avvertenze sui limiti di onestà, tabella di confronto tra X.509 / IAM federato / DKMS — è presso /consent/.

Se la vostra organizzazione sta affrontando l’implementazione dell’Articolo 71 dell’EHDS, gli obblighi di propagazione dell’Articolo 17(2) del GDPR, o le decisioni di architettura di consenso che arrivano con lo scambio di dati basato su FHIR, una review dell’architettura di consenso di 30 minuti mappa la vostra situazione specifica rispetto a questi invarianti. Prenotate una qui.