Datenschutz

Erkennungsmodi, die Bibliothek mit 60 Detektoren, Entitätserkennung samt wählbarer Modelle, Security-Scanning, 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 fünf 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, ein mitgeliefertes Namenswörterbuch und NER: ein Erkennungsmodell, das Sluis als netzwerkinternen Sidecar betreibt, sodass Text zum Scannen niemals den Perimeter des Deployments verlässt. NER findet Personen, Organisationen und Orte im Fließtext.

Das Namenswörterbuch ist das deterministische Gegenstück zu NER: Vor- und Nachnamen, aus offenen Behördendaten zu einem Wörterbuch kompiliert, das im Gateway mitgeliefert wird. Es erkennt vollständige Namen und Namen nach einer Anrede, ohne zusätzliche Latenz und ohne dass etwas Ihren Perimeter verlässt. Namen, die zugleich gewöhnliche Wörter sind, werden nur mit namensartigem Kontext erkannt; seltene Namen bleiben Sache des Verzeichnisses oder des NER.

NER-Modelloptionen

Zwei Stufen wägen Latenz gegen Trefferquote ab: swift (spaCy xx_ent_wiki_sm) antwortet in einstelligen Millisekunden mit mehrsprachiger Basisabdeckung; deep (GLiNER2-PII auf mDeBERTa-v3-Basis, Apache-2.0) erkennt deutlich mehr, bei höherer Latenz pro gescanntem Segment. Wählen Sie pro Organisation unter Richtlinien → Datenschutz; ein Key kann über seine Option-Overrides ein anderes Modell wählen, die Ebene aber nie einschalten, wenn die Organisation sie ausgeschaltet lässt.

Gemessen am 2026-08-12 in einem internen Benchmark: WikiANN-Testsätze in sechs Sprachen (NL, EN, DE, FR, ES, IT; 150 pro Sprache), bewertet als Mikro-F1 über (Label, Text)-Paare auf Textebene mit angewandtem Produktions-Fehlalarmfilter, auf einer Apple-Silicon-Entwicklungsmaschine in FP32. WikiANN ist automatisch annotiertes Wikipedia-Material und spaCys Heimterrain: Lesen Sie die Zahlen als relative Orientierung zwischen den Stufen, nicht als absolute Feldgenauigkeit.

Security-Scanning

Optionale Prompt-Injection- und Jailbreak-Erkennung an der Schleuse, gescannt vor dem Versand. Drei Modi: off | log | block. log hält Treffer im Audit-Protokoll fest, ohne den Traffic zu berühren; block weist die Anfrage mit einem versiegelten 403 permission_error ab ("request refused: prompt-injection scan flagged this request"). Der Auslöse-Schwellwert ist pro Organisation konfigurierbar, und der Scan fällt offen aus: ein Scanner-Ausfall legt niemals den Traffic lahm.

Der Scan kostet bei einem kurzen Prompt etwa 20 ms und bei einem langen (1500 Zeichen) etwa 620 ms, gemessen in einem internen Benchmark; der schlimmste Fall ist begrenzt, weil der Scanner die Zahl der bewerteten 512-Token-Fenster pro Anfrage deckelt. Er läuft parallel zum NER-Scan, die kombinierte Zusatzlatenz liegt also nahe am größeren der beiden Werte, nicht an ihrer Summe. Die Erkennung ist ein Klassifizierer, kein Beweis: harmloser, anweisungsartiger Text kann als Injection eingestuft werden, eine branchenweit bekannte Realität, weshalb log der empfohlene Startmodus ist.

Jeder Treffer wird im Audit-Protokoll als sec:injection:<score> offengelegt, die Durchsicht braucht also kein zusätzliches Werkzeug. Abweichungen pro Key laufen über dieselben Option-Overrides wie der Datenschutz.

Built with Llama. The scan model is Llama Prompt Guard 2 86M (multilingual), used under the Llama 4 Community License.

Getrennt davon läuft die optionale Anomalie-Erkennung des Key-Verhaltens als Hintergrund-Job ohne jede Request-Latenz: Baselines pro Key aus robusten Statistiken mit Wochenstunden-Saisonalität, plus eine multivariate Isolation-Forest-Ebene. Alerts sind erklärbar, nie ein nackter Score, und erscheinen im Security-Tab der Console, auf Wunsch per E-Mail.

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.

Option-Overrides pro Key

Overrides per Request-Header sind Geschichte: Abweichungen sind stehende, gouvernierte Key-Konfiguration. Ein Owner oder Admin setzt spärliche option_overrides auf einem Key, in der API-keys-Ansicht der Console oder via POST/PUT /admin/keys: den Datenschutzmodus (einschließlich off), das NER-Modell und den Injection-Scan-Modus. Alles Ungesetzte erbt die Organisations-Policy, und ein Key kann nie eine Ebene einschalten, die die Organisation ausgeschaltet lässt.

# per-key option overrides are standing key config, set by an owner or admin
curl -X PUT https://api.sluis.ai/admin/keys/{key_id} \
  -H "Authorization: Bearer $SLUIS_ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "option_overrides": {
        "dlp": { "mode": "off" },
        "ner_model": "deep",
        "security": { "prompt_injection": { "mode": "block" } } } }'
# sparse: absent fields inherit org policy; every deviation is sealed in the audit trail

Der Request-Header x-sluis-dlp wurde entfernt. Eine Anfrage, die ihn noch trägt, gleich mit welchem Wert, wird mit 400 abgewiesen samt Verweis auf die Option-Overrides des Keys. Jede wirksame Abweichung wird auf der versiegelten Audit-Zeile offengelegt, das Protokoll zeigt also immer, welche Konfiguration tatsächlich lief.