Kurzüberblick: Die DSGVO fordert Datenminimierung, Zweckbindung, Transparenz und Betroffenenrechte – Blockchains setzen auf Unveränderlichkeit, Replikation und Offenheit. Ein Widerspruch ist das nicht zwingend. Mit einer sauberen Architektur (off-chain-first, on-chain-minimum, Commitments statt Klartext), präziser Rollenverteilung (Verantwortliche/Auftragsverarbeiter/joint controllership), eIDAS-gestützten Nachweisen und klaren Vertrags- und Governance-Regeln lassen sich die Kernpflichten erfüllen. Der Beitrag skizziert praxistaugliche Muster, typische Irrtümer und eine Checkliste für Projekte, die 2025 belastbar sein müssen.

Ausgangslage: DSGVO-Pflichten und technische Eigenschaften in Einklang bringen

Die DSGVO arbeitet mit Grundprinzipien (Art. 5), Rechtsgrundlagen (Art. 6, bei besonderen Kategorien Art. 9), Transparenz- und Informationspflichten (Art. 13/14), technischen und organisatorischen Maßnahmen (Art. 25, 32), sowie Betroffenenrechten (Auskunft, Berichtigung, Löschung, Einschränkung, Widerspruch). Blockchains setzen dem die Eigenschaften Unveränderlichkeit, dezentrale Speicherung, Verifikation per Konsens und globale Replikation entgegen. Daraus ergeben sich klassische Spannungsfelder:

• Datenminimierung versus vollständige, dauerhafte Speicherung.
• Löschung/Rectification versus Unveränderlichkeit.
• Verantwortlichkeit versus verteilte Governance und „Niemand ist verantwortlich“.
• Internationale Datenflüsse (Nodes weltweit) versus Transferregime.

Die Lösung liegt selten in „Blockchain oder DSGVO“, sondern in der Architektur: Persönliche Daten gehören grundsätzlich nicht als Klartext on-chain, sondern in kontrollierte Off-Chain-Speicher; on-chain verbleiben nur minimal notwendige Anker (Hash/Commitment, Referenzen, Zustandsmarker). Diese Sicht wird seit Jahren von europäischen Fachstellen gestützt und konkretisiert, u. a. durch die CNIL mit Richtlinien und Praxisempfehlungen zum datenschutzkonformen Blockchain-Einsatz sowie Studien des Europäischen Parlaments und des EU Blockchain Observatory. Diese betonen: Permissioned-Architekturen erleichtern Rollen- und Transferkontrolle; in permissionless-Netzen ist die Compliance anspruchsvoller, aber nicht ausgeschlossen, wenn personenbezogene Inhalte durch geeignete Konstrukte ersetzt werden (Commitments, selektive Offenlegung, Kryptografie). (cnil.fr, Europäisches Parlament, EU Blockchain Observatory and Forum)

Ein weiterer Baustein für die rechtliche Anschlussfähigkeit ist eIDAS 2: Elektronische Ledger sind als Beweis-Infrastruktur rechtlich verortet; qualifizierte elektronische Ledger genießen eine Vermutung für Integrität und korrekte zeitliche Reihenfolge ihrer Einträge. Das hebt die Beweiskraft gut gestalteter Ketten – ersetzt aber nicht die DSGVO-Pflichten. (EUR-Lex, european-digital-identity-regulation.com, EY)

Architektur- und Technikmuster: Off-Chain-First, Commitments und selektive Offenlegung

Off-Chain-First und On-Chain-Minimum
Personenbezogene Daten werden außerhalb der Blockchain in Systemen verarbeitet, deren Zugriffe, Speicherfristen und Löschungen steuerbar sind (Datenbanken, Objektspeicher, WORM-Repos). On-chain werden ausschließlich verifizierende Marker gehalten: kryptografische Hashes, Merkle-Root-Commitments, Zustands-IDs oder Token-Identifier ohne Eigenbezug zu einer Person. Der Hash dient als Unveränderlichkeitsnachweis; der Personenbezug verbleibt off-chain. CNIL empfiehlt diese Trennung ausdrücklich – mit dem Zusatz, dass Permissioned-Netze die Governance erleichtern. (cnil.fr)

Pseudonymisierung statt Anonymisierung
Öffentliche Schlüssel, Adressen, Transaktions-IDs: In vielen Konstellationen sind diese Identifier personenbezogene Daten, weil sie mittelbar einer natürlichen Person zugeordnet werden können. Das bedeutet: Pseudonymisierung ja, echte Anonymisierung selten. Darauf reagieren Architekturen mit wechselnden Schlüsseln, Privacy-Enhancements (z. B. Adress-Rotation, Payment-Codes), aber vor allem mit der Verlagerung sensibler Inhalte off-chain. Studien und Workshops (EU-Parlament/EU-Observatory) warnen vor einer falschen Sicherheit: Schon Metadaten reichen oft zur Re-Identifizierung. (Europäisches Parlament, ResearchGate)

Commitments und Nachweise
Statt Daten selbst zu veröffentlichen, werden Commitments geschrieben: Hashes auf strukturierte Datensätze, Merkle-Bäume, akkumulierte Zustände. Eine spätere Offenlegung ist selektiv möglich (Proof-of-Inclusion, Zero-Knowledge-Nachweise). Die Kette belegt Integrität und Zeitpunkt; off-chain werden die Daten gelenkt gelöscht, berichtigt oder gesperrt. So lassen sich Datensparsamkeit und Nachweisinteressen verbinden.

Selektive Offenlegung und Zero-Knowledge
ZK-Nachweise (z. B. zk-SNARKs) erlauben, Eigenschaften eines Datums zu beweisen, ohne das Datum offenzulegen: Alter ≥ 18, Adresse im Land X, Berechtigung Y. In der Praxis wird das häufig mit verifizierbaren Berechtigungsnachweisen (verifiable credentials) kombiniert: Ein Aussteller signiert Attribute; Inhaber legt gegenüber einem Prüfer nur die relevanten Attribute offen, idealerweise mit ZK-Stichproben (Range-Proofs, Membership-Proofs). Damit lassen sich Identitäts- und Berechtigungsprüfungen realisieren, ohne zentrale Datenhaltung.

Redaktion statt „Löschen auf Kette“
Wo Ketten redaktionsfähige Strukturen unterstützen (per Governance-Beschluss, „redactable ledgers“/Chameleon-Hashes), sind Korrekturen möglich. Dabei ist rechtlich zu beachten: Ein technisches Überschreiben ist nicht zwingend erforderlich; genügt oft, dass personenbezogene Inhalte nie on-chain standen oder durch kryptografische Entkopplung und Löschung der Off-Chain-Daten faktisch unerreichbar werden. Die DSGVO fordert Wirksamkeit, nicht zwingend Bit-Löschung an jedem Speicherort.

Datenbank- und Urheberrechte mitdenken
Viele blockchain-gestützte Register enthalten schutzfähige Datenbanken. Extraktionen, Spiegelungen und Miner/Validator-Kopien können Rechte berühren. Gleichzeitig entstehen an Smart-Contract-Code urheberrechtliche Positionen; die Zweckübertragung (z. B. Audit, Fork, Re-Use) ist vertraglich zu regeln. Diese Fragen sind parallel zur DSGVO zu adressieren.

eIDAS-gestützte Nachweise
Qualifizierte Zeitstempel und Siegel lassen sich vor die on-chain-Schicht ziehen: Off-chain-Dokumente, Logs und Zustandsnachweise werden qualifiziert signiert/gestempelt, die Hashes zusätzlich in ein Ledger geschrieben. So wird eine doppelte Beweiskaskade geschaffen (Trust-Service + Ledger). eIDAS 2 verleiht gerade qualifizierten elektronischen Ledgers eine gesetzliche Vermutung für Integrität/Chronologie. (EUR-Lex, european-digital-identity-regulation.com)

Betroffenenrechte und „Unveränderlichkeit“: Praktische Lösungen für Auskunft, Berichtigung, Löschung

Auskunft (Art. 15)
Auskunftspflichten betreffen vor allem Off-Chain-Bestände und Protokolle. Empfehlenswert sind Datenkataloge, die für jede on-chain-Referenz den Off-Chain-Speicher verweisen (Data Lineage). On-chain-Hashes werden in der Antwort erklärt, ohne sensible Inhalte offenzulegen. Für verteilte Netze ist zu definieren, welche Stelle Auskunft erteilt (Lead-Controller/Koordinationsstelle, vertraglich festgelegt).

Berichtigung (Art. 16)
Ist ein off-chain gespeicherter Datensatz fehlerhaft, wird er dort berichtigt; die neue Version erhält einen neuen Hash. On-chain kann ein Korrektur-Marker eingetragen werden (z. B. „superseded by state X“). Ein tatsächlich auf der Kette gespeicherter Klartext ist zu vermeiden; sonst bleibt nur eine Korrekturanmerkung plus Unterbindung der weiteren Nutzung durch Governance-Regeln.

Löschung (Art. 17)
Löschen heißt wirksam entfernen oder unbrauchbar machen. In Blockchain-Architekturen werden personenbezogene Inhalte deshalb gar nicht erst auf die Kette geschrieben. Für Off-Chain-Bestände sind Löschroutinen verbindlich zu definieren; on-chain wird eine Referenz unbrauchbar, wenn der Off-Chain-Datensatz nicht mehr existiert oder der Entschlüsselungsschlüssel vernichtet wurde (Krypto-Shred). CNIL und weitere Stellen betonen, dass Permissioned-Umgebungen mit klaren Lösch- und Zugriffspflichten die praktische Umsetzung erleichtern. (cnil.fr)

Einschränkung/Widerspruch (Art. 18/21)
Einschränkung lässt sich als „Freeze“ im Off-Chain-System abbilden; on-chain kann ein Flag oder ein Zustandswechsel gesetzt werden, der weitere Verarbeitung verhindert. Beim Widerspruch ist zu prüfen, ob die Rechtsgrundlage berechtigte Interessen oder Einwilligung war; bei berechtigten Interessen ist die Abwägung zu aktualisieren und ggf. zu Gunsten des Betroffenen anzupassen.

Datenübertragbarkeit (Art. 20)
Portabilität bezieht sich auf die vom Betroffenen bereitgestellten Daten. Technisch lassen sich exportfähige Off-Chain-Profile (maschinenlesbare Formate, APIs) bereitstellen; on-chain-Marker spielen hierfür regelmäßig keine Rolle. Wichtig ist, dass die Portabilität nicht mit einer Pflicht zur Offenlegung von Geschäftsgeheimnissen oder Rechten Dritter verwechselt wird.

Besondere Kategorien (Art. 9)
Gesundheitsdaten, politische Meinung, biometrische/ genetische Daten haben strengste Anforderungen. Solche Inhalte gehören nicht in öffentlich einsehbare Register. Wo eine Verarbeitung nötig ist (z. B. Berechtigungsnachweis in Gesundheits-Szenarien), sind Zero-Knowledge/selektive Offenlegung und starke Off-Chain-Kontrollen Pflicht.

Governance, Rollen, Transfers: Verantwortlichkeit definieren, internationale Risiken beherrschen

Rollenmodell
In Permissioned-Netzen ist regelmäßig ein oder mehrere Verantwortliche identifizierbar (Konsortium, Betreiber, Use-Case-Owner). Je nach Konstellation liegt gemeinsame Verantwortlichkeit nahe (Art. 26), weil über Zwecke und Mittel gemeinsam entschieden wird. Validatoren/Mitglieder können als Auftragsverarbeiter eingebunden werden, sofern sie weisungsgebunden handeln. In Permissionless-Netzen ist die Rollenzuordnung schwieriger; praktikabel sind Konstruktionen, die den konkret angebotenen Dienst (z. B. eine Wallet- oder Registry-Anwendung) als eigenständige Verantwortlichkeit konzipieren, während das zugrundeliegende Protokoll als „Infrastruktur“ behandelt wird. CNIL weist darauf hin, dass eine klare Verantwortlichenbestimmung unverzichtbar ist – „niemand ist verantwortlich“ ist kein DSGVO-Modell. (cnil.fr)

Rechtsgrundlagen und DPIA
Für viele Register-Anwendungen kommen berechtigte Interessen in Betracht (Art. 6 Abs. 1 lit. f), bei Identitäts-/Zertifikatsprozessen ggf. rechtliche Pflichten oder Verträge. In risikoreichen Szenarien ist eine Datenschutz-Folgenabschätzung angebracht: systematische Bewertung der Risiken (Re-Identifizierbarkeit, Krypto-Schlüsselverlust, Chain-Forks, internationale Replikation) und der vorgesehenen Abhilfen (Off-Chain-Kontrollen, ZK-Nachweise, Zugriffskontrollen, Audit).

Internationale Datentransfers
Öffentliche Ketten replizieren Daten global, was die Regeln für Drittlandstransfers auslöst. CNIL empfiehlt deshalb Permissioned-Netze, in denen der Node-Standort kontrolliert und vertraglich über Standardvertragsklauseln/BCR abgesichert werden kann. In öffentlichen Netzen ist das kaum umfassend sicherzustellen; deshalb gilt umso mehr: Keine personenbezogenen Inhalte on-chain, sondern nur nicht-personenbeziehbare Commitments. (cnil.fr)

eIDAS-Brücke und Beweisführung
eIDAS 2 stärkt die rechtliche Wirkung elektronischer Ledger. Ein elektronisches Ledger darf als Beweis nicht allein wegen seiner Form zurückgewiesen werden; bei qualifizierten Ledgers bestehen Vermutungen für Integrität und korrekte zeitliche Reihenfolge. Für forensische/Compliance-Nachweise ist es sinnvoll, Trust-Services (qualifizierter Zeitstempel/Siegel) mit dem Ledger zu kombinieren, um Doppel-Anker (Trust-Service + Chain) zu erhalten. (EUR-Lex, european-digital-identity-regulation.com)

Typische Vertragsbausteine

• Rollen und Verantwortlichkeit (Art. 26-Abkommen/joint controllership; AVV nach Art. 28).
• Datenkategorien, On-/Off-Chain-Abgrenzung, Retention, Löschung, Schlüssellebenszyklus (Erzeugung, Rotation, Vernichtung).
• Sicherheits- und Auditklauseln, eIDAS-Trust-Services, Beweisführung (Zeitstempel/Siegel, Hash-Register), Fork-/Incident-Regeln.
• Drittlandtransfers und Node-Standorte (nur Permissioned), Standardvertragsklauseln/BCR, Subverarbeiterketten.
• Rechte an Smart-Contract-Code/Datenbanken, Zweckübertragung, Fork-Reuse-Regeln.

Prüfpunkte/Checkliste (kompakt)

1. On-chain nur Commitments/Zustände – keine Klardaten, keine „besonderen Kategorien“.
2. Off-Chain-Speicher mit Lösch-/Berichtigungsroutinen, Zugriff, Logging, Retention.
3. ZK/Verifiable Credentials für selektive Offenlegung; Adress-Rotation/Key-Hygiene.
4. Verantwortliche/AVV/joint-controller-Agreement; DPIA mit Risikominderung.
5. International: Nodes und Transfers steuern oder personenbezogene Daten vollständig off-chain halten.
6. eIDAS-Trust-Services + Ledger als Nachweiskaskade.
7. Dokumentation: Datenkatalog, Policy-Stack, Incident- und Key-Management.

Fazit

GDPR-konforme Blockchains sind kein Widerspruch, sondern eine Frage von Design, Governance und Beweisdisziplin. Wer personenbezogene Inhalte strikt off-chain hält, on-chain nur verifizierende Marker nutzt, selektive Offenlegung ermöglicht und Verantwortlichkeiten klar regelt, löst die klassischen Konflikte aus Datenminimierung, Löschung und Internationalität. eIDAS 2 liefert die Brücke zur gerichtsfesten Beweisführung: Ein sauberer Mix aus qualifizierten Zeitstempeln/Siegeln und elektronischen Ledgers schafft Nachweise, die fachlich tragfähig und rechtlich anschlussfähig sind. Entscheidend bleibt der Nachweis im Detail – Korpus, Schlüssel, Protokolle, Policies und Verträge – nicht die Schlagwort-Kompatibilität.

Author: Marian Härtel

Marian Härtel ist Rechtsanwalt und Fachanwalt für IT-Recht mit einer über 25-jährigen Erfahrung als Unternehmer und Berater in den Bereichen Games, E-Sport, Blockchain, SaaS und Künstliche Intelligenz. Seine Beratungsschwerpunkte umfassen neben dem IT-Recht insbesondere das Urheberrecht, Medienrecht sowie Wettbewerbsrecht. Er betreut schwerpunktmäßig Start-ups, Agenturen und Influencer, die er in strategischen Fragen, komplexen Vertragsangelegenheiten sowie bei Investitionsprojekten begleitet. Dabei zeichnet sich seine Beratung durch einen interdisziplinären Ansatz aus, der juristische Expertise und langjährige unternehmerische Erfahrung miteinander verbindet. Ziel seiner Tätigkeit ist stets, Mandanten praxisorientierte Lösungen anzubieten und rechtlich fundierte Unterstützung bei der Umsetzung innovativer Geschäftsmodelle zu gewährleisten.