Routage d'API IA prenant en compte la rétention des données : appliquer les politiques ZDR, de résidence et de journalisation au niveau de la passerelle

Les équipes de sécurité n'ont pas seulement besoin de savoir quel modèle est le moins cher, le plus rapide ou le plus performant. Ils doivent savoir si une demande spécifique peut légalement et opérationnellement être envoyée à un fournisseur, un point de terminaison, une région, une fonctionnalité et un mode de journalisation spécifiques.

C'est plus difficile qu'il n'y paraît. Un modèle peut être acceptable pour une conversation interne ordinaire, mais pas pour les informations personnelles d'un client. Un fournisseur peut offrir une rétention de données nulle pour un chemin d'API, tandis qu'une fonctionnalité de recherche stocke les invites et les sorties pendant une période fixe. Une région peut prendre en charge la résidence de stockage, mais pas le mode de traitement attendu. Les journaux appartenant aux développeurs peuvent être configurables, tandis que les journaux de surveillance des abus des fournisseurs suivent une politique différente.

La réponse pratique consiste à déplacer les décisions de rétention des applications individuelles vers la passerelle API AI. La passerelle doit classer la demande, l'évaluer par rapport à une matrice de capacités du fournisseur, bloquer les fonctionnalités incompatibles, l'acheminer uniquement vers des profils de modèle approuvés et enregistrer une décision politique sans stocker les invites brutes par défaut.

Le problème du lecteur : les conditions de confidentialité du fournisseur ne sont pas des contrôles d'exécution

La plupart des équipes commencent par une feuille de calcul ou un examen de sécurité indiquant quels fournisseurs d'IA sont approuvés. C'est utile, mais ce n'est pas suffisant pour le routage de la production.

Les applications font des choix d'exécution :

• Quel ID de modèle doit traiter cette demande ?
• La requête doit-elle utiliser la mise en cache de la recherche, le téléchargement de fichiers, l'exécution de code, le traitement par lots, la mise en cache des invites ou les conversations stockées ?
• Quelle région ou quel point de terminaison doit traiter la demande ?
• Le système peut-il enregistrer l'invite brute pour le débogage ?
• Le routage de secours peut-il envoyer la même requête à un autre fournisseur ?

Chacun de ces choix peut modifier le profil de rétention. Une demande qui était conforme en mode chat simple peut devenir non conforme lorsque le développeur active la mise à la terre ou le stockage persistant des conversations. Une règle de secours conçue pour la fiabilité peut accidentellement acheminer des données réglementées vers un chemin de fournisseur qui n'a pas été approuvé pour la conservation zéro des données, la résidence des données ou les contrôles de surveillance des abus.

Recommandation : traitez le comportement de rétention comme une contrainte de routage de premier ordre, et non comme une documentation jointe à un compte fournisseur.

Faits à coder avant de concevoir une politique

Les conditions exactes varient selon le fournisseur, le produit, le contrat, la région, le point de terminaison et la fonctionnalité. Ne comptez pas sur la mémoire ou sur un examen ponctuel. Créez une matrice appartenant à la source et mettez-la à jour lorsque les termes changent.

Plusieurs documents actuels des fournisseurs publics illustrent pourquoi cela est nécessaire :

• OpenAI : la résidence des données de l'API est documentée comme étant configurée par le projet, les demandes régionales nécessitant des préfixes de domaine spécifiques à la région. OpenAI distingue également la prise en charge du stockage de la prise en charge du traitement par région et note des exigences supplémentaires pour les régions non américaines. OpenAI déclare que la résidence des données API non américaines nécessite l'approbation des contrôles de surveillance des abus et un amendement de conservation modifiée.
• Anthropic : Anthropic documente l'absence de conservation des données pour les cas d'utilisation commerciale liés aux API, tout en notant que certains produits associés ou flux de conformité ont des modèles de conservation distincts, notamment une conservation plus longue pour le flux d'activité et les transcriptions de sessions à distance.
• Google Gemini : les termes de l'API Gemini distinguent les services non payants et payants. Pour les services non payants, Google peut utiliser le contenu soumis et les réponses générées pour améliorer les produits ; pour les services payants, Google indique que les invites et les réponses ne sont pas utilisées pour améliorer les produits. La documentation ZDR de l'API Gemini Developer indique que les journaux de surveillance des abus des services payants conservent normalement les invites et les réponses pendant une période limitée, tandis que les projets ZDR approuvés effacent le contenu utilisateur et les métadonnées identifiables avant la journalisation.
• Stockage spécifique aux fonctionnalités : la documentation Gemini indique que Grounding with Google Search et Grounding with Google Maps stockent les invites, les informations contextuelles et les résultats générés pendant 30 jours, sans aucun moyen de désactiver ce stockage lorsque ces fonctionnalités sont utilisées.
• Journaux appartenant aux développeurs : la documentation de journalisation de l'API Gemini indique que les journaux d'API appartenant aux développeurs peuvent être conservés jusqu'à 55 jours par défaut pour les projets activés pour la facturation et que les développeurs peuvent choisir des fenêtres plus courtes, telles que 7, 14 ou 28 jours.
• Gestion des risques : le profil d'IA générative du NIST recommande de surveiller le contenu généré par l'IA pour détecter les risques liés à la confidentialité et de connecter les politiques d'IA générative aux données, logiciels, processus juridiques, de conformité et de gestion des risques existants.

Il s'agit de faits à vérifier par rapport à la documentation actuelle du fournisseur avant le déploiement. La leçon d'architecture est stable : la rétention n'est pas une valeur booléenne au niveau du fournisseur.

Architecture : un moteur de politique de passerelle dans le chemin de la requête

Une passerelle prenant en compte la rétention comporte cinq composants principaux :

1. Classificateur de sensibilité des requêtes : étiquette la charge de travail avant le routage.
2. Matrice des capacités du fournisseur : décrit le comportement du fournisseur, du modèle, du point de terminaison, de la région, de la rétention, de la journalisation et des fonctionnalités.
3. Règles de stratégie en tant que code : convertissez les exigences de sécurité en décisions d'exécution d'autorisation, de refus ou de révision.
4. Couche de portes de fonctionnalités : bloque les fonctionnalités modifiant la rétention, sauf autorisation explicite.
5. Couche d'audit et d'analyse : enregistre les métadonnées utiles sans stocker les invites brutes par défaut.

La passerelle n'a pas besoin de comprendre toutes les nuances juridiques. Il doit appliquer les décisions approuvées par vos équipes juridiques, de sécurité, de conformité et de plate-forme.

Étape 1 : classer la sensibilité des requêtes avant de sélectionner un modèle

Commencez par une petite taxonomie de classification. Il doit être suffisamment simple à utiliser pour les développeurs, mais suffisamment expressif pour orienter la politique.

Exemples d'étiquettes de confidentialité :

• public : documentation publique, copie marketing, contenu de site Web public.
• interne : informations non publiques sur l'entreprise et peu sensibles.
• confidentiel : stratégie, contrats, contexte client, détails inédits du produit.
• customer_pii : noms, adresses e-mail, adresses, identifiants de compte, transcriptions d'assistance.
• réglementées : données protégées en matière de santé, financières, juridiques, éducatives ou spécifiques à une juridiction.
• source_code : code propriétaire, configuration, fichiers d'architecture.
• identifiants : secrets, jetons, mots de passe, clés privées. Dans la plupart des systèmes, cela devrait être bloqué et non acheminé.

La classification peut provenir de plusieurs sources :

• Un en-tête fourni par l'application, tel que X-Data-Class : customer_pii.
• Règle de locataire, selon laquelle tout le trafic provenant d'un client réglementé est traité comme réglementé à moins qu'il ne soit déclassé par une règle approuvée.
• Règle de point de terminaison, où le résumé du ticket d'assistance est par défaut customer_pii.
• Analyse légère du contenu à la recherche d'identifiants, d'informations personnelles évidentes ou de violations des règles.

Recommandation : ne dépendez pas entièrement de la détection automatique. Exigez que les applications déclarent la classe de données souhaitée, puis utilisez l'analyse pour détecter les incohérences évidentes ou forcer une classe plus sûre.

Étape 2 : créer une matrice de capacités du fournisseur

La matrice de capacités est la source de vérité évaluée par le routeur. Il doit être versionné, révisé et testé comme la configuration de production.

Exemples de champs :

refuser si data_class == "credentials"
  raison "credentials_must_not_be_sent_to_model"
autoriser uniquement si data_class dans ["regulated", "customer_pii"]
  et profile.zdr_eligible == true
  et profile.zdr_contract_required_satisfied == true
  Reason_on_failure "model_profile_not_zdr_eligible"
refuser si résidence_required == "eu"
  et "eu" pas dans profile.processing_residency
  raison "region_processing_not_supported"
refuser si data_class dans ["confidential", "customer_pii", "regulated"]et request.raw_prompt_logging == true
  raison "raw_prompt_logging_not_allowed"
refuser si request.features.search_grounding == true
  et Policy.requires_zdr == true
  et profile.feature_storage.search_grounding_days > 0
  raison "grounding_requires_retained_content"
refuser si fallback_profile.retention_level