Un dossier de preuves d'approvisionnement pour une passerelle IA devrait rendre l'approbation reproductible. Ce n'est pas un dossier de déclarations du fournisseur. C'est la preuve, détenue par l'acheteur, que la sécurité, le service juridique, l'ingénierie de la plateforme, la finance et le responsable métier ont examiné le même comportement de la passerelle avant que le trafic ne la traverse.
C'est important car une passerelle IA se situe entre vos applications et les fournisseurs de modèles. Elle peut affecter les clés, les routes, l'accès aux fournisseurs, la facturation, le traitement des prompts et des réponses, les journaux, les quotas, le comportement de repli et la réponse aux incidents. Si le dossier d'approbation indique seulement « page de confiance examinée », le prochain renouvellement, audit, panne ou question sur les données repartira de zéro.
Flatkey est conçue pour les équipes qui souhaitent une surface de passerelle API IA unique pour l'accès aux modèles, le routage, la facturation, l'analyse de l'utilisation et les contrôles opérationnels. Avant d'approuver une passerelle, y compris Flatkey, sauvegardez des preuves datées qui montrent ce qui a été examiné, qui l'a accepté, quelles hypothèses nécessitent encore une preuve au niveau du compte, et ce qui devrait déclencher une révision pour le renouvellement.
Le dossier de preuves d'approvisionnement pour une passerelle IA en un coup d'œil
Utilisez ce tableau comme première page du dossier. Le nom du fichier doit inclure le fournisseur, l'environnement, le responsable métier, la date d'approbation et la date de renouvellement.
| Fichier de preuve | À sauvegarder avant l'approbation | Propriétaire | Déclencheur de renouvellement |
|---|---|---|---|
| Identité du fournisseur | Entité juridique, contact du support, contrepartie contractuelle, conditions actuelles, politique de confidentialité, politique de remboursement et pages SLA | Approvisionnement et service juridique | Changement d'entité, de conditions, de politique de confidentialité, de paiement ou de SLA |
| Périmètre de la passerelle | Ce que la passerelle couvrira : familles de points de terminaison, applications, environnements, fournisseurs de modèles, alias de modèles et classes de données | Ingénierie de la plateforme | Nouvelle application, nouvelle famille de points de terminaison, nouveau fournisseur, charge de travail réglementée |
| Traitement des données | Politique de confidentialité, DPA ou conditions de données, paramètres de rétention, politique de charge utile des journaux, conditions de transmission au fournisseur et contrôles de rédaction | Sécurité et service juridique | Changement dans la journalisation des prompts/réponses, demande ZDR, nouvelle catégorie de données |
| Contrôles d'accès | Propriétaires des clés, processus de création de clés, calendrier de rotation, procédure de départ, comptes de service et limites du moindre privilège | Sécurité et plateforme | Nouvelle équipe, clé partagée découverte, départ d'un propriétaire, rotation d'une clé de production |
| Audit et journaux | Champs d'ID de requête, exportations d'utilisation, attribution du propriétaire, champs de facturation, enregistrements d'erreurs et limites de rétention | Sécurité et finance | Demande d'audit, incident, propriétaire de coût manquant, changement de champ de journal |
| Facturation et quotas | Page de tarification actuelle, conditions de prépaiement ou de facturation, limites de quota, politique de recharge, processus de remboursement et propriétaire du budget | Finance et opérations | Changement de prix, nouvelle classe de modèle, épuisement du crédit, problème de facturation |
| Fiabilité | Page de statut ou processus d'incident, SLA, clauses de maintenance, politique de repli, test de santé de la route et propriétaire du rollback | Ingénierie de la plateforme | Panne, changement de route du fournisseur, latence dégradée, échec du test de fumée |
| Approbation finale | Note d'approbation, risques ouverts, exceptions, transcription des tests, cas d'utilisation acceptés et date de révision | Responsable métier | Tout changement matériel de périmètre, de politique, de tarification ou d'architecture |
La règle pratique : si un réviseur avait besoin du même artefact lors d'un renouvellement, d'un incident, d'un questionnaire de sécurité ou d'un litige financier, il a sa place dans le dossier de preuves d'approvisionnement pour une passerelle IA.
Commencez par l'identité, l'autorité et le périmètre
Le service des achats devrait pouvoir répondre à trois questions sans ouvrir une discussion : qui est la contrepartie, qu'achetons-nous et qui a approuvé le périmètre ?
Pour Flatkey, sauvegardez des copies datées des pages publiques qui sont importantes pour le contrat et le dossier d'exploitation : la page d'accueil, la tarification, les conditions, la politique de confidentialité, l'accord de niveau de service et la politique de remboursement. La page de tarification actuelle de Flatkey décrit les recharges prépayées en libre-service, le support pour les achats d'entreprise, un solde unique pour les modèles GPT, Claude, Gemini, DeepSeek, d'image, d'audio et de vidéo, ainsi que la mesure de l'utilisation par modèle, type de jeton et journaux de requêtes. Sauvegardez la page que vous avez examinée plutôt que de vous fier à un prix ou à une liste de modèles mémorisés.
Ensuite, définissez le périmètre dans le langage de l'acheteur :
| Question sur le périmètre | Preuve à sauvegarder | Pourquoi c'est important |
|---|---|---|
| Quels environnements utiliseront la passerelle ? | Liste des environnements de développement, de préproduction, de production, de traitement par lots et d'évaluation | Empêche le trafic de production d'hériter d'une exception de test non examinée |
| Quelles applications sont dans le périmètre ? | Noms des applications, propriétaires et classification des données | Permet à la sécurité de faire correspondre l'utilisation de la passerelle à des systèmes réels |
| Quelles familles de points de terminaison sont requises ? | Chat, Responses, Messages, images, vidéo ou routes spécifiques au fournisseur | Évite d'approuver une route et d'en utiliser accidentellement une autre |
| Quels fournisseurs et modèles sont autorisés ? | Liste des fournisseurs, alias de modèles, candidats de repli et modèles non autorisés | Maintient le routage aligné sur les achats et la politique |
| Quelles classes de données peuvent transiter ? | Statut : public, interne, client, réglementé, secrets, identifiants ou PHI | Détermine si les preuves de DPA, de rétention et de rédaction sont suffisantes |
Ne considérez pas une approbation générale de la passerelle comme une approbation pour chaque futur modèle, fournisseur ou classe de données. Le dossier doit nommer ce qui est approuvé et ce qui nécessite une autre révision.
Sauvegardez les preuves de confidentialité, de DPA et de rétention en tant que preuves datées
L'erreur la plus risquée dans les preuves d'approvisionnement d'une passerelle IA est de confondre le langage marketing public avec le traitement des données spécifiques au compte. Les documents publics sont des preuves de sélection utiles. L'approbation finale nécessite toujours le contrat signé, l'APD (Accord de Protection des Données), les paramètres du compte et toutes les conditions spécifiques au fournisseur qui s'appliquent à votre trafic.
Sauvegardez ces fichiers avant l'approbation :
| Artefact de données | Ce qu'il faut capturer | Note de révision |
|---|---|---|
| Politique de confidentialité du fournisseur | Date d'entrée en vigueur, catégories de données couvertes, données de compte, données d'utilisation de l'API, données de support, langage de rétention | La politique publique ne remplace pas un APD |
| APD ou conditions de données | Entité juridique, sous-traitants, langage de transfert, droits d'audit, processus de violation | Confirmez qu'il correspond à votre entité contractante |
| Rétention des invites et des réponses | Si les invites, les sorties, les fichiers, les embeddings, les images ou les journaux sont stockés ; TTL par défaut et configurables | Séparez la rétention de la passerelle de la rétention du fournisseur |
| Transmission au fournisseur | Quelles conditions du fournisseur en amont s'appliquent lorsque la passerelle route vers ce fournisseur | Une passerelle peut simplifier l'accès sans supprimer les obligations en aval |
| Contrôles de rédaction et d'omission | Quels champs peuvent être masqués, omis ou exclus des journaux | Nécessaire avant les charges de travail sensibles ou les charges utiles des clients |
| Résidence des données | Région, sauvegarde, accès au support et déclarations de traitement transfrontalier | Doit correspondre aux engagements légaux et clients |
Les documents du fournisseur montrent pourquoi cela doit être explicite. La documentation sur la rétention des données de l'API d'Anthropic distingue la Rétention Nulle des Données (Zero Data Retention) d'autres arrangements et note que certaines fonctionnalités ou certains modèles nécessitent un stockage pour des périodes spécifiques. La documentation de la plateforme Gemini Enterprise Agent de Google Cloud présente de même la rétention nulle des données comme quelque chose que les clients obtiennent en remplissant des conditions et des paramètres spécifiques. Le Cadre de Gestion des Risques de l'IA du NIST est une directive volontaire, mais il est clair que l'utilisation digne de confiance de l'IA dépend de la gestion des risques tout au long de la conception, de l'utilisation et de l'évaluation, et non de l'acceptation d'une simple déclaration d'un fournisseur.
Le dossier appartenant à l'acheteur doit donc inclure à la fois la documentation publique du fournisseur et vos preuves spécifiques au compte : captures d'écran des paramètres, avenants signés, confirmations de support et une brève déclaration de ce qui est encore supposé.
Prouver le contrôle d'accès avant de partager les clés de production
L'approbation d'accès ne se limite pas à « qui peut se connecter ». Pour une passerelle IA, cela signifie qui peut créer des clés, effectuer la rotation des clés, afficher l'utilisation, modifier les routes, approuver les modèles, recharger le solde, exporter les journaux et désactiver le trafic.
Sauvegardez une page de contrôle des clés dans le dossier :
| Contrôle | Preuve à conserver | Échec à éviter |
|---|---|---|
| Propriétaire de la clé | Propriétaire humain désigné et propriétaire de secours pour chaque clé de production | Clé orpheline après des changements d'équipe |
| Portée de la clé | Environnement, application, route, ensemble de fournisseurs et ensemble de modèles | Clé partagée utilisée pour des charges de travail non liées |
| Rotation | Date de la dernière rotation, date de la prochaine rotation et runbook de rotation d'urgence | Clé à longue durée de vie sans propriétaire |
| Départ (Offboarding) | Comment l'accès est supprimé lorsqu'un ingénieur ou un fournisseur quitte l'entreprise | L'ancien utilisateur conserve l'accès à la route ou au tableau de bord |
| Utilisation du compte de service | Si l'automatisation utilise des identifiants d'utilisateur partagés, des identifiants de compte de service ou une identité de charge de travail | Changements d'automatisation non traçables |
| Stockage des secrets | Chemin du gestionnaire de secrets, référence CI/CD et captures d'écran non secrètes | Clés API apparaissant dans les tickets, les documents ou les journaux |
Le positionnement public de Flatkey autour d'une seule clé et d'un seul tableau de bord est utile pour réduire la prolifération des comptes de fournisseurs. L'approvisionnement a toujours besoin de preuves sur la manière dont votre équipe empêchera cette unique clé de passerelle de devenir une super-clé partagée. Associez cet article à l'examen de l'accès à l'API IA et aux journaux d'audit pour l'utilisation de l'API IA lors de la création du flux de travail de révision interne.
Transformer les déclarations de journalisation en fichiers d'audit
Un dossier de preuves d'approvisionnement pour une passerelle IA doit répondre aux questions suivantes : que s'est-il passé, qui en était responsable, combien cela a-t-il coûté et qu'est-ce qui a changé. Sauvegardez des exemples d'exportations, pas seulement des captures d'écran de graphiques de tableau de bord.
Champs d'audit minimum à tester :
| Champ d'audit | Pourquoi les réviseurs en ont besoin |
|---|---|
| ID de la requête et horodatage | Soutient la reconstruction d'incidents et les tickets de support |
| Étiquette de la clé ou du propriétaire | Lie le trafic à une équipe ou un service responsable |
| Famille de point de terminaison et route | Indique si le trafic a utilisé le chemin de passerelle approuvé |
| Modèle demandé et modèle servi | Révèle le comportement de routage, de repli et d'alias |
| Fournisseur ou compte en amont | Sépare les preuves de la passerelle des preuves du fournisseur en aval |
| Unités d'utilisation | Jetons, images, secondes, unités de cache ou autres dimensions de facturation |
| Coût estimé et réel | Permet au service financier d'examiner les dépenses et l'amplification des nouvelles tentatives |
| Classe d'erreur et nombre de tentatives | Indique si les échecs ont entraîné des dépenses supplémentaires |
| Statut de la rédaction | Confirme si les invites/réponses ont été journalisées, masquées ou omises |
Conservez un test positif et un test négatif. Le test positif prouve qu'une requête normale est visible avec les champs attendus de propriétaire, modèle, coût et route. Le test négatif prouve qu'une clé défaillante, une route bloquée, un événement de quota ou un modèle invalide est capturé sans exposer de secrets.
Pour l'examen des risques liés aux fournisseurs, reliez ces preuves à l'évaluation des risques des fournisseurs d'API d'IA. Pour les opérations, reliez-les aux guides de quotas, de relances et d'incidents afin que les journaux soient utiles en cas de problème.
Conserver les preuves de tarification, de facturation et de quota
Le service financier ne doit pas approuver une passerelle IA uniquement sur la base d'un titre de tarification. Le dossier doit montrer comment l'équipe comprendra le coût unitaire, le solde prépayé, les enregistrements de recharge, la gestion des factures, les remboursements et les limites budgétaires une fois que le trafic aura commencé.
Sauvegardez ces artefacts financiers :
| Artefact financier | Ce qu'il faut sauvegarder |
|---|---|
| Page de tarification actuelle | PDF daté ou capture d'écran avec les classes de modèles, les unités et le langage du plan d'entreprise |
| Coût de la requête de test | ID de la requête, modèle, unités d'entrée/sortie et coût affiché dans le tableau de bord |
| Solde ou flux de facturation | Enregistrement de recharge, exemple de facture, gestion des taxes, processeur de paiement ou contact de facturation d'entreprise |
| Paramètres de quota | Captures d'écran des quotas par clé, par équipe ou au niveau du compte et propriétaire |
| Politique de remboursement ou de litige | Processus pour les frais en double, les déductions incorrectes, les échecs de livraison, les erreurs de facturation et les preuves de support |
| Hypothèses de renouvellement | Utilisation mensuelle prévue, mix de modèles, fourchette de croissance et propriétaire pour l'examen des changements de prix |
Le contrôle clé n'est pas de savoir si le tarif actuel est acceptable. C'est de savoir si le service financier peut reproduire la piste des coûts plus tard. Les catalogues de tarification et de fournisseurs changent, en particulier pour les modèles de texte, d'image, d'audio et de vidéo. Sauvegardez les preuves datées et exigez un déclencheur de renouvellement lorsqu'une nouvelle classe de modèle ou une nouvelle route de fournisseur est ajoutée.
Exécuter le test de fumée d'approbation
Avant l'approbation, exécutez un test contrôlé via le chemin de la passerelle proposée. Si aucune clé de production n'est encore disponible, exécutez-le dans un bac à sable avec des paramètres représentatifs et étiquetez la preuve comme étant de pré-production.
Utilisez ce test d'approbation :
- Créez ou sélectionnez la clé de test approuvée.
- Envoyez une requête à faible risque via l'URL de base et la famille de points de terminaison approuvées.
- Capturez l'ID de la requête, l'alias du modèle, le modèle servi si disponible, la route, le fournisseur, la latence, les unités d'utilisation et le coût estimé.
- Confirmez que la requête apparaît dans le tableau de bord ou l'exportation sous le bon propriétaire.
- Déclenchez un échec attendu, tel qu'un modèle invalide, une mauvaise clé, un plafond de quota ou une route bloquée.
- Confirmez que l'enregistrement de l'échec ne révèle pas de secrets ou de charges utiles sensibles.
- Sauvegardez le chemin de restauration : comment désactiver la clé, dérouter le trafic ou revenir à un accès direct au fournisseur.
Le site public actuel de Flatkey dirige les utilisateurs vers la console, la page de tarification, la page des modèles et le flux d'inscription, et positionne la plateforme autour de l'accès à la passerelle, du routage, de la facturation, de l'analyse de l'utilisation et des contrôles opérationnels. C'est suffisant pour élaborer un plan de test d'approvisionnement. Ce n'est pas suffisant pour ignorer les preuves spécifiques au compte.
La validation doit inclure les risques ouverts
La dernière page du dossier de preuves d'approvisionnement pour une passerelle IA doit être un enregistrement de décision, pas une liste de contrôle festive.
Incluez :
| Champ de décision | Exemple |
|---|---|
| Cas d'utilisation approuvé | Assistant de support à la production, résumé de lots internes, évaluation de modèles ou outils de développement |
| Route approuvée | URL de base, famille de points de terminaison, ensemble de fournisseurs, alias de modèles et politique de repli |
| Données approuvées | Publiques uniquement, internes uniquement, données clients autorisées, données réglementées exclues ou PHI autorisées uniquement après BAA |
| Contrôles requis | Propriétaire de la clé, plafond de quota, rédaction des journaux, examen mensuel, propriétaire de l'incident |
| Risques ouverts | DPA en attente, ZDR non activé, passthrough du fournisseur non confirmé, repli non approuvé |
| Date de révision | Prochain renouvellement, premier mois de production ou avant toute nouvelle classe de fournisseur/modèle |
| Approbateurs | Approvisionnement, juridique, sécurité, plateforme, finance et propriétaire métier |
Cet enregistrement garantit l'honnêteté de l'approbation. Si un risque est accepté, indiquez qui l'a accepté et quand il expire. Si une affirmation nécessite encore des preuves, ne l'enterrez pas dans un fil de discussion.
En résumé
De bonnes preuves d'approvisionnement pour une passerelle IA transforment les affirmations des fournisseurs en fichiers que l'acheteur contrôle : pages de politique datées, conditions contractuelles, paramètres de compte, propriétaires d'accès, exportations d'audit, tests de coûts, transcriptions de tests de fumée et déclencheurs de renouvellement.
Pour Flatkey, commencez par sauvegarder les pages actuelles du produit, de la tarification, des conditions, de la confidentialité, du SLA et des remboursements ; définissez les applications, routes, modèles, fournisseurs, classes de données et propriétaires exacts dans le périmètre ; puis exécutez un petit test de passerelle avant l'approbation de la production. Utilisez la checklist de la passerelle API IA d'entreprise comme examen de contrôle plus large, puis obtenez une clé et conservez l'enregistrement d'approbation joint à l'équipe qui possédera le trafic.
FAQ
Qu'est-ce qu'une preuve d'approvisionnement pour une passerelle IA ?
La preuve d'approvisionnement pour une passerelle IA est le dossier de preuves appartenant à l'acheteur qui soutient l'approbation d'une passerelle API IA. Il comprend des pages de fournisseurs datées, des conditions signées, des preuves de confidentialité et de conservation, des preuves de contrôle d'accès, des échantillons d'audit, des enregistrements de tarification, des tests de fumée et la validation de l'approbation.
Une page de confiance est-elle suffisante pour l'approbation d'une passerelle IA ?
Non. Une page de confiance est une preuve de sélection, pas un dossier d'approbation complet. Les acheteurs doivent sauvegarder la page de confiance, mais ils ont également besoin du périmètre du contrat, du statut du DPA, des paramètres du compte, de la propriété de l'accès, des échantillons de journalisation, des preuves de tarification et des résultats des tests.
Qui devrait posséder le dossier de preuves d'approvisionnement pour la passerelle IA ?
Le service des achats ou le service juridique peut être propriétaire du dossier de contrat, mais l'ingénierie de la plateforme doit être propriétaire du périmètre technique et des preuves de tests de fumée. La sécurité doit être propriétaire des preuves de données, d'accès et d'audit. La finance doit être propriétaire des preuves de tarification, d'utilisation, de quota et de facturation.
À quelle fréquence le dossier de preuves doit-il être actualisé ?
Actualisez-le lors du renouvellement, après des modifications importantes de la politique ou de la tarification, avant d'ajouter un nouveau fournisseur ou une nouvelle classe de modèle, avant de router des données réglementées et après tout incident qui modifie les hypothèses de fonctionnement de la passerelle.
Que doivent sauvegarder les acheteurs de Flatkey avant l'approbation ?
Les acheteurs de Flatkey doivent sauvegarder des copies datées de la page d'accueil, de la page de tarification, des conditions, de la politique de confidentialité, du SLA, de la politique de remboursement, du périmètre du modèle et de la route, du plan du propriétaire de la clé, des paramètres de quota, des échantillons d'audit/de journaux, des preuves de facturation et du premier test de fumée réussi de la passerelle.
