GLiNER - DSGVO-konforme KI durch lokale PII-Erkennung

GLiNER ist ein Open-Source NER-Modell für lokale PII-Erkennung, das vollständig auf dem eigenen Server läuft. Es erkennt Personennamen, Adressen, Kontaktdaten und Finanz-Identifikatoren und ermöglicht zwei Datenschutz-Strategien: dauerhafte Anonymisierung oder temporäre Pseudonymisierung mit Re-Personalisierung nach der KI-Verarbeitung.

Kategorie:Datenschutz-Tools

GLiNER (Generalist and Lightweight Named Entity Recognition) ist ein Open-Source-Modell zur Erkennung von Named Entities, das vollständig lokal ausgeführt wird. Es bildet die Grundlage für DSGVO-konforme KI-Anwendungen, bei denen personenbezogene Daten (PII) vor der Verarbeitung durch externe LLMs geschützt werden müssen.

Das Problem

Wenn Dokumente mit personenbezogenen Daten an LLMs wie GPT-4 oder Claude gesendet werden, verlassen diese Daten den eigenen Server. Das ist datenschutzrechtlich problematisch und kann gegen die DSGVO verstoßen. GLiNER löst dieses Problem durch lokale PII-Erkennung vor dem API-Aufruf.

Erkannte Entitäten (PII-Typen)

  • Personennamen: Vor- und Nachnamen, Titel
  • Adressen: Straße, Hausnummer, PLZ, Stadt, Land
  • Kontaktdaten: Telefon, E-Mail, Fax
  • Finanzielle Daten: IBAN, BIC, Kreditkartennummern
  • Identifikatoren: Personalausweis, Reisepass, SVN
  • Gesundheitsdaten: Versicherungsnummern, Diagnosen
  • Unternehmensdaten: Firmennamen, Handelsregisternummern
  • Digitale IDs: Benutzernamen, IP-Adressen

Zwei Strategien: Anonymisierung vs. Pseudonymisierung

Je nach Anwendungsfall setzen wir GLiNER in zwei verschiedenen Architekturen ein:

Strategie A: Dauerhafte Anonymisierung

PII wird entfernt und NICHT wiederhergestellt

Eingabe → GLiNER → PII entfernen → LLM → Anonymer Output

Geeignet für:

  • Chatbots und Kundenservice
  • Allgemeine Fragen und Recherchen
  • Dokumentenanalyse ohne personalisierte Antwort
  • Szenarien, wo der Output keine Namen enthalten muss

Beispiel:

Eingabe: "Herr Müller aus München hat eine Frage zu seiner Rechnung #12345"

An LLM: "Ein Kunde hat eine Frage zu seiner Rechnung"

LLM-Antwort: "Für Rechnungsfragen empfehle ich folgende Schritte..."

Vorteile
  • Maximale Sicherheit - PII existiert nicht mehr
  • Keine Mapping-Tabelle nötig
  • Einfache Architektur
  • Kein Risiko durch Datenlecks
Einschränkungen
  • Output kann nicht personalisiert werden
  • Nicht für Briefe/E-Mails geeignet

Strategie B: Pseudonymisierung mit Re-Personalisierung

PII wird ersetzt, verarbeitet und wiederhergestellt

Eingabe → GLiNER → Pseudonymisieren → LLM → Re-Personalisieren → Personalisierter Output

Geeignet für:

  • Automatisierte E-Mail-Generierung
  • Personalisierte Briefe und Dokumente
  • Vertragsvorlagen mit Kundendaten
  • Support-Antworten mit direkter Anrede

Beispiel:

Eingabe: "Schreibe eine Erinnerungs-E-Mail an Max Mustermann, Musterstraße 42, 80331 München. Offener Betrag: 1.250,00 EUR"

An LLM: "Schreibe eine Erinnerungs-E-Mail an [PERSON_1], [ADRESSE_1]. Offener Betrag: [BETRAG_1]"

LLM generiert: "Sehr geehrter [PERSON_1], wir möchten Sie freundlich an die offene Rechnung über [BETRAG_1] erinnern..."

Re-personalisiert: "Sehr geehrter Max Mustermann, wir möchten Sie freundlich an die offene Rechnung über 1.250,00 EUR erinnern..."

Vorteile
  • Personalisierte Outputs möglich
  • PII verlässt nie den eigenen Server
  • LLM sieht nur Platzhalter
  • Volle Automatisierung möglich
Zu beachten
  • Mapping-Tabelle muss sicher gespeichert werden
  • Etwas komplexere Architektur
  • Mapping nur für Session-Dauer halten

Technische Implementierung: Re-Personalisierung

Der Pseudonymisierungs-Workflow besteht aus drei Phasen:

Phase 1: PII-Erkennung und Pseudonymisierung

// GLiNER erkennt alle PII im Text
const erkannteEntitäten = gliner.analyze(eingabeText);

// Ergebnis:
[
  { text: "Max Mustermann", type: "PERSON", start: 32, end: 46 },
  { text: "Musterstraße 42", type: "ADDRESS", start: 48, end: 63 },
  { text: "80331 München", type: "ADDRESS", start: 65, end: 78 },
  { text: "1.250,00 EUR", type: "MONEY", start: 98, end: 110 }
]

// Pseudonymisierung: Ersetze PII durch Platzhalter
const mapping = new Map();
let pseudonymisierterText = eingabeText;

erkannteEntitäten.forEach((entity, index) => {
  const platzhalter = `[${entity.type}_${index + 1}]`;
  mapping.set(platzhalter, entity.text);
  pseudonymisierterText = pseudonymisierterText.replace(entity.text, platzhalter);
});

// Mapping (nur im RAM, nie persistiert!):
// [PERSON_1] → "Max Mustermann"
// [ADDRESS_1] → "Musterstraße 42"
// [ADDRESS_2] → "80331 München"
// [MONEY_1] → "1.250,00 EUR"
      

Phase 2: LLM-Verarbeitung

// Der pseudonymisierte Text geht an das LLM
const llmResponse = await openai.chat.completions.create({
  model: "gpt-4",
  messages: [{
    role: "system",
    content: "Du schreibst professionelle Geschäftsbriefe. Platzhalter wie [PERSON_1] werden später ersetzt - verwende sie exakt so im Text."
  }, {
    role: "user",
    content: pseudonymisierterText
  }]
});

// LLM sieht NUR:
// "Schreibe eine Erinnerungs-E-Mail an [PERSON_1], [ADDRESS_1], [ADDRESS_2].
//  Offener Betrag: [MONEY_1]"

// LLM antwortet mit Platzhaltern:
// "Sehr geehrte/r [PERSON_1], wir möchten Sie freundlich daran erinnern..."
      

Phase 3: Re-Personalisierung

// Ersetze alle Platzhalter durch die Original-PII
let finalerOutput = llmResponse.choices[0].message.content;

mapping.forEach((originalWert, platzhalter) => {
  finalerOutput = finalerOutput.replaceAll(platzhalter, originalWert);
});

// Mapping sofort löschen - nie persistieren!
mapping.clear();

// Ergebnis: Vollständig personalisierter Text
// "Sehr geehrter Max Mustermann, wir möchten Sie freundlich daran erinnern..."
      

Sicherheitsarchitektur

Kritische Sicherheitsregeln für Re-Personalisierung

  1. Mapping nur im RAM: Die Zuordnung Platzhalter → PII wird NIE in einer Datenbank oder Datei gespeichert
  2. Session-gebunden: Das Mapping existiert nur für die Dauer der Anfrage und wird danach sofort gelöscht
  3. Keine Logs: Weder Eingabe noch Mapping noch finaler Output werden geloggt
  4. Verschlüsselte Übertragung: Alle Kommunikation über HTTPS/TLS
  5. Isolierte Verarbeitung: Jede Anfrage hat ihr eigenes Mapping - keine Vermischung

Datenfluss-Diagramm

┌─────────────────────────────────────────────────────────────────────────────┐
│                        EIGENER SERVER (Sichere Zone)                         │
│  ┌──────────┐    ┌─────────┐    ┌─────────────┐    ┌──────────────────────┐ │
│  │  Nutzer  │───▶│ GLiNER  │───▶│   Mapping   │    │   Re-Personalisierung│ │
│  │ Eingabe  │    │  (NER)  │    │ (nur RAM!)  │    │                      │ │
│  └──────────┘    └────┬────┘    └──────┬──────┘    └──────────▲───────────┘ │
│                       │                │                      │             │
│                       ▼                │                      │             │
│              ┌────────────────┐        │                      │             │
│              │ Pseudonymisiert│        │                      │             │
│              │ [PERSON_1]...  │────────┼──────────────────────┘             │
│              └───────┬────────┘        │                                    │
└──────────────────────┼─────────────────┼────────────────────────────────────┘
                       │                 │
                       ▼                 │ (Mapping bleibt intern!)
        ┌──────────────────────────┐     │
        │      EXTERNE API         │     │
        │  ┌────────────────────┐  │     │
        │  │   LLM (GPT-4)      │  │     │
        │  │                    │  │     │
        │  │ Sieht NUR:         │  │     │
        │  │ "[PERSON_1] hat    │  │     │
        │  │  eine Frage..."    │  │     │
        │  └────────────────────┘  │     │
        └──────────────────────────┘     │
                       │                 │
                       │ Antwort mit     │
                       │ Platzhaltern    │
                       ▼                 │
              ┌────────────────┐         │
              │ "Sehr geehrter │─────────┘
              │  [PERSON_1]"   │  Mapping wird angewendet
              └────────────────┘
      

Wann welche Strategie?

Anwendungsfall Empfohlene Strategie Begründung
Chatbot / Kundenservice A: Anonymisierung Antworten müssen nicht personalisiert sein
Dokumentenanalyse A: Anonymisierung Zusammenfassungen brauchen keine Namen
E-Mail-Generierung B: Re-Personalisierung E-Mails müssen Empfänger direkt ansprechen
Brief-/Vertragsvorlagen B: Re-Personalisierung Dokumente benötigen echte Namen und Adressen
Interne Wissenssuche A: Anonymisierung Faktenwissen, keine Personalisierung nötig
Personalisierte Reports B: Re-Personalisierung Reports für spezifische Personen/Firmen

Warum GLiNER?

  • 100% lokal: Keine Daten verlassen den Server während der NER-Analyse
  • Open Source: Volle Transparenz und Auditierbarkeit (MIT-Lizenz)
  • Leichtgewichtig: Läuft auf CPU, kein teures GPU-Cluster nötig
  • Multilingual: Unterstützt Deutsch, Englisch und viele weitere Sprachen
  • Zero-Shot NER: Erkennt auch neue Entity-Typen ohne Retraining
  • Schnell: Verarbeitet Dokumente in Millisekunden

DSGVO-konforme KI für Ihr Unternehmen

Wir implementieren GLiNER-basierte Datenschutz-Layer für Ihre KI-Anwendungen. Ob Chat, Dokumentenverarbeitung oder automatisierte Korrespondenz - Ihre Daten bleiben geschützt.

Weitere Glossarbegriffe