Un modèle accessible par API permet à son fournisseur de mettre en place plusieurs couches de contrôle autour du système d’intelligence artificielle.
Une architecture classique peut être schématisée ainsi :
Utilisateur
↓
Authentification / compte
↓
Rate limiting
↓
Filtrage du prompt
↓
Instructions système
↓
MODÈLE
↓
Filtrage de la réponse
↓
Provenance / watermark éventuel
↓
Utilisateur
Ces protections peuvent être totalement indépendantes des poids du modèle lui-même.
Un modèle peut techniquement être capable de produire une réponse donnée alors qu’une couche extérieure empêche cette demande d’arriver jusqu’à lui ou bloque sa réponse avant qu’elle ne soit retournée à l’utilisateur.
Le filtrage des entrées
Le premier niveau consiste généralement à analyser la requête envoyée au modèle.
Un système de modération peut rechercher :
- des contenus interdits ;
- des instructions dangereuses ;
- des tentatives de contournement ;
- des requêtes correspondant à certaines catégories de risque ;
- des comportements automatisés anormaux.
Ces filtres peuvent fonctionner à partir de règles déterministes, de classifieurs spécialisés ou de modèles d’intelligence artificielle distincts du modèle principal.
Guardrails et contrôle des réponses
Une seconde couche intervient au niveau du comportement du modèle.
Les guardrails peuvent notamment imposer :
- des limites sur les sujets abordés ;
- des formats de réponse précis ;
- des refus automatiques ;
- des contrôles avant l’appel d’un outil externe ;
- des validations après génération.
Une architecture peut ainsi devenir :
Prompt
↓
Input Guardrail
↓
LLM
↓
Output Guardrail
↓
Réponse
Protection contre les jailbreaks et prompt injections
Les systèmes modernes doivent également faire face aux tentatives de jailbreak et de prompt injection.
Il faut distinguer au minimum deux situations :
- l’attaque directe, dans laquelle l’utilisateur tente volontairement de faire ignorer ses instructions au modèle ;
- l’injection indirecte, dans laquelle une instruction malveillante se trouve dans un document, une page Web, un email, une base RAG ou le résultat retourné par un outil.
Cette seconde catégorie est particulièrement importante pour les systèmes capables de consulter des sources externes.
Utilisateur
↓
Agent IA
↓
Page Web / document / email
↓
instruction malveillante cachée
↓
tentative de modification du comportement
Une architecture robuste doit donc considérer les données récupérées comme potentiellement non fiables et maintenir une séparation entre instructions système, demande utilisateur et contenu externe.
Le contrôle de l’utilisation de l’API
Le fournisseur peut également contrôler l’accès au service à travers :
- les comptes utilisateurs ;
- les clés API ;
- les quotas ;
- les limitations de débit ;
- les permissions ;
- les outils accessibles ;
- la journalisation ;
- la suspension d’un accès en cas d’abus.
L’API permet donc de construire une véritable défense en profondeur autour du modèle.
Le cas très différent des modèles open-weight
Avec un modèle open-weight, une partie importante de ce contrôle disparaît pour le fournisseur.
Une fois les poids téléchargés, l’architecture devient plutôt :
Poids du modèle
↓
Serveur local
↓
Runtime choisi par l’utilisateur
↓
Ollama / llama.cpp / vLLM / ComfyUI
↓
Application
L’exploitant peut alors décider lui-même de mettre en place ses protections.
Une infrastructure locale peut par exemple utiliser :
Utilisateur
↓
Pare-feu déterministe
↓
Détection prompt injection
↓
Modèle local
↓
Classifieur de sécurité
↓
Contrôle de sortie
↓
Journal d’incident
Des modèles spécialisés peuvent être utilisés comme garde-fous indépendants du modèle principal.
L’intérêt est de conserver la même infrastructure de protection même si le moteur principal change :
Mistral
↓
Gemma
↓
Llama
↓
autre modèle
La sécurité devient alors une couche indépendante du modèle génératif lui-même.
Pourquoi les protections intégrées sont plus difficiles à garantir en open-weight ?
Le fournisseur d’une API contrôle généralement :
modèle
+
runtime
+
filtres
+
infrastructure
+
sortie
Avec un modèle open-weight, il ne contrôle plus nécessairement que le checkpoint initialement distribué.
L’utilisateur peut ensuite appliquer :
- un fine-tuning ;
- un LoRA ;
- une quantification ;
- un pruning ;
- un merge ;
- une conversion ;
- un autre tokenizer ;
- un autre system prompt ;
- un nouveau pipeline d’inférence.
Le comportement obtenu peut donc s’éloigner de celui du modèle distribué initialement.
Cela ne signifie pas qu’un modèle open-weight serait intrinsèquement moins sécurisé. Cela signifie plutôt que la responsabilité de la sécurisation est largement transférée vers celui qui héberge et exploite le modèle.
