Protection des données

Les modes de détection, la bibliothèque de 60 détecteurs, la détection d'entités et ses modèles au choix, l'analyse de sécurité, 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 cinq 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, un dictionnaire de noms embarqué, et NER : un modèle de reconnaissance exploité par Sluis comme sidecar interne au réseau, si bien que le texte ne quitte jamais le périmètre du déploiement pour être analysé. NER repère personnes, organisations et lieux en prose libre.

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

Deux niveaux arbitrent entre latence et taux de détection : swift (spaCy xx_ent_wiki_sm) répond en quelques millisecondes avec une couverture multilingue basique ; deep (GLiNER2-PII sur socle mDeBERTa-v3, Apache-2.0) détecte nettement plus, avec une latence plus élevée par segment analysé. Choisissez par organisation dans Politiques → Protection des données ; une clé peut choisir un autre modèle via ses option overrides, mais ne peut jamais activer la couche quand l'organisation la garde désactivée.

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. log consigne les détections dans le journal d'audit sans toucher au trafic ; block refuse la requête avec un 403 permission_error scellé ("request refused: prompt-injection scan flagged this request"). Le seuil de déclenchement se configure par organisation, et l'analyse échoue en mode ouvert : une panne du scanner n'interrompt jamais le trafic.

L'analyse ajoute environ 20 ms sur un prompt court et environ 620 ms sur un prompt long (1500 caractères), mesuré sur un banc d'essai interne ; le pire cas est borné, car l'analyseur limite le nombre de fenêtres de 512 tokens évaluées par requête. Elle s'exécute en parallèle du scan NER : la latence ajoutée combinée est proche du plus grand des deux, pas de leur somme. La détection est un classifieur, pas une preuve : un texte bénin à l'allure d'instruction peut être noté comme injection, une réalité connue dans tout le domaine, raison pour laquelle log est le mode de départ recommandé.

Chaque détection est divulguée dans le journal d'audit sous sec:injection:<score>, la revue ne demande donc aucun outillage supplémentaire. Les dérogations par clé passent par les mêmes option overrides que la protection des données.

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

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 l'onglet 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. 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.

Option overrides par clé

Les dérogations par en-tête de requête ont disparu : les écarts sont une configuration de clé permanente et gouvernée. Un owner ou admin définit des option_overrides épars sur une clé, dans la vue API keys de la Console ou via POST/PUT /admin/keys : le mode de protection des données (y compris off), le modèle NER et le mode d'analyse d'injection. Tout ce qui n'est pas défini hérite de la politique de l'organisation, et une clé ne peut jamais activer une couche que l'organisation garde désactivée.

# 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

L'en-tête de requête x-sluis-dlp a été supprimé. Une requête qui le porte encore, quelle qu'en soit la valeur, est refusée avec 400 et un renvoi vers les option overrides de la clé. Chaque dérogation en vigueur est divulguée sur la ligne d'audit scellée : le journal montre toujours quelle configuration a réellement été appliquée.