Blockchain klingt nach Sicherheit: Ein Datensatz wird nachvollziehbar, eine Transaktion ist unveränderlich, ein Zeitnachweis lässt sich später prüfen. Genau diese Stärke kann aber zum Datenschutzproblem werden, wenn personenbezogene Daten auf der falschen Ebene landen. Was einmal in einer Kette steht, lässt sich oft nicht einfach aus dem System nehmen. Für Website-Betreiber, Webshops, Plattformen und KMU ist deshalb nicht die Frage, ob Blockchain modern wirkt. Die Frage ist, ob der Datenplan dazu passt.

Der aktuelle Anlass ist konkret: Der Europäische Datenschutzausschuss (EDPB) hat am 7. Juli 2026 die finale Version seiner Leitlinien zur Verarbeitung personenbezogener Daten durch Blockchain-Technologien angenommen. Am 8. Juli wurde die Entscheidung öffentlich kommuniziert. Die Leitlinien richten sich nicht nur an große Web3-Projekte. Sie sind auch für österreichische Unternehmen relevant, die Wallet-Logins, Kundenprogramme, digitale Zertifikate, Zeitnachweise, Smart Contracts, Lieferkettennachweise oder tokenbasierte Community-Funktionen prüfen.

Dieser Beitrag ist keine individuelle Rechtsberatung. Er zeigt, welche praktischen Fragen ein Website-Team vor dem ersten Blockchain-Test stellen sollte.

Unveränderlichkeit ist kein Datenschutzargument

Der EDPB beschreibt Blockchain als verteilte, konsistente Datenbank ohne zentrale Verwaltung, bei der Daten auf mehreren Knoten repliziert und validierte Einträge später nur schwer oder gar nicht entfernt werden können. Für Integrität und Nachvollziehbarkeit kann das nützlich sein. Für Datenschutzgrundsätze wie Datenminimierung, Speicherbegrenzung, Berichtigung und Löschung ist es aber anspruchsvoll.

Der entscheidende Punkt: Eine Blockchain macht personenbezogene Daten nicht automatisch anonym. Auch Wallet-Adressen, Transaktionsmetadaten, Hashes oder Zeitstempel können relevant werden, wenn sie mit Personen, Kundenkonten, Bestellungen oder anderen Systemdaten verknüpft werden können. Wer eine Blockchain für ein Kundenprogramm, ein Zertifikat oder eine Plattformfunktion nutzt, muss deshalb den gesamten Verarbeitungskontext betrachten, nicht nur den technischen Eintrag auf der Kette.

Der gestrige Beitrag Anonymisierung ist kein Löschknopf passt hier gut dazu: Auch bei Blockchain-Projekten reicht es nicht, sichtbare Namen zu entfernen. Entscheidend ist, ob Personen mit realistischen Mitteln isoliert, verknüpft oder aus Mustern erkannt werden können.

Der Off-Chain-Plan kommt vor dem Smart Contract

Ein praktischer Blockchain-Datenschutzcheck beginnt mit einer nüchternen Architekturfrage: Muss dieser Datensatz wirklich auf die Blockchain? Der EDPB empfiehlt, vorab zu dokumentieren, ob die Kette personenbezogene Daten enthält, warum Blockchain notwendig und verhältnismäßig ist, welche Alternativen geprüft wurden, welche Art von Blockchain verwendet wird und ob eine datenschutzfreundlichere Architektur möglich ist.

Für KMU heißt das: Der Standard sollte nicht „alles on-chain“ sein. Häufig ist ein Off-Chain-Modell sinnvoller. Personenbezogene Informationen bleiben dann in kontrollierten Systemen des Unternehmens oder eines Dienstleisters, während auf der Blockchain nur ein Nachweis, ein Fingerabdruck oder ein technischer Verweis landet. Auch dieser Verweis muss geprüft werden, aber das Risiko ist meist besser steuerbar als bei vollständigen Kundendaten, Formularinhalten oder Dokumenten auf der Kette.

Die WKO zeigt beim Blockchain-Datenzertifizierungsservice ein praxisnahes Beispiel für diesen Gedanken: Unternehmen können digitale Informationen mit einem Zeitnachweis versehen, ohne die Daten aus der Hand zu geben oder öffentlich zu machen. Laut WKO bleibt nur ein anonymer Fingerabdruck der Daten in der Blockchain, während vertrauliche Informationen im Betrieb bleiben. Genau solche Trennungen zwischen Nachweis und Inhalt gehören in jedes Projektbriefing.

Löschrechte brauchen einen technischen Weg

Viele Blockchain-Ideen scheitern nicht an der Demo, sondern an der Frage: Was passiert, wenn eine betroffene Person ihr Recht auf Löschung, Berichtigung oder Widerspruch ausübt? Der EDPB stellt klar, dass technische Entscheidungen diese Rechte nicht beschneiden dürfen. Wenn personenbezogene Daten nach Ablauf einer Speicherfrist oder nach einem wirksamen Löschbegehren nicht gelöscht oder anonymisiert werden können, sollten sie nicht auf der Kette gespeichert werden.

Das klingt streng, ist aber operativ hilfreich. Ein Webshop, der ein tokenbasiertes Bonusprogramm testet, sollte nicht Kundennamen, E-Mail-Adressen oder Bestellnotizen in einen dauerhaften Ledger schreiben. Eine Plattform, die Wallets für Alters- oder Mitgliedsnachweise nutzt, muss prüfen, welche Daten im Wallet, in der Website, beim Anbieter und auf der Kette gespeichert werden. Der Beitrag EU-Altersnachweis: Datenschutzfreundliche Prüfwege für Webshops und Plattformen zeigt, warum gerade Nachweisfunktionen datensparsam gestaltet werden sollten.

Auch der Beitrag Löschanfragen enden nicht im Postfach bleibt relevant. Ein Blockchain-Projekt braucht nicht erst nach der ersten Anfrage einen Löschprozess. Es braucht den Prozess, bevor die Architektur live geht.

Consent löst die Architekturfrage nicht

Ein häufiger Reflex lautet: Dann holen wir eben eine Einwilligung ein. Der EDPB bremst diesen Reflex. Wenn Einwilligung als Rechtsgrundlage genutzt wird, muss sie frei, widerrufbar und ohne Nachteile verweigerbar sein. Technische Entscheidungen müssen das unterstützen. Besonders heikel wird es, wenn personenbezogene Daten auf der Blockchain nicht wirksam gelöscht oder anonymisiert werden können, obwohl die Einwilligung widerrufen wird.

Für Website-Teams heißt das: Ein Consent-Banner oder eine Checkbox ersetzt kein Löschkonzept. Der AdSimple Consent Manager hilft dabei, einwilligungspflichtige Dienste und Zwecke kontrolliert zu strukturieren. Bei Blockchain-Funktionen muss aber zusätzlich geklärt werden, ob der technische Aufbau die versprochene Wahlfreiheit tatsächlich einlösen kann.

Rollen und Empfänger sauber trennen

Blockchain-Projekte haben oft mehrere Beteiligte: Website-Betreiber, Plugin-Anbieter, Wallet-Dienst, Node-Betreiber, Agentur, SaaS-Anbieter, Chain-Explorer, Cloud-Provider oder Smart-Contract-Entwickler. Datenschutzrechtlich ist damit nicht automatisch klar, wer Verantwortlicher, Auftragsverarbeiter oder gemeinsam Verantwortlicher ist. Genau diese Rollen müssen vor dem Go-live dokumentiert werden.

Der AdSimple Datenschutz Generator unterstützt Website-Betreiber dabei, Dienste, Empfänger und Zwecke in verständlichen Datenschutztexten abzubilden. Das ist bei Blockchain-Funktionen besonders wichtig, weil Nutzerinnen und Nutzer verstehen müssen, welche Daten wohin fließen, welche Informationen dauerhaft öffentlich oder für Teilnehmer sichtbar sein können und wie sie ihre Rechte ausüben können.

Wenn Blockchain in Verträge, Plattformregeln oder ein neues Geschäftsmodell eingebettet wird, gehört auch die Anbieterkommunikation auf den Prüfstand. Der AdSimple Impressum Generator deckt nicht die Blockchain-Architektur ab, sorgt aber dafür, dass die grundlegenden Anbieterangaben der Website sauber bleiben.

DSFA kann früher nötig sein als gedacht

Die österreichische Datenschutzbehörde weist darauf hin, dass bei neuen Technologien eine Datenschutz-Folgenabschätzung nötig sein kann, wenn eine Verarbeitung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen mit sich bringt. Blockchain kann solche Risiken erhöhen: Daten sind schwer löschbar, mehrere Beteiligte verarbeiten Metadaten, internationale Knoten können beteiligt sein, Schlüsselmanagement ist sicherheitskritisch und Fehler in Smart Contracts lassen sich nicht immer elegant korrigieren.

Das bedeutet nicht, dass jedes Blockchain-Projekt automatisch eine Datenschutz-Folgenabschätzung braucht. Es bedeutet aber, dass die Schwellenprüfung in den Projektstart gehört. Der Beitrag EDPB-Template bringt DSFA in den Website-Plan zeigt, wie Website-Teams solche Prüfungen früher in den Ablauf holen können. Für laufende Betreuung, Dokumentation und wiederkehrende Checks ist das AdSimple Business Paket der natürlichere Rahmen als ein einmaliger Spickzettel.

Ein kurzer Prüfpfad für KMU

Ein pragmatischer Prüfpfad beginnt mit sechs Fragen. Erstens: Welche konkrete Aufgabe soll die Blockchain lösen, und welche Alternative wäre weniger eingriffsintensiv? Zweitens: Welche Daten stehen on-chain, welche off-chain, und welche Metadaten entstehen trotzdem? Drittens: Können Löschung, Berichtigung, Widerspruch und Auskunft praktisch erfüllt werden? Viertens: Wer sind die Beteiligten, und welche Rolle haben sie? Fünftens: Welche Schlüssel, Wallets, Schnittstellen und Smart Contracts müssen abgesichert werden? Sechstens: Muss eine Datenschutz-Folgenabschätzung oder eine vertiefte rechtliche Prüfung gestartet werden?

Wer diese Fragen nicht beantworten kann, sollte mit Blockchain nicht live gehen. Das ist kein Innovationsstopp. Es ist ein Schutz vor teuren Umwegen. Viele nützliche Projekte kommen am Ende mit einem einfachen Nachweis, einer sauberen Off-Chain-Datenhaltung und klaren Löschwegen besser aus als mit einem dauerhaften Datensatz auf einer öffentlichen Kette. Auch der Data-Act-Blick auf Cloud- und SaaS-Wechsel erinnert daran: Datenarchitektur ist heute ein Geschäftsrisiko, nicht nur eine technische Präferenz.

Fazit: Erst Architektur, dann Kette

Die finalen EDPB-Leitlinien machen Blockchain nicht unmöglich. Sie verschieben aber die Reihenfolge. Vor dem Smart Contract kommt der Datenschutzplan. Vor dem Wallet-Login kommt die Rollenklärung. Vor dem Zeitnachweis kommt die Frage, ob personenbezogene Daten überhaupt auf die Kette müssen.

Für österreichische KMU ist die beste Startregel einfach: Personenbezogene Daten bleiben nach Möglichkeit off-chain, Nachweise werden minimiert, Rechte werden technisch eingeplant und die Datenschutzerklärung wird erst dann geschrieben, wenn die Datenflüsse wirklich verstanden sind. Blockchain kann Vertrauen schaffen. Ohne Off-Chain-Plan kann sie aber auch Vertrauen verspielen.

Quellen