Datenschutz

Erkennungsmodi, die Bibliothek mit 60 Detektoren, Namenserkennung, der Modellhinweis und Aufbewahrung.

Der Datenschutz läuft bei jeder Anfrage vor dem Versand. Der Standardmodus ist tokenize: jeder erkannte Wert wird durch ein stabiles typisiertes Token wie «EMAIL_1». Nur die Tokens erreichen den Anbieter, und die Antwort wird auf dem Rückweg zu Ihnen wieder auf die echten Werte zurückgesetzt, gestreamt oder nicht. Die Token-Zuordnung lebt für die Dauer der Anfrage im Speicher und wird niemals persistiert.

# tokenize mode (the default): what you send
curl https://api.sluis.ai/v1/chat/completions \
  -H "Authorization: Bearer $SLUIS_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "model": "sluis/auto", "messages": [{ "role": "user",
        "content": "Mail j.devries@acme.nl that IBAN NL91ABNA0417164300 is active." }] }'

# what the model provider receives — only stable typed tokens
{ "role": "user",
  "content": "Mail «EMAIL_1» that IBAN «IBAN_1» is active." }

# what you get back — restored at the single client egress, streaming included
{
  "choices": [{
    "message": {
      "role": "assistant",
      "content": "Draft: Dear j.devries@acme.nl, your account NL91ABNA0417164300 is active…"
    }
  }]
}

Weitere Modi: mask schreibt erkannte Werte irreversibel um, block weist die Anfrage mit 422 ab, und allow_log lässt sie durch und markiert dabei die Audit-Zeile.

60 integrierte Detektoren sind von Haus aus dabei: 28 für personenbezogene Daten, von der US Social Security Number bis zum Paket nationaler IDs, das 12 EU-Länder per Prüfsumme validiert, und 32 für Secrets und Zugangsdaten. Jeder lässt sich pro Organisation schalten, und eigene Begriffe (Klartext oder Regex) decken alles ab, was für Ihr Geschäft spezifisch ist:

Entitätserkennung

Personen, Organisationen und Orte lassen sich allein per Muster schwer erfassen. Sluis fügt vier optionale Ebenen hinzu: Kontext-Heuristiken (Anreden, Grußformeln, Signaturen; nur Personen), E-Mail-Korrelation (leitet Namen aus Adressen im selben Text ab), ein mandantenspezifisches Namensverzeichnis und NER: ein mehrsprachiges Erkennungsmodell, das im Deployment mitgeliefert wird (spaCy xx_ent_wiki_sm-Gewichte, von Sluis als netzwerkinterner Sidecar betrieben), sodass Text zum Scannen niemals Ihren Perimeter verlässt. NER findet Personen, Organisationen und Orte im Fließtext.

Modell-Hinweis

Wenn die Tokenisierung eine Anfrage umgeschrieben hat, fügt Sluis eine vorangestellte System-Nachricht ein, die dem Modell mitteilt, dass die «…»-Tokens undurchsichtige Platzhalter sind, die es unversehrt lassen muss; genau das hält die Wiederherstellung zuverlässig. Standardmäßig aktiviert; pro Organisation anpassbar oder abschaltbar.

Aufbewahrung & Audit-Fidelität

Die Inhaltsaufbewahrung (Request- und Response-Bodies für das Audit-Log) ist standardmäßig aktiv und im Ruhezustand verschlüsselt; die Audit-Fidelität entscheidet, ob der aufbewahrte Inhalt die Tokens oder die Originalwerte speichert. Schalten Sie die Aufbewahrung ab für ein reines Metadaten-Register; das deaktiviert auch die Response-Caches.

Dokument-Anonymisierung

Senden Sie eine docx-, pdf-, Bild- oder Textdatei an POST /v1/documents/anonymize und dasselbe Dokument kommt zurück, mit PII und Secrets ersetzt durch Platzhalter wie «PERSON_NAME_1» im Text und unkenntlich gemacht in Bildern und PDF-Seiten. Die Verarbeitung bleibt lokal in der gateway, OCR inklusive; der Vorgang wird in der Audit-Kette versiegelt und pro Seite/Bild abgerechnet. Die Token-Zuordnung wird nur auf Anfrage zurückgegeben und nie gespeichert. Geschwärzte PDFs behalten eine unsichtbare, durchsuchbare Textebene aus dem anonymisierten Text. Für große Dokumente reihen Sie einen asynchronen Job ein und holen das Ergebnis später über eine zeitlich begrenzte signierte URL ab.

Derselbe Schutz wirkt im Transit: mit aktiver dlp_documents-Policy werden über /v1/files hochgeladene Dateien und Inline-OCR-Dokumente vor dem Versand an einen Provider anonymisiert, unter block abgelehnt und unter allow_log gescannt.

# enqueue a large document (202 + job id; Idempotency-Key honoured)
curl https://api.sluis.ai/v1/documents/anonymize/jobs \
  -H "Authorization: Bearer $SLUIS_KEY" \
  -F file=@archive.pdf

# poll until succeeded; the signed download_url then needs no API key
curl https://api.sluis.ai/v1/documents/anonymize/jobs/9c31… \
  -H "Authorization: Bearer $SLUIS_KEY"

{
  "id": "9c31…",
  "state": "succeeded",
  "filename": "archive.pdf",
  "summary": { "pages": 12, "images": 3, "categories": ["PERSON_NAME", "EMAIL"], "downgraded": false },
  "download_url": "https://api.sluis.ai/v1/documents/deliverables/9c31…?tenant=…&exp=…&sig=…"
}

Embeddings

Pseudonymisierte Token sind innerhalb einer Anfrage stabil, nicht über Anfragen hinweg; Embeddings tokenisierten Texts können daher zwischen Aufrufen abweichen. Die Einstellung dlp_embeddings steuert, ob der Scan /v1/embeddings abdeckt: standardmäßig an, mit off gehen Embedding-Eingaben ungescannt an den Provider. Jeder ausgenommene Aufruf wird im Audit-Protokoll festgehalten.

Overrides pro Schlüssel

Ein Owner oder Admin kann einen API-Schlüssel mit allow_dlp_override ausstellen. Anfragen mit diesem Schlüssel können den Datenschutzmodus der Organisation für genau diesen Aufruf über den Header x-sluis-dlp überschreiben: off, allow_log, mask, block oder tokenize.

# a key minted with allow_dlp_override may swap the mode for one call
curl https://api.sluis.ai/v1/embeddings \
  -H "Authorization: Bearer $SLUIS_KEY" \
  -H "x-sluis-dlp: off" \
  -H "Content-Type: application/json" \
  -d '{ "model": "mistral/mistral-embed", "input": "raw text, embedded verbatim" }'
# keys without the grant get 403; every override is sealed in the audit trail

Ein Schlüssel ohne diese Berechtigung erhält beim Senden des Headers einen 403, und auch diese Ablehnung wird im Audit-Protokoll versiegelt. Jeder angewandte Override wird auf der versiegelten Audit-Zeile offengelegt, das Protokoll zeigt also immer, welcher Modus tatsächlich lief.