KI-Mandantentrennung: Bewerberdaten auch beim Anbieter schützen

KI-Mandantentrennung verhindert, dass Kunden auf die KI-Eingaben, abgerufenen Kontextdaten und Ausgaben anderer Kunden zugreifen können. Im Recruiting müssen Sie dafür sowohl die Anwendung prüfen, die den Zugriff auf Kandidatendaten erlaubt, als auch den Anbieter, der den daraus entstehenden Prompt verarbeitet. Die Zusage, Ihre Daten nicht zum Modelltraining zu verwenden, beantwortet eine andere Frage.

Diese Unterscheidung ist auch dann wichtig, wenn Ihre Recruiter sämtliche übermittelten Felder lesen dürfen. Die Berechtigung kann zu Beginn einer Anfrage korrekt geprüft worden sein, während ein anderer Teil der Verarbeitung eigene Schutzmaßnahmen braucht. Verfolgen Sie die Kandidateninformationen deshalb durch die gesamte Verarbeitungskette, einschließlich der Antwort.

Die praktische Frage lautet: Welche Nachweise rechtfertigen es, diese Felder für diese Aufgabe über diesen Verarbeitungsweg zu senden? Klären Sie das, bevor Sie eine weitere KI-Funktion für Ihren gesamten Recruiting-Prozess freigeben.

Was belegt Cloudflares Veröffentlichung?

Cloudflares Veröffentlichung vom 26. Oktober betrifft GLM-5.3 auf Workers AI. Demnach wurden zwischen dem 27. August und dem 9. September 2026 in 155 Antworten Inhalte anderer Kunden offengelegt. Betroffen waren Prompts mit mehr als 681.280 Tokens. Cloudflare nennt kein weiteres betroffenes Workers-AI-Modell und berichtet, keine Hinweise auf eine gezielte Ausnutzung gefunden zu haben.

Laut Cloudflare leitete die Inferenz-Engine eine Ablehnung aus der Prefill-Phase nicht an die Decode-Phase weiter. Diese las daraufhin Cache-Seiten, die nicht von der betreffenden Anfrage beschrieben worden waren. Cloudflare erhielt die Meldung des Forschers am 8. September, schränkte das Modell am Folgetag ein und stellte es nach Korrekturen an Konfiguration und Engine wieder bereit. Der Bericht erschien im Rahmen einer koordinierten Offenlegung.

Beschrieben wird ein Fehler bei der Trennung von Inferenzanfragen. Daraus folgt nicht, dass Kunden-Prompts zum Training verwendet wurden. Die Diskussion auf Hacker News machte die Veröffentlichung zu einem aktuellen Thema. Keine der beiden Quellen belegt, dass Bewerbungsunterlagen oder Anfragen aus Kit betroffen waren.

Welche KI-Datenschutzzusagen beantworten unterschiedliche Fragen?

Prüfen Sie Training, Aufbewahrung, Berechtigungen und Mandantentrennung jeweils gesondert. Eine überzeugende Antwort zu einem dieser Punkte belegt die anderen nicht.

Offizielle Dokumentationen behandeln diese Themen häufig getrennt. Die aktuelle Dokumentation zur Datennutzung bei Workers AI beschreibt Training und die Aufbewahrung bei der Inferenz ebenso wie zustandsbehaftete Funktionen, ausgewählte Speicherangebote sowie Protokollierung oder Caching über Gateways. Lesen Sie die Bedingungen für den tatsächlich genutzten Dienst. Übertragen Sie dessen Zusagen nicht auf einen anderen Dienst, den Sie über ein Gateway erreichen.

Auch Microsoft Foundrys Datenschutzdokumentation behandelt Kundentrennung, Trainingsnutzung, gespeicherte Funktionsdaten und Missbrauchsüberwachung gesondert. Die Bedingungen hängen von der Bereitstellung und den verwendeten Funktionen ab. Diese Dokumentationen zeigen, welche Fragen Sie stellen sollten; sie begründen keine Rangfolge der Anbieter.

Halten Sie zu jeder Antwort fest, wofür sie gilt. Ohne benannten Dienst und zugehörige Bedingungen bleibt bei „kein Training“ vieles offen. Dasselbe gilt für „keine Aufbewahrung“, wenn die aktivierten Funktionen nicht genannt werden. Hinterlegen Sie neben der jeweiligen Konfiguration einen datierten Link oder eine freigegebene Vertragsreferenz. So ist später nachvollziehbar, was die ursprüngliche Entscheidung abdeckte.

Welche Kandidateninformationen braucht diese Aufgabe tatsächlich?

Wählen Sie die für die Aufgabe erforderlichen Felder aus, bevor Sie den Prompt zusammenstellen. Die Berechtigung, ein Kandidatenprofil zu öffnen, bedeutet nicht, dass jedes Feld in eine KI-Anfrage gehört.

Ein hypothetischer Auftrag lautet: „Fassen Sie die Erfahrung dieser Person im Betrieb von Produktionsdatenbanken anhand der Anforderungen für diese Backend-Stelle zusammen.“ Dafür sind die einschlägige Erfahrung und die Stellenkriterien nötig. Eine Telefonnummer, Privatanschrift, E-Mail-Signatur oder sachfremde vertrauliche Korrespondenz werden dafür normalerweise nicht gebraucht.

Legen Sie die vorgesehenen Eingaben fest, bevor Sie die Integration anbinden:

Das ist ein Vorschlag zur Feldauswahl, keine Aussage über die Voreinstellungen eines bestimmten Produkts. Eine andere Aufgabe kann andere Informationen benötigen. Ein Nachrichtenentwurf braucht möglicherweise einen Namen; der Versand braucht eine Zieladresse im versendenden System. Die Zieladresse muss deshalb nicht zwangsläufig im Prompt an das Modell stehen.

OWASPs Leitlinien zur Offenlegung sensibler Informationen behandeln minimale Berechtigungen, eingeschränkte Datenquellen sowie Schwärzung oder Tokenisierung. Wenden Sie diese Grundsätze auf die konkrete Aufgabe an. Eine allgemeine Anweisung wie „Daten vertraulich behandeln“ ersetzt keine Schutzmaßnahme.

Auch bei internen Referenzen ist Sorgfalt nötig. Kann Ihre Anwendung die Referenz wieder einer Person zuordnen, sollten Sie das Ergebnis nicht als anonym bezeichnen. Ein ausführlicher beruflicher Werdegang kann jemanden auch ohne Namensangabe identifizieren. Datenminimierung verringert die Menge potenziell offengelegter Informationen. Sie repariert keine Inferenz-Engine und verhindert nicht jede mögliche Schlussfolgerung.

Erstellen Sie für jeden Ablauf eine kurze Prüfdokumentation. Halten Sie Aufgabe, anfragende Rolle, Quelldatensätze, ausgewählte Felder, Empfänger und Speicherorte für Eingaben oder Ausgaben fest. Berücksichtigen Sie auch Wiederholungsversuche und Ausweichwege. Kennzeichnen Sie offene Fragen ausdrücklich und weisen Sie Verantwortliche zu, damit Ungewissheit nicht stillschweigend als Zustimmung gilt. Unser Leitfaden zur Sicherheit von Kandidatendaten ordnet den Umgang mit den Datensätzen rund um die Anfrage ein.

Was sollten Sie den Inferenzanbieter fragen?

Verlangen Sie Nachweise, die zu Ihrem Dienst, Modell und Ihrer Bereitstellung passen. Eine allgemeine Sicherheitsseite liefert hilfreichen Hintergrund. Ihre Entscheidung muss aber den Verarbeitungsweg berücksichtigen, der die Bewerbungsinformationen tatsächlich erhält.

Beschreiben Sie zunächst Ihren Ablauf konkret. Erläutern Sie, welche Arten von Datensätzen Sie übermitteln möchten, ob Sie ein Gateway oder einen Router einsetzen, welche Speicherfunktionen aktiv sind und ob Ihre Anwendung fehlgeschlagene Anfragen wiederholt. Geben Sie dem Anbieter genug Informationen, um für Ihre Konfiguration antworten zu können.

Stellen Sie anschließend Fragen, aus deren Antworten Ihr Team eine Entscheidung ableiten kann:

• Trennung bei der Verarbeitung: Wie wird die Kundentrennung während der Inferenz und bei wiederverwendbaren Verarbeitungszuständen durchgesetzt? Welche Komponenten werden gemeinsam genutzt und welche Maßnahmen sichern die Trennung ab?
• Verhalten bei Fehlern: Was passiert, wenn eine Anfrage abgelehnt, abgebrochen, unterbrochen oder wiederholt wird? Deckt das dokumentierte Trennungskonzept auch diese Fälle ab?
• Speicherung: Welche aktivierten Funktionen speichern Prompts, Ausgaben oder zugehörige Datensätze? Welche Protokollierungs- und Cache-Einstellungen gehören zum Gateway und nicht zum Modelldienst?
• Nachweise bei Vorfällen: Mit welchen Kennungen kann der Anbieter eine Anfrage finden und den Umfang eines gemeldeten Problems eingrenzen? Wie erfahren Sie, ob der betreffende Dienst oder das Modell betroffen ist?
• Verantwortung für Änderungen: Wer informiert Ihr Team, wenn sich ein Verarbeitungsweg, ein Modell, eine Funktion oder eine Verarbeitungsbedingung so ändert, dass eine erneute Prüfung nötig wird?

Das sind vorgeschlagene Fragen für die Beschaffung. Sie bilden kein Zertifizierungsverfahren. Ein Anbieter kann berechtigte Gründe haben, sensible Implementierungsdetails nicht offenzulegen. Ihre Sicherheitsverantwortlichen benötigen dennoch ausreichend konkrete Nachweise, um über die Freigabe des Ablaufs zu entscheiden.

NISTs Leitlinien zur sicheren Entwicklung generativer KI richten sich an Hersteller und Beschaffer über den gesamten Lebenszyklus hinweg. Berücksichtigen Sie diese Perspektive bei der Aufgabenverteilung: Beschaffung, Konfiguration, Betrieb und Vorfallbearbeitung brauchen jeweils Verantwortliche. Die obigen Fragen übertragen diese Perspektive auf Recruiting-Abläufe; sie sind keine von NIST vorgeschriebene Checkliste.

Dokumentieren Sie das Ergebnis als ausdrückliche Entscheidung. Sie können eine eng begrenzte Aufgabe freigeben, weniger Eingabefelder zulassen, eine Speicherfunktion deaktivieren oder die Freigabe zurückstellen, bis eine wesentliche Frage geklärt ist. Hinterlegen Sie die Begründung bei Ihrer Übersicht der Verarbeitungswege. Spätere Teammitglieder sollten erkennen können, was eine erneute Prüfung auslösen würde.

Was können Ihre eigenen Tests zur Mandantentrennung belegen?

Ihre Tests können das beobachtete Verhalten der Anwendung in den von Ihnen kontrollierten Umgebungen prüfen. Den internen Betrieb der Infrastruktur eines verwalteten Anbieters können sie nicht zertifizieren.

Verwenden Sie synthetische Kandidaten in Konten, die Ihrer Organisation gehören. Geben Sie den Datensätzen eindeutig unterscheidbare erfundene Angaben und Referenzen. Nutzen Sie keine echten Bewerbungsinformationen als Testmarkierung und versuchen Sie nicht, Inhalte anderer Kunden abzurufen.

Ein sinnvoller Testplan für die Anwendung verfolgt den Zugriff bis zur Antwort:

1. Kontogrenze prüfen. Ein Mitglied aus Testkonto A fordert den synthetischen Kandidaten an, der ausschließlich zu Konto B gehört. Prüfen Sie, ob die Anwendung den Zugriff verweigert, bevor sie eine ausgehende Anfrage mit Informationen aus B erstellt.
2. Eingeschränkte Bereiche innerhalb eines Kontos prüfen. Ein Mitglied ohne Zugriff auf eine eingeschränkte Stelle fordert deren synthetische Kontextdaten an. Prüfen Sie die jeweiligen Stellenberechtigungen, statt sich allein auf die Kontomitgliedschaft zu verlassen.
3. Fehler und Wiederholungsversuche prüfen. Unterbrechen Sie eine Anfrage in der kontrollierten Testumgebung. Prüfen Sie, ob ein erneuter Versuch denselben berechtigten Konto- und Aufgabenkontext behält und ein Fehler keinen umfassenderen Datenabruf auslöst.
4. Ziel der Antwort prüfen. Führen Sie eine zulässige Anfrage aus und prüfen Sie, wo die Antwort gespeichert und angezeigt wird. Berücksichtigen Sie auch den Abschluss im Hintergrund, nicht nur die unmittelbare Antwort.
5. Zugriff nach einer Änderung prüfen. Ändern Sie die Berechtigungen des Testmitglieds, während eine Verarbeitung noch läuft. Prüfen Sie, ob sich Ihr Produkt wie zugesagt verhält, wenn die Antwort später verfügbar wird.

Halten Sie für jeden Test das erwartete Ergebnis vor der Ausführung fest. Sichern Sie genügend Nachweise, um eine abgewiesene Anfrage von einer Anfrage zu unterscheiden, die unzulässige Daten abgerufen und lediglich die Antwort verborgen hat. Diese unterschiedlichen Verhaltensweisen der Anwendung haben unterschiedliche Folgen.

Eindeutige synthetische Markierungen können helfen, einen Fehler im eigenen System nachzuverfolgen. Ein bestandener Test beweist nicht, dass jede Anfrage, jedes Modell, Gerät oder jede Bereitstellung des Anbieters isoliert ist. Begrenzen Sie Ihre Aussage zum Ergebnis: Der getestete Anwendungspfad verhielt sich unter den dokumentierten Bedingungen wie erwartet.

Legen Sie fest, bei welchen Änderungen der Testplan überprüft wird. Änderungen an Datenabruf, Hintergrundaufgaben, Anbieterwechseln bei Fehlern oder Ausgabespeicherung können die Sicherheitsgrenze verschieben, selbst wenn die sichtbare Recruiting-Funktion gleich aussieht. Prüfen Sie die einschlägigen Tests bei solchen Änderungen erneut. Die Fragen an den Anbieter bleiben von den Prüfaussagen für die Anwendung getrennt.

Wie gehen Sie mit unerwarteten Daten in einer KI-Antwort um?

Behandeln Sie unerwartete personenbezogene Datensätze als Vorfall, den Sie eindämmen und untersuchen müssen. Eine selbstsichere Erklärung des Modells ist kein Nachweis dafür, woher die Informationen stammen.

Beschränken Sie zunächst den Zugriff auf die Antwort und pausieren Sie den betroffenen Ablauf oder den Verarbeitungsweg zum Modell, während die zuständige Person den Vorfall bewertet. Legen Sie den Umfang der Unterbrechung so klar fest, dass Ihr Team weiß, welche Verarbeitung ausgesetzt ist. Kopieren Sie den unerwarteten Datensatz nicht in einen Gruppenchat, einen Support-Screenshot oder ein anderes externes KI-Werkzeug zur Analyse.

Sichern Sie die für die Untersuchung benötigten Kennungen und Konfigurationsangaben: Anfrage- und Antwortreferenzen, Zeitstempel, Modell und Verarbeitungsweg, relevante Einstellungen und das anfragende Konto. Bewahren Sie nach Ihrem Verfahren für Sicherheitsvorfälle nur die erforderlichen Inhalte auf. Beschränken Sie den Zugang zu diesen Nachweisen und benennen Sie eine verantwortliche Person.

Kontaktieren Sie dann den Anbieter über seinen Meldekanal für Vorfälle oder Sicherheitsprobleme. Bitten Sie um Unterstützung dabei, Herkunft und Umfang der Antwort zu klären. Untersuchen Sie selbst auch den Datenabruf und die Zuordnung von Ausgaben. Ein Anwendungsfehler bleibt eine mögliche Erklärung, solange die Nachweise keine andere Ursache belegen. Falls Sie einen solchen Meldekanal aufbauen, behandelt unser Leitfaden zur koordinierten Schwachstellenmeldung die zugehörigen Abläufe für den Eingang von Meldungen.

Verfolgen Sie, was nach Eingang der Antwort passiert ist. Wurde sie als Notiz gespeichert, in eine Kandidatenzusammenfassung aufgenommen, exportiert oder einer anderen prüfenden Person angezeigt? Die Eindämmung muss diese Kopien ebenso erfassen wie die ursprüngliche Anfrage. Dokumentieren Sie die Ergebnisse, ohne den Zugang zu den personenbezogenen Informationen selbst auszuweiten.

Lassen Sie die zuständigen Datenschutz- und Sicherheitsverantwortlichen anhand der bestätigten Fakten und geltenden Anforderungen prüfen, ob Benachrichtigungspflichten bestehen. Unerwarteter Text allein begründet keine bestimmte rechtliche Schlussfolgerung. Dokumentieren Sie vor der Wiederaufnahme, was fehlgeschlagen ist, welche Änderung die Wiederaufnahme rechtfertigt und was noch unklar bleibt.

Machen Sie die Zugriffs- und Verarbeitungsgrenzen in Kit deutlich

Beziehen Sie Kits Zugriffskontrollen und Anbietereinstellungen in Ihre Prüfung ein und halten Sie fest, was jeweils abgedeckt ist. Beides ersetzt nicht die Prüfung der Informationen, die die Anwendung verlassen.

Eine Prüfung des Quellcodes von Kits MCP-Werkzeug für Kandidatenzusammenfassungen zeigt eine konkrete Zugriffsgrenze: Das Werkzeug setzt eine Kontomitgliedschaft voraus, sucht den Kandidaten innerhalb des aktuellen Kontos und prüft zugängliche Stellenanzeigen. Ist ein Kandidat ausschließlich eingeschränkten Stellen zugeordnet, erhält ein Mitglied ohne entsprechenden Zugriff über dieses Werkzeug kein Ergebnis.

Die berechtigt abgerufene Zusammenfassung kann dennoch Name, E-Mail-Adresse, Telefonnummer und zugängliche Lebenslaufinformationen enthalten. Die verschlüsselte Speicherung von E-Mail-Adresse und Telefonnummer bedeutet nicht, dass diese Felder nie als Klartext in einem zulässigen Werkzeugergebnis erscheinen. Prüfen Sie das konkrete Werkzeug und die Aufgabe, bevor Sie davon ausgehen, dass Kontaktdaten ausgeschlossen wurden.

Kits Dokumentation zu KI-Anbietern beschreibt außerdem getrennte Verarbeitungswege. Der bevorzugte Anbieter übernimmt den Großteil der internen Chats und Textgenerierung. Semantische Indexierung und Suche verwenden Googles Embedding-Dienst über Kits Plattformschlüssel, unabhängig von dieser Einstellung. Hiring Live Review nutzt den eigenen Gemini-Schlüssel des Kontos; für die Hintergrundanreicherung der Gehaltsrecherche gibt es einen weiteren festgelegten Gemini-Verarbeitungsweg. Ausgabenlimits für Kontoschlüssel stoppen nicht sämtliche dieser getrennten Abläufe.

Ein externer Assistent, der über MCP angebunden ist, bringt eine eigene Verarbeitungsgrenze mit. Seine Berechtigung, Informationen aus Kit anzufordern, und sein Umgang mit den zurückgegebenen Informationen müssen gesondert geprüft werden. Eine Änderung des bevorzugten Anbieters in Kit konfiguriert diesen externen Assistenten nicht.

Beginnen Sie mit einer einzelnen Recruiting-Aufgabe. Klären Sie, wer die Datensätze abrufen darf, prüfen Sie die Felder, die die Anwendung verlassen, und untersuchen Sie den tatsächlichen Verarbeitungsweg sowie gespeicherte Ausgaben. Testen Sie anschließend die Zugriffsgrenzen, die Sie selbst absichern können, und klären Sie die Anbieterfragen mit den zuständigen Personen. Wenn Sie Kit prüfen, führen Sie diese Prüfung anhand der dokumentierten Verarbeitungswege und eines synthetischen Kandidaten durch, bevor Sie sensible Bewerbungsinformationen ergänzen.