Prévention des fuites de données (DLP)

La couche DLP est une porte de workflow configurable. Elle s'exécute chaque fois qu'un workflow souhaite valider le contenu en entrée ou en sortie par rapport à une politique définie — détection et masquage des données personnelles, scoring d'hallucination, validation JSON ou correspondance regex.

Cette page documente le bloc Guardrails et les quatre types de validation qu'il prend en charge.

Quand l'utiliser

Emplacements typiques :

• Porte d'entrée — analyser un message utilisateur à la recherche de données personnelles avant qu'il n'atteigne un LLM.
• Porte de sortie — analyser une réponse LLM à la recherche de données personnelles avant de la renvoyer à l'utilisateur.
• Porte d'hallucination — scorer une réponse par rapport à une base de connaissances avant de l'exposer.
• Porte de format — vérifier qu'un LLM a produit du JSON valide / correspond à une regex avant de le transmettre en aval.

Le bloc Guardrails fait partie du produit scrydon:guardrails — voir Vendeurs → Scrydon.

Quatre types de validation

La détection des données personnelles se décline en trois variantes — choisies par bloc :

Détection des données personnelles

Le détecteur de données personnelles reconnaît plus de 30 types d'entités dans plus de 10 régions.

Entités prises en charge

Deux modes d'action

Exemple — détection par regex

Entrée : Contact john@acme.com, SSN 123-45-6789, card 4111111111111111

Sortie :

[
  { type: "EMAIL_ADDRESS", text: "john@acme.com",    start: 8,  end: 21, score: 0.95 },
  { type: "US_SSN",        text: "123-45-6789",      start: 27, end: 38, score: 0.90 },
  { type: "CREDIT_CARD",   text: "4111111111111111", start: 45, end: 61, score: 0.95 },
]

Exemple — sortie en mode masquage

"Contact <EMAIL_ADDRESS>, SSN <US_SSN>, card <CREDIT_CARD>"

Exemple — sortie en mode blocage

{
  "passed": false,
  "error": "PII detected: EMAIL_ADDRESS, US_SSN, CREDIT_CARD",
  "detectedEntities": [
    { "type": "EMAIL_ADDRESS", "text": "john@acme.com", "start": 8, "end": 21, "score": 0.95 }
  ]
}

Mode hybride

Le mode hybride exécute les deux moteurs en parallèle et déduplique les détections qui se chevauchent en privilégiant les correspondances les plus fiables :

Détection des hallucinations

Valide une sortie LLM par rapport à une base de connaissances en utilisant RAG et le scoring LLM :

Échelle de confiance :

Exemple de sortie

{
  "passed": false,
  "score": 2,
  "reasoning": "The claim about Q4 revenue is not mentioned in any knowledge base document",
  "error": "Low confidence: score 2/10 is below threshold 3"
}

Configuration

Le bloc Guardrails expose ces champs dans l'éditeur de workflow :

Association avec le bloc Evaluator

Le bloc Guardrails est fail-closed (fermé en cas d'échec) — en cas d'échec, le workflow suit la branche d'échec. Le bloc Evaluator est scoring — il renvoie un score sur lequel le workflow peut brancher comme il le souhaite. Utilisez Guardrails pour des portes strictes, Evaluator pour des vérifications de qualité qui pilotent des tentatives de reprise ou des chemins de secours.

Comment nous mesurons le moteur DLP de la plateforme

Au-delà du bloc Guardrails, Scrydon exécute un moteur DLP de niveau plateforme sur chaque appel de capacité (complétions LLM, transcription, OCR, …) — en analysant les entités de données personnelles et les violations d'égress selon la classification (contenu classifié sortant vers une destination moins habilitée). Les affirmations sur la qualité de détection sont faciles à formuler et difficiles à vérifier, c'est pourquoi nous mesurons ce moteur de la même manière que nous mesurons la qualité de la récupération : sur un benchmark public tiers, avec le harnais en CI comme porte de publication — une version qui régresserait en dessous des seuils ne sera pas livrée.

Mesurée sur une tranche anglophone de 2 661 prompts de ai4privacy/pii-masking-300k (révision de dataset épinglée, évaluée au moment du build — le dataset lui-même n'est jamais redistribué) plus une banque d'escalade de classification interne :

Par type d'entité gradué : email 99,6 %, adresse IP 99,5 %, numéro de téléphone 86,1 % de rappel.

Ce que nous ne prétendons pas. Le rapport comporte une section obligatoire hors périmètre listant les catégories de détection que le moteur ne couvre pas, avec des preuves mesurées plutôt que le silence : noms de personnes en texte libre (domaine NER — l'heuristique regex mesurée à 14 % de rappel, nous ne le notons donc pas), formats libres de date de naissance (3 % — le moteur revendique ISO 8601 uniquement), et identifiants nationaux génériques (27 % — le moteur revendique des formats juridictionnels spécifiques tels que US_SSN ou BE_NRN, pas des suites de chiffres arbitraires). Chacun est documenté dans l'artefact de rapport signé afin que les auditeurs voient le périmètre, et non un chiffre marketing.

Voir aussi

• Architecture → Cortex — où Cortex peut appliquer des garde-fous sur chaque appel LLM en tant que couche indépendante du workflow.
• Habilitation de la base de connaissances — l'habilitation est un axe distinct de la DLP, et non un remplacement.
• Conformité — comment la DLP se mappe aux contrôles des référentiels (RGPD, EU AI Act, ISO 42001).