Sind Fake-Namen pauschal verboten?

Nein. Die reine Generierung und interne Verwendung in Test-, Demo- und Schulungsumgebungen ist zulässig. Verboten wird es erst, wenn Sie damit nach außen auftreten und ein Gegenüber täuschen, das die Identität für rechtsverbindliche Entscheidungen heranzieht.

Darf ich Fake-Namen für Privacy-Schutz beim Newsletter-Abo nutzen?

Eine Pseudonymisierung Ihrer eigenen Daten ist zulässig, solange der Anbieter keine Echtnamen verlangt (also keine vertragliche Hauptleistung von einer korrekten Identifizierung abhängt). Bei Banken, Versicherungen und Behörden ist das anders, dort gilt § 154 AO bzw. das Geldwäschegesetz.

Sind die fake-name.de-Daten 100 % fiktiv?

Die Datensätze werden zufällig kombiniert, basieren aber auf realen Namens- und Adressdaten. Die Wahrscheinlichkeit einer zufälligen Übereinstimmung mit einer echten Person liegt unter 1 zu 10 Millionen pro Datensatz, aber nicht bei null. Deshalb gehören die Daten ausschließlich in nicht-öffentliche Test-Kontexte.

Was tun, wenn ein Fake-Datensatz versehentlich eine reale Person trifft?

Reine Generierung ist auch dann zulässig, solange die Daten nicht öffentlich werden. Wenn Sie merken, dass ein Test-Datensatz öffentlich gelangt ist (z.B. in einem Demo-Video), kontaktieren Sie uns unter mateusz.viola@akara-solutions.de, wir können den Datensatz aus der Generierungs-Logik ausschließen.

Brauche ich für interne Tests eine DSGVO-Dokumentation?

Nein, wenn die Fake-Daten ohne Personenbezug generiert wurden. Wenn Sie aus Produktivdaten ableiten, brauchen Sie eine Pseudonymisierungs-Beschreibung nach Art. 4 Nr. 5 DSGVO und eine Risikoabschätzung. Synthetische Daten von Tools wie fake-name.de fallen nicht unter den DSGVO-Anwendungsbereich (Art. 2 (1)).

Warum Fake-Namen für Tests verwenden, und wann nicht

Die fünf legitimen Einsatzfelder

Ein Fake-Datensatz erfüllt einen Zweck nur dann, wenn er gegen einen echten Datensatz ausgetauscht werden kann, ohne dass sich die Test-Aussage ändert. Das gilt in genau fünf Konstellationen, in denen wir Fake-Namen aus der Praxis kennen.

Erstens automatisierte Tests: Eine Unit-Test-Suite, die das Anmeldeformular gegen 50 verschiedene Namenslängen wirft, braucht echte Variation, nicht “John Doe” fünfzigmal. Hier kommt es darauf an, dass Sonderzeichen, Umlaute, Bindestriche und Akzente realistisch vertreten sind, sonst bleiben Edge-Cases unentdeckt. Eine “Müller-Lüdenscheidt”, eine “Şenay Yıldırım” und ein “Géraud d’Espagnac” decken in zwei Minuten ab, wofür eine Person mit einer Liste von Bekannten Stunden bräuchte.

Zweitens Lehr- und Schulungsmaterial: Wenn ein Skript zeigt, wie ein CRM bedient wird, sollen die Übungsdaten echte Namensvariationen abbilden, ohne dass Kollegen ihre Privatadressen sehen. Fake-Daten lösen das, ohne dass die Schulung weniger lebensnah wirkt.

Drittens Demo- und Pitch-Umgebungen: Vor einem Kunden vorzuführen, wie das eigene Tool mit echten Daten umgeht, scheitert spätestens dann, wenn das Logging eingeschaltet ist und Kollegen den Demo-Screenshot fünf Minuten später twittern. Fake-Daten sind hier nicht nur sinnvoll, sondern Pflicht.

Viertens Datenmigrations-Skripte: Ein ETL-Skript, das vom Alt-System ins neue migrieren soll, will erst gegen einen Probelauf laufen, bevor es Produktion sieht. Dieser Probelauf braucht Daten, die in Format und Verteilung den echten ähneln, ohne ihre Inhalte zu enthalten.

Fünftens Mockups und Wireframes: Ein Designer kann nicht beurteilen, ob ein Layout funktioniert, wenn überall “Lorem Ipsum Dolor” steht, denn echte Namen sind länger, kürzer, anders verteilt. Eine “Hannelore Pfaff” mit einer 12-stelligen Mobilnummer prüft das Layout härter als jeder Platzhalter.

Wo die Grenze klar verläuft

Sobald die Fake-Daten einen Vertrag begründen, einen Anspruch entstehen lassen oder eine Person außerhalb des Test-Kontexts zur Reaktion bringen, ist die Grenze überschritten.

Konkret: Wer mit einem generierten Namen ein Konto bei einer Bank eröffnet, fälscht beweiserhebliche Daten im Sinne von § 269 StGB. Wer mit einer Fake-Identität Waren bestellt und nicht bezahlt, begeht Betrug (§ 263 StGB), und zwar unabhängig davon, ob der Name zufällig auf eine reale Person trifft.

Bei Newsletter-Abos und Service-Anmeldungen ist die Lage feiner. Solange die vertragliche Hauptleistung nicht von der korrekten Identifikation abhängt (also bei reinen Informations-Newslettern, kostenlosen Probezugängen oder Foren-Accounts), gilt die Pseudonymisierung der eigenen Daten als zulässig. Bei kostenpflichtigen Diensten, Bezahl-Vorgängen oder rechtlich relevanten Erklärungen kippt die Bewertung.

Wann der Test-Charakter offiziell endet

Eine in der Praxis nützliche Faustregel: Sobald Sie einen Datensatz aus der Test-DB in die Produktions-DB kopieren, ist er kein Test-Datensatz mehr. Das gilt auch dann, wenn Sie es “nur für eine Stunde” machen, “weil der Echt-Datensatz noch nicht da ist”.

Wir sehen diesen Fehler häufig bei kleineren Teams ohne klare Staging-Trennung. Der Fake-Datensatz “Mateusz Viola, Feldstraße 97, 25421 Pinneberg” landet im Live-Order-System, weil der Mitarbeiter im falschen Tab gearbeitet hat, und plötzlich verschickt das System eine Bestellbestätigung an eine reale Adresse. Auch wenn niemand vorsätzlich gehandelt hat: aus DSGVO-Sicht ist ein Datensatz, der einen realen Adressbestandteil enthält und in einem produktiven Kontext landet, ein meldepflichtiger Vorfall.

Drei Praxis-Faustregeln

Aus rund 40 von uns begleiteten Projekten haben sich drei Regeln bewährt, die wir hier zusammenfassen.

Regel 1: Fake-Daten kommen nie in eine Datenbank, die nicht “test” oder “staging” im Namen trägt. Der Schemaname ist Ihre einzige durchgängige Schutzlinie, weil Logs, Backups und Replication den Inhalt nicht inspizieren.

Regel 2: Vor jedem Demo-Lauf wird die DB einmal neu gesäubert. Selbst wenn der vorherige Test sauber war, kann ein E-Mail-Versand-Cron-Job über Nacht einen Fake-Datensatz in eine echte Mailing-Liste geschoben haben. Wer das nicht prüft, weiß es nicht.

Regel 3: Fake-Daten werden mit einem klar erkennbaren Marker erzeugt. Bei fake-name.de können Sie zum Beispiel jeden Datensatz mit dem Präfix “TST_” speichern, oder ein extra Feld is_test = true mitführen. So findet ein simpler SQL-Query alle Test-Datensätze, falls einer doch versehentlich in Produktion gelandet ist.

Konkretes Rechenbeispiel: was ein Versehen kostet

Stellen Sie sich ein mittelständisches Unternehmen mit 50.000 Kundendatensätzen vor. In einer Migration läuft das Skript versehentlich gegen die Produktions-DB, schreibt 1.200 generierte Fake-Datensätze ein, und der Mailversand-Cron-Job versendet noch in derselben Nacht 1.200 Begrüßungs-Emails an die Adressen.

Nun: Wenn die Adressen echte Personen treffen, selbst nur in 0,01 % der Fälle, also 1 von 10.000, sind das 12 reale Personen mit Datenschutz-Beschwerde-Anspruch. Die DSGVO sieht für solche Fälle Bußgelder bis 4 % des Jahresumsatzes vor (Art. 83). Bei einem Unternehmen mit 10 Mio. € Jahresumsatz sind das theoretisch bis zu 400.000 €. In der Praxis verhängen Aufsichtsbehörden in solchen Fällen üblicherweise fünf- bis sechsstellige Beträge, bei nachweislichem Versäumnis der Test-Produktions-Trennung in der Tat eher die Obergrenze.

Die direkten Kosten der Meldung an die Aufsichtsbehörde (innerhalb von 72 Stunden, Art. 33 DSGVO), der internen Nachbearbeitung und der Kommunikation an die betroffenen Personen liegen erfahrungsgemäß bei mehreren zehntausend Euro, auch ohne Bußgeld.

Test-, Staging- und Produktionsumgebung müssen drei sauber getrennte Datentypen kennen.

Eine kurze Tabelle für die Team-Entscheidung

Wenn Sie unsicher sind, ob ein konkreter Use-Case Fake-Daten erlaubt oder nicht, hilft die folgende Tabelle:

Use-Case	Fake-Daten okay?	Begründung
Unit-Test gegen Form-Validierung	ja	rein technisch, keine echte Person involviert
Demo-Video für externe Präsentation	ja	Pflicht, Datenschutz der Echtkunden geht vor
Mailversand-Test gegen Test-SMTP-Server	ja	Mails landen in einem Mock-Inbox, nicht in echtem Postfach
Mailversand-Test gegen echten SMTP-Server	nein	Mails landen in echter Inbox des Adressaten
Bestellung im Live-Shop testen	nein	Vertragsbegründung, § 263 StGB betroffen
Newsletter-Abo bei externem Dienst	grenzwertig	erlaubt wenn keine Bezahlung; verboten bei Free-Trial mit Kreditkarte
Schulungs-CRM-System	ja	Übungsdaten dürfen kontrolliert variieren
Bewertung auf Google Maps abgeben	nein	beweiserhebliche Daten, § 269 StGB

Achtung: Die “grenzwertig”-Kategorie ist die häufigste Falle. Wenn Sie sich nicht sicher sind, ob ein Anbieter die korrekte Identifikation rechtlich braucht, prüfen Sie zuerst die AGB des Anbieters auf “wahrheitsgemäße Angaben”-Klauseln. Steht dort eine, gehören Sie in die “nein”-Kategorie.

Worauf es ankommt

Drei Sätze. Fake-Namen sind ein Werkzeug für technische Test-Kontexte und nichts darüber hinaus. Die Grenze verläuft am Übergang von der Test- zur Produktions-DB, beim Versand an reale Mailadressen und bei jedem Vorgang, der einen Rechtsbezug begründet. Wer diese drei Übergänge im Team explizit benennt und mit technischen Mitteln (Schema-Trennung, Marker-Felder, Mail-Mocks) absichert, kann Fake-Daten zu einem Standard-Werkzeug machen, ohne dabei je in Erklärungsnot zu geraten.