Leçon 2 sur 5 · 10 min
Comment Guardrino est conçu : des couches, des politiques et un test avant chaque changement
La conception prévue de Guardrino, le pare-feu IA de HisnLabs pour l’arabe et l’anglais : des règles rapides d’abord, un petit classifieur qui ne fait que décider, un examen approfondi seulement quand un message est ambigu, cinq actions mesurées, des politiques gérées comme du code versionné, un panneau de tests avant chaque déploiement, et une piste d’audit.
Guardrino est conçu comme une passerelle : vos applications et vos agents lui envoient leurs requêtes, il les contrôle, puis les transmet au modèle de langage de votre choix, hébergé ou le vôtre. La réponse revient par le même chemin et est contrôlée pendant qu’elle s’affiche. Deux idées guident tout le reste : contrôler vite d’abord et n’approfondir que lorsqu’un message est ambigu, et ne jamais gêner les utilisateurs normaux.
Couche 1 : des règles rapides, sur chaque message
La première couche est un ensemble de règles appliquées à chaque message, dans les deux sens, en une infime partie du temps qu’un modèle met à répondre. Elles traitent ce qui se reconnaît à sa forme :
- Les secrets : clés d’API, jetons et mots de passe collés dans une conversation ou présents dans une réponse.
- Les données personnelles du Golfe, vérifiées et non devinées : carte d’identité émiratie (Emirates ID), carte d’identité saoudienne ou Iqama, IBAN des pays du Golfe (validé par ses chiffres de contrôle mod-97 [1]), numéros de téléphone et de carte.
- Vos propres listes : mots et noms à bloquer, valeurs toujours acceptées (votre numéro de support), règles désactivées pour une application.
Avant tout contrôle, le texte est nettoyé pour qu’une astuce d’écriture ne puisse pas cacher un mot. Cette étape tient compte de l’arabe dès le départ :
- Le tashkeel, les signes de voyelles brèves de l’arabe [2], et le tatweel, le trait d’allongement (ـ) qui étire un mot [3], sont neutralisés pour la comparaison : تَجَاهَلْ et تجـــاهل se lisent تجاهل.
- L’arabizi, l’arabe écrit en lettres latines et en chiffres (3 pour ع, 7 pour ح) [4], est lu comme de l’arabe.
- Les lettres sosies, les caractères invisibles et les encodages simples sont normalisés ou décodés, selon le principe de la normalisation Unicode [5].
Cette normalisation sert à comparer, jamais à juger. L’arabe entièrement vocalisé est normal dans le Coran, la poésie et les manuels scolaires : le tashkeel seul n’est jamais considéré comme le signe d’une attaque.
Couche 2 : un petit classifieur qui ne fait que décider
La deuxième couche est Guardrino-t7, un petit modèle que HisnLabs entraîne pour une seule tâche : répondre à des questions précises sur un message. Est-ce une tentative directe de prendre le contrôle de l’assistant ? Une instruction cachée dans un document ou un résultat d’outil ? Une tentative d’extraire le prompt système ? Hors sujet pour cette application ? Déguisé dans un encodage ? Il est entraîné sur l’arabe avec et sans tashkeel, sur l’arabizi et sur l’anglais.
Guardrino-t7 ne fait que classer. Il lit un message une fois et renvoie des scores ; il n’écrit jamais de texte. Un modèle qui ne génère rien ne peut pas être amené à dire ce qu’il ne faut pas : c’est ce qui en fait un juge fiable, assez léger pour examiner chaque message qui en a besoin.
Couche 3 : un examen approfondi, seulement en cas de doute
La plupart des messages sont tranchés par les deux premières couches. Les rares qui restent ambigus passent à un modèle de garde plus grand qui examine le sens : ce qui est réellement demandé, et si la conversation dans son ensemble se dirige vers ce que la politique interdit. Réserver cette étape aux cas ambigus, c’est ce qui rend la conception à la fois rigoureuse et rapide pour tous les autres.
Cinq actions, pas une seule
| Action | Ce qui se passe | Usage typique |
|---|---|---|
| Autoriser | Le message passe sans changement. | Les questions et demandes du quotidien. |
| Masquer | Les données personnelles sont remplacées par un jeton comme [EMIRATES_ID_1] avant que le modèle ne les voie ; vos propres systèmes peuvent les restaurer ensuite. | Un client colle son numéro d’identité dans un chat de support. |
| Avertir | Le message passe, et l’utilisateur ou votre équipe est informé de la raison. | Un collaborateur partage un document interne avec un modèle externe. |
| Demander de reformuler | L’assistant demande à l’utilisateur de le dire autrement. | Une demande ambiguë, ou un texte encodé qu’un bot de support n’a aucune raison de décoder. |
| Bloquer | Le message s’arrête là. | Une tentative claire de prendre le contrôle de l’assistant ou d’extraire ses secrets. |
Cette échelle est ce qui garde l’assistant utile : le client qui a collé son numéro obtient quand même sa réponse, simplement sans exposer le numéro.
Les politiques en tant que code
Chaque application a sa propre politique : quels contrôles sont actifs, quelle action s’applique à quoi, quels mots et valeurs figurent sur ses listes. Les politiques sont prévues sous forme de fichiers versionnés : chaque changement a un historique, peut être comparé à la version précédente et peut être annulé. Elles pourront aussi être écrites en langage courant grâce à un assistant ; la leçon suivante le montre pas à pas.
Un panneau de tests avant chaque déploiement
Modifier une politique, c’est modifier le comportement de votre IA : la conception le traite donc comme une mise en production logicielle. Chaque politique porte ses propres cas de test : des messages qui doivent être arrêtés et des messages ordinaires qui doivent passer. Avant qu’un brouillon ne passe en production :
- Le brouillon est validé, pour qu’une faute de frappe ne puisse pas atteindre la production.
- Les cas de test s’exécutent sur exactement ce brouillon et sur la politique en production, côte à côte : vous voyez ce que le changement arrête et ce qu’il signalerait en plus.
- Le déploiement n’a lieu que si tous les cas passent, ou si quelqu’un accepte un cas en échec avec une raison écrite, conservée dans le journal d’audit.
- Il peut démarrer en mode observation : Guardrino enregistre ce qu’il aurait fait sur le trafic réel sans rien bloquer, pour régler avec des preuves avant d’appliquer.
Une piste d’audit que vous pouvez montrer
Chaque décision et chaque changement sont prévus pour être journalisés : ce qui a été contrôlé, quelle règle a agi, quelle version de la politique était en production, qui l’a modifiée et pourquoi. Les données personnelles des journaux sont masquées. Les journaux sont conçus pour alimenter les outils de votre équipe de sécurité, afin que l’IA rejoigne la surveillance que vous avez déjà.
Le prototype de console
HisnLabs a réalisé un prototype fonctionnel de la console d’administration, en arabe, en anglais et en français, avec une mise en page entièrement de droite à gauche pour l’arabe. Il montre les écrans prévus : un éditeur de politiques avec ses versions, les tests de règles et la porte de déploiement, l’assistant en langage courant, un bac à sable pour essayer des messages, une file de revue, la trace d’un incident, et les réglages des applications, des connexions aux modèles, des utilisateurs et du journal d’audit. Il fonctionne sur des données d’exemple ; c’est un prototype, pas un produit utilisable aujourd’hui.
Pour voir la conception en mouvement, visitez la page Guardrino, où les entreprises peuvent aussi demander à rejoindre le programme pilote.
À retenir
- La couche 1 applique des règles rapides à chaque message : secrets, données personnelles du Golfe avec de vrais chiffres de contrôle, vos listes, après un nettoyage adapté à l’arabe.
- La couche 2, Guardrino-t7, ne fait que classer et ne génère jamais ; la couche 3 examine le sens uniquement quand un message est ambigu.
- Cinq actions (autoriser, masquer, avertir, demander de reformuler, bloquer) gardent l’assistant utile tout en traitant les quelques cas à risque.
- Les politiques sont du code versionné, testé sur des cas à arrêter et des cas à laisser passer avant la mise en production, avec une piste d’audit.
- Tout ceci est la conception prévue : Guardrino est en développement, avec un programme pilote pour les entreprises.
Vérifiez vos connaissances
1. Pourquoi Guardrino-t7 est-il conçu pour seulement classer, sans jamais générer ?
- C’est moins cher à imprimer
- Un modèle qui n’écrit rien ne peut pas être amené à dire ce qu’il ne faut pas — Exact.
- Parce que la génération est illégale
- Pour remplacer le modèle principal
Un modèle qui ne fait que décider renvoie des scores, ce qui en fait un juge fiable.
2. Un client colle son numéro Emirates ID dans un chat de support. Quelle action convient le mieux ?
- Bloquer tout le message
- Masquer le numéro et laisser passer la question — Exact.
- L’ignorer
- Lui demander de reformuler
Le masquage protège la donnée et le client obtient quand même sa réponse.
3. Pourquoi neutraliser le tashkeel et le tatweel avant la comparaison ?
- Parce qu’un texte vocalisé est toujours une attaque
- Pour qu’une astuce d’écriture ne puisse pas cacher un mot aux règles — Exact.
- Pour raccourcir les messages
- Pour traduire l’arabe en anglais
La normalisation sert à comparer ; le tashkeel seul n’est jamais le signe d’une attaque.
4. Que doit-il se passer avant qu’un brouillon de politique passe en production ?
- Rien
- Il doit être validé et passer ses cas de test, ou un échec doit être accepté avec une raison — Exact.
- Il doit être envoyé par e-mail à chaque utilisateur
- Il doit bloquer plus de messages qu’avant
La porte de déploiement traite un changement de politique comme une mise en production logicielle.
Sources
- International Bank Account Number (IBAN), check digits (Wikipedia)
- Arabic diacritics (tashkeel) (Wikipedia)
- Kashida (tatweel) (Wikipedia)
- Arabic chat alphabet (Arabizi) (Wikipedia)
- Unicode Standard Annex #15, Unicode Normalization Forms
- Guardrino, HisnLabs (in development)
Mettez-le en pratique sur votre Mac
Essayez toutes les fonctionnalités gratuitement pendant 17 jours, sans carte bancaire.