Comment créer un routeur de politique de rétention de données pour les API LLM multi-fournisseurs

Un routeur LLM multi-fournisseurs ne doit pas d'abord choisir un modèle et poser des questions de rétention plus tard. Si un flux de travail d'assistance est marqué comme étant sans rétention, la passerelle doit savoir si la combinaison de fournisseur, de point de terminaison, de région, de paramètre de compte et de fonctionnalités sélectionnée peut honorer cette promesse avant que la demande ne quitte vos limites.

Il est facile de rater le mode d'échec. Une équipe commence par terminer le chat sans état. L'itinéraire est acceptable. Plus tard, quelqu'un ajoute le téléchargement de fichiers, l'historique des conversations stocké, la mise à la terre Web, le traitement par lots ou un magasin de vecteurs. Le nom du modèle peut rester le même, mais le comportement des données change. Un simple routeur de latence ou de coût peut envoyer silencieusement des invites réglementées ou liées au contrat client vers un chemin qui stocke le contenu plus longtemps que ne le permet la charge de travail.

La solution pratique consiste à placer les contrôles de conservation des données LLM avant le routage du modèle. Le routeur doit classer la demande, la comparer à une politique de rétention canonique, filtrer les capacités du fournisseur, bloquer les fonctionnalités non autorisées et émettre des preuves vérifiables pour la décision.

Faits à traiter comme des contraintes de conception

Le traitement des données du fournisseur n'est pas uniforme et est rarement capturé par le seul nom du fournisseur. Les faits suivants sont importants lors de la conception d'un routeur prenant en charge la rétention :

• OpenAI indique que API les données ne sont pas utilisées pour former ou améliorer des modèles, sauf si le client l'accepte. Les clients éligibles peuvent configurer la surveillance modifiée des abus ou la conservation zéro des données au niveau de l'organisation ou du projet après approbation.
• La conservation zéro des données de OpenAI modifie le comportement des points de terminaison, notamment en traitant le paramètre store pour les réponses et les discussions terminées comme faux, mais certains points de terminaison et fonctionnalités peuvent toujours stocker l'état de l'application et ne sont pas éligibles à la conservation zéro des données.
• Anthropic documente la conservation zéro des données pour le Claude API comme ne stockant pas les invites ou les réponses des clients au repos après le retour de la réponse API, mais la couverture dépend de l'éligibilité du point de terminaison et de la fonctionnalité.
• Anthropic indique que certaines Claude fonctionnalités ou modèles couverts peuvent nécessiter une conservation et peuvent être indisponibles sous Zero Data Retention, sauf autorisation spécifique.
• Google Le cloud documente que Gemini les données de l'Enterprise Agent Platform ne sont pas utilisées pour entraîner ou affiner des modèles d'IA/ML sans autorisation ou instruction préalable, mais que la conservation zéro des données nécessite des actions spécifiques et peut ne pas être possible pour certaines fonctionnalités avancées.
• Google Documents cloud qui Grounding with Google Search stocke les journaux de requêtes et de contexte dérivés pendant trois jours maximum et ne peut pas désactiver ce stockage pour cette fonctionnalité. Il recommande Web Grounding for Enterprise lorsqu'une rétention de données nulle est requise.
• Microsoft documente que les modèles hébergés sur Azure vendus par Azure ne mettent pas les invites et les complétions à la disposition de OpenAI ou d'autres fournisseurs de modèles et ne les utilisent pas pour entraîner des modèles de base sans autorisation ni instruction.
• Microsoft indique que le type de déploiement Azure affecte l'emplacement de traitement. Les déploiements globaux peuvent traiter les invites et les réponses dans n'importe quelle zone géographique où le modèle est déployé, tandis que les déploiements DataZone limitent le traitement à la zone sélectionnée. Les données stockées restent dans la zone géographique désignée par le client.
• Microsoft documente que certaines fonctionnalités Azure avec état stockent des données, notamment des fichiers, des magasins de vecteurs, l'historique des messages de réponses, les threads des assistants, les entrées de traitement par lots et les complétions stockées.
• Microsoft documente que les clients approuvés peuvent modifier la surveillance des abus et que le portail Azure ou CLI peuvent afficher ContentLogging=false lorsque le stockage des données de surveillance des abus est désactivé.

Ce ne sont pas des détails de contour. Cela signifie que le routeur doit évaluer ensemble le point de terminaison, la fonctionnalité, l’approbation du compte et la région. Une étiquette à l'échelle du fournisseur telle que "ZDR activé" est trop grossière pour la politique de production.

Architecture de référence

Une passerelle d'IA multimodèle APIcompatible avec la rétention a besoin de cinq composants dans le chemin de requête :

1. Classificateur de requêtes : extrait la sensibilité des données, le contrat du locataire, les exigences régionales, l'utilisation des fonctionnalités, les entrées de fichiers, l'utilisation des outils et les autorisations de journalisation.
2. Résolveur de stratégie : mappe la requête à une stratégie de rétention canonique, généralement à partir du locataire, du projet, de l'environnement, de la clé API et des métadonnées de la charge de travail.
3. Registre des capacités du fournisseur : enregistre les capacités de rétention du fournisseur, du point de terminaison, du modèle, des fonctionnalités, de la région et du compte avec des preuves datées.
4. Évaluateur de politique : filtre les itinéraires candidats et renvoie soit un itinéraire approuvé, soit un refus de politique avec un code de motif.
5. Émetteur d'audit : enregistre l'itinéraire choisi, la stratégie correspondante, les hypothèses de capacité, la région, les indicateurs de stockage et le mode de journalisation du contenu.

Cette architecture sépare les décisions de rétention et de résidence du coût, de la latence et des solutions de secours. L'acheminement des coûts peut toujours avoir lieu, mais uniquement à l'intérieur de l'ensemble des itinéraires qui satisfont à la politique de rétention.

Définir une politique de conservation canonique

Commencez avec un objet de stratégie indépendant du fournisseur. Ne copiez pas la terminologie d'un fournisseur dans votre contrat interne. Votre politique interne doit décrire ce que la charge de travail est autorisée à faire, et non comment un fournisseur spécifique commercialise un contrôle.

{
  "policy_id": "support_no_retention_eu_v1",
  "max_content_retention": "none_after_response",
  "training_allowed": false,
  "human_review_allowed": false,
  "allowed_regions": ["EU"],
  "stateful_storage_allowed": false,
  "file_storage_allowed": false,
  "grounding_allowed": false,
  "batch_processing_allowed": false,
  "full_content_logging_allowed": false,
  "redacted_content_logging_allowed": true,
  "audit_level": "route_decision_with_provider_evidence"
}

Pour les charges de travail moins restreintes, utilisez une relaxation explicite plutôt que des champs manquants :

{
  "policy_id": "internal_analytics_standard_v1",
  "max_content_retention": "30_days",
  "training_allowed": false,
  "human_review_allowed": false,
  "allowed_regions": ["US", "EU"],
  "stateful_storage_allowed": true,
  "file_storage_allowed": true,
  "grounding_allowed": true,
  "batch_processing_allowed": true,
  "full_content_logging_allowed": false,
  "redacted_content_logging_allowed": true,
  "audit_level": "metadata_and_decision"
}

Les champs importants ne concernent pas seulement la durée de conservation. Les fonctionnalités avec état, les fichiers, la mise à la terre, le traitement par lots et le mode de journalisation affectent tous l'acceptabilité d'un itinéraire.

Créer le registre des capacités des fournisseurs

Le registre de capacités est la source de vérité du routeur. Il doit être conservé sous forme de configuration contrôlée et non dispersé via des adaptateurs de fournisseur.

Un enregistrement utile comprend :

• provider : fournisseur ou plateforme cloud.
• account_scope : organisation, projet, déploiement, abonnement ou locataire pour lequel un paramètre est approuvé.
• endpoint : chat, réponses, messages, lots, fichiers, assistants, intégrations, mise à la terre, magasin de vecteurs ou autre API surface.
• model_family et model_id facultatif : car l'éligibilité des modèles peut différer.
• region_mode : mondial, régional, zone de données, zone géographique désignée par le client ou équivalent spécifique au fournisseur.
• content_retention : pas de stockage après réponse, rétention de surveillance des abus, rétention de l'état de l'application, journaux dérivés de durée fixe ou inconnu.
• training_use : désactivé par défaut, opt-in ou inconnu.
• human_review : activé, modifié, désactivé ou inconnu.
• stateful_storage : indique si le point de terminaison ou la fonctionnalité stocke l'état de la conversation, les fichiers, les données vectorielles, les complétions ou les entrées par lots.
• feature_flags : mise à la terre, fichiers, outils, cache, sorties stockées, lots, assistants ou fonctionnalités équivalentes.
• evidence : nom du document source, URL, date de récupération et date de révision par le propriétaire.

Exemple :

{
  "capability_id": "azure-openai-gpt4o-datazone-chat-zdrlike-v3",
  "provider": "azure_openai",
  "account_scope": "prod-subscription-123",
  "endpoint": "chat_completions",
  "model_family": "gpt-4o",
  "region_mode": "datazone_eu",
  "content_retention": "abuse_monitoring_disabled_when_contentlogging_false",
  "training_use": "disabled_without_permission",
  "human_review": "modified_abuse_monitoring_approved",
  "stateful_storage": false,
  "features": {
    "files": false,
    "vector_store": false,
    "stored_completions": false,
    "grounding": false,
    "batch": false
  },
  "evidence": {
    "source": "provider_data_privacy_and_abuse_monitoring_docs",
    "retrieved_at": "2026-10-08",
    "review_owner": "security-architecture"
  }
}

La recommandation est de traiter l'inconnu comme un refus pour les charges de travail sensibles. Si un enregistrement de capacité ne comporte pas de champ de rétention, de mode régional ou d'éligibilité à une fonctionnalité, il ne doit pas satisfaire à des politiques strictes.

Classer la requête avant le routage

La classification doit avoir lieu avant la sélection du modèle. Un bon classificateur combine métadonnées statiques et inspection des requêtes :

• API Portée clé : locataire, équipe, environnement, application et type de charge de travail.
• Balises de contrat : non-rétention, contrôles de type HIPAA, données financières, données confidentielles du client ou internes uniquement.
• Type de charge utile : texte libre, document, image, référence de fichier, entrée d'intégration, résultat d'outil ou contexte récupéré.
• Utilisation des fonctionnalités : mise à la terre Web, téléchargement de fichiers, stockage de vecteurs, tâches par lots, historique des conversations stocké, appels d'outils ou stockage de réponses.
• Mode de journalisation : contenu complet autorisé, contenu rédigé autorisé, métadonnées uniquement ou aucun contenu du journal d'application.
• Conseils régionaux : emplacement de l'utilisateur, résidence des données du locataire, région du projet ou région de déploiement.

Ne vous fiez pas uniquement à la détection automatique des données sensibles. Utilisez la politique de charge de travail déclarée à partir de la clé ou du projet API comme source principale, puis utilisez des classificateurs pour renforcer la politique lorsque la charge utile contient des signaux de risque.

function resolvePolicy(request) {
  const base = policyForApiKey(request.apiKeyId);
  const tenant = tenantContractPolicy(request.tenantId);
  const features = detectRequestedFeatures(request);
  const sensitivity = classifyPayload(request);

  return strictestApplicablePolicy([base, tenant, features, sensitivity]);
}

En pratique, cela signifie qu'une clé de support client peut par défaut être sans conservation, tandis qu'une clé d'expérimentation interne peut permettre un routage plus large. Si la même clé de support tente de télécharger un fichier, la stratégie efficace doit inclure file_storage_allowed=false à moins qu'il n'existe une route compatible avec les fichiers approuvée.

Évaluer la stratégie avant le routage des coûts ou de la latence

L'évaluateur doit fonctionner comme un filtre. Il reçoit une politique, des fonctionnalités de demande et des itinéraires de fournisseurs candidats. Il renvoie uniquement les itinéraires qui satisfont à la politique.

function eligibleRoutes(request, policy, capabilities) {
  return capabilities.filter((route) => {
    if (!regionAllowed(route, policy.allowed_regions)) return false;
    if (!retentionAllowed(route, policy.max_content_retention)) return false;
    if (!trainingAllowed(route, policy.training_allowed)) return false;
    if (!humanReviewAllowed(route, policy.human_review_allowed)) return false;
    if (request.usesFiles && !policy.file_storage_allowed) return false;
    if (request.usesFiles && route.features.files !== true) return false;
    if (request.usesGrounding && !policy.grounding_allowed) return false;
    if (request.requiresState && !policy.stateful_storage_allowed) return false;
    if (route.content_retention === "unknown") return false;
    return true;
  });
}

function routeRequest(request) {
  const policy = resolvePolicy(request);
  const candidates = capabilityRegistry.findByModelIntent(request.modelIntent);
  const eligible = eligibleRoutes(request, policy, candidates);

  if (eligible.length === 0) {
    return deny("RETENTION_POLICY_NO_ELIGIBLE_ROUTE", policy.policy_id);
  }

  return chooseByCostLatencyAndHealth(eligible);
}

Cet ordre est important. Le routage de secours ne doit pas passer à un fournisseur non éligible lors d'une panne. Le routage par lots ne doit pas déplacer une demande de non-rétention vers un magasin de travaux asynchrone. La mise à la terre ne doit pas activer une fonctionnalité qui introduit des journaux dérivés lorsque la stratégie l'interdit.

Si votre plate-forme expose un multimodèle compatible OpenAI API, gardez la couche de compatibilité honnête : le même corps de requête peut être compilé vers différentes fonctionnalités natives du fournisseur. L'évaluateur de politique doit inspecter la requête compilée, pas seulement la forme SDK originale.

Bloquer explicitement les combinaisons de fonctionnalités à risque

La mise en œuvre la plus sûre consiste à créer des règles de refus explicites pour les combinaisons connues à haut risque. Exemples :

• NO_RETENTION + FILE_UPLOAD : refuser à moins que le point de terminaison de fichier spécifique et le paramètre de compte ne soient approuvés pour la stratégie.
• NO_RETENTION + VECTOR_STORE : refuser à moins que le magasin de vecteurs ne se trouve dans votre propre stockage contrôlé et que le fournisseur ne reçoive jamais l'état du fichier persistant.
• NO_RETENTION + STORED_RESPONSE : force la désactivation ou le refus des indicateurs de stockage de réponse si le point de terminaison ne peut pas désactiver le stockage.
• EU_ONLY + GLOBAL_DEPLOYMENT : refuser si le traitement peut avoir lieu en dehors de la région ou de la zone de données autorisée.
• NO_RETENTION + WEB_GROUNDING : refuser si la fonctionnalité de mise à la terre stocke les journaux de requêtes ou de contexte dérivés au-delà de la politique.
• METADATA_ONLY_LOGGING + DEBUG_TRACE : supprimez le contenu des invites et des achèvements des journaux et des traces des applications.
• ZDR_REQUIRED + STATEFUL_ASSISTANT_THREAD : refuser, sauf si la fonctionnalité est spécifiquement éligible dans le cadre des contrôles approuvés du compte.

Renvoyer des erreurs spécifiques. Un refus utile indique au développeur ce qui a échoué et quelles alternatives approuvées existent.

{
  "error": {
    "code": "RETENTION_POLICY_DENIED",
    "reason": "NO_RETENTION_POLICY_DISALLOWS_FILE_STORAGE",
    "policy_id": "support_no_retention_eu_v1",
    "requested_feature": "file_upload",
    "approved_alternatives": [
      "send extracted text without provider file storage",
      "use internal document retrieval with metadata-only provider call",
      "request policy approval for controlled file processing"
    ]
  }
}

Journalisation d'inférence séparée de la télémétrie opérationnelle

La politique de rétention ne doit pas forcer la passerelle à devenir aveugle. Vous pouvez généralement conserver la télémétrie opérationnelle sans stocker le contenu d'invite ou d'achèvement.

Pour les charges de travail strictes, préservez :

• ID de demande et ID de trace ;
• identifiants de locataire, de projet, de clé API et de charge de travail ;
• ID de stratégie et version de la stratégie ;
• fournisseur, point de terminaison, modèle, déploiement et région utilisés ;
• indicateurs de fonctionnalités demandés et autorisés ;
• codes de motif de décision ;
• nombre de jetons, latence, code d'état et métadonnées de coût ;
• hachages ou empreintes digitales stables pour la déduplication, si approuvés par la stratégie.

Supprimer ou expurger :

• invites brutes ;
• achèvements bruts ;
• contenu du fichier téléchargé ;
• résultats de l'outil contenant des données client ;
• contexte récupéré à partir de systèmes sensibles ;
• charges utiles de débogage du fournisseur qui dupliquent le contenu.

C'est ici que le routage de rétention se connecte à l'observabilité LLM indépendante du fournisseur. L'observabilité devrait prouver ce qui s'est passé sans étendre l'ensemble des systèmes qui conservent le contenu sensible.

Émettre des preuves d'audit pour chaque décision

Un enregistrement d'audit doit expliquer pourquoi un itinéraire a été autorisé ou refusé. Il n'a pas besoin d'un contenu complet pour être utile.

{
  "request_id": "req_01J...",
  "tenant_id": "tenant_42",
  "policy_id": "support_no_retention_eu_v1",
  "policy_version": 7,
  "decision": "allow",
  "provider": "anthropic",
  "endpoint": "messages",
  "model_family": "claude",
  "region_mode": "approved_region",
  "features": {
    "files": false,
    "grounding": false,
    "stateful_storage": false,
    "batch": false
  },
  "logging_mode": "metadata_only",
  "capability_record_id": "anthropic-claude-messages-zdr-v5",
  "capability_evidence_date": "2026-10-08",
  "reason_codes": [
    "POLICY_MATCHED_NO_RETENTION",
    "REGION_ALLOWED",
    "STATELESS_ENDPOINT",
    "CONTENT_LOGGING_SUPPRESSED"
  ]
}

Pour les demandes refusées, conservez la même structure avec decision=deny et les codes de motif tels que REGION_NOT_ALLOWED, GROUNDING_RETENTION_EXCEEDS_POLICY ou STATEFUL_STORAGE_NOT_ALLOWED.

Utiliser les tests de contrat pour les règles de rétention

Le routage de rétention doit avoir des tests automatisés. Les tests importants ne sont pas seulement des tests unitaires pour des fournisseurs individuels ; il s'agit de tests contractuels pour le comportement des politiques entre les combinaisons de fournisseurs.

Les cas de test à forte valeur ajoutée incluent :

• La politique de non-rétention et le téléchargement de fichiers doivent être refusés à moins qu'il n'existe une route spécifique approuvée compatible avec les fichiers.
• La politique européenne uniquement et le déploiement mondial devraient refuser même lorsque le modèle est par ailleurs disponible.
• La politique de rétention zéro et l'historique des conversations stocké devraient refuser ou forcer la désactivation du stockage lorsqu'ils sont pris en charge.
• La fonctionnalité de mise à la terre avec conservation des journaux dérivés devrait être refusée en vertu d'une politique de non-rétention.
• La politique de journalisation des métadonnées uniquement doit supprimer le contenu des invites et des complétions des traces, des journaux et des rapports d'erreurs.
• L'enregistrement de capacité du fournisseur avec une rétention inconnue devrait être refusé pour les charges de travail réglementées.
• Le repli après une panne du fournisseur doit rester dans l'ensemble de routes éligibles.
• Le traitement par lots doit être refusé lorsque le point de terminaison du lot stocke les fichiers d'entrée plus longtemps que la politique ne le permet.

Testez également la dérive. Lorsqu'un enregistrement de capacité est modifié, le système doit indiquer quelles politiques et routes sont affectées avant que la modification n'atteigne la production.

Propriété opérationnelle

Le plus difficile n'est pas d'écrire le premier évaluateur. Il maintient le registre à jour et empêche les exceptions non documentées.

Attribuer des propriétaires à :

• cadence de révision de la documentation du fournisseur ;
• état d'approbation pour les contrôles au niveau du compte tels que la surveillance modifiée des abus ou la conservation zéro des données ;
• inventaire de déploiement régional ;
• éligibilité aux fonctionnalités pour les fichiers, les magasins de vecteurs, les réponses de mise à la terre, par lots et stockées ;
• workflow d'exception de politique ;
• conservation des enregistrements d'audit et contrôle d'accès ;
• Messages d'erreur destinés aux développeurs et alternatives approuvées.

Chaque enregistrement de capacité doit avoir une date de révision. S'il expire, des politiques strictes devraient cesser de lui faire confiance ou exiger une approbation manuelle. La documentation du fournisseur et le comportement des fonctionnalités changent trop souvent pour qu'il s'agisse d'une configuration statique.

Compromis

Un routeur de rétention strict réduit les choix de modèles disponibles. Certains modèles d'aperçu, API avec état, outils de mise à la terre et flux de travail de fichiers ne seront pas disponibles pour les charges de travail sensibles. C'est l'intérêt du contrôle, mais les équipes produit ont besoin d'alternatives claires.

Le routage régional peut augmenter la latence ou les coûts lorsque le déploiement le plus rapide est mondial mais que la charge de travail nécessite une zone géographique ou une zone de données spécifique. Rendez cela visible dans la télémétrie afin que les équipes comprennent pourquoi une requête a utilisé un itinéraire plus coûteux ou plus lent.

Le blocage des fonctionnalités avec état peut pousser les équipes à créer leur propre couche de mémoire. C'est peut-être la bonne architecture, mais elle nécessite toujours une politique de stockage, des flux de travail de suppression, un chiffrement, un contrôle d'accès et des journaux d'audit. Le déplacement de l'état hors du fournisseur ne supprime pas le travail de gouvernance.

La rédaction d'invite et d'achèvement protège les données sensibles, mais elle affaiblit le débogage et l'évaluation de la qualité. Utilisez des métadonnées de requête reproductibles, des appareils de test déterministes, un échantillonnage contrôlé pour les charges de travail autorisées et un accès sécurisé documenté lorsque la politique le permet.

Recommandations

• Appliquer la rétention et la résidence avant le routage du modèle, et non comme contrôle post-traitement.
• Modéliser les capacités au niveau du fournisseur, du point de terminaison, des fonctionnalités, de la région et de l'approbation du compte.
• Utilisez un comportement de refus par défaut pour les charges de travail réglementées ou liées à un contrat client.
• Traitez le téléchargement de fichiers, les magasins de vecteurs, la mise à la terre du Web, le traitement par lots et l'historique des conversations stocké comme des dimensions de stratégie distinctes.
• Conservez la télémétrie opérationnelle même lorsque le contenu des invites et des complétions doit être supprimé.
• Émettez des enregistrements d'audit qui incluent la stratégie, l'itinéraire, les preuves de capacité, la région, les indicateurs de stockage et les codes de motif.
• Écrivez des tests de contrat pour les combinaisons de fonctionnalités à haut risque et le comportement de secours.

Prédiction : le routage de rétention deviendra une couche de passerelle standard

Il est probable que le routage de rétention devienne une couche standard dans les plates-formes LLM d'entreprise, à l'instar des limites de débit, des contrôles budgétaires et de l'observabilité. À mesure que les fournisseurs ajoutent davantage d'outils avec état, d'options de mise à la terre, de caches, de fichiers, d'agents et de fonctionnalités de mémoire gérée, la route sécurisée dépendra moins du nom du modèle et davantage du chemin d'exécution complet.

Il s'agit d'une prédiction, pas d'une exigence universelle actuelle. L'exigence actuelle est plus simple : si votre équipe ne promet aucune rétention, aucun traitement régional, aucune utilisation de formation ou aucun examen humain, votre passerelle a besoin de suffisamment de logique politique et de preuves pour prouver que chaque demande a respecté ces contraintes.

Conclusion exploitable

Construisez le routeur de rétention en tant que porte d'entrée politique avant la sélection du fournisseur. Définissez une politique de rétention canonique, classez chaque demande avant le routage, maintenez un registre de capacités de fournisseur daté, refusez les combinaisons dangereuses par défaut et enregistrez les preuves d'audit sans conserver le contenu sensible.

L'objectif de conception n'est pas de trouver un fournisseur toujours sûr. L'objectif est de prouver qu'une requête spécifique, utilisant un point de terminaison et un ensemble de fonctionnalités spécifiques, sous un compte et une région spécifiques, satisfaisait à la stratégie avant d'être envoyée.

Lecture connexe

• Conception d'observabilité LLM indépendante du fournisseur