Évaluation des risques fournisseur d’API IA se پیچique lorsque le fournisseur est une passerelle multi-modèle plutôt qu’un fournisseur d’un seul modèle. L’acheteur n’approuve pas seulement un point de terminaison d’API. L’acheteur approuve un chemin de requête qui peut inclure un compte passerelle, des clés API, des routes de modèle, un comportement de repli, des journaux d’utilisation, des enregistrements de facturation, des flux de support et des fournisseurs de modèles en aval.
Ce guide s’adresse aux équipes achats, sécurité, plateforme, conformité et gestion des risques fournisseurs qui évaluent une passerelle d’API IA avant le trafic de production. Il ne constitue pas un avis juridique, d’audit ou de conformité. Utilisez-le comme une liste de questions pratique : quoi demander, quelles preuves solliciter, quoi tester en préproduction et quoi conserver dans le dossier d’achat.
Flatkey est pertinent parce que flatkey.ai positionne actuellement le produit comme une passerelle API unique pour les équipes IA en production, avec une seule clé, l’accès aux modèles, l’acheminement, la facturation, les analyses d’utilisation, les contrôles opérationnels et une console. Un instantané de l’API de tarification pris le 19 juin 2026 a renvoyé 638 lignes de modèles, 23 fournisseurs répertoriés et des familles de points de terminaison incluant OpenAI-compatible, Anthropic, Gemini, la génération d’images, Responses et la vidéo. Le pied de page public de Flatkey renvoie également vers des pages de consultation de certificats SOC 2 Type II et ISO 27001:2022 pour VOC AI Inc. Considérez-les comme des éléments publics de présélection datés, et non comme un substitut au rapport privé, à l’accord signé, au DPA, à la configuration du compte, au test de route ou à la confirmation du support.
Réponse rapide : ce qu’une évaluation des risques d’un fournisseur d’API IA doit prouver
Une évaluation des risques d’un fournisseur d’API IA doit prouver quatre choses : où les données circulent, qui peut modifier ce flux, quelles preuves existent lorsque le flux change, et quelles responsabilités restent à la charge de l’acheteur. Un questionnaire fournisseur générique va rarement assez loin pour une passerelle qui peut acheminer les requêtes vers plusieurs fournisseurs.
| Zone de risque | Question à poser | Preuve à demander | Condition d’arrêt |
|---|---|---|---|
| Exposition aux fournisseurs | Quels fournisseurs de modèles en aval, familles de points de terminaison, régions et comptes peuvent recevoir chaque workflow approuvé ? | Inventaire des routes, catalogue des modèles, politique fournisseur, journal des changements de route et statut actuel de disponibilité. | Le fournisseur ne peut pas montrer quel fournisseur peut traiter les prompts et les sorties. |
| Flux de données | Quelles données de prompt, de sortie, de métadonnées, d’erreur, de support et de facturation sont traitées ou conservées ? | Politique de confidentialité, parcours DPA, politique de rétention, mode de journalisation des charges utiles, processus de suppression/export et conditions du fournisseur. | Le traitement des charges utiles ou la rétention ne sont pas clairs pour la catégorie de données acheminée. |
| Contrôles de sécurité | Les preuves de contrôle couvrent-elles le service de passerelle que vous allez utiliser ? | Rapport SOC 2 Type II, périmètre ISO 27001, lettre de pont si nécessaire, exceptions, CUEC et traitement des sous-services. | Le périmètre du rapport ne peut pas être relié à la passerelle, aux clés, aux journaux, au support ou au workflow de routage réels. |
| Auditabilité | L’acheteur peut-il reconstituer qui a envoyé le trafic, quelle route l’a traité, combien cela a coûté et ce qui a changé ? | Export d’échantillon de journaux, journal des événements d’administration, champs de propriétaire de clé, champs de tentative de route, unités d’utilisation et relevés de facturation. | Les journaux n’affichent que le succès/l’échec sans contexte de propriétaire, de route, de modèle, de fournisseur ou de coût. |
| Continuité | Que se passe-t-il lorsqu’un fournisseur, un modèle, un compte, une région ou une route échoue ? | Politique de repli, politique de nouvelle tentative, métadonnées de tentative auprès du fournisseur, procédure de gestion d’incident, chemin de retour arrière et processus de notification client. | Le repli peut déplacer silencieusement le trafic vers un fournisseur ou une frontière de données non approuvés. |
| Contrôles de facturation | L’utilisation peut-elle être attribuée à la bonne équipe, clé, workflow, modèle et personne responsable des coûts ? | Tableau de bord d’utilisation, export de facturation, contrôles de quota/budget, enregistrements de recharge, unité tarifaire et processus de revue des anomalies. | L’approvisionnement ne peut pas relier une décision de routage à des preuves de dépenses. |
Commencez par une cartographie du chemin de requête
La première erreur dans l’évaluation des risques des fournisseurs d’API IA consiste à traiter la passerelle comme un substitut boîte noire à l’intégration directe d’un fournisseur. Une passerelle ne réduit la dispersion opérationnelle que si l’acheteur peut décrire le nouveau chemin de requête avec une précision suffisante pour l’examen de sécurité et des achats.
Pour chaque flux de production, cartographiez ces champs avant d’évaluer le fournisseur :
| Champ | À capturer | Pourquoi c’est important |
|---|---|---|
| Application et environnement | Nom de l’application, responsable, frontière préproduction/production, classe de données et cas d’usage métier. | La même passerelle peut présenter un faible risque pour la génération de contenu public et un risque élevé pour le support client ou des données réglementées. |
| Périmètre des identifiants | Propriétaire de la clé, processus de rotation, chemin de révocation, compte de service et personnes pouvant créer ou consulter les clés. | Une clé partagée peut masquer les responsabilités ; des clés séparées facilitent l’audit et le confinement des incidents. |
| Route de la passerelle | Famille de points de terminaison, ligne de modèle, fournisseur, groupe/niveau, règle de repli et responsable de la route. | La sélection de la route détermine qui peut voir la requête et quelles conditions de coût, de disponibilité et de fournisseur s’appliquent. |
| Fournisseur en aval | Nom du fournisseur, modèle de compte fournisseur, région ou lieu de traitement si disponible, et conditions d’utilisation des données. | L’approbation de la passerelle n’approuve pas automatiquement chaque fournisseur en aval. |
| Surface de preuve | Journaux, métadonnées, événements d’administration, enregistrements de facturation, tickets de support et chemins d’exportation. | L’approbation des achats devrait dépendre de preuves que l’acheteur peut examiner ultérieurement. |
Le cadre de gestion des risques liés à l’IA de NIST fournit un langage utile pour ce type d’examen, car il sépare la gouvernance, la cartographie, la mesure et la gestion. Dans une revue de passerelle, ces idées deviennent concrètes : qui possède la route, quel contexte est cartographié, comment les risques sont mesurés et comment les changements sont gérés après approbation.
Posez d’abord les questions sur l’exposition des fournisseurs, avant les questions sur les données
Une passerelle multi-modèles peut simplifier les opérations des API d’IA, mais elle modifie aussi la conversation sur le risque fournisseur. L’acheteur doit savoir si la passerelle se contente de transmettre le trafic à un seul fournisseur approuvé, choisit entre plusieurs fournisseurs, ou applique un comportement de basculement/répartition de charge qui peut changer le destinataire en aval.
Utilisez ces questions d’évaluation des risques fournisseurs pour les API d’IA pour l’exposition des fournisseurs :
| Question | Preuve | Note du réviseur |
|---|---|---|
| Quels fournisseurs peuvent recevoir ce workflow aujourd’hui ? | Ligne du catalogue actuelle, famille de points de terminaison, fournisseur, statut de disponibilité et configuration de route. | N’approuvez pas une catégorie telle que « tous les modèles GPT » sans lignes et responsables nommés. |
| Qui peut ajouter, supprimer ou réordonner les fournisseurs ? | Autorisations d’administration, piste d’audit des changements de route, flux de validation et paramètre de notification. | Un changement de fournisseur est un changement de risque, pas seulement une optimisation d’ingénierie. |
| La passerelle peut-elle basculer automatiquement vers un autre fournisseur en cas de panne ? | Politique de basculement, métadonnées de tentative, conditions d’arrêt et processus de retour arrière. | Le basculement doit être préapprouvé pour chaque workflow et chaque classe de données. |
| Les conditions spécifiques au fournisseur diffèrent-elles selon les routes de basculement ? | Conditions d’utilisation des données du fournisseur, déclarations de conservation, conditions d’entraînement, conditions de traitement régional et chemin de support. | Une route de basculement peut franchir une frontière de traitement ou de conservation des données. |
| Comment sont représentés les modèles non pris en charge, indisponibles ou défaillants ? | Statut de disponibilité, message d’incident, test de route actuel et comportement attendu côté client. | Une entrée de catalogue n’est pas la même chose qu’une route prête pour la production. |
Les recommandations d’OWASP sur les risques de la chaîne d’approvisionnement GenAI sont utiles ici, car un workflow de modèle dépend souvent de composants et de services en dehors de la base de code directe de l’acheteur. Pour une passerelle, le dossier pratique de la chaîne d’approvisionnement devrait inclure le fournisseur de la passerelle, les systèmes cloud et de support, les fournisseurs de modèles en aval, les systèmes de journalisation et d’analyse, les processeurs de facturation, ainsi que tout service pouvant affecter le prompt, la sortie, les métadonnées ou la gestion des clés.
Transformer le flux de données en liste de contrôle
Une solide évaluation des risques liés aux fournisseurs d’API IA ne pose pas une seule question générale comme « nos données sont-elles sécurisées ? ». Elle décompose le flux de données en enregistrements distincts, car chaque enregistrement peut avoir un profil de risque et de conservation différent.
| Type de données | Questions à poser au fournisseur de passerelle | Preuves à conserver par l’acheteur |
|---|---|---|
| Prompts et entrées | Les prompts sont-ils stockés, inspectés, masqués, chiffrés ou transmis à des fournisseurs en aval ? L’enregistrement des charges utiles peut-il être désactivé ? | Paramètre de journalisation, politique de confidentialité, DPA ou conditions de traitement des données, et confirmation spécifique au compte. |
| Sorties | Les sorties sont-elles stockées avec les prompts ? Les sorties sont-elles utilisées pour le débogage, le support, la revue qualité, la revue des abus ou l’amélioration du fournisseur ? | Politique de conservation, politique de données de support et journal de test montrant si les charges utiles de sortie sont enregistrées. |
| Métadonnées de requête | Quels champs de métadonnées sont conservés, tels que la clé, le projet, le modèle, le fournisseur, le statut, le nombre de jetons, le coût, la classe d’erreur et la durée ? | Export d’exemple de journal contenant uniquement des métadonnées et dictionnaire des champs. |
| Événements administratifs | La création de clés, la révocation, les changements de route, les changements d’autorisations et les changements de facturation sont-ils auditables ? | Exemple d’événement administrateur, matrice des rôles et processus de revue des accès. |
| Matériels de support | Le personnel du support peut-il accéder aux enregistrements de requêtes, aux traces d’erreur, aux prompts, aux sorties, aux captures d’écran ou à la configuration du compte ? | Politique d’accès du support, voie d’escalade et règle de minimisation des données. |
| Enregistrements de facturation | Quels champs d’utilisation sont stockés pour la facturation, le remboursement, le litige, la fiscalité, la comptabilité ou la revue antifraude ? | Export de facturation, facture ou enregistrement de recharge, et déclaration de conservation. |
La page de confidentialité publique de Flatkey indique que les entrées et sorties peuvent transiter par les systèmes Flatkey ainsi que par les services techniques ou de modèles concernés, et que le traitement peut être soumis à des règles de fournisseur différentes. Elle mentionne également les métadonnées de requête, les enregistrements d’erreur, les enregistrements d’utilisation, les journaux nécessaires, les matériels de support et les enregistrements conservés à des fins fiscales, comptables, de sécurité, de contrôle des risques, de paiement, de litige, d’audit, de conformité ou de besoins juridiques. Ces déclarations publiques constituent des preuves de départ utiles. Elles doivent toutefois encore être rapprochées du compte de l’acheteur, de la classe de données, du contrat, du chemin DPA et des paramètres du tableau de bord.
Examinez ensemble SOC 2, ISO, GDPR et les contrôles de l’acheteur
Les certifications de sécurité aident au triage des achats, mais elles ne clôturent pas à elles seules une évaluation des risques d’un fournisseur d’API d’IA. Un badge public répond à une question de présélection. L’acheteur doit encore disposer du périmètre, de la période, des critères, des exceptions, des contrôles complémentaires de l’entité utilisatrice, du traitement des organisations sous-traitantes et de la configuration propre au compte.
| Preuve | Ce qu’elle peut aider à prouver | Ce qu’elle ne prouve pas à elle seule |
|---|---|---|
| Rapport SOC 2 Type II | Les contrôles du système décrit pour les critères de services de confiance couverts pendant la période du rapport. | Il ne prouve pas que chaque route de modèle, fournisseur, champ de journal, classe de données ou configuration client soit approuvée. |
| Certificat ISO 27001:2022 | Le périmètre et le statut de certification du système de management de la sécurité de l’information. | Il ne remplace pas un rapport SOC 2, un DPA, un test de route ou une revue des contrôles de l’acheteur. |
| Documents GDPR | Le mapping des rôles, l’examen du sous-traitant, la minimisation des données, la sécurité du traitement, les garanties de transfert et les workflows des droits lorsque des données personnelles sont impliquées. | Ils ne deviennent pas satisfaisants parce qu’un fournisseur possède un badge de sécurité. |
| Journaux de passerelle et événements d’administration | Des preuves opérationnelles de qui a utilisé la route, quel modèle/fournisseur l’a traitée, combien cela a coûté et ce qui a changé. | Ils ne prouvent pas les clauses contractuelles, les limites de conservation ou les règles d’utilisation des données par le fournisseur, sauf s’ils sont liés à une politique. |
| Contrôles de l’acheteur | Les cas d’usage approuvés, la classification des données, la taxonomie des clés, les approbations de route, les limites budgétaires et la cadence de revue. | Ils ne remplacent pas les contrôles du fournisseur ; ils rendent les preuves du fournisseur exploitables dans l’environnement de l’acheteur. |
Pour Flatkey, les pages publiques de consultation des certificats vérifiées le 19 juin 2026 indiquaient VOC AI Inc. avec une entrée SOC 2 Type II, certificat USA-SOC2-220513, période indiquée du 15 juillet 2025 au 14 juillet 2026, et statut actif ; la page ISO indiquait le certificat USA-I-270513, ISO 27001:2022, période indiquée du 1er mai 2024 au 30 avril 2027, et statut actif. Utilisez ces pages pour commencer le dossier de confiance, puis demandez directement à Flatkey le rapport privé et les détails du périmètre avant approbation.
Pour une profondeur de revue spécifique au GDPR, associez cet article à la checklist GDPR pour passerelle d’API d’IA. Pour une profondeur de preuve SOC 2, utilisez la checklist de preuves SOC 2 pour passerelle d’API d’IA.
Exiger des journaux qui reconstituent la décision
Les journaux les plus utiles pour l’évaluation du risque fournisseur d’API d’IA ne sont pas de simples journaux de débogage. Ce sont des éléments de preuve d’achat. Ils doivent permettre à un évaluateur de reconstituer le propriétaire de la requête, la route, le fournisseur, le modèle, le statut, l’utilisation, le coût et les changements administratifs, sans exposer plus de données de prompt ou de sortie que nécessaire.
La documentation publique des passerelles montre la forme d’éléments de preuve utiles. La documentation de journalisation de l’AI Gateway de Cloudflare décrit des journaux contenant des champs tels que le fournisseur, l’horodatage, le statut de la requête, l’utilisation des jetons, le coût, la durée et des champs DLP facultatifs, avec un contrôle de journalisation du contenu utile qui peut conserver les métadonnées tout en omettant les corps bruts des requêtes et des réponses. La documentation de métadonnées personnalisées de Cloudflare montre des balises de requête telles que des identifiants d’utilisateur ou d’équipe pour le filtrage et l’analyse. Utilisez-les comme preuve publique de modèle, et non comme une affirmation sur le comportement de Flatkey.
| Champ de journal | Pourquoi les achats s’en soucient | Garde-fou de confidentialité |
|---|---|---|
| Horodatage et ID de requête | Prend en charge l’examen des incidents, l’examen des litiges de facturation et la reconstitution des pannes de fournisseur. | Évitez de mettre des données personnelles dans les ID de requête. |
| Clé, projet, application ou propriétaire | Relie l’utilisation à une équipe et à un environnement responsables. | Utilisez, si possible, des identifiants non sensibles plutôt que des noms d’utilisateur. |
| Modèle, fournisseur et famille de point de terminaison | Indique quelle route en aval a traité la requête. | Ne supposez pas que le nom visible du modèle capture chaque détail de fournisseur ou de compte. |
| Statut, classe d’erreur et tentative de repli | Explique si la passerelle a réessayé, échoué ou basculé vers une route de secours. | Rendez les métadonnées de tentative de repli disponibles sans exposer le contenu brut des charges utiles. |
| Unités d’utilisation d’entrée/sortie et coût | Prend en charge les revues de quotas, de budget, de refacturation et d’anomalies. | Les métadonnées d’utilisation peuvent souvent être conservées séparément des charges utiles de prompt/sortie. |
| Changements administratifs | Indique qui a créé les clés, modifié les autorisations, changé les routes ou ajusté les contrôles de facturation. | Restreignez l’accès aux journaux d’administration et conservez-les conformément à la politique de sécurité. |
Les utilisateurs de Flatkey devraient vérifier quels de ces champs sont visibles dans le compte actuel et le chemin d’exportation. Les textes marketing publics et les pages de politique ne suffisent pas. Enregistrez un enregistrement de test en environnement de préproduction, un enregistrement de refus, un enregistrement de changement de route et un enregistrement de facturation dans le dossier d’achat.
Séparer la fiabilité du recours de secours approuvé
Les affirmations de fiabilité peuvent créer un risque caché lié au fournisseur si un itinéraire de repli n’est pas approuvé. La documentation publique de secours du Vercel AI Gateway décrit un schéma dans lequel des modèles de secours peuvent être essayés dans l’ordre lorsque le modèle principal échoue, et les métadonnées du fournisseur peuvent montrer les tentatives de modèle. C’est un élément de preuve utile du schéma qu’une passerelle peut exposer. Cela ne prouve pas le comportement de Flatkey pour un compte spécifique.
Pour une évaluation des risques d’un fournisseur d’API IA, posez ces questions sur le recours de secours avant la mise en production :
- Quels échecs déclenchent le secours ? Un délai d’attente du fournisseur, une limitation de débit, un modèle indisponible, des erreurs 5xx et des erreurs réseau sont différents des requêtes malformées, des blocages de politique, des échecs d’authentification ou de l’épuisement du budget.
- Quels itinéraires de secours sont préapprouvés ? Chaque secours doit avoir un fournisseur, un modèle, une famille de points de terminaison, une classe de données, un coût et un examen de conformité.
- Quelles métadonnées montrent la chaîne de tentatives ? Une réponse finale réussie ne doit pas masquer les tentatives de fournisseur ayant échoué.
- Le recours de secours peut-il être désactivé par flux de travail ? Certains flux réglementés ou en contact avec les clients devraient échouer de manière fermée au lieu de basculer vers un autre fournisseur.
- Qui est notifié ? Les achats, la sécurité, la plateforme et les finances peuvent tous avoir besoin d’un enregistrement de changement d’itinéraire ou d’incident de secours.
- Comment le retour arrière est-il géré ? L’équipe a besoin d’un responsable, d’une procédure d’exploitation et d’une condition d’arrêt claire.
Utilisez le workflow de rotation des clés d’API IA et la liste de vérification des journaux d’audit d’utilisation des API IA comme contrôles de preuve adjacents lorsque les revues de fiabilité et de sécurité se chevauchent.
Faites l’examen de la facturation et des quotas tôt
Le coût fait partie de l’évaluation des risques des fournisseurs d’API d’IA car les changements de route peuvent aussi modifier les dépenses. Une passerelle peut simplifier la facturation, mais les achats doivent tout de même demander comment l’utilisation est mesurée, attribuée, limitée, contestée, remboursée et conservée.
| Question de facturation | Preuve à demander | Risque en cas d’absence |
|---|---|---|
| Quelle est l’unité tarifaire pour chaque route approuvée ? | Ligne du catalogue, unité tarifaire, ratio du modèle, ratio d’achèvement, ratio de cache ou unité par seconde/par image lorsque cela est pertinent. | Les équipes peuvent approuver un modèle sans comprendre comment l’utilisation devient un coût. |
| Les dépenses peuvent-elles être attribuées par clé, projet, équipe, flux de travail ou environnement ? | Tableau de bord d’utilisation, champs d’exportation, balises de métadonnées et échantillon de rapport de facturation. | L’utilisation partagée devient un problème de finances et de responsabilité. |
| Des budgets ou des limites de quota peuvent-ils arrêter une utilisation incontrôlée ? | Paramètres de budget, configuration des quotas, paramètres d’alerte et comportement en cas de dépassement de limite. | Une boucle de prompt, une boucle de repli ou un bug d’intégration peuvent devenir un incident de coût. |
| Comment les enregistrements de recharge, de remboursement, de litige et de taxe sont-ils conservés ? | Conditions, export de facturation, page de facture ou de recharge et déclaration de conservation. | Les achats ne peuvent pas rapprocher l’utilisation du paiement ou des preuves de litige. |
Les conditions publiques et la page d’accueil de Flatkey décrivent le solde prépayé, l’accès aux modèles, l’utilisation, la facturation, les clés, les paramètres d’équipe, les autorisations, les budgets, les modèles, les journaux et les paramètres de sécurité. Vérifiez les libellés exacts et les contrôles disponibles dans la console actuelle avant de vous y fier pour l’approbation de l’acheteur.
Questions d’approvisionnement Flatkey à poser avant approbation
Utilisez cette checklist spécifique à Flatkey de évaluation des risques des fournisseurs d’API IA après avoir répondu aux questions générales sur la passerelle. L’objectif est de distinguer les preuves publiques des preuves spécifiques au compte.
| Élément de revue Flatkey | Ce que montrent les preuves publiques | Ce qu’il faut vérifier directement |
|---|---|---|
| Positionnement de la passerelle | Le texte public de Flatkey indique une clé unique, l’accès aux modèles, le routage, la facturation, l’analytique d’utilisation, les contrôles opérationnels et le contexte de la console. | Quel compte, quelle route, quelle famille de points de terminaison et quelles lignes de modèles sont activés pour votre flux de travail de production. |
| Périmètre du catalogue | Le snapshot de l’API de tarification du 19 juin 2026 a renvoyé 638 lignes de modèles et 23 fournisseurs répertoriés. | La ligne, le fournisseur, l’unité de tarification, l’état de la route et la disponibilité le jour de l’approbation. |
| Preuves SOC 2 et ISO | Le pied de page public renvoie vers des pages de consultation des certificats SOC 2 Type II et ISO 27001:2022 pour VOC AI Inc. | Le rapport SOC 2 privé, le périmètre ISO, la période du rapport, les exceptions, les CUEC, les organisations de sous-traitance de services et la lettre de transition si nécessaire. |
| Gestion des données | La page de confidentialité de Flatkey décrit les entrées, les sorties, les métadonnées de requête, les enregistrements d’utilisation, les journaux, les supports d’assistance, la conservation et le traitement par le fournisseur au niveau de la politique publique. | Le chemin du DPA, le paramètre de journalisation des charges utiles, les périodes de conservation, l’accès du support, les conditions d’utilisation des données par le fournisseur et le processus de suppression/exportation pour votre compte. |
| Administration | Les conditions mentionnent le contrôle par l’administrateur de l’organisation sur les autorisations, les budgets, les modèles, les journaux, les clés et les paramètres de sécurité. | La matrice de rôles exacte, les journaux d’événements d’administration, l’approbation des changements de route et qui peut modifier le fallback ou l’accès aux modèles. |
| Opérations | Le texte public décrit la bascule automatique et l’équilibrage de charge. | Les déclencheurs d’échec, les conditions d’arrêt du fallback, les métadonnées des tentatives chez les fournisseurs, le processus d’incident et la notification à l’acheteur. |
Après ces vérifications, envoyez l’acheteur vers la checklist de passerelle d’API IA d’entreprise pour l’examen plus large de l’architecture et vers la tarification Flatkey pour l’inspection actuelle du catalogue. Lorsque la route est acceptable, le parcours de conversion est simple : obtenez une clé, exécutez un test de préproduction à faible risque, enregistrez les preuves, puis ne faites passer le trafic approuvé qu’ensuite.
Modèle de dossier de preuves d’approvisionnement
Le résultat final d’une évaluation des risques d’un fournisseur d’API d’IA doit être un dossier qu’un autre réviseur peut rouvrir plus tard. Gardez-le suffisamment court pour être maintenu, mais suffisamment spécifique pour résister à un examen d’incident.
| Section du dossier | Contenu requis | Responsable |
|---|---|---|
| Résumé du cas d’usage | Flux de travail, environnement, classe de données, responsable métier, responsable technique et date d’approbation. | Responsable produit ou plateforme |
| Inventaire des routes | Compte passerelle, clé/projet, ligne de modèle, fournisseur, famille de point de terminaison, routes de repli et unité tarifaire. | Ingénierie plateforme |
| Dossier sécurité | Rapport SOC 2, preuves ISO, exceptions, lettre de pont, CUEC, organisations de sous-traitance et notes de pénétration/sécurité si fournies. | Sécurité ou GRC |
| Dossier confidentialité | Chemin DPA, cartographie des rôles, catégories de données, conservation, journalisation des charges utiles, suppression/export, accès support et conditions du fournisseur. | Confidentialité ou juridique |
| Dossier opérations | Test de fumée, test de refus, test de repli si activé, test de changement de route, manuel d’incident et responsable du retour arrière. | Ingénierie plateforme |
| Dossier d’audit | Exemple de champ de journal, exemple d’événement administrateur, exemple de facturation, capture d’écran ou export quota/budget, et processus de revue des accès. | Sécurité et finance |
| Enregistrement de décision | Routes approuvées, routes interdites, risques non résolus, date de renouvellement, déclencheurs d’examen et responsables de validation. | Approvisionnement ou responsable du risque |
Flux de travail étape par étape
- Classifiez le flux de travail : nommez l’application, le propriétaire, l’environnement, la classe de données, la population d’utilisateurs et le volume de requêtes attendu.
- Listez les routes approuvées : enregistrez le compte de passerelle, la famille de points de terminaison, la ligne du modèle, le fournisseur, le chemin de repli, l’unité de tarification et le propriétaire de la route.
- Demandez des preuves de confiance : collectez les preuves SOC 2, ISO 27001, de confidentialité, DPA, de sous-service, d’incident, de support et de conservation.
- Exécutez un test de fumée de préproduction : envoyez un trafic de test sans danger, puis enregistrez le journal, l’enregistrement d’utilisation, l’enregistrement de facturation et l’enregistrement de route.
- Exécutez un test de refus : essayez un modèle interdit, une clé expirée, une requête dépassant le quota ou une classe de données bloquée, puis enregistrez le résultat.
- Examinez le comportement de repli : approuvez ou désactivez le repli selon le flux de travail ; n’autorisez pas de changements silencieux de fournisseur pour les flux sensibles.
- Approuvez les contrôles acheteur : définissez la rotation des clés, la revue des accès, la revue des routes, les alertes budgétaires, la réponse aux incidents et le rythme de renouvellement.
- Enregistrez la décision : documentez ce qui est approuvé, ce qui est interdit, ce qui doit être renouvelé et ce qui déclenche une nouvelle revue.
FAQ
Qu’est-ce qu’une évaluation des risques d’un fournisseur d’API d’IA ?
Une évaluation des risques d’un fournisseur d’API d’IA est un examen, mené dans le cadre des achats et de la sécurité, du flux de données d’un fournisseur d’API d’IA, des preuves de sécurité, de l’exposition du fournisseur, des contrôles opérationnels, des journaux, des contrôles de facturation, du processus de continuité et des responsabilités de l’acheteur. Pour une passerelle multi-modèles, elle doit inclure les fournisseurs de modèles en aval et le comportement de changement de route.
En quoi une évaluation des risques d’une passerelle multi-modèles diffère-t-elle d’un examen d’un fournisseur unique ?
Un examen d’un fournisseur unique se concentre généralement sur le contrat, les conditions de données, les preuves de sécurité et le comportement de l’API d’un seul fournisseur. Un examen d’une passerelle doit également couvrir la sélection des routes, les mécanismes de repli, les changements de catalogue, la propriété des clés, les journaux de la passerelle, l’attribution de la facturation, les fournisseurs en aval et les personnes autorisées à modifier le fournisseur qui reçoit le trafic.
L’approbation SOC 2 signifie-t-elle qu’une passerelle d’IA est approuvée pour tous les cas d’usage en production ?
Non. Les preuves SOC 2 peuvent aider à évaluer la conception et le fonctionnement des contrôles pour le système décrit et les critères couverts, mais elles n’approuvent pas automatiquement chaque flux de travail d’un acheteur, chaque classe de données, chaque route de modèle, chaque chemin de repli, chaque condition fournisseur ou chaque paramètre de compte. Il faut rattacher le rapport à une route spécifique et à un dossier de contrôles de l’acheteur.
Quels journaux les achats doivent-ils demander avant d’approuver une passerelle d’IA ?
Demandez des exemples de journaux ou d’exports montrant l’horodatage, la clé ou le projet, le propriétaire, le modèle, le fournisseur, la famille d’endpoint, le statut, la classe d’erreur, les jetons ou unités d’utilisation, le coût, la tentative de routage, les modifications administratives et le mode de journalisation des charges utiles. Évitez de stocker les prompts et les sorties bruts, sauf si le cas d’usage et la politique l’exigent.
Que doivent vérifier les acheteurs de Flatkey avant un trafic de production ?
Les acheteurs de Flatkey doivent vérifier la ligne de modèle actuelle, le fournisseur, la famille d’endpoint, l’unité tarifaire, la disponibilité, le comportement de routage, les journaux, la gestion des charges utiles, la conservation, le chemin DPA, le périmètre du rapport SOC 2, le périmètre ISO, la matrice des rôles administratifs, le comportement de repli, l’export de facturation et les contrôles budgétaires. Les pages publiques sont utiles comme preuves de présélection, mais l’approbation en production doit utiliser des preuves à jour et spécifiques au compte.
Appel à l’action final
Une évaluation des risques d’un fournisseur d’API d’IA est la plus solide lorsqu’elle transforme les affirmations du fournisseur en preuves au niveau de la route. Pour Flatkey, commencez par les pages publiques de confiance, de tarification et de politique ; puis vérifiez dans votre propre compte le routage exact du modèle, les journaux, les contrôles et le parcours contractuel. Lorsque la route est prête pour un test de préproduction à faible risque, obtenez une clé et préparez le dossier d’achat avant que le trafic de production ne bascule.
