Derselbe Pass, zwei Antworten
Ein Reisepass ist ein Reisepass. Er wird von einem Staat ausgestellt, enthält einen NFC-Chip, ist maschinenlesbar und weltweit als Identitätsnachweis anerkannt. Man sollte annehmen, dass ein Unternehmen, das diesen Pass einmal als Identitätsnachweis akzeptiert hat, ihn auch ein zweites Mal akzeptiert.
Diese Annahme ist falsch. Dieser Teil beschreibt, warum.
Akt 1: Der Pass wird akzeptiert
Beim Anlegen meines Profils auf einem großen Karrierenetzwerk passierte etwas Unerwartetes: Während ich Profildaten manuell eintrug, sperrte die Plattform mein Konto. Die Begründung, soweit überhaupt eine gegeben wurde: verdächtige Aktivität. Was daran verdächtig war, Berufsstationen und Qualifikationen in ein Formular zu tippen, blieb offen.
Um das Konto wieder freizuschalten, verlangte die Plattform eine Identitätsprüfung per Reisepass. Ich reichte meinen deutschen Pass ein — von meinem Wohnort außerhalb der EU aus. Die Prüfung lief durch. Das Konto war wieder freigeschaltet.
Festzuhalten: Deutscher Pass, Nicht-EU-Standort, erfolgreich verifiziert. Dokumentiert, abgeschlossen, funktioniert.
Akt 2: Derselbe Pass wird abgelehnt
Wochen später wollte ich die Profilverifizierung durchlaufen — jenes Abzeichen, das anzeigt, dass die Identität eines Profils bestätigt wurde. Dafür nutzt die Plattform einen externen Dienstleister namens Persona.
Derselbe Pass. Derselbe Standort. Dasselbe Gerät. Die Verifizierung scheitert. Reproduzierbar.
Ich wandte mich an den Support. Nach mehreren Runden kam eine ausführliche, professionell formulierte Antwort, die die Sache klarstellte. Sinngemäß: Die Verifizierung könne nicht abgeschlossen werden, wenn ein EU-ausgestelltes Ausweisdokument mit einem Nicht-EU-Standort zusammentreffe. Grund seien Anforderungen an Datenverarbeitung und -speicherung. Das sei kein technischer Fehler und nichts, was der Support umgehen oder manuell erledigen könne.
Ich verwies auf Akt 1 — dieselbe Konstellation, erfolgreich geprüft, wenige Wochen zuvor. Die Antwort darauf war bemerkenswert offen:
Eine zuvor erfolgreiche Identitätsprüfung garantiert keine Berechtigung für die Persona-basierte Profilverifizierung, da jeder Ablauf seinem eigenen Compliance-Rahmen unterliegt.
Und weiter:
Support-Teams haben nicht die Möglichkeit, alternative Verifizierungsmethoden außerhalb des genehmigten Verfahrens anzuwenden.
Das ist keine Ausrede. Das ist eine präzise Beschreibung des Problems — nur eben aus der Perspektive dessen, der es verursacht hat. Die Plattform bestätigt: Es gibt einen Weg, der mit meinen Dokumenten funktioniert hat. Es gibt einen zweiten, der nicht funktioniert. Und der erste darf nicht verwendet werden, um den zweiten zu ersetzen, weil die beiden Wege organisatorisch nichts miteinander zu tun haben.
Der Nutzer steht dazwischen und ist nach der internen Logik zweier Systeme gleichzeitig verifiziert und nicht verifizierbar.
Akt 3: Die Kettenreaktion
Ein blockiertes Abzeichen wäre für sich genommen ein kosmetisches Problem. Es bleibt aber nicht dabei, denn die Plattform hat ihre Funktionen aufeinander gestapelt:
Die Identitätsverifizierung ist Voraussetzung für das Anlegen und Verifizieren einer Unternehmensseite. Die verifizierte Unternehmensseite mit registrierter Domain ist wiederum Voraussetzung dafür, sich im persönlichen Profil über eine berufliche E-Mail-Adresse verifizieren zu lassen.
Drei Funktionen, eine Abhängigkeitskette, ein blockiertes erstes Glied. Für einen Soloselbständigen, der die Plattform beruflich nutzen will, bedeutet das: kein Verifizierungsabzeichen, keine Unternehmensseite, keine berufliche Verifizierung. Nicht wegen fehlender Nachweise — ich besitze einen gültigen Pass, eine registrierte Firma und eine eigene Domain — sondern weil ein Prüfverfahren eine Konstellation nicht vorsieht, die ein anderes Prüfverfahren desselben Anbieters problemlos verarbeitet hat.
Es gibt keinen dokumentierten Ausweichweg. Der Support darf keinen anbieten. Das ist die vollständige Auskunft.
Was daran fachlich interessant ist
Der genannte Ablehnungsgrund lautet sinngemäß: Anforderungen an Datenverarbeitung und -speicherung. Datenschutzrecht also.
Das ist die Pointe dieser Serie. In Teil 1 ging es darum, dass das europäische Datenschutzrecht materiell gilt, der Beschwerdeweg für Betroffene außerhalb der EU aber praktisch ins Leere führt. In Teil 2 ging es darum, dass ein Auskunftsanspruch mit Textbausteinen beantwortet und am Ende ausdrücklich verweigert wurde. Und hier taucht dasselbe Datenschutzrecht ein drittes Mal auf — diesmal aber nicht als mein Recht, sondern als Begründung des Unternehmens dafür, warum es mir eine Funktion verweigert.
Ob diese Begründung trägt, kann ich nicht beurteilen. Ich kenne die internen Datenflüsse des Verifizierungsdienstleisters nicht, und ich will nicht spekulieren. Was ich beurteilen kann, ist die Widersprüchlichkeit im Ergebnis: Dieselben Daten, dieselbe Person, derselbe Ort — einmal verarbeitbar, einmal nicht. Wenn regulatorische Anforderungen der Grund sind, dann müsste die erste Prüfung ebenso problematisch gewesen sein wie die zweite. War sie offenbar nicht.
Plausibler ist eine schlichtere Erklärung: Zwei Systeme, zwei Regelwerke, historisch getrennt gewachsen, niemand mit Zuständigkeit für die Lücke dazwischen. Gewachsene Systemlandschaft — das kennt jeder, der schon einmal in einer größeren IT-Organisation gearbeitet hat.
Nur ist das intern eine Unannehmlichkeit und extern etwas anderes. Intern ruft man den Kollegen an, der die Ausnahme freigibt; man kennt die Zuständigkeiten, man kommt an die Menschen heran, und im Zweifel eskaliert man eine Ebene höher. Hier gibt es keinen Kollegen. Es gibt einen Support, der ausdrücklich erklärt, dass er nichts freigeben darf, keine benennbare Instanz dahinter und keinen Weg, den Widerspruch überhaupt zur Entscheidung zu bringen.
Eine Organisation darf ihre internen Systembrüche haben. Was sie nicht darf, ist die Folgen davon nach außen weiterreichen und den Betroffenen gleichzeitig jeden Weg abschneiden, sie zu korrigieren. Genau das passiert hier: Der Fehler liegt vollständig in der Sphäre des Anbieters, die Konsequenzen trägt ausschließlich der Nutzer.
Was ich daraus mitnehme
Drei Dinge, die über diesen konkreten Fall hinausgehen und für jeden gelten, der geschäftlich von einer Plattform abhängt:
Abhängigkeitsketten sind ein Risiko, das man vorher kennen sollte. Wenn drei Funktionen aufeinander aufbauen, ist die unterste ein Single Point of Failure. Das gilt für Serverarchitekturen genauso wie für Plattformkonten — nur dass man bei der eigenen Architektur die Reihenfolge selbst bestimmt.
Dokumentation ist das Einzige, was man selbst in der Hand hat. Screenshots, Zeitstempel, Ticketverläufe, Serverprotokolle. Ohne sie hätte ich Akt 1 nicht belegen können, und die ganze Geschichte wäre eine Behauptung geblieben. Mit ihnen ist sie ein dokumentierter Widerspruch.
Reichweite auf fremdem Boden ist geliehen. Diese drei Artikel stehen auf meiner eigenen Domain, auf meinem eigenen Server. Das ist keine ideologische Entscheidung, sondern eine praktische: Was hier steht, kann mir niemand mit einem Regelwerk-Update wegnehmen.
Damit ist die Serie abgeschlossen. Nicht mit einer Lösung — die gibt es nicht — sondern mit einer Bestandsaufnahme.
Dies ist Teil 3 einer dreiteiligen Serie. Teil 1 analysiert die Zuständigkeitslücke im DSGVO-Beschwerderecht für EU-Bürger außerhalb der EU. Teil 2 dokumentiert ein Auskunftsverfahren nach Art. 15 DSGVO von der Anfrage bis zur Verweigerung.
Wer ähnliche Erfahrungen gemacht hat, eine Konstellation kennt, in der es doch funktioniert hat, oder schlicht anderer Meinung ist: Ich freue mich über eine Nachricht. Rückmeldungen zu dieser Serie erreichen mich am besten über das Kontaktformular.