Anonymität als Architektur-Invariante: warum „wir kontaktieren Sie nicht” nicht reicht
Versprechen wie „Sie werden nie unaufgefordert kontaktiert” sind in B2B-Plattformen nicht durchsetzbar — Anbieter umgehen sie offline. Was funktioniert ist eine technische Invariante: Kontaktdaten leben in einer getrennten Sphäre, der Server gibt sie erst bei beidseitigem Match frei. Eine Eigenschaft des Codes, kein TOS-Satz.
Klassisches B2B-Matching-Versprechen: „Sie werden nie unaufgefordert kontaktiert.” Schön formuliert. Nicht haltbar.
Eine Plattform kann nicht verhindern, dass ein Anbieter außerhalb der Plattform recherchiert, eine Firmen-Nummer aus dem Handelsregister zieht und anruft. Das Versprechen ist eine Behauptung über die Welt — und die Welt ist breiter als jeder TOS-Vertrag.
Was wirklich trägt: Architektur-Invarianten
Auf PairSonal haben wir das Versprechen umformuliert. Statt:
„Wir werden Ihre Kontaktdaten nicht weitergeben.”
steht jetzt:
„Ihre HR-Kontaktdaten sind auf der Plattform technisch nicht für Anbieter sichtbar — solange Sie nicht selbst einen Match freigeben.”
Der Unterschied ist nicht semantisch. Er ist strukturell:
- Kontaktdaten leben in einer separaten Datenbank-Sphäre.
- Listing-Endpoints geben Profile zurück, in deren Payload
email,telefon,kontakt_personschlicht nicht existieren. - Match-Endpoint führt server-seitig erst nach Freigabe das Join auf die Kontakt-Sphäre durch.
- Frontend hat keinen Code-Pfad, der die fehlenden Felder rekonstruieren könnte — der Typ-Generator weiß nicht, dass sie existieren.
Das Versprechen wird zur Eigenschaft des Codes. Wer testet „Was passiert, wenn ich Profile lade?” — die Felder fehlen. Nicht „sind gefiltert”, nicht „sind null” — existieren nicht im Schema.
Warum das stärker ist
- Auditierbar. Ein Auditor liest die OpenAPI-Schemata und kann feststellen: die Kontaktfelder existieren in der Anonymous-Sphäre nicht. Das ist Faktum, kein TOS.
- Skaliert mit Personal. Ein neuer Teamkollege kann nicht versehentlich ein Endpoint bauen, das die Felder leakt — sie liegen nicht in der Datenmodell-Klasse, die er importiert.
- Resistent gegen Auth-Bugs. Ein Bug in der Privilege-Layer kann keine versteckten Felder enthüllen, die im Response-Schema nicht existieren.
Wann das überzogen ist
Architektur-Invarianten kosten. Du baust effektiv zwei Datenmodelle, zwei Repositories, zwei Service-Klassen, eine explizite Bridge dazwischen. Bei einem User-Profil mit drei Attributen ist das Overkill.
Der Punkt, an dem es sich lohnt: wenn das Versprechen das Produkt ist. Wenn Kunden auf die Plattform kommen, weil sie der Anonymität trauen, dann darf die Anonymität keine TOS-Klausel sein. Sie muss in der Layer-Architektur stehen — sonst stirbt das Produkt mit dem ersten Leak.
Die generelle Regel
Bei jedem „wir werden nicht X tun”-Versprechen fragen wir uns inzwischen:
Können wir es so bauen, dass wir es technisch nicht können?
Wenn ja: bauen. Wenn nein: das Versprechen ist eine Behauptung, kein Feature — und sollte als Behauptung benannt werden, nicht als Feature verkauft.
Ähnlicher Brand bei dir?
Wir haben vermutlich schon etwas ähnliches gesehen. Sprich mit uns.
Gespräch starten→