Protection des données

Les modes de détection, la bibliothèque de 60 détecteurs, la détection des noms, l'avis au modèle et la 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». Seuls les tokens atteignent le fournisseur, 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.

# 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 motif seul. Sluis ajoute quatre couches optionnelles : heuristiques de contexte (titres de civilité, salutations, signatures ; personnes uniquement), corrélation d'e-mails (déduit les noms à partir des adresses présentes dans le même texte), un annuaire de noms du locataire, et NER : un modèle de reconnaissance multilingue livré dans le déploiement (poids spaCy xx_ent_wiki_sm, exploité par Sluis comme sidecar interne), si bien que le texte ne quitte jamais votre périmètre pour être analysé. NER repère personnes, organisations et lieux en prose libre.

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. Désactivez la rétention pour un registre limité aux métadonnées ; cela désactive aussi les caches 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.

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.

Dérogations par clé

Un owner ou admin peut créer une clé API avec allow_dlp_override. Les requêtes portant cette clé peuvent remplacer le mode de protection des données de l'organisation pour un appel via l'en-tête x-sluis-dlp : off, allow_log, mask, block ou 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

Une clé sans ce droit reçoit un 403 quand elle envoie l'en-tête, refus lui aussi scellé dans le journal d'audit. Chaque dérogation appliquée est divulguée sur la ligne d'audit scellée : le journal montre toujours quel mode a réellement été appliqué.