Une politique de caviardage pour une API d’IA est le cadre qui définit ce que votre équipe peut envoyer à un modèle, ce qu’elle peut stocker après la réponse du modèle, ce qui apparaît dans les journaux de requêtes, et ce que le support peut voir lorsqu’un client ouvre un ticket. C’est important parce que les prompts et les sorties ne sont plus de simples entrées transitoires pour les développeurs. Ils deviennent des enregistrements de débogage, des preuves d’audit, des captures d’écran, des exportations, des pièces jointes de support et des éléments d’examen des achats.
La version faible de cette politique dit « ne consignez pas de données sensibles ». Ce n’est pas suffisant. Les équipes ont besoin de décisions au niveau des champs, de propriétaires, de fenêtres de conservation et d’une gestion des exceptions avant que le trafic de production n’atteigne une passerelle de modèle. Une bonne politique de caviardage pour une API d’IA indique à l’ingénierie quand bloquer une requête, à la sécurité quand masquer des données, au support quand caviarder un ticket, et aux achats quelles preuves montrent que le processus est maîtrisé.
Flatkey est utile dans cette discussion parce que le site public actuel positionne flatkey.ai comme une clé API unique pour le trafic officiel GPT, Claude, Gemini et d’autres modèles, avec des analyses d’utilisation, des contrôles de coûts et une seule facture pour plusieurs fournisseurs. Considérez cela comme une surface unifiée d’accès et de revue. Ne le considérez pas comme un remplacement de votre propre classification des données, de votre examen juridique, de votre politique de conservation ou de votre processus de caviardage du support. Avant le déploiement, vérifiez dans votre propre compte acheteur les paramètres de compte exacts, les journaux, les exportations, le comportement de conservation et le périmètre du DPA.
Politique de caviardage pour l’API IA : la version courte
Une politique de caviardage pour une API d’IA doit répondre à cinq questions opérationnelles avant qu’un prompt n’atteigne la production :
| Question | Décision de politique | Propriétaire |
|---|---|---|
| Quelles données sont interdites dans les prompts ? | Bloquer les secrets, les données de paiement, les identifiants bruts, les clés privées et les données réglementées non prises en charge avant l’appel à l’API | Responsable sécurité |
| Quelles données peuvent être masquées et envoyées ? | Remplacer les identifiants directs par des jetons, des hachages, des libellés ou des espaces réservés synthétiques lorsque la qualité de la tâche reste suffisante | Responsable applicatif |
| Qu’est-ce qui est stocké dans les journaux ? | Privilégier par défaut des journaux limités aux métadonnées ; stocker des extraits de charge utile uniquement pour des cas de débogage approuvés | Responsable de la plateforme |
| Qu’est-ce que le support peut voir ? | Caviarder les prompts, sorties, pièces jointes, captures d’écran et traces du client avant le partage du ticket | Responsable support |
| Quand le caviardage peut-il être contourné ? | Exiger une exception nommée, une finalité d’incident, une limite d’accès, une date de conservation et une approbation juridique/sécurité | Responsable gouvernance |
L’objectif pratique n’est pas de supprimer chaque détail utile. L’objectif est de préserver suffisamment de preuves pour déboguer, rapprocher l’usage et aider les clients sans transformer les prompts, les sorties, les journaux ou les tickets en enregistrements sensibles incontrôlés.
Commencez par une cartographie des données, pas par une liste d’expressions régulières
Le caviardage des prompts LLM échoue généralement lorsque les équipes commencent par une liste restreinte d’expressions régulières. Les regex aident à repérer des motifs évidents, mais elles ne définissent pas la politique. Commencez par cartographier où apparaît le trafic IA :
| Surface d’enregistrement | Champs typiques | Traitement par défaut |
|---|---|---|
| Corps du prompt | Texte utilisateur, arguments d’outil, contexte importé, documents récupérés, instructions système | Classer avant envoi ; bloquer ou tokeniser les valeurs sensibles |
| Sortie du modèle | Réponse générée, citations, appels d’outil, code, JSON structuré | Analyser avant affichage, stockage, export ou copie dans un ticket |
| Métadonnées de passerelle | Fournisseur, modèle, statut, latence, nombre de jetons, ID de requête, espace de travail, environnement | Conserver pour les opérations et la facturation sauf si cela révèle du contenu sensible |
| Journal de charge utile de passerelle | Prompt, réponse, entrée/sortie d’outil, pièces jointes, entrée d’embeddings | Désactivé par défaut ou coffre de débogage à conservation courte |
| Ticket de support | Rapport client, prompt copié, sortie, captures d’écran, fichiers HAR, traces de pile | Caviarder avant un partage large ; séparer les preuves d’incident du support courant |
| Export d’analytique | Lignes de coût, lignes d’usage, libellés client/équipe, catégories d’erreur | Désidentifier les libellés lorsque les exportations quittent l’équipe opérationnelle |
Cette carte devrait devenir l’annexe de votre politique de caviardage pour l’API d’IA. Elle donne aux réviseurs un endroit où poser des questions concrètes : quels champs sont classifiés, lesquels sont masqués, lesquels sont conservés, et quel rôle peut approuver les exceptions.
Classifiez les prompts avant l’appel au modèle
Les contrôles de conservation du fournisseur sont importants, mais ils ne remplacent pas l’hygiène des prompts. Les contrôles de données API actuels d’OpenAI API data controls indiquent que les données API ne sont pas utilisées pour entraîner les modèles OpenAI, sauf si un client choisit explicitement de participer, mais ils décrivent aussi des journaux de surveillance des abus qui peuvent contenir des prompts, des réponses et des métadonnées dérivées, et qui sont conservés jusqu’à 30 jours par défaut. La documentation de rétention des données et de l’API d’Anthropic Anthropic's API and data retention documentation distingue également les accords de traitement des données, la rétention zéro des données, et les cas où des entrées et sorties signalées pour la sécurité peuvent être conservées.
Cela signifie que votre politique doit éviter de s’appuyer uniquement sur « le fournisseur ne l’utilisera pas pour l’entraînement » comme seul contrôle. Une politique de caviardage pour une API d’IA en production doit définir ce qui ne franchit jamais la frontière :
| Type de données | Action recommandée | Exemple de remplacement |
|---|---|---|
| Clés API, jetons de session, jetons d’actualisation OAuth, clés privées | Bloquer la requête et alerter le propriétaire | SECRET_BLOCKED |
| Numéros de carte de paiement et coordonnées bancaires | Bloquer sauf si un flux de paiement conforme et approuvé existe | PAYMENT_FIELD_REMOVED |
| Mots de passe ou réponses de récupération | Bloquer et créer un ticket de sécurité | CREDENTIAL_REMOVED |
| Identifiants personnels directs non nécessaires à la qualité de la tâche | Tokeniser ou généraliser | CUSTOMER_4821, city_region |
| Identifiants de compte nécessaires au débogage | Hacher ou utiliser un identifiant substitut interne | acct_hash_... |
| Prompts système internes et texte de politique caché | Ne pas exposer à l’entrée utilisateur ni aux tickets d’assistance | SYSTEM_CONTEXT_REDACTED |
Le classifieur de prompts n’a pas besoin d’être parfait pour être utile. Il a besoin de voies d’escalade. Si la requête contient un identifiant d’accès, bloquez. Si elle contient des données personnelles dont le modèle n’a pas besoin, masquez-les. Si le produit a réellement besoin d’une valeur sensible, exigez une finalité documentée, un chemin de modèle limité, un responsable de conservation et un évaluateur.
Pour les équipes qui construisent leurs propres classifieurs, Google Sensitive Data Protection est une référence officielle utile pour les concepts de transformation de dé-identification et de caviardage. Utilisez-la comme source de modèle de conception, et non comme preuve qu’une passerelle quelconque a ces contrôles activés.
Analyser les sorties avant qu’elles ne deviennent des enregistrements
La confidentialité des sorties de prompts est souvent négligée parce que les équipes considèrent la réponse du modèle comme un artefact d’affichage. En pratique, les sorties sont copiées dans des tickets, stockées dans des historiques de chat, intégrées dans des analyses, jointes à des rapports de bogues et collées dans des e-mails clients. Votre politique de sortie devrait couvrir au moins quatre risques :
| Risque de sortie | Contrôle |
|---|---|
| Le modèle répète du contenu sensible du prompt | Analyser le texte généré avant la persistance et le partage avec l’assistance |
| Le modèle révèle des instructions système ou un contexte caché | Détecter et bloquer les schémas de fuite de politique/préambule |
| Le modèle invente des faits personnels ou financiers | Exiger une revue tenant compte de la source avant toute utilisation réglementée ou ayant un impact client |
| Le modèle inclut du code non sûr, des secrets ou des identifiants | Mettre en quarantaine et orienter vers une revue de sécurité |
La catégorie de risque LLM02 divulgation d’informations sensibles de l’OWASP présente la divulgation comme un risque pour le modèle et l’application pouvant inclure des données personnelles, des détails financiers, des dossiers de santé, des données commerciales confidentielles, des identifiants et des documents juridiques. C’est un rappel utile : la politique de caviardage pour l’API IA ne concerne pas uniquement le filtrage des entrées. Elle concerne aussi l’inspection des sorties, le contrôle du stockage et le contrôle des flux d’assistance.
Pour les flux de travail à haut risque, conservez la réponse générée séparément du prompt brut. Stockez une transcription caviardée pour les opérations courantes et ne conservez les preuves brutes que dans un coffre-fort d’incident à accès restreint lorsqu’une finalité approuvée existe.
Faire du caviardage des journaux de l’API IA une approche centrée sur les métadonnées
Le caviardage des journaux de l’API IA devrait commencer par un défaut centré sur les métadonnées. La plupart des équipes de plateforme ont besoin des identifiants de requête, des noms de modèle, des codes d’état, de la latence, des comptes de jetons, des tentatives de routage, de l’environnement, du propriétaire et des champs de coût. Elles n’ont pas toujours besoin du prompt brut et de la réponse brute.
La documentation de journalisation de Cloudflare AI Gateway est un bon exemple de l’importance de cette distinction : elle documente séparément les contrôles pour la collecte des journaux et la collecte des charges utiles de journaux, ainsi que des champs DLP lorsque les politiques se déclenchent. La documentation d’observabilité de Vercel AI Gateway décrit la journalisation des dépenses, de l’utilisation des modèles et des métriques d’observabilité pour la surveillance et le débogage. Ces exemples ne sont pas des affirmations de fonctionnalités de Flatkey. Ils montrent le modèle opérationnel que chaque acheteur de passerelle devrait évaluer : les métadonnées, la charge utile, les signaux DLP, la conservation et la suppression sont des décisions distinctes.
Utilisez cette politique de journalisation comme base :
| Champ du journal | Par défaut | Exception |
|---|---|---|
| ID de requête, espace de travail, environnement, route, modèle, fournisseur | Conserver | Aucune ; nécessaire pour l’assistance et l’audit |
| Statut, code d’erreur, latence, événement de nouvelle tentative/de repli | Conserver | Aucune ; nécessaire pour l’examen de la fiabilité |
| Utilisation des jetons et estimation du coût | Conserver | Dé-identifier les libellés client/équipe dans les exports financiers lorsque requis |
| Corps du prompt et de la réponse | Ne pas stocker par défaut | Coffre de débogage à conservation courte avec incident nommé |
| Arguments de l’outil et sortie de l’outil | Caviarder par champ ; ne stocker que des extraits approuvés | Incident de sécurité ou cas de bogue reproductible |
| Catégorie de correspondance DLP | Conserver les identifiants de politique et les catégories | Éviter de stocker le secret correspondant lui-même |
La politique de caviardage pour l’API IA devrait également définir les mécanismes de suppression. Qui peut supprimer un journal ? Qui peut placer une mise en conservation légale ? Que se passe-t-il aux analyses dérivées après purge d’une charge utile brute ? Si l’équipe ne peut pas répondre à ces questions, la journalisation des charges utiles n’est pas prête pour une utilisation large en production.
Caviarder les tickets d’assistance avant qu’ils ne se propagent
Les tickets d’assistance sont souvent l’endroit où les contrôles d’ingénierie rigoureux fuient. Un client colle un prompt complet dans un ticket. Un ingénieur joint une trace avec un corps de requête. Une capture d’écran inclut une clé. Une macro d’assistance transfère la discussion à un autre fournisseur. Soudain, l’enregistrement sensible ne se trouve plus seulement dans le chemin du modèle ; il se trouve aussi dans un help desk, une notification par e-mail, une exportation d’entrepôt de données et un compte rendu d’incident.
Votre politique de caviardage pour l’API IA devrait traiter l’assistance comme une surface distincte :
| Artefact d’assistance | Revue requise |
|---|---|
| Prompt copié ou sortie du modèle | Caviarder les identifiants, les secrets et les données réglementées avant une visibilité large dans l’assistance |
| Capture d’écran | Recadrer ou flouter les clés, e-mails, identifiants client, corps de requête et prompts cachés |
| Fichier HAR ou trace | Supprimer les en-têtes d’autorisation, les cookies, les charges utiles et les URL signées |
| Pièce jointe de ticket | Caviarder ou supprimer les fichiers sensibles avant l’escalade |
| Escalade vers un fournisseur | Partager le minimum de données de reproduction, pas le contenu brut du client |
La documentation officielle des API de Zendesk soutient ce modèle opérationnel en documentant le caviardage des chaînes dans les commentaires de ticket, ainsi qu’un endpoint distinct de caviardage des pièces jointes de commentaires. Même si votre équipe utilise un autre help desk, le point de politique reste le même : le caviardage de l’assistance doit être un workflow nommé, et non un nettoyage ponctuel après que quelqu’un a remarqué une valeur divulguée.
Définir les exceptions avant les incidents
Chaque politique stricte a besoin d’un chemin d’exception contrôlé. Sans cela, les équipes contournent la politique de manière informelle ou conservent trop peu de preuves pour résoudre les problèmes de production.
Utilisez cet enregistrement d’exception :
| Champ | Valeur requise |
|---|---|
exception_id |
Identifiant unique lié à l’incident ou à l’enquête |
business_purpose |
Débogage, revue de fraude, revue de sécurité, conservation légale ou assistance approuvée par le client |
data_scope |
Champs exacts autorisés, pas « charge utile complète » par défaut |
access_group |
Personnes nommées ou rôle avec accès limité dans le temps |
retention_until |
Date ou événement mettant fin à l’exception |
reviewer |
Sécurité, juridique, confidentialité ou responsable produit |
customer_notice_required |
Oui/non avec justification |
deletion_or_redaction_task |
Ticket de suivi qui clôt la boucle |
Le chemin d’exception doit être suffisamment contraignant pour empêcher un accès occasionnel aux charges utiles brutes, et suffisamment rapide pour la réponse aux incidents. Pour le débogage courant, utilisez d’abord des reproductions synthétiques ou des jeux de données caviardés. Pour les conservations légales, ne conservez que le périmètre requis par le conseil juridique. Pour l’assistance client, demandez le consentement avant d’utiliser du contenu brut fourni par le client en dehors du contexte d’assistance initial.
Attribuer la responsabilité dans la politique
Une politique sans responsables devient un document dormant. Attribuez les décisions par surface :
| Surface | Responsable principal | Responsable de secours | Fréquence de revue |
|---|---|---|---|
| Classificateur de prompts et règles de blocage | Ingénierie sécurité | Plateforme applicative | Mensuelle et après les incidents |
| Analyseur de sorties | Ingénierie produit | Trust and safety | Mensuelle |
| Champs de logs de passerelle | Ingénierie plateforme | Ingénierie sécurité | Trimestrielle |
| Plan de conservation | Confidentialité/juridique | Ingénierie sécurité | Trimestrielle |
| Workflow de caviardage de l’assistance | Opérations support | Opérations sécurité | Mensuelle |
| Dé-identification des exportations et des analyses | Opérations data/finance | Confidentialité/juridique | Trimestrielle |
| Approbations d’exception | Conseil sécurité/confidentialité | Commandant d’incident | Chaque exception |
Réexaminez la politique de caviardage de l’API IA après les changements majeurs de modèle, les nouvelles modalités, les nouveaux outils d’assistance, les nouveaux sous-traitants de données et tout incident impliquant une exposition de prompts ou de sorties. Le caviardage n’est pas un projet ponctuel de regex. C’est un contrôle vivant qui suit le cycle de vie du trafic IA.
Comment les acheteurs Flatkey devraient utiliser cette politique
Si votre équipe évalue un accès unifié à l’API IA, utilisez cette politique comme liste de contrôle d’achat. Posez les mêmes questions, que le trafic passe par des comptes fournisseurs directs, un proxy interne ou une passerelle gérée :
- Quels champs de requête sont visibles dans les logs, les exportations, les factures, les tableaux de bord et les workflows d’assistance ?
- La journalisation des charges utiles peut-elle être désactivée, limitée ou soumise à une durée ?
- Qui peut voir les prompts et sorties bruts ?
- Comment les tickets d’assistance et les pièces jointes sont-ils caviardés ?
- Quels paramètres de conservation sont contractuels, configurables ou relèvent uniquement de la pratique opérationnelle ?
- Comment le fournisseur gère-t-il les sous-traitants, le périmètre du DPA, les conservations légales et les demandes de suppression ?
- Quelles preuves un acheteur peut-il exporter pour un audit sans exporter le contenu brut du client ?
Les pages publiques actuelles de Flatkey la positionnent autour d’un seul élément clé : l’accès aux modèles, les analyses d’utilisation, les contrôles des coûts, le solde prépayé et une seule facture pour l’ensemble des fournisseurs. Cela en fait un endroit pertinent pour centraliser l’examen opérationnel de l’API IA. L’acheteur doit toujours valider les contrôles spécifiques au compte avant de considérer toute passerelle comme la source de référence en matière de confidentialité, de conservation ou de preuves pour l’assistance. Pour le contexte actuel des offres, des modèles et des recharges, consultez la tarification Flatkey avant validation.
Liste de contrôle de mise en œuvre
Utilisez cette liste de contrôle avant le premier lancement en production :
- Classez les champs de prompt, de sortie, de métadonnées, de journaux, de ticket, de capture d’écran et d’export.
- Bloquez les secrets et les identifiants avant la requête à l’API IA.
- Tokenisez ou généralisez les identifiants personnels qui ne sont pas nécessaires à la qualité de la tâche.
- Stockez par défaut les journaux de métadonnées et exigez une approbation pour la capture des charges utiles brutes.
- Définissez une courte fenêtre de conservation pour les charges utiles de débogage approuvées.
- Analysez les sorties avant la persistance, l’export d’analytique ou le partage avec l’assistance.
- Caviardez les tickets d’assistance, les pièces jointes, les captures d’écran et les traces avant l’escalade.
- Documentez les responsables des exceptions, les dates de conservation et les tâches de suppression.
- Vérifiez les contrôles de données du fournisseur, les conditions du DPA, le périmètre des sous-traitants et les paramètres du compte.
- Réexaminez la politique de caviardage de l’API IA après des incidents, de nouveaux modèles et de nouveaux outils d’assistance.
Questions fréquentes
Qu’est-ce qu’une politique de caviardage pour l’API IA ?
Une politique de caviardage pour l’API IA définit les champs sensibles qui doivent être bloqués, masqués, tokenisés, conservés, supprimés ou approuvés dans les prompts, les sorties de modèle, les journaux de passerelle, les exports et les tickets d’assistance. Elle est plus spécifique qu’une déclaration de confidentialité, car elle attribue un traitement et des responsables au niveau des champs.
La conservation zéro des données par le fournisseur suffit-elle ?
Non. La conservation zéro des données ou une conservation modifiée peut réduire le stockage côté fournisseur, mais cela ne classe pas vos propres prompts, ne nettoie pas vos journaux, ne caviarde pas les tickets d’assistance et ne régit pas les exports. Considérez la conservation du fournisseur comme un contrôle parmi d’autres dans une politique de caviardage plus large pour l’API IA.
Les journaux de l’API IA doivent-ils inclure les prompts et les sorties ?
Les journaux limités aux métadonnées devraient être la norme pour la plupart du trafic de production. Ne stockez les prompts et les sorties bruts que lorsque l’objectif de débogage ou de conformité est approuvé, que l’accès est limité, que la conservation est courte et que la tâche de nettoyage est suivie.
Comment l’assistance doit-elle traiter les prompts des clients ?
L’assistance doit demander la reproduction la plus minimale nécessaire, caviarder les prompts et sorties copiés avant tout partage élargi, retirer les secrets des traces et des captures d’écran, et ne conserver les preuves brutes que dans un flux de travail d’incident ou d’assistance restreint avec un responsable de la conservation.
Par où une équipe Flatkey devrait-elle commencer ?
Commencez par les liens internes entre la journalisation des charges utiles, la conservation des données et la gouvernance de la passerelle : consultez la journalisation des charges utiles de l’API IA, associez-la à une liste de contrôle de conservation des données de l’API IA, mappez-la à votre liste de contrôle RGPD pour la passerelle d’API IA, puis obtenez une clé et vérifiez les paramètres spécifiques au compte avant la production.
Conclusion
La politique de caviardage durable pour l’API IA est celle que vos développeurs, votre équipe d’assistance, votre référent confidentialité et votre responsable financier peuvent tous appliquer. Conservez les métadonnées utiles. Masquez ou bloquez les valeurs sensibles avant qu’elles ne se propagent. Ne stockez les charges utiles brutes que pour des exceptions nommées. Caviardez les tickets d’assistance avant l’escalade. Ensuite, utilisez une surface d’examen de la passerelle, la documentation actuelle du fournisseur et vos propres preuves DPA pour démontrer que la politique n’est pas seulement rédigée, mais qu’elle fonctionne.
