Fake Unternehmensdaten sind ein nützliches technisches Material und eine ernste Haftung im selben Paket. Derselbe Datensatz, der Ihnen erlaubt, ein Onboarding-Formular gefahrlos zu proben, wird zur Falschdarstellung, sobald er als echtes Unternehmen präsentiert wird, und die Grenze zwischen beiden Verwendungen wird leichter überschritten, als die meisten Teams erwarten – oft durch einen Screenshot, einen Export oder eine E-Mail, die niemand als Auslieferung verstanden hat.
Dieser Artikel legt dar, welche Verwendungen zulässig sind, welche nicht, wie man synthetische Datensätze unmissverständlich synthetisch macht und wie man sie in den Umgebungen hält, in die sie gehören.
Wofür sind Fake Unternehmensdaten gedacht?
Sie existieren, damit Software an einem Geschäftsdatensatz erprobt werden kann, ohne ein Unternehmen einzubeziehen. Das umfasst mehr, als man annimmt:
- Formulare während Entwicklung und Qualitätssicherung ausfüllen, damit Prüfregeln tatsächlich greifen können.
- Eine Staging- oder Demonstrationsumgebung füllen, damit sie wie ein funktionierendes Produkt aussieht.
- Eine Datenbank in großem Umfang befüllen, um Last und Leistung zu proben.
- Stabile Testdatensätze bereitstellen, damit automatisierte Tests auf bekannte Eingaben prüfen können.
- Konto-, Rechnungs- und Prüfabläufe proben, bevor sie einen Kunden berühren.
- Screenshots, Dokumentation und Schulungsmaterial erstellen, ohne jemandes Angaben offenzulegen.
Jeder Punkt dieser Liste teilt eine Eigenschaft: Der Datensatz verlässt nie einen kontrollierten Zusammenhang, und kein Ergebnis hängt davon ab, dass die Welt ihn für wahr hält. Der Datensatz ist ein Reiz für ein System und keine Aussage über die Wirklichkeit.
Welche Verwendungen sind ausgeschlossen?
Ausgeschlossen sind die Verwendungen, in denen der Datensatz aufhört, ein Reiz zu sein, und zu einer Behauptung wird. Sie verdienen eine klare Aufzählung, weil jede von ihnen eine harmlos klingende Variante hat, zu der Menschen greifen, wenn sie es eilig haben.
Verwenden Sie erfundene Unternehmen nicht, um echte Konten zu eröffnen, Zulassungen oder Genehmigungen zu erhalten oder eine Prüfung abzuschließen, deren Zweck es ist, die Existenz eines echten Unternehmens festzustellen. Stellen Sie eine synthetische Rechtsperson nicht einem echten Kunden, Partner oder einer Behörde als Gegenpartei vor. Verwenden Sie erfundene Kennungen nicht auf einer echten Rechnung und auf keinem Dokument, auf das sich jemand außerhalb Ihrer Organisation verlassen wird. Und hängen Sie keine erfundene Identität an eine reale Person oder ein reales Unternehmen – nicht als Platzhalter in einer Demo, nicht als Startwert in einem Produktivsystem, nicht als vorläufigen Datensatz, während die echten Daten noch eintreffen.
Der gemeinsame Nenner ist nicht, dass die Daten falsch wären. Es ist, dass ihre Verwendung an diesen Stellen der Versuch ist, ein System etwas Falsches glauben zu lassen, und wo Geld, Zugang oder Erlaubnisse im Spiel sind, ist das Betrug und keine Testabkürzung.
Es gibt eine leisere zweite Kategorie: Verwendungen, die nicht betrügerisch sind und trotzdem schaden. Etwa die Registrierungsangaben eines echten Unternehmens in eine Entwicklungsdatenbank zu kopieren oder einen Zahlungsweg mit den Bankdaten eines echten Lieferanten zu testen. Die Absicht ist gutmütig; die Wirkung ist trotzdem, dass fremde Daten in eine Umgebung mit schwächeren Kontrollen und mehr Kopien wandern.
Warum ist die Annahme trügerisch, dass es niemand sehen wird?
Weil synthetische Daten selten dort bleiben, wo sie entstanden sind, und weil die Leckwege alltäglich sind und nicht dramatisch.
Ein Testdatensatz wird in eine Sicherung kopiert. Ein Screenshot einer Staging-Maske wird in ein Ticket eingefügt. Ein Export landet in einer Tabellenkalkulation, die zur Durchsicht per E-Mail herumgereicht wird. Eine Demonstrationsumgebung wird einem Interessenten geöffnet. Die Sandbox eines Integrationspartners behält die Nutzdaten in ihren eigenen Protokollen. An keiner Stelle hat jemand entschieden, etwas zu veröffentlichen, und doch liegt ein Datensatz, der nie als echtes Unternehmen behandelt werden sollte, nun irgendwo, wo auf seiner Grundlage eine echte Geschäftsentscheidung getroffen werden könnte.
Die Folge skaliert damit, wie überzeugend der Datensatz ist. Ein Datensatz, der offensichtlich Platzhaltertext ist, grenzt sich selbst ein: Ein Leser versteht sofort, dass es sich um Beispieldaten handelt. Ein Datensatz, der wohlgeformt, in sich stimmig und plausibel benannt ist, kann von jedem, der ihm ohne Kontext begegnet, für eine echte Gegenpartei gehalten werden – und ein solcher Irrtum lässt sich schwer auflösen, weil aufgrund des Datensatzes möglicherweise schon gehandelt wurde.
Wie macht man synthetische Daten offensichtlich synthetisch?
Indem man die Markierung in die Daten einbaut und nicht in die umgebende Dokumentation, sodass der Datensatz seine eigene Warnung trägt.
Die Namen sind der erste Hebel. Ein erzeugter Firmenname sollte aus einem neutralen Wortschatz zusammengesetzt sein und auf den ersten Blick als Platzhalter lesen – klar erfundene Wörter in der Gestalt einer Rechtsform, niemals der Name einer echten Firma und niemals einem solchen zum Verwechseln ähnlich. Dasselbe gilt für jeden weiteren Unternehmensnamen im Datensatz: jede zugeordnete Person, jeden Geschäftsnamen, jede Marke.
Die Adressen sind der zweite Hebel. Die Dokumentationspraxis verwendet seit langem reservierte Beispieladressen für genau diesen Zweck, und wer dieser Konvention folgt, verhindert, dass ein synthetischer Datensatz auf ein reales Grundstück zeigt. Das Prinzip verallgemeinert sich, auch wenn die konkrete Konvention unbekannt ist: Eine synthetische Adresse sollte keine echte Adresse sein und auch keine, die dafür gehalten werden könnte.
Die Kennungen sind der dritte Hebel. Erzeugte Registernummern, Steuernummern und Umsatzsteuernummern sollten gestaltkorrekt und nicht eingetragen sein – ein Zustand, der ein Formular erfüllt und eine Abfrage scheitern lässt, was genau das Verhalten ist, das ein Test braucht. Domainnamen sollten im reservierten Beispielraum bleiben, damit niemals Post oder Datenverkehr an ein reales Ziel abgeht.
Markieren Sie schließlich die Daten selbst und nicht nur die Datei. Ein Kennzeichen auf Zeilenebene, ein reservierter Identitätsschlüssel, ein synthetisches Präfix in einem Referenzfeld – irgendetwas, worauf eine Abfrage filtern kann – verwandelt die Annahme, dass es sich um Testdaten handelt, in den Nachweis, auf den man sich stützen kann.
Für Entwickler: Isolation, Kennzeichnung und Aufräumen
Behandeln Sie synthetische Datensätze als eigene Datenklasse mit eigenem Lebenszyklus und erzwingen Sie die Isolation im System statt in einer Verfahrensanweisung.
Die Umgebungstrennung kommt zuerst. Testeinheiten sollten Produktionswege überhaupt nicht erreichen können: eigene Zugangsdaten, nach Möglichkeit getrennte Speicher und keine gemeinsamen Warteschlangen oder ausgehenden Integrationen, über die ein synthetischer Datensatz eine echte Nachricht auslösen könnte. Der verwandte Prüfablauf ist die Stelle, an der das am meisten zählt, weil ein Prüflauf, der eine echte Behörde erreicht, genau der Unfall ist, den es zu verhindern gilt.
Die Kennzeichnung kommt zweitens. Jede exportierte Datei sollte eine Kopfzeile oder einen Begleitvermerk tragen, der festhält, dass der Inhalt zu Testzwecken erfunden ist, dass kein reales Unternehmen beschrieben wird und dass die Datensätze nicht dafür verwendet werden dürfen, Konten zu eröffnen, Zulassungen zu erlangen oder echte Dokumente auszustellen. Protokolle verdienen dieselbe Behandlung: Schwärzen oder markieren Sie synthetische Werte beim Eintragen, damit eine Protokollsuche einen erzeugten Datensatz nicht mit einem echten verwechselt.
Das Aufräumen kommt drittens und ist der Schritt, der übersprungen wird. Testumgebungen sammeln sich an: eingespielte Zeilen, die niemand nutzt, Testdaten aus einem beendeten Projekt, Konten aus einer Demo. Geben Sie ihnen ein Ablaufdatum, sehen Sie sie regelmäßig durch und löschen Sie, was keinen Eigentümer mehr hat. Die erzeugten Unternehmensdatensätze, die Sie für eine Probe anlegen, lassen sich aus demselben Identitätsschlüssel günstig neu erzeugen, es gibt also selten einen Grund, sie zu behalten.
Eine letzte Gewohnheit, und sie geht in der Praxis am häufigsten schief: Greifen Sie nie zu einem erzeugten Datensatz als vorläufige Lösung in der Produktion. Fehlt ein echter Wert, besteht die richtige Antwort darin, dass das Feld seine Abwesenheit akzeptiert, und nicht darin, es mit etwas Erfundenem zu füllen – denn ein leeres Feld scheitert sichtbar, ein erfundenes scheitert leise. Das größere Bild dessen, was ein synthetischer Datensatz enthält, findet sich in den Testunternehmensdaten, und die Kennungsseite desselben Problems behandelt der Beitrag zur Handelsregisternummer.
Nächste Schritte
Suchen Sie eine Stelle, an der in Ihrer Organisation bereits synthetische Unternehmensdaten existieren, und prüfen Sie drei Dinge: ob sie sichtbar erfunden sind, ob sie in den Daten und nicht nur in einem Dokument als solche markiert sind und ob sie die Produktion erreichen können. Beheben Sie diese Woche die schwächste der drei. Erzeugen Sie dann mit diesen Regeln im Unternehmensdaten-Generator einen frischen Satz, damit die nächste Umgebung, die Sie befüllen, von Anfang an ehrlich beginnt.