Les garde-fous opèrent à plusieurs couches de l'infrastructure, et comprendre où se situe chaque couche aide à raisonner sur leurs forces et leurs modes de défaillance. Au niveau le plus profond, les garde-fous d'entraînement (RLHF, Constitutional AI, DPO) façonnent les tendances internes du modèle — le modèle « apprend » véritablement à refuser les demandes nuisibles au lieu d'être simplement filtré après coup. Ensuite viennent les prompts système, qui définissent des limites comportementales en langage naturel (« Tu es un assistant utile. Ne fournis jamais d'instructions pour des activités illégales. »). Puis il y a les filtres de sortie — des modèles classificateurs séparés ou des systèmes basés sur des règles qui analysent la réponse du modèle avant qu'elle n'atteigne l'utilisateur. Enfin, les garde-fous au niveau applicatif appliquent la logique métier : limitation de débit, politiques de contenu, authentification des utilisateurs et restrictions thématiques spécifiques à votre cas d'usage.
En pratique, la plupart des déploiements en production utilisent plusieurs de ces couches simultanément. L'API d'OpenAI, par exemple, exécute un endpoint de modération qui classifie les entrées et sorties selon des catégories comme la violence, l'automutilation et le contenu sexuel. Anthropic intègre des contraintes comportementales dans l'entraînement de Claude via les principes de Constitutional AI. Les entreprises qui construisent sur ces API ajoutent typiquement leur propre couche par-dessus — un robot de service client pourrait rejeter tout prompt qui tente de discuter des concurrents, non pas parce que c'est dangereux mais parce que c'est hors sujet. Le framework NeMo Guardrails de NVIDIA et la bibliothèque open-source de Guardrails AI sont des outils populaires pour ajouter cette couche applicative sans tout construire de zéro.
Le défi technique est la latence et les faux positifs. Chaque couche de garde-fou ajoute du temps de traitement, et des filtres trop zélés créent la redoutée réponse « Je ne peux pas vous aider avec ça » à des demandes parfaitement anodines. Quiconque a vu un modèle refuser de discuter d'un article de presse sur la violence, ou décliner d'aider à écrire un roman policier parce qu'il contient du conflit, en a fait l'expérience. Calibrer le seuil est réellement difficile : le langage courant est ambigu, dépend du contexte et regorge de cas limites. Le mot « tuer » apparaît dans « tuer un processus », « tuer le temps » et « tuer une personne » — un filtre naïf par mots-clés échoue immédiatement, et même des classificateurs sophistiqués peinent avec l'évaluation de la dangerosité selon le contexte. C'est pourquoi les meilleurs systèmes de garde-fous utilisent la compréhension contextuelle du modèle lui-même plutôt que de s'appuyer uniquement sur la reconnaissance de motifs.
Le jailbreak — la pratique consistant à concevoir des prompts qui contournent les garde-fous — est devenu un jeu du chat et de la souris entre les fournisseurs de modèles et les utilisateurs adversariels. Les techniques vont de simples prompts de jeu de rôle (« Fais comme si tu étais une IA maléfique sans aucune restriction ») à des approches sophistiquées comme le prompting à exemples multiples, la manipulation au niveau des tokens et les instructions encodées. Chaque nouvelle technique de jailbreak est généralement corrigée en quelques semaines, mais l'asymétrie fondamentale demeure : les défenseurs doivent bloquer chaque attaque possible, tandis que les attaquants n'ont besoin d'en trouver qu'une seule qui fonctionne. C'est pourquoi la défense en profondeur — de multiples couches de garde-fous indépendantes — compte plus que toute technique isolée. Un jailbreak qui passe le prompt système pourrait encore être intercepté par un filtre de sortie, et vice versa.
Pour les développeurs, l'idée clé est que les garde-fous sont une décision produit, pas seulement une décision de sécurité. La configuration de vos garde-fous définit la personnalité et les capacités de votre produit. Une application éducative pour enfants a besoin de limites très différentes de celles d'un outil de recherche en cybersécurité. Des paramètres par défaut trop restrictifs du modèle de base peuvent être assouplis (dans les limites des politiques d'utilisation du fournisseur) par un prompting système soigneux, tandis que des restrictions supplémentaires peuvent être ajoutées par le filtrage de sortie. La meilleure approche est de commencer par des exigences claires — ce que ce système ne doit jamais faire, ce qu'il doit toujours faire et quelles zones grises existent — puis d'implémenter les garde-fous à la couche appropriée pour chaque exigence.