Protection des données

Modes de détection, bibliothèque de 60 détecteurs, détection d’entités et modèles au choix, analyse de sécurité, avis au modèle et rétention.

La protection des données s'exécute sur chaque requête avant l'envoi. Le mode par défaut est tokenize : chaque valeur détectée est remplacée par un token typé stable comme «EMAIL_1». Les valeurs détectées n’atteignent le fournisseur que sous forme de tokens, et la réponse est restaurée avec les valeurs réelles sur le chemin du retour, en streaming ou non. La correspondance des tokens vit en mémoire le temps de la requête et n'est jamais persistée. La pseudonymisation est à sens unique : elle protège ce que vous envoyez. Dans Sluis Workspace, les résultats publics de recherche web et la sortie du modèle produite plus tôt dans le même tour ne sont pas tokenisés à nouveau ; une valeur déjà tokenisée dans la conversation reste remplacée par son token, et le journal d’audit indique quand cette règle s’est appliquée.

# 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…"
    }
  }]
}

Autres modes : mask réécrit irréversiblement les valeurs détectées, block refuse la requête avec 422, et allow_log la laisse passer tout en signalant la ligne d'audit.

60 détecteurs intégrés sont fournis d'emblée : 28 pour les données personnelles, du numéro de sécurité sociale américain à un pack d'identifiants nationaux validés par somme de contrôle dans 12 pays de l'UE, et 32 pour les secrets et identifiants. Chacun est activable par organisation, et des termes personnalisés (texte brut ou regex) couvrent tout ce qui est propre à votre activité :

Détection d'entités

Les personnes, organisations et lieux sont difficiles à repérer par motifs seuls. Sluis combine heuristiques de contexte, corrélation d’e-mails, annuaire du locataire, dictionnaires embarqués et NER optionnel. Le modèle NER fonctionne comme sidecar interne au réseau : le texte reste dans le périmètre du déploiement. Ces couches analysent aussi le texte extrait des documents et par OCR lorsque la protection des documents est activée. Avec le NER actif, une requête peut nommer jusqu’à 100 000 entités distinctes ; au-delà de ce plafond, l’analyse est considérée comme incomplète. Un nom que le modèle détecte une fois est remplacé partout où il réapparaît dans la requête, comme le même mot entier avec la même casse et le même token, y compris dans les messages où le modèle ne l’a pas signalé. Les mots génériques isolés et les sigles courts ne couvrent que l’occurrence signalée par le modèle.

Le dictionnaire de noms est le pendant déterministe du NER : des prénoms et noms de famille compilés à partir de données ouvertes gouvernementales en un dictionnaire livré dans la passerelle. Il capte les noms complets et les noms précédés d'un titre de civilité, sans latence ajoutée et sans que rien ne quitte votre périmètre. Les noms qui sont aussi des mots courants ne sont captés que dans un contexte de forme nominale ; les noms rares restent l'affaire de l'annuaire ou du NER.

Modèles NER au choix

Choisissez Base, Étendu ou Approfondi dans Protection des données. Base utilise les détecteurs intégrés et six couches déterministes de noms, sans appel de modèle ; c’est le profil par défaut des nouvelles organisations. Étendu ajoute Swift (spaCy) ; Approfondi ajoute GLiNER2-PII à la place. Les deux profils IA exigent une inspection complète et bloquent les échecs ou analyses incomplètes. Approfondi demande davantage de calcul, sans garantir un meilleur rappel. Personnalisé permet les réglages individuels. Politiques existantes, exclusions, annuaires et dérogations des workloads restent inchangés ; les mots inconnus restent désactivés dans les trois profils. Un workload ne peut pas activer NER si l’organisation le désactive. La reconnaissance des noms par IA est facturée une fois par requête client inspectée : 0,005 € avec Swift (Étendu), 0,01 € avec GLiNER2 (Approfondi) ; Base est inclus. Les appels de suivi que Sluis effectue dans cette requête ne sont pas refacturés, et une inspection incomplète ne coûte rien. Chaque facturation est un reçu d’audit lié qui compte dans vos budgets.

Approfondi ajoute une latence importante avant que le modèle choisi commence à générer une réponse. Le temps d’analyse de Swift et GLiNER2 dépend de la longueur du texte, du nombre de messages et du matériel. Le délai couvre toute l’analyse NER des messages, pièces jointes et fenêtres d’une requête, pas chaque fenêtre : 30 secondes jusqu’à 320 000 caractères, plus 30 secondes par tranche supplémentaire de 320 000 caractères, 10 minutes au maximum. C’est un maximum, pas une latence habituelle. L’inspection LLM hébergée facultative ajoute une attente distincte avant la génération de réponse, selon le texte, la charge du fournisseur et les nouvelles tentatives ; elle est hors de ce délai NER.

Mesuré le 2026-08-12 sur un benchmark interne : phrases de test WikiANN en six langues (NL, EN, DE, FR, ES, IT ; 150 par langue), notées en micro-F1 sur paires (label, texte) au niveau du texte avec le filtre anti-faux-positifs de production appliqué, sur une machine de développement Apple Silicon en FP32. WikiANN est un corpus Wikipédia à annotation automatique et le terrain d'entraînement de spaCy : lisez ces chiffres comme un repère relatif entre les niveaux, pas comme une précision absolue sur le terrain.

Analyse de sécurité

Détection optionnelle d'injections de prompt et de jailbreaks à l'écluse, analysée avant l'envoi. Trois modes : off | log | block. off désactive l’analyse. log consigne les détections sans bloquer le trafic. block refuse les attaques détectées et bloque si Prompt Guard est indisponible ou la classification échoue ou reste incomplète. Aucun repli automatique vers un autre modèle.

La sécurité utilise toujours Llama Prompt Guard 2 86M (sluis/prompt-guard-2-86m), dans Sluis sans transfert externe du texte. 0,01 EUR par analyse logique terminée, une seule fois quels que soient les fenêtres et le verdict, y compris les extraits sûrs ; aucun supplément au token. Désactivé, refus préalables et erreurs techniques ne sont pas facturés. Les fenêtres chevauchantes de 512 tokens du modèle au maximum préservent les segments, dans le budget total configuré de 4096 à 65536 tokens. Le seuil fixe de détection est de 0,8. L’analyse suit la protection des données, qui peut conserver des données personnelles si elle est désactivée ou limitée au journal. Les analyses ajoutent de la latence et ont un délai maximal. Les entrées longues utilisent des extraits ; un verdict sûr couvre seulement le texte inspecté. Audit indique les octets inspectés et totaux. Built with Llama. Meta Llama 3.1 Community License.

Chaque analyse a une entrée d’audit facturable distincte et liée : security.scan. Des frais peuvent s’appliquer même si la requête initiale est bloquée ou servie depuis le cache. Les dérogations par workload peuvent changer le mode d’analyse. Séparément, l’inspection de confidentialité Nemotron optionnelle utilise Nebul selon votre politique de résidence et est facturée au token.

Séparément, la détection optionnelle d'anomalies de comportement par clé tourne en tâche de fond, sans aucune latence sur les requêtes : des lignes de base par clé issues de statistiques robustes avec saisonnalité heure-de-semaine, plus une couche multivariée à forêt d'isolation. Les alertes sont explicables, jamais un score brut, et arrivent dans la vue Sécurité de la Console, avec e-mail en option.

Notice au modèle

Lorsque la tokenisation a réécrit une requête, Sluis injecte en tête un message système indiquant au modèle que les tokens «…» sont des espaces réservés opaques qu'il doit conserver intacts ; c'est ce qui garantit la fiabilité de la restauration. Activé par défaut ; personnalisez-le ou désactivez-le par organisation.

Rétention et fidélité de l'audit

La rétention du contenu (corps des requêtes et des réponses pour le journal d'audit) est activée par défaut et chiffrée au repos ; la fidélité de l'audit détermine si le contenu conservé stocke les tokens ou les valeurs d'origine. Le contenu conservé est gardé jusqu'à ce que vous l'effaciez, sauf si vous fixez une durée de conservation en jours dans la vue Protection des données de la Console. Une purge quotidienne applique la durée en vigueur au contenu déjà stocké : la raccourcir supprime donc aussi le contenu plus ancien. Le contenu des conversations Sluis Workspace est supprimé après la plus courte de cette durée et de la durée Workspace pour les valeurs personnelles des conversations (7 jours par défaut). Le registre des métadonnées d'audit est conservé et jamais modifié. Désactivez la rétention pour un registre limité aux métadonnées ; cela désactive aussi le cache de réponse.

Anonymisation de documents

Envoyez un fichier docx, pdf, image ou texte à POST /v1/documents/anonymize et le même document revient avec les PII et secrets remplacés par des balises comme «PERSON_NAME_1» dans le texte, et floutés dans les images et pages PDF. Le traitement reste local à la gateway, OCR compris; l'opération est scellée dans la chaîne d'audit et facturée par page/image. La table de correspondance des jetons n'est renvoyée que si vous la demandez et n'est jamais stockée. Les PDF caviardés conservent une couche de texte invisible et cherchable construite à partir du texte anonymisé. Pour les gros documents, déposez un job asynchrone et récupérez le résultat plus tard via une URL signée à durée limitée. Sur les scans, les lignes que l’OCR ne peut pas lire de façon fiable, comme les signatures et l’écriture manuscrite illisible, et l’encre hors de toute ligne de texte reconnue, comme les paraphes et les tampons, sont détruites plutôt que devinées. Elles apparaissent comme «UNREADABLE» dans la couche de texte, et la réponse signale la catégorie UNREADABLE_REDACTED.

La même protection s'applique en transit: avec la politique dlp_documents active, les fichiers envoyés via /v1/files et les documents OCR inline sont anonymisés avant de partir vers un fournisseur, refusés en mode block et analysés en mode allow_log.

# 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

Les jetons pseudonymisés sont stables au sein d'une requête, pas entre requêtes ; les embeddings de texte tokenisé peuvent donc différer entre appels. Le paramètre dlp_embeddings contrôle si l'analyse couvre /v1/embeddings : activé par défaut, le passer à off envoie les entrées d'embedding au fournisseur sans analyse. Chaque appel exempté est consigné dans le journal d'audit.

Termes à retirer par requête

Toute requête JSON du plan de données — chat completions, completions, embeddings, responses, ainsi que les ingresses natifs Anthropic — peut porter une extension sluis de premier niveau. Sa liste remove nomme les termes que la gateway doit retirer du prompt avant l'envoi : une simple chaîne, ou un objet avec un text et un kind parmi person | organization | location | term. Au maximum 128 entrées, chacune non vide après trim et d'au plus 256 caractères ; la correspondance se fait aux limites de mots, sans distinction de casse. L'extension elle-même est une construction de la gateway et est toujours retirée avant l'envoi : elle n'atteint jamais un fournisseur, le cache, ni le contenu conservé.

# name the terms the gateway must remove — the top-level "sluis" object never leaves the gateway
curl https://api.sluis.ai/v1/chat/completions \
  -H "Authorization: Bearer $SLUIS_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "model": "mistral/mistral-large-latest",
        "messages": [{ "role": "user",
          "content": "Bas Alderding did a good job, send an email explaining how happy you are with that" }],
        "sluis": { "remove": [{ "text": "Bas Alderding", "kind": "person" }, "Project Nightingale"] } }'

# provider receives  → "«PERSON_NAME_1» did a good job, send an email explaining how happy you are with that"
# you receive back   → "Dear Bas Alderding, I am delighted with your work on Project Nightingale…"
# audit note         → dlp:tokenize:person_name(request)|dlp:tokenize:term(request)

# the OpenAI SDKs forward the gateway extension through extra_body
resp = client.chat.completions.create(
    model="mistral/mistral-large-latest",
    messages=[{"role": "user", "content": "Bas Alderding did a good job…"}],
    extra_body={"sluis": {"remove": [{"text": "Bas Alderding", "kind": "person"}]}},
)
# the originals are restored on the way out — the provider only ever saw «PERSON_NAME_1»
print(resp.choices[0].message.content)

Chaque correspondance devient un jeton réversible — «PERSON_NAME_1» — qui rejoint la passe de pseudonymisation normale : en mode tokenize, le mode par défaut, les valeurs d'origine sont restaurées dans la réponse, streaming compris ; en mode mask le terme est remplacé par [REDACTED:<kind>] ; en mode block la requête est refusée avec 422. L'instruction est toujours honorée, même si la clé pose dlp: off, si l'organisation tourne en allow_log ou si /v1/embeddings est exempté : elle ne peut que renforcer la protection, jamais l'affaiblir, et c'est pourquoi elle est admise par requête là où l'en-tête retiré x-sluis-dlp ne l'était pas. Le terme listé n'atteint jamais le fournisseur.

Une directive malformée n'est jamais ignorée en silence : un kind inconnu, une entrée hors limites ou un champ inconnu dans l'extension sont refusés avec 422. Ce qui a réellement été appliqué est divulgué sur la ligne d'audit scellée, où les termes fournis par l'appelant portent la couche request — dlp:tokenize:person_name(request) — distincte des couches (ner) et (directory), de sorte que le journal montre l'origine de chaque retrait. La même liste est acceptée comme option remove sur /v1/documents/anonymize et ses jobs asynchrones.

Dérogations du workload

Les dérogations appartiennent au workload et concernent tous ses identifiants. Un owner ou admin configure option_overrides dans Console → Workloads ou avec POST /admin/workloads à la création. Les options absentes héritent de la politique de l'organisation. Pour modifier un workload, PATCH /admin/workloads/{workload_id} exige tous ses paramètres modifiables, dont nom, statut, limites et budget ; il les remplace sans fusionner les champs.

# create a workload with governed overrides; keys inherit its settings
curl -X POST https://api.sluis.ai/admin/workloads \
  -H "Authorization: Bearer $SLUIS_ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "name": "document-review", "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

L'en-tête de requête x-sluis-dlp a été supprimé. Les requêtes qui le portent reçoivent 400 ; configurez le workload. Les dérogations effectives sont consignées dans la piste d’audit scellée.