Une équipe chargée de la gestion des risques reçoit un nouveau chatbot d’assistance aux adhérents d’un service de santé deux jours avant son lancement. Lors d’un test tardif, le bot fournit à un adhérent des conseils posologiques étape par étape pour un médicament sur ordonnance, alors que le cahier des charges stipule qu’il doit refuser de donner un avis médical et orienter l’adhérent vers une ligne d’assistance infirmière. Personne ne peut répondre à la première question nécessaire pour évaluer le risque : à quel stade du système ce comportement aurait-il pu être évité, détecté ou contenu ?
La suite de cette leçon consiste à élaborer un modèle de menace pour les sorties nuisibles en parcourant la chaîne de l’incident de bout en bout, puis en transformant cette chaîne en points de contrôle concrets, mesurables et pilotables.
Dans ce cours, un modèle de menace est une description structurée de la manière dont un préjudice spécifique peut survenir dans votre application LLM, en identifiant les composants impliqués, les conditions requises et les preuves permettant de confirmer ou d’infirmer le scénario. Pour les sorties nuisibles, cela signifie que nous considérons la sortie comme l’état de défaillance et que nous remontons la chaîne — du prompt à la livraison, en passant par la récupération, la génération et la modération — jusqu’à identifier les points de rupture contrôlables.
Simulation — extrait du récit de l’incident :
Un adhérent demande au chatbot s’il peut doubler sa dose pour compenser une journée oubliée. Le chatbot récupère une FAQ générale sur les médicaments ainsi qu’un extrait de forum communautaire contenant une discussion informelle sur le dosage. Le modèle répond en fournissant des conseils posologiques conditionnels accompagnés d’un avertissement, et l’interface utilisateur affiche la réponse sans filtre supplémentaire. Aucun message de refus n’est déclenché et aucune vérification humaine n’a lieu.
L’étape clé consiste à décomposer le dysfonctionnement en événements système observables : une requête utilisateur est reçue, l’étape de récupération renvoie un mélange de contexte acceptable et non sûr, le modèle produit un conseil relevant de la réglementation, l’étape de modération ne bloque ni ne réoriente la réponse, et le canal de diffusion la présente comme un contenu d’aide ordinaire. Nous avons besoin d’un modèle de menace car chaque étape implique des données de télémétrie et des limites de contrôle différentes.
Nous pouvons concrétiser cette chaîne dans le schéma du système. En l’examinant, concentrez-vous sur le composant qui a transformé un risque latent en une réponse effectivement délivrée. Reportez maintenant les points de défaillance sur l’architecture :
Un point de contrôle est une étape du parcours allant de la requête à la réponse où l’on peut appliquer une décision de sécurité ou de sûreté en s’appuyant sur une entrée, une politique et une mesure d’application. Concernant les sorties nuisibles, il est utile de classer les points de contrôle selon trois phases : pré-génération, génération et post-génération, car chaque groupe offre des garanties et implique des coûts liés aux faux positifs différents.
Les contrôles de pré-génération façonnent ce que le modèle perçoit. Ils incluent le filtrage des entrées utilisateur, les contraintes de récupération d’informations et les modèles de prompt. Ils peuvent réduire la probabilité de sorties nuisibles, mais ne garantissent pas la sécurité : des entrées apparemment inoffensives peuvent engendrer des réponses dangereuses, et la récupération de données peut faire remonter du contenu limite, potentiellement dangereux selon le contexte.
Les contrôles durant la génération définissent ce que le modèle est autorisé à produire. C’est à ce stade que l’on utilise les instructions système, les politiques d’outils pour les agents et les fonctionnalités de sécurité intégrées au modèle (lorsqu’elles sont disponibles). Bien qu’ils permettent de restreindre les comportements, leur efficacité dépend de la capacité du modèle à respecter les instructions face à des entrées malveillantes ou ambiguës, et ils sont difficiles à vérifier sans tests systématiques.
Les contrôles de post-génération déterminent ce qui est transmis à l’utilisateur et comment le contenu est acheminé. Cela inclut les classifieurs de modération des sorties, les listes d’autorisation et d’exclusion pour les sujets à haut risque, ainsi que les files d’attente pour examen humain. Ils constituent souvent le seul moyen de garantir qu’un contenu interdit ne parvient pas à l’utilisateur, mais ils peuvent engendrer de la latence, nuire à la cohérence de l’expérience utilisateur et nécessitent une journalisation rigoureuse pour prouver leur bon fonctionnement en cas de besoin.
Les garanties nécessitent une mise en applicationL’énoncé d’une politique ne constitue pas un contrôle. Un point de contrôle n’existe que s’il s’accompagne d’une décision applicable et d’une piste d’audit consultable.
Une idée reçue courante consiste à penser que le risque de sorties nuisibles relève uniquement de la qualité du modèle. En réalité, le modèle n’est qu’un composant parmi d’autres dans un système distribué. Un même modèle de base peut être jugé acceptable dans un flux de triage infirmier avec un routage strict en post-génération, mais inacceptable dans une interface de chat en libre-service sans filtrage, car le canal de diffusion modifie l’impact et la détectabilité des risques.
Pour rendre les points de contrôle opérationnels, nous y associons des preuves. Pour chaque point, nous devons être en mesure d’identifier le signal journalisé, son lieu de stockage et ses modalités d’examen. Voici un aperçu des points d’intervention et des journaux associés :