Tutoriel : écrire une politique de garde-fou en langage courant

Les personnes qui savent ce que l’IA d’une entreprise doit faire ou non sont rarement celles qui écrivent des règles de détection : un responsable conformité, un directeur du service client, un responsable produit. L’assistant de politiques de Guardrino est conçu pour elles. Vous décrivez une règle avec vos mots, en arabe, en anglais ou en français, et l’assistant propose des règles dans la bonne couche. Rien ne change tant que vous ne les avez pas ajoutées à un brouillon, testées et déployées.

Étape 1 : dites ce que vous voulez

Écrivez le résultat attendu, pas la technique. Par exemple :

• « Anonymise les numéros de permis de conduire. »
• « أخفِ أرقام رخص القيادة. »
• « Mask driving licence numbers. »

Étape 2 : répondez aux questions de l’assistant

Un bon assistant demande avant de deviner. Un numéro Emirates ID ou un IBAN a une structure publiée et des chiffres de contrôle : une règle peut le reconnaître avec précision. Un numéro de permis de conduire, non : les formats diffèrent selon le pays et l’émirat, et il n’existe pas de chiffre de contrôle public. L’assistant est donc conçu pour ne pas inventer de format. Il demande quelques exemples réalistes (vous pouvez en inventer qui ont la bonne forme) et propose une règle prudente qui ne se déclenche que si un mot de contexte est proche, comme « permis », « licence » ou « رخصة ».

Cette seule question fait la différence entre une règle qui protège vos clients et une règle qui masque chaque numéro de commande à huit chiffres de vos conversations de support.

Étape 3 : l’assistant choisit la couche

Étape 4 : vérifiez-la sur des exemples

Avant que vous n’ajoutiez quoi que ce soit, l’assistant applique la règle proposée aux exemples que vous avez donnés et à un ensemble de messages ordinaires :

• Doit correspondre : les numéros de permis fournis sont trouvés.
• Ne doit pas correspondre : les numéros de commande et les dates fournis sont laissés tranquilles.
• Messages ordinaires : combien de messages sains la règle signalerait. Tout chiffre au-dessus de zéro mérite un coup d’œil avant de continuer.

Voici une esquisse de ce à quoi la règle obtenue pourrait ressembler dans le fichier de politique. Elle est illustrative ; le format final peut différer.

app: customer-support
rules:
  - id: driving-licence
    layer: fast-rules
    find: pattern learned from your examples
    only_near: ["permis de conduire", "رخصة قيادة", "driving licence"]
    action: mask        # le modèle voit [DRIVING_LICENCE_1]
    tests:
      should_match: ["Mon numéro de permis est <exemple>"]
      should_pass: ["La commande <exemple> a été livrée hier"]

Étape 5 : brouillon, test, déploiement

1. Ajoutez au brouillon. La politique en production n’a pas changé ; l’assistant ne modifie jamais que le brouillon.
2. Lancez les tests de règles. Le brouillon et la politique en production s’exécutent côte à côte sur chaque cas à arrêter et à laisser passer.
3. Déployez par la porte de déploiement. Elle ne s’ouvre que si les tests passent sur exactement ce brouillon, ou si un cas en échec est accepté avec une raison écrite versée au journal d’audit.
4. Commencez en mode observation si vous le souhaitez : voyez ce que la règle aurait fait sur le trafic réel avant qu’elle n’agisse.

Des demandes qui fonctionnent

• Une règle par demande. « Masque les numéros de permis » et « bloque les noms des concurrents » sont deux demandes.
• Nommez l’action : masquer, avertir, demander de reformuler ou bloquer. Le masquage laisse la conversation continuer et c’est souvent le meilleur choix pour les données personnelles.
• Donnez des exemples dans chaque langue et chaque écriture qu’utilisent vos clients, y compris l’arabizi s’ils l’écrivent.
• Précisez pour qui, quand cela compte : une règle pour un chat anonyme sur un site peut être plus stricte qu’une règle pour un outil interne.