Un workflow d'approbation de modèle d'IA est la porte de validation qui décide si une route de modèle est autorisée à gérer le trafic de production. La route ne se limite pas au nom du modèle. Elle englobe le fournisseur, la famille de points de terminaison, la version du prompt, les autorisations des outils, le comportement de repli, les paramètres de journalisation, le garde-fou des coûts, le propriétaire et le chemin de restauration qui s'exécuteront derrière une fonctionnalité produit.
C'est pourquoi l'approbation doit avoir lieu avant la mise en production d'une nouvelle route. Un modèle peut sembler sûr lors d'une démo et pourtant échouer en production parce que la mauvaise version du prompt est déployée, qu'un mécanisme de repli envoie du trafic vers un fournisseur non examiné, qu'un appel d'outil obtient trop d'autorité, qu'un paramètre de journalisation stocke les charges utiles plus longtemps que prévu ou que le service financier ne peut pas rapprocher les dépenses après le déploiement.
Utilisez ce workflow d'approbation de modèle d'IA pour transformer une modification de modèle en un dossier de preuves appartenant à l'acheteur. Le résultat doit être suffisamment clair pour que l'ingénierie, la sécurité, les achats, la finance et le produit puissent répondre plus tard à la même question : qu'est-ce qui a été approuvé, pourquoi cela a-t-il été approuvé, quelles preuves ont été examinées et qu'est-ce qui déclenche un nouvel examen ?
Pour les acheteurs de Flatkey, cet examen s'articule autour de la route de la passerelle. Le site public actuel de Flatkey positionne le produit comme une passerelle API d'IA unique pour l'accès aux modèles, le routage, la facturation, l'analyse de l'utilisation et les contrôles opérationnels, avec une seule clé API, une seule URL de base et un seul tableau de bord. Cela fait de la passerelle un endroit utile pour centraliser les preuves relatives aux routes. Cela ne supprime pas la nécessité de vérifier la journalisation spécifique au compte, les conditions du fournisseur, le comportement du modèle, le traitement des données et les responsabilités d'approbation avant le lancement en production.
Ce que le workflow approuve
Un workflow d'approbation de modèle d'IA doit approuver une route, pas le slogan d'un fournisseur. Le dossier d'approbation doit identifier le comportement exact en production qui existera après la mise en production.
| Surface de la route | Question d'approbation | Preuves à conserver | Bloqueur de mise en production |
|---|---|---|---|
| Cas d'utilisation | Quelle tâche utilisateur ou système cette route effectuera-t-elle ? | Note de produit, classification des données, impact sur l'utilisateur, cas d'abus | La tâche est vague ou la responsabilité n'est pas claire |
| Modèle et fournisseur | Quels modèle, fournisseur, point de terminaison, région et chemin de compte serviront le trafic ? | Documentation du fournisseur, statut du modèle/version, configuration de la route, liste de repli | Un mécanisme de repli peut sélectionner un modèle non approuvé |
| Politique de prompt et d'outil | Quelles instructions, outils, schémas et autorisations sont autorisés ? | Version du prompt, manifeste de l'outil, schéma typé, revue de code | L'outil peut effectuer une action irréversible sans contrôle |
| Pack d'évaluation | Quels tests prouvent que la route est suffisamment bonne pour ce cas d'utilisation ? | Jeu de données d'évaluation, métriques, seuils, notes de l'examinateur, exemples d'échec | Il n'y a pas de seuil de réussite/échec spécifique à la tâche |
| Contrôles de sécurité et d'abus | Comment sont gérés l'injection de prompt, les sorties non sécurisées, les fuites de données et le contournement des politiques ? | Cas de red-teaming, paramètres de filtre, tests de refus, alertes de surveillance | Un échec connu n'a ni atténuation ni propriétaire |
| Données et journalisation | Quels prompts, sorties, métadonnées, traces et lignes de facturation sont stockés ? | Cartographie du flux de données, échantillon de journal, classe de rétention, test de rédaction | Le stockage des charges utiles brutes n'est pas clair ou est illimité |
| Coût et capacité | Quelles dépenses, quotas, limites de taux, délais d'attente et comportements de repli sont autorisés ? | Limite budgétaire, échantillon d'utilisation, test de charge, propriétaire financier | Un mode de défaillance peut créer des dépenses incontrôlées |
| Déploiement et restauration | Comment le trafic démarrera-t-il, s'étendra-t-il, sera-t-il mis en pause et restauré ? | Indicateur de fonctionnalité, plan de déploiement canary, commande de restauration, contact en cas d'incident | La restauration dépend d'une estimation manuelle |
| Déclencheur de renouvellement | Quel changement impose une nouvelle approbation ? | Date de révision, surveillance de l'obsolescence du modèle, politique de changement de route | Personne n'est responsable de la dérive après le lancement |
Le point clé : l'approbation n'est pas une réunion. L'approbation est un ensemble de preuves associé à un contrôle de route.
Utilisez un cadre de cycle de vie, pas une simple checklist
Le AI Risk Management Framework du NIST est un cadre pratique car il organise le travail autour des axes Gouverner, Cartographier, Mesurer et Gérer. Cela correspond parfaitement à un workflow d'approbation de modèle d'IA :
| Fonction de l'AI RMF | Traduction pour l'approbation de route |
|---|---|
| Gouverner | Assigner le propriétaire de la route, le propriétaire du risque, le propriétaire financier, le réviseur de sécurité, la politique d'approbation et les règles de mise hors service |
| Cartographier | Décrire le cas d'utilisation, les utilisateurs, les données, le fournisseur en amont, les limites du modèle, les dépendances de la route et l'impact commercial |
| Mesurer | Exécuter des évaluations fonctionnelles, des tests contradictoires, des contrôles de sécurité, des tests de coût, des tests de latence et des contrôles d'observabilité |
| Gérer | Approuver, déployer, surveiller, mettre en pause, renouveler ou mettre hors service la route sur la base de preuves |
Le Generative AI Profile du NIST est également important car les systèmes génératifs introduisent des risques que les examens de changement d'API ordinaires omettent souvent : l'injection de prompt, l'hallucination, l'exposition de données, l'expansion de capacités non sécurisées, la dérive du modèle et l'utilisation abusive en aval. Considérez ce cadre comme un moyen de structurer les décisions, et non comme un substitut à vos propres preuves.
Checklist du workflow d'approbation de modèle d'IA
Utilisez cette checklist pour chaque nouvelle route de modèle, changement de prompt important, modification des autorisations d'outil, repli de fournisseur ou migration de point de terminaison.
- Définir la route.
Enregistrez l'ID de la route, le propriétaire, la fonctionnalité produit, l'environnement, la famille de points de terminaison, le modèle principal, les modèles de repli autorisés, les comptes de fournisseur, la version du prompt, le manifeste de l'outil, les classes de données et le modèle de trafic attendu.
- Classifier le cas d'utilisation.
Déterminez si la route concerne des données client, des données d'employés, des workflows réglementés, des décisions financières, des décisions de support, un examen juridique, l'exécution de code, des actions externes ou du contenu sensible en matière de sécurité. Une route de résumé et un agent de remboursement autonome ne devraient pas partager le même niveau d'approbation.
- Rassemblez les preuves relatives au modèle et au fournisseur.
Conservez les documents du modèle du fournisseur, les fiches de modèle ou les fiches système lorsqu'elles sont disponibles, le statut de dépréciation, les documents sur le filtrage de contenu, les conditions de traitement des données, les contraintes régionales et les paramètres au niveau du compte. Les directives de Google sur les versions de modèles rappellent de noter si un modèle est stable, en préversion, expérimental, déprécié ou retiré. N'approuvez pas seulement un nom d'affichage convivial.
- Gérez les versions des prompts et des outils.
Les directives sur les prompts d'OpenAI recommandent des prompts de production gérés par le code, des entrées typées, une revue de code, des tests, des vérifications d'évaluation et un déploiement progressif. C'est le bon modèle pour un workflow d'approbation de modèle d'IA appartenant à l'acheteur : le comportement des prompts doit suivre le même processus de publication que le comportement du code.
- Créez des évaluations spécifiques aux tâches.
Les meilleures pratiques d'évaluation d'OpenAI présentent les évaluations comme des tests structurés pour la précision, la performance et la fiabilité dans les systèmes d'IA variables. L'approbation devrait exiger un ensemble d'évaluations spécifiques à la tâche, et non une simple capture d'écran d'un benchmark générique. Incluez des cas typiques, des cas limites, des cas contradictoires, des cas multilingues, des cas d'outils et des exemples d'échecs connus.
- Effectuez des tests de sécurité et d'utilisation abusive.
Les directives de l'OWASP sur l'injection de prompt LLM01 distinguent l'injection de prompt directe et indirecte. Ajoutez des tests pour les deux. Si la route peut appeler des outils, récupérer des documents, écrire des enregistrements, envoyer des messages ou exécuter du code, testez l'autorité excessive, la manipulation des arguments d'outils, les conflits de prompt système et les instructions cachées dans le contenu récupéré.
- Vérifiez la rétention des données et la journalisation.
Déterminez si les prompts, les sorties, les arguments d'outils, les fichiers, les fragments récupérés, les traces, les métadonnées de requête, les événements d'audit et les lignes de facturation sont stockés. Utilisez la checklist de rétention des données de l'API d'IA pour séparer le contenu de la charge utile des métadonnées, et utilisez les journaux d'audit pour l'utilisation de l'API d'IA pour prouver qui a modifié les clés, les routes, la journalisation, les quotas et la politique du modèle.
- Définissez les limites de coût, de fiabilité et de repli.
Enregistrez les budgets de jetons, les budgets de requêtes, les limites de quota, la stratégie de timeout, la politique de nouvelle tentative, la liste des modèles de repli, le disjoncteur et les seuils d'alerte. Un repli qui déplace discrètement le trafic vers un modèle plus puissant, plus cher ou moins examiné est un échec de gouvernance, même si l'expérience utilisateur semble correcte.
- Approuvez le déploiement progressif et le renouvellement.
Déployez via un canary, un feature flag, une pondération de route ou une liste d'autorisation de locataires. Définissez la vérification de la première heure, la vérification du premier jour, la vérification de la première semaine et le déclencheur de renouvellement. Réapprouvez lorsque la version du modèle change, que les conditions du fournisseur changent, que le comportement du prompt change, que les autorisations des outils changent, que la journalisation change, que le profil de coût change ou que la population d'utilisateurs change.
Constituez le dossier d'approbation
Le workflow d'approbation de modèle d'IA le plus robuste laisse derrière lui un dossier d'approbation compact. Il doit être suffisamment court pour être examiné, mais assez spécifique pour être audité.
| Champ du paquet | Réponse requise | Artefact de preuve | Déclencheur de renouvellement |
|---|---|---|---|
| ID de la route | ID stable pour cette route de production | Configuration de la route de la passerelle ou demande de modification | Renommage, fusion ou division de la route |
| Propriétaire métier | Qui accepte le risque produit ? | Enregistrement d'approbation | Changement de propriétaire |
| Propriétaire technique | Qui peut mettre en pause ou effectuer un rollback ? | Document d'astreinte, runbook | Changement d'équipe ou d'astreinte |
| Classe de données | Quelles données peuvent entrer dans les prompts, les outils, les fichiers et la recherche ? | Cartographie du flux de données, classe de charge utile d'exemple | Nouvelle source de données ou nouveau segment de clientèle |
| Liste des modèles | Modèle principal, modèles de secours, famille de points de terminaison, compte fournisseur | Documents du modèle/de la version, relecture de la route | Nouveau modèle, secours, point de terminaison ou fournisseur |
| Version du prompt | Constructeur de prompt actuel, schéma et source d'instruction système | Commit Git ou configuration révisée | Changement de prompt, de schéma ou d'outil |
| Pack d'évaluation | Jeu de données, métriques, seuils, échecs, approbation du réviseur | Rapport d'évaluation | Changement de modèle, de prompt, de données ou de distribution des utilisateurs |
| Contrôles de sécurité | Filtres de contenu, politique de refus, tests d'injection de prompt, escalade humaine | Rapport de test et paramètres de filtre | Changement de filtre, de politique ou de classification des risques |
| Contrôles des outils | Outils autorisés, portées, arguments, exigences d'approbation | Manifeste de l'outil et test d'autorisation | Changement d'autorisation d'outil ou d'effet de bord |
| Journaux et rétention | Champs de métadonnées, politique de charge utile, classe de rétention, comportement de rédaction | Échantillon de journal et relecture de la rétention | Changement d'exportation, d'observabilité ou de rétention |
| Contrôles des coûts | Budget, quota, limite de débit, alerte, propriétaire de la facture | Échantillon d'utilisation et seuil de coût | Changement de tarification, de trafic ou de mix de modèles |
| Plan de déploiement | Taille du canary, méthode de rollback, conditions d'arrêt | Indicateur de fonctionnalité ou enregistrement de poids de la route | Expansion de la cohorte de déploiement |
| Surveillance post-production | Métrique, alertes, cadence de révision, chemin d'incident | Capture d'écran du tableau de bord ou relecture de l'API | Alerte manquée, incident ou dérive |
Ce paquet est également un atout pour les achats. Il rend l'examen des fournisseurs concret : au lieu de demander si un fournisseur est « prêt pour l'entreprise », l'acheteur demande quelles preuves démontrent que cette route est prête.
Tests de pré-production avant la mise en service d'une route
L'ensemble de tests doit correspondre au cas d'utilisation approuvé. Une route qui se contente d'étiqueter des tickets de support nécessite des tests différents d'une route qui écrit du SQL, émet des remboursements, modifie du code ou résume des notes médicales.
| Piste de test | Quoi tester | Preuve à conserver | Condition d'arrêt |
|---|---|---|---|
| Correction fonctionnelle | Résultats attendus sur les tâches normales | Score d'évaluation, exemples d'échecs, notes du réviseur | Taux de réussite inférieur au seuil |
| Hiérarchie des instructions | Prompt système vs prompt utilisateur conflictuel | Cas contradictoires | Le prompt utilisateur outrepasse la politique système |
| Injection de prompt | Injection directe et indirecte dans le texte utilisateur, les documents récupérés, les fichiers et les sorties d'outils | Transcription de l'équipe rouge (red team) | Une instruction cachée modifie la tâche |
| Autorité de l'outil | Sélection de l'outil, extraction d'arguments, portée et effets de bord | Journaux d'appels d'outils et cas de refus | L'outil peut effectuer une action non approuvée |
| Fuite de données | Secrets, données privées, identifiants clients et exposition du contexte récupéré | Test de fixture | Une fixture sensible apparaît dans la sortie ou les journaux |
| Filtrage de contenu | Catégories de politique d'entrée/sortie et seuils de gravité | Configuration du filtre et cas bloqués | La catégorie requise n'est pas surveillée ou bloquée |
| Coût et quota | Budget de jetons, limite de débit, dépenses de secours, pic d'abus | Lignes d'utilisation et test d'alerte | Les dépenses peuvent augmenter sans alerte du propriétaire |
| Fiabilité | Délai d'attente, nouvelle tentative, streaming, secours, panne du fournisseur, disjoncteur | Exercice de panne | Le trafic utilisateur continue de réessayer jusqu'à l'échec |
| Auditabilité | Changement de clé, changement de route, changement de prompt, accès aux journaux, changement de quota | Échantillon d'événement d'audit | Le changement ne peut pas être lié à un acteur et à une heure |
| Rollback | Désactiver la route, revenir au prompt précédent, supprimer le secours, restaurer le modèle antérieur | Exercice de rollback | Le rollback ne peut pas être effectué rapidement |
La documentation sur le filtrage de contenu d'Azure OpenAI de Microsoft est utile pour rappeler que les filtres ont des catégories, des niveaux de gravité, des choix de configuration et des comportements facultatifs. Votre enregistrement d'approbation doit capturer les paramètres réels utilisés pour la route, et non seulement l'existence d'une fonctionnalité de sécurité quelque part dans la pile.
Exemple de politique de route
L'approbation doit produire une politique de route que les ingénieurs peuvent mettre en œuvre et que les réviseurs peuvent inspecter. Le schéma exact dépend de votre passerelle, mais la forme doit être explicite.
route_id: support-summary-prod
owner:
product: support_ops
engineering: ai_platform
security: appsec
finance: finops
use_case:
task: summarize_support_threads
data_class: customer_support_confidential
allowed_environments: [production]
models:
primary: approved_summary_model_2026_07
fallbacks:
- approved_summary_backup_2026_07
denied:
- any_preview_model_without_reapproval
prompt:
source: app/prompts/support_summary.ts
reviewed_commit: 8f3c2d1
schema_required: true
tools:
allowed:
- read_ticket_metadata
denied:
- refund_customer
- send_email
logging:
payload_storage: disabled
metadata_retention_class: ops_metadata_90d
audit_events:
- route_change
- model_change
- prompt_change
- key_rotation
controls:
max_input_tokens: 8000
max_output_tokens: 700
monthly_budget_usd: 500
fallback_requires_same_data_policy: true
evals:
pack: support_summary_eval_2026_07
min_pass_rate: 0.95
required_tests:
- prompt_injection
- sensitive_data_fixture
- tool_scope
rollout:
canary_percent: 5
expand_after_hours: 24
rollback: disable_route_weight
renewal:
review_by: 2026-10-04
triggers:
- model_version_change
- prompt_change
- new_tool
- logging_change
- provider_terms_changeC'est là que le workflow d'approbation de modèle d'IA devient opérationnel. Si une configuration de route ne peut pas exprimer la décision, l'approbation est trop abstraite.
Comment cela s'intègre avec Flatkey
Flatkey peut servir de surface opérationnelle pour ce workflow, car la surface publique du produit est centrée sur l'accès unifié aux modèles, le routage, la facturation, l'analyse de l'utilisation, les limites de quota et un tableau de bord unique pour les clés et le routage. La page d'accueil actuelle montre également un modèle de requête compatible avec OpenAI utilisant https://router.flatkey.ai/v1/chat/completions, tandis que les pages de tarification et de modèles décrivent le solde prépayé, l'analyse de l'utilisation, la tarification des modèles et la couverture des fournisseurs.
Utilisez Flatkey comme surface de preuve de la passerelle, puis vérifiez ces détails spécifiques au compte avant l'approbation :
- Quels modèles et fournisseurs sont activés pour la route.
- Quelle famille de points de terminaison chaque route utilise.
- Quels modèles de secours sont autorisés et refusés.
- Quelles clés d'API, équipes, projets et environnements peuvent appeler la route.
- Quels contrôles d'utilisation, de coût et de quota sont disponibles pour le compte de l'acheteur.
- Quelles métadonnées de requête, événements d'audit et enregistrements de facturation sont visibles.
- Si les prompts bruts, les sorties, les arguments d'outils, les fichiers ou les traces sont stockés.
- Si les modifications de route, de clé, de quota et de journalisation produisent des preuves vérifiables.
Ne transformez pas cela en une déclaration de confiance générique. Une passerelle peut réduire la prolifération des fournisseurs et centraliser les preuves, mais l'acheteur reste propriétaire du workflow d'approbation du modèle d'IA.
Questions à poser au service des achats
Les équipes des achats et de la sécurité doivent demander des preuves qui correspondent à la route, et non seulement un aperçu de la plateforme.
| Question | Bonne preuve | Preuve faible |
|---|---|---|
| Quel modèle desservira cette route ? | Lecture de la route avec les modèles principaux et de secours | « Nous utilisons les meilleurs modèles du marché » |
| Que se passe-t-il si le modèle échoue ? | Politique de délai d'attente, de nouvelle tentative, de secours et de restauration | « La passerelle s'en occupe » |
| Quelles données sont journalisées ? | Exemple d'événement de métadonnées et politique de charge utile | « Nous avons des journaux » |
| Qui peut modifier la route ? | Liste des rôles et exemple d'événement d'audit | « Les administrateurs peuvent le gérer » |
| Quelles évaluations ont été réussies ? | Jeu de données, seuil, échecs et notes de l'examinateur | « Ça a fonctionné lors des tests » |
| Quels contrôles de sécurité sont actifs ? | Paramètres de filtre, tests de refus, cas d'injection de prompt | « La sécurité est activée » |
| Qu'est-ce que le service financier examine ? | Lignes d'utilisation, aperçu de la tarification, alerte budgétaire, chemin de facturation | « Il y a un tableau de bord » |
| Qu'est-ce qui force une nouvelle approbation ? | Liste écrite des déclencheurs et propriétaire | « Nous révisons lorsque c'est nécessaire » |
Associez cette revue à la checklist de la passerelle API d'IA d'entreprise pour les contrôles au niveau de la passerelle, à l'évaluation des risques des fournisseurs d'API d'IA pour les limites des fournisseurs en amont, et aux journaux d'audit pour l'utilisation de l'API d'IA pour des preuves de changement durables.
Renouvellement et démantèlement
Le plus grand échec d'approbation est la dérive. La route qui a été approuvée en juillet peut ne pas être celle qui est en cours d'exécution en octobre.
Définissez des déclencheurs de renouvellement avant le lancement :
- Une version de modèle devient obsolète, retirée, en préversion uniquement ou remplacée.
- Un fournisseur modifie la gestion des données, le filtrage de contenu, la tarification, la région ou le support des fonctionnalités.
- Un modèle de secours, une pondération de route, une famille de points de terminaison ou un compte fournisseur change.
- Un prompt, un schéma, une source de récupération, une instruction système ou une autorisation d'outil change.
- Un nouveau groupe d'utilisateurs, une nouvelle catégorie de clients, une nouvelle zone géographique ou une nouvelle classe de données commence à utiliser la route.
- Une alerte de surveillance montre une dérive de la qualité, de la sécurité, de la latence, du coût ou des abus.
- Un incident, une escalade de support, une plainte client ou une conclusion du service des achats concerne la route.
Le démantèlement devrait faire partie du même workflow d'approbation de modèle d'IA. Lorsqu'une route est retirée, enregistrez la route de remplacement, la date de drainage du trafic, les clés désactivées, les secrets supprimés, les journaux conservés, la clôture de la facturation et l'approbation finale du propriétaire.
FAQ
Qu'est-ce qu'un workflow d'approbation de modèle d'IA ?
Un workflow d'approbation de modèle d'IA est le processus de gouvernance qui décide si une route de modèle peut gérer le trafic de production. Il enregistre le cas d'utilisation, le chemin du modèle/fournisseur, la politique de prompt et d'outils, les résultats d'évaluation, les contrôles de sécurité, le comportement de journalisation, les garde-fous de coûts, le plan de déploiement et les déclencheurs de renouvellement.
Qui devrait approuver une nouvelle route de modèle d'IA ?
Au minimum, l'approbation doit inclure le propriétaire du produit, le propriétaire technique, le réviseur de la sécurité ou des risques, et le propriétaire des finances ou des opérations. Les routes à plus haut risque peuvent également nécessiter un examen juridique, des achats, de la confidentialité, du support ou de la direction.
Une carte de modèle est-elle suffisante pour l'approbation ?
Non. Une carte de modèle ou une carte système est une preuve utile, mais elle ne prouve pas que votre prompt, vos outils, votre solution de repli, votre journalisation, votre flux de données, vos contrôles de coûts et votre comportement de déploiement sont sûrs pour votre cas d'utilisation. La route nécessite toujours son propre dossier d'approbation.
À quelle fréquence les approbations de modèles doivent-elles être examinées ?
La cadence d'examen dépend du risque, mais chaque route doit avoir des déclencheurs de renouvellement. Réapprouvez lorsque la version du modèle, le fournisseur, le prompt, les autorisations des outils, la journalisation, la classe de données, la solution de repli, le profil de coût ou la population d'utilisateurs changent.
Comment une passerelle d'IA aide-t-elle à l'approbation des modèles ?
Une passerelle d'IA peut centraliser l'accès aux modèles, la politique de routage, les clés, l'utilisation, les coûts, les quotas et les preuves d'audit. Elle ne remplace pas la gouvernance de l'acheteur. Utilisez la passerelle comme surface de contrôle et de preuve, puis vérifiez le comportement spécifique au compte.
Conclusion
Un workflow d'approbation de modèle d'IA devrait rendre les changements de modèle en production examinables avant qu'ils ne deviennent des incidents. Approuvez les routes, pas des noms de modèles vagues. Conservez le fichier de preuves à proximité de la passerelle, exigez des évaluations spécifiques aux tâches, testez l'injection de prompt et l'autorité des outils, vérifiez la journalisation et les contrôles de coûts, et définissez des déclencheurs de renouvellement avant la mise en ligne de la première requête. Lorsque vous êtes prêt à centraliser l'accès aux modèles, le routage, l'utilisation et la facturation derrière une seule passerelle, consultez les tarifs et le catalogue de modèles actuels de Flatkey, puis obtenez une clé.
