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 des données personnelles gérée par l'organisation, 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

Détection des données personnelles

L'opération PII Guardrails gouvernée utilise l'ensemble de règles maintenu par les administrateurs de l'organisation dans Paramètres → Gouvernance → DLP. Un workflow ne peut pas choisir une autre liste d'entités, une autre méthode de détection ni une autre action d'application. L'analyse des capacités et la validation des workflows partagent ainsi une seule politique.

Lorsqu'une règle correspond, la validation Guardrails échoue et le workflow suit sa branche d'échec. Le résultat contient les métadonnées de la règle et les positions de caractères nécessaires au routage et au diagnostic, mais jamais le texte brut correspondant :

{
  "passed": false,
  "evaluated": true,
  "validationType": "pii",
  "policyMode": "enforce",
  "findings": [
    {
      "ruleId": "email-address",
      "entityType": "EMAIL",
      "detector": "builtin",
      "confidence": "HIGH",
      "channel": "tool_call",
      "start": 8,
      "end": 21
    }
  ]
}

La politique doit être disponible, activée et inclure le canal tool_call. L'exécution directe en dehors de l'hôte gouverné de Scrydon est refusée, car elle ne peut pas charger la politique d'organisation de confiance.

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 :

Le choix des règles PII, la configuration des détecteurs et le mode de la politique sont des paramètres de l'organisation, et non des entrées du bloc Guardrails.

L'intégration Guardrails sous-jacente expose également l'outil de vérification des hallucinations avec des paramètres de modèle et de base de connaissances. Il ne figure pas actuellement dans la liste déroulante des types de validation du bloc 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 applique la politique DLP de l'organisation aux appels de capacité couverts, notamment les complétions LLM, la transcription et les embeddings. L'exécution gouvernée des outils applique séparément la classification de confiance des destinations et bloque les violations de non-écriture vers un niveau inférieur lorsque le mode de classification est Enforce. Les affirmations sur la qualité de détection sont faciles à formuler et difficiles à vérifier, c'est pourquoi nous mesurons le moteur partagé 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.

Politique DLP de l'organisation et appels LLM bloqués

L'opération Guardrails des workflows et les appels LLM de la plateforme utilisent la même politique DLP de l'organisation (Paramètres → Gouvernance → DLP). Lorsque cette politique est en mode Enforce et que l'analyse d'une entrée LLM produit une détection — correspondance d'un motif PII/secret ou classification d'injection de prompt — l'appel est bloqué avant d'atteindre le fournisseur de modèle :

HTTP 422 Unprocessable Entity

{
  "error": "llm_blocked_by_dlp",
  "detail": "Your input contained content that could not be processed.",
  "dlpReason": "input_blocked"
}

• detail est le message d'entrée bloquée configuré par l'administrateur dans l'éditeur de politique DLP.
• dlpReason distingue un blocage d'entrée (input_blocked) d'un refus fail-closed du classificateur ou du chargement de politique (classifier_unavailable, policy_not_loaded).
• Les étapes d'agent de workflow échouent avec Blocked by DLP policy: <message> ; les appels SDK et API reçoivent le refus de politique typé sur les opérations Base Platform unaires et streaming.
• Un 422 signifie que le blocage est déterministe — réessayer la même entrée re-bloque. Examinez la règle concernée dans Paramètres → Gouvernance → DLP → Hits ou ajustez le mode de la politique.

Le classificateur sémantique d'injection de prompt est activé lorsqu'une organisation ne s'en est pas explicitement désinscrite. Dans Paramètres avancés, les administrateurs peuvent également configurer la politique pré-action canonique : une liste d'autorisation ou de refus des destinations externes et des rangs maximaux de classification des données par catégorie d'outil.

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).