Zustimmung ist kein Kontrollkästchen: EHDS Artikel 71 machte es zum Gesetz. Wir machten es funktionsfähig.

Drei Vergleiche wurden im ersten Quartal 2026 abgeschlossen. Zusammen belaufen sie sich auf USD 69 Millionen und etwas noch Bedeutenderes: ein struktureller Nachweis des Versagens.

Kaiser Permanente zahlte USD 47,5 Millionen. Sutter Health zahlte USD 21,5 Millionen. ING Bank Śląski zahlte EUR 4,375 Millionen. Im Gesundheitswesen und im Finanzsektor, in drei verschiedenen Jurisdiktionen. Jede Organisation hatte Datenschutzrichtlinien verfasst. Jede hatte ein funktionierendes Consent-Dashboard. Benutzer konnten sich anmelden, Präferenzen umschalten, ihre Datensätze aktualisieren. Die Consent-Infrastruktur war im konventionellen Sinne vorhanden und funktionsfähig.

Und doch verlor jede Organisation die Fähigkeit, der Zustimmung Geltung zu verschaffen, sobald Daten eine institutionelle Grenze überschritten.

Der Kaiser-Fall dokumentiert die Abfolge genau: Ein Opt-Out eines Patienten für Sekundärnutzung wurde im Consent-Management-System aufgezeichnet, vom primären Leistungserbringer bestätigt und dann stillschweigend verworfen, als der Datensatz zu einem Forschungs-Aggregator weitergeleitet wurde. Das Opt-Out wurde nicht überschrieben. Es wurde nicht ignoriert. Es war dem nachgelagerten Verantwortlichen einfach architektonisch unzugänglich. Dasselbe Muster wiederholt sich in den Sutter- und ING-Unterlagen. Eine Zustimmungspräferenz, die in einem System existiert, kann von einem anderen System, das die Daten bereits erhalten hat, nicht gelesen werden.

Dies ist kein Richtlinienversagen. Es ist ein Architekturversagen. Und es erklärt, warum die Vergleiche von 2026 so aussehen, wie sie aussehen.

Die Falle, die Artikel 71(8) gestellt hat

EHDS Artikel 71 trat am 26. März 2025 in Kraft, gemäss Verordnung (EU) 2025/327. Er macht das Opt-Out für Sekundärnutzung zu einem Rechtsanspruch, nicht zu einem höflichen Feature. Eine Person kann ihre Zustimmung zur Nutzung ihrer Gesundheitsdaten für Forschung, Statistik oder Schulung widerrufen — jederzeit, wobei der Widerruf für jeden Verantwortlichen, der ihre Daten hält, verbindlich ist.

Die offensichtliche technische Reaktion ist eine zentralisierte Liste: Führung eines Registers von opt-out-Kennungen, Überprüfung jeder nachgelagerten Nutzung gegen die Liste, Blockierung bei Übereinstimmung. Schnell, überprüfbar, handhabbar.

Artikel 71(8) schliesst diese Tür. Er verbietet explizit Re-Identifizierungsregister — genau der Mechanismus, der eine zentralisierte Opt-Out-Liste funktionsfähig macht. Die Logik hinter dem Verbot ist schlüssig: Eine Liste von Kennungen korreliert mit Opt-Out-Entscheidungen ist selbst ein sensitiver Datensatz. Seine Existenz schafft Re-Identifizierungsrisiko. Die Verordnung wurde geschrieben, um genau dieses Risiko zu verhindern, daher kann sie den offensichtlichsten Implementierungspfad zur Wahrnehmung des Rechts, das sie schafft, nicht erlauben.

Das ist die Falle. Der Verantwortliche kann keine Liste darüber führen, wer opt-out hat, ohne den Schaden zu reproduzieren, den die Verordnung verhindern sollte. Artikel 71 schafft eine gesetzliche Verpflichtung, das Opt-Out über institutionelle Grenzen hinweg zu respektieren. Artikel 71(8) verhindert den architektonischen Ansatz, der dies für zentralisierte Infrastruktur machbar machen würde. Erwägungsgrund 54 fügt hinzu, dass das Opt-Out reversibel und frei ausübbar sein muss — keine Reibung, keine Neuregistrierung, keine Wartezeit.

Die Verordnung ist präzise. Die architektonische Implikation ist radikal.

Fünf Invarianten. Null Architekturen, die sie alle erfüllen — bis jetzt.

Entfernen Sie die Rechtssprache und lesen Sie, was Regulatoren tatsächlich verlangen. Über EHDS Artikel 71, GDPR Artikel 7(3) und 17(2) sowie eIDAS 2.0 Artikel 5a erscheinen fünf technische Invarianten:

Personenbezogene Kennungen. Das Opt-Out muss einer spezifischen Person zurechenbar sein, nicht einer Sitzung, einem Gerät oder einem Konto. Die Kennung muss institutionelle Grenzen überdauern.

Überprüfbares, mit Zeitstempel versehenes Opt-Out. Ein Verantwortlicher muss nachweisen können, wann das Opt-Out aufgezeichnet wurde und dass es nicht manipuliert wurde. Selbst gemeldete Protokolle sind unzureichend; kryptographische Nachweise sind erforderlich.

Reversibilität ohne Re-Identifizierung. EHDS Artikel 71(8) benennt dies explizit. Die Person kann ihr Opt-Out widerrufen, ohne dass der Widerruf die Erstellung eines verknüpfbaren Identitätsdatensatzes erfordert.

Verbreitungsstelle über Controller. GDPR Artikel 17(2) erfordert, dass ein Zustimmungswiderruf jeden nachgelagerten Prozessor erreicht. Die Verpflichtung endet nicht beim Verantwortlichen, der die ursprüngliche Zustimmung erhalten hat.

Entkopplung. eIDAS 2.0 Artikel 5a(16)(b) verlangt, dass Identitätsinteraktionen über Kontexte hinweg entkoppelt sind, damit Opt-Out nicht zur Erstellung eines kontextubergreifenden Profils ausgenutzt werden kann.

Diese fünf Invarianten sind in primärem Recht benannt. Sie sind keine Interpretationspositionen. Und sie schaffen einen präzisen Test für jede Consent-Architektur: erfüllt sie alle fünf?

X.509 PKI erfüllt null. Eine Zertifikatskette kann die Identität eines Servers bestätigen, bietet aber keinen Mechanismus für personenbezogene Kennungen, die institutionelle Grenzen überdauern, keine kryptographische Opt-Out-Aufzeichnung unabhängig von den eigenen Protokollen des Verantwortlichen und keine Entkopplung — X.509 verlässt sich bei Design darauf, dass die CA weiss, wer Sie sind.

Verbundene Identität erfüllt die Verbreitung — wenn ein Verbundanbieter ein Opt-Out erhält, kann er es an vertrauende Parteien verbreiten. Aber sie erfüllt die Verbreitung nur durch Verletzung der Entkopplung. Der Verbundanbieter hat eine vollständige Sicht, welche Person mit welcher Institution interagiert hat. Diese Verknüpfbarkeit ist das, was die Verbreitung funktionsfähig macht. Es ist auch das, was Artikel 5a(16)(b) verbietet.

DKMS erfüllt alle fünf.

Warum DKMS die Antwort ist — und was das in der Praxis bedeutet

Decentralized Key Management ist die erste strukturell sichere Grundlage zur Wahrnehmung des Opt-Out von End zu End in organisationsübergreifenden, nach der Offenlegung bestehenden, von Regulatoren überwachten Bedingungen. Die qualifizierende Phrase ist wichtig. In Single-Tenant-Workloads, innerhalb der Perimeter einer einzelnen Institution, sind einfachere Ansätze angemessen. Das strukturelle Problem tritt nur auf, wenn Daten eine Grenze überschritten haben — wenn die Person, die ihr Opt-Out ausübt, nicht mehr mit dem ersten Verantwortlichen interagiert.

Der Mechanismus funktioniert wie folgt. Jede Person hält eine selbstbestätigende Kennung — eine Autonomous Identifier oder AID — die als kryptographische Wurzel ihrer Zustimmungsermächtigungen dient. Diese AID ist bei keiner zentralen Behörde registriert. Sie wird selbst erzeugt und vollständig von der Person kontrolliert, die sie hält. DKMS ist auf KERI aufgebaut, eine offene Spezifikation der Trust over IP Foundation, die definiert, wie diese Kennungen funktionieren und wie Änderungen daran sich verbreiten.

Neben der AID steht ein Key Event Log — eine manipulationssichere, kryptographisch verkettet aufgezeichnete Datei aller Ermächtigungen und Widerruf. Wenn eine Person die Sekundärnutzung opt-out, wird dieser Widerruf als Schlüsselereignis aufgezeichnet: mit Zeitstempel versehen, signiert und an das Protokoll angehängt. Jeder nachgelagerte Verantwortliche, der die Daten der Person hält, kann den aktuellen Stand der Ermächtigung überprüfen, indem er das Protokoll direkt liest — kein zentrales Register, kein Anruf einer gemeinsamen Datenbank, keine Re-Identifizierung.

Wenn eine Person ihr Opt-Out widerruft, ist dieser Widerruf auch ein Schlüsselereignis. Das Subjekt treibt die Rotation voran. Die Verpflichtung des Verantwortlichen ist es zu überprüfen, nicht seine eigene Interpretation des Status zu führen.

Die Verbreitung über Verantwortliche folgt aus der Protokollstruktur. Institution B, die Daten von Institution A erhalten hat, muss keine Benachrichtigung von Institution A erhalten. Sie kann das Protokoll selbst lesen. Die Verbreitung ist Pull-basiert und auditbereit.

Wo DKMS nicht liefert

Ehrlichkeit über den Umfang ist das, was die These verteidigbar macht.

Daten, die zur Schulung eines Modells verwendet wurden, können nicht durch Schlüsselrotation nicht gelernt werden. Ein Ableitungsdatensatz — ein Aggregat, eine anonymisierte Teilmenge, ein statistisches Artefakt — behält keine Verbindung zur AID der ursprünglichen Person. Opt-Out kann nicht zu diesen Ableitungen zurückreich. DKMS kann die forensische Erkennung bereitstellen, wann Daten verwendet wurden, bevor das Opt-Out aufgezeichnet wurde; es kann die Nutzung nicht rückgängig machen.

Vor dem Opt-Out erstellte Sicherungen unterliegen denselben Grenzen. Die Sicherung existiert ausserhalb der Ermächtigungskette. Das Erreichen erfordert eine separate Richtlinienentscheidung, die DKMS informieren, aber nicht autonom durchsetzen kann.

Ein einzelner unehrlicher Gegenpart kann das Protokoll ignorieren. DKMS ist keine Compliance-Erzwingungsfunktion für Aktoren, die sich entscheiden, ihre gesetzlichen Verpflichtungen zu verletzen. Was es bietet, ist ein überprüfbares Protokoll, das die Verletzung sichtbar und nachweisbar macht — genau das, was Regulatoren und Gerichte brauchen, um Haftung zuzuweisen. Die Vergleiche von 2026 waren schwierig zu lösen, genau weil der Zustimmungsstatus an jeder institutionellen Grenze mehrdeutig war. DKMS beseitigt diese Mehrdeutigkeit.

Single-Tenant-Workloads innerhalb der Perimeter einer einzelnen Institution benötigen DKMS nicht für die Consent-Durchsetzung. Bestehende Consent-Management-Systeme funktionieren angemessen, wenn Daten nie eine Grenze überschreiten. Die strukturelle Anforderung tritt an der Grenze ein.

Dies im Voraus zu sagen ist keine Schwäche. Es ist das, was ein Architektur-Argument von einem Produktanspruch unterscheidet.

In Betrieb

Die Bereitstellung von Vereign mit der Health Info Net AG der Schweiz verarbeitet 800.000+ verifizierte Nachrichten pro Monat. Diese Zahl stellt Kommunikation dar, die von SEAL verarbeitet wird — das verschlüsselte Swarm-Delivery-System, das als HINs sicherer Kanal zu Empfängern ausserhalb des professionellen Netzwerks dient. Es ist der Produktionsnachweis, dass die zugrunde liegende Architektur zu institutionellen Workloads im Gesundheitswesen skaliert.

Stargate — die vollständige Trust-Infrastruktur, die dezentralisierte Identität, Autorisierungsebenen und kryptographische Audit-Trails auf diesem sicheren Kanal hinzufügt — trat ab Juni 2026 in frühe Produktion ein. Das Grosseinsatz-Narrativ wird nach Sommer 2026 verfügbar sein, wenn sich die Bereitstellung ausbreitet.

FHIR-over-Stargate ist architektonisch — Produktionsbereitstellung hängt von der Krankenhaus-Onboarding ab; frühestens plausibel September 2026. Der klinische Datenaustausch via FHIR mit der Consent-Durchsetzungsebene von Stargate inline ist die Zielarchitektur für EHDS-Artikel-71-Konformität. Die Teile sind an Ort und Stelle. Der Zeitrahmen hängt von Institution-für-Institution-Onboarding ab, nicht von weiterer Technik.

Das ist das ehrliche Bild. Die Architektur ist solide. Die Produktionsgrundlage existiert. Der Pfad von der aktuellen Produktion zur vollständigen EHDS-Artikel-71-Konformität ist definiert und läuft.

Die Consent-Architektur-Bewertung

Die vollständige technische These — fünf Invarianten, Mechanismus-Detail, Regulierungszitate, Grenzen-der-Ehrlichkeit-Vorbehalte, Vergleichstabelle über X.509 / Verbundene IAM / DKMS — ist unter /consent/.

Wenn Ihre Organisation die EHDS-Artikel-71-Implementierung, GDPR-Artikel-17(2)-Ausbreitungsverpflichtungen oder die Consent-Architektur-Entscheidungen, die mit FHIR-basiertem Datenaustausch verbunden sind, arbeitet, ordnet eine 30-Minuten-Consent-Architektur-Bewertung Ihre spezifische Situation gegen diese Invarianten. Buchen Sie hier.