Ein Mitarbeiter kopiert eine E-Mail mit sensiblen Kundendaten (Name, Adresse, E-Mail) in den KI-Chatbot, um eine Zusammenfassung zu erhalten. Diese Anfrage wird an einen Cloud-Dienst wie OpenAI oder Google gesendet. Selbst wenn das LLM die Daten nicht speichert, der Anbieter tut es möglicherweise. In den USA wurde OpenAI zwischenzeitlich sogar gerichtlich gezwungen, Anfragen 30 Tage lang zu speichern.
Der Einsatz von «LLM-as-a-Service» (LLMaaS) ist effizient und leistungsstark. Er birgt jedoch ein inhärentes Datenschutzrisiko: Sensible Unternehmensdaten verlassen das Unternehmen und werden in einer fremden Jurisdiktion (z.B. den USA) verarbeitet und potenziell gespeichert. Für Unternehmen, die mit PII (Personal Identifiable Information), Finanzdaten oder Gesundheitsdaten arbeiten, ist dies ein kritisches Compliance-Risiko. Sie müssen technisch sicherstellen, dass solche Daten niemals an den externen Anbieter gesendet werden.
Das Problem: Daten verlassen unkontrolliert das Unternehmen
- Speicherung durch Anbieter: Auch wenn die LLMs selbst «stateless» sind, speichern viele Anbieter die Anfragen (Prompts und Antworten) für einen gewissen Zeitraum (z.B. 30 Tage) zu Abrechnungs-, Missbrauchs- oder (wie im Fall OpenAI) rechtlichen Zwecken.
- Daten-Souveränität: Daten werden ausserhalb Ihrer Kontrolle (z.B. ausserhalb der EU oder der Schweiz) gespeichert, was gegen Datenschutzgesetze (DSGVO, revDSG) verstossen kann.
- Unwissenheit der Nutzer: Mitarbeiter sind sich oft nicht bewusst, dass die Daten, die sie in den Chat eingeben, das Unternehmen verlassen..
Exklusiv für CEOs und GL: Sichern Sie Ihre Compliance und minimieren Sie KI-Risiken
Compliance-Falle KI? Als CEO oder GL-Mitglied tragen Sie die Verantwortung. Dieser exklusive Kurs deckt Compliance-Anforderungen im Umgang mit KI auf.
Die Lösung: PII-Schutz als Guardrail auf dem Gateway
Hier kommt eine letzte, entscheidende Funktion des LLM-Gateways (siehe Teil 2 und Teil 3) ins Spiel: der Datenschutz-Filter.
Der Gateway fungiert als «letztes Bollwerk» oder «Security Guard» direkt vor dem Ausgang zum Internet. Bevor eine Anfrage an das externe LLM (z.B. OpenAI) gesendet wird, durchläuft sie eine automatisierte PII-Prüfung. Diese Prüfung hat zwei mögliche Aktionen zur Folge:
- BLOCK (Blockieren): Die rigoroseste Methode. Der Gateway erkennt, dass die Anfrage eine IBAN-Nummer oder eine Sozialversicherungsnummer enthält, und blockiert die Anfrage komplett. Der Nutzer erhält eine Fehlermeldung: «Anfrage enthält sensible Daten und wurde nicht gesendet.»
- MASK (Maskieren / Anonymisieren): Die flexiblere Methode. Der Gateway erkennt PII und ersetzt sie durch Platzhalter, bevor sie gesendet wird.
Beispiel für PII-Maskierung:
- Nutzer-Input: «Fasse die Beschwerde von Emre Müller (emre.mueller@beispiel.ch) zusammen.»
- Gateway-Aktion (Masking): Erkennt «Emre Müller» als PERSON und die E-Mail als EMAIL.
- Anfrage an OpenAI: «Fasse die Beschwerde von <PERSON> (<EMAIL>) zusammen.»
- Antwort von OpenAI: «Die Beschwerde von <PERSON> bezüglich…»
- (Optional: De-Masking) Der Gateway könnte die Platzhalter auf dem Rückweg wieder ersetzen.
Dieser Prozess wird oft durch spezialisierte, kleinere KI-Modelle oder Dienste durchgeführt, die darauf trainiert sind, PII (Namen, E-Mail-Adressen, Telefonnummern, Kreditkartennummern etc.) in Texten zu erkennen.
Strategien und Lösungen
KI-Beratung für KMU
Von der Strategie bis zur Umsetzung: Unsere KI-Beratung unterstützt Ihr Unternehmen mit passgenauen AI-Lösungen.
Praxis-Beispiel: PII-Detection & Guardrails Frameworks
- Microsoft Presidio: Ein Open-Source-Framework, das genau auf die Erkennung und Anonymisierung von PII in Texten spezialisiert ist.
- AWS Comprehend / Google DLP API: Cloud-Dienste, die PII-Erkennung als API anbieten (wobei hier die Daten wiederum den Dienstleister erreichen, was für die PII-Prüfung aber oft unumgänglich ist, wenn man es nicht self-hosted macht).
- Guardrail-Modelle: Neuere Ansätze nutzen kleine, schnelle Modelle wie LlamaGuard (Meta) oder NeMo Guardrails (NVIDIA) direkt auf dem Gateway, um nicht nur PII, sondern auch toxische Sprache oder «Jailbreak-Versuche» zu erkennen und zu blockieren.
Mit dieser letzten Komponente schliesst sich der Kreis unseres KI-Infrastruktur-Blueprints (Teil 1). Der LLM-Gateway ist nicht nur für Strategie (Teil 2) und Kosten (Teil 3) zuständig, sondern auch das entscheidende Organ für Sicherheit und Datenschutz.
FAQ KI Datenschutz
Ist PII-Maskierung 100% sicher?
Nein, keine automatisierte Erkennung ist 100% perfekt. Es besteht immer ein Restrisiko, dass eine PII nicht erkannt wird. Die «BLOCK»-Methode ist daher bei hochsensiblen Daten (z.B. im Gesundheitswesen) oft die sicherere Wahl als «MASK».
Verlangsamt diese zusätzliche Prüfung nicht die Anfrage?
Ja, sie fügt eine minimale Latenz hinzu (Latenz-Overhead), da die Anfrage einen zusätzlichen Verarbeitungsschritt durchlaufen muss. Dieser Overhead ist bei Nutzung schneller PII-Modelle (wie Presidio) jedoch meist im Millisekunden Bereich und für den Nutzer kaum spürbar.
Was ist mit Self-Hosting? Löst das nicht alle Datenschutzprobleme?
Ja, wenn Sie ein Open-Source-Modell komplett auf Ihrer eigenen Hardware (On-Premise) betreiben, verlassen keine Daten das Unternehmen. Dies löst das PII-Problem, schafft aber neue Herausforderungen (Hardware-Kosten, Performance, Wartung). Der PII-Filter auf dem Gateway ist die pragmatische Lösung für Unternehmen, die die Leistung von Cloud-LLMs nutzen und ihre Daten schützen wollen.
DAS KÖNNTE SIE AUCH INTERESSIEREN
Verantwortungsvolle digitale Transformation: Chancen nutzen, Risiken managen
Warum die Pimcore-Enterprise-Edition für Unternehmen der Gamechanger ist
Transparenz – was passiert im Inneren des KI-Agenten?
