Vérification d’une passerelle API IA SOC 2 devrait commencer avant que l’acheteur ne demande un dossier de sécurité. La question d’approvisionnement n’est pas « avez-vous un badge ? » Il s’agit de savoir si la passerelle, les routes de modèles, les journaux, les clés, les relevés de facturation, le processus de support et les fournisseurs en aval peuvent être reliés à des éléments de preuve qu’un évaluateur de sécurité peut réellement examiner.
Ce guide s’adresse aux équipes achats, sécurité, plateforme, conformité et gestion des risques fournisseurs qui évaluent une passerelle API IA avant le trafic de production. Il ne constitue pas un avis juridique ni un avis d’audit. Utilisez-le comme une liste de contrôle pratique des preuves : quoi demander, quoi vérifier dans le rapport SOC 2, quoi tester dans la passerelle et quoi conserver dans votre propre dossier côté acheteur.
Flatkey est pertinent car flatkey.ai présente publiquement le produit comme une passerelle API unique pour les équipes IA de production, avec accès aux modèles, routage, facturation, analyses d’utilisation, contrôles opérationnels, un tableau de bord et une seule clé pour plusieurs fournisseurs. Le pied de page public de Flatkey renvoie également à des pages de vérification de certificat pour VOC AI Inc., indiquant une entrée SOC 2 Type II et une entrée ISO 27001:2022, et l’instantané actuel de l’API de tarification vérifié le 19 juin 2026 a renvoyé 638 lignes de modèles sur 23 fournisseurs. Traitez ces éléments comme des preuves publiques datées, et non comme un substitut au rapport SOC 2 privé, à l’accord signé, au DPA, aux paramètres du compte ou à la validation des journaux de production.
Réponse rapide : ce que les preuves d’une passerelle API IA SOC 2 doivent démontrer
Une revue d’une passerelle API IA SOC 2 doit démontrer trois choses : le rapport de contrôle du fournisseur couvre le service pertinent, la passerelle peut produire des preuves opérationnelles pour votre trafic IA, et votre propre équipe dispose des contrôles pour les responsabilités que le rapport du fournisseur laisse aux clients.
| Domaine de revue | Preuves à demander | Ce qu’il faut vérifier |
|---|---|---|
| Périmètre du rapport SOC 2 | Rapport SOC 2 Type II actuel, période du rapport, auditeur, description du système et lettre de pont si la période du rapport est obsolète. | La passerelle IA, le routage des API, la journalisation, le support, la facturation et l’infrastructure pertinente sont inclus dans la limite du système. |
| Critères des services de confiance | Catégories couvertes par le rapport, généralement la sécurité ainsi que tout critère de disponibilité, de confidentialité, d’intégrité du traitement ou de confidentialité des données personnelles. | Les catégories couvertes correspondent au risque de l’acheteur. N’assumez pas que la confidentialité des données personnelles ou la disponibilité sont couvertes à moins que le rapport ne le précise. |
| Contrôles utilisateur complémentaires | CUEC et responsabilités de l’acheteur indiquées dans le rapport SOC 2. | Votre équipe peut satisfaire les exigences clés de gestion, d’approbation des routes, de classification des données, d’accès utilisateur, de conservation et de gestion des incidents. |
| Organisations de sous-traitance | Description des organisations de sous-traitance en modèle carve-out ou inclusif, liste des fournisseurs et contrôles de supervision. | Les fournisseurs de modèles en aval, les services cloud, les outils de support, l’observabilité et les fournisseurs de facturation sont traités conformément au modèle du rapport. |
| Opérations de la passerelle IA | Exemples de journaux, champs de propriété des clés, historique des changements de route, inventaire des routes vers les fournisseurs de modèles et processus d’export des incidents. | La passerelle peut montrer qui a envoyé le trafic, quel modèle/fournisseur l’a reçu, ce qui a changé et quelles preuves sont conservées. |
| Données et confidentialité | Politique de confidentialité, chemin DPA, emplacements de traitement des données, politique de conservation, politique de journalisation des charges utiles et conditions d’utilisation des données par le fournisseur. | Les prompts, les sorties, les métadonnées, les supports de support et les dossiers de facturation ont des règles de traitement claires. |
| Preuves côté acheteur | Votre propre dossier de déploiement, les cas d’usage approuvés, la taxonomie des clés, la politique de routage, le mode de journalisation et la cadence de revue. | Les preuves du fournisseur sont reliées à la manière dont votre équipe utilisera réellement la passerelle. |
Commencez par le périmètre SOC 2, pas par le badge
Un badge public peut être utile pour un premier tri, mais les achats doivent toujours demander le rapport SOC 2 réel dans le cadre du processus de confiance du fournisseur. L’AICPA décrit le reporting SOC 2 comme un examen des contrôles d’une organisation de services pertinents pour la sécurité, la disponibilité, l’intégrité du traitement, la confidentialité ou la vie privée. Cela signifie que la question d’achat utile porte sur le périmètre : quel système, quel service, quelle plage de dates, quels critères, quels contrôles, quelles exceptions et quelles assertions de la direction sont couverts ?
Pour une SOC 2 AI API gateway, la revue du périmètre doit répondre à :
| Champ du périmètre | Question de l’acheteur | Pourquoi c’est important pour le trafic de l’API IA |
|---|---|---|
| Entité juridique | Quelle entité est nommée dans le rapport et le contrat ? | La recherche publique de certificat de Flatkey fait référence à VOC AI Inc. ; votre dossier d’achat doit correspondre à l’entité contractante et au propriétaire du service. |
| Périmètre du système | Le rapport couvre-t-il la passerelle IA, le routage API, le tableau de bord, les clés, la facturation, les journaux d’utilisation et le processus de support ? | Un rapport portant sur une plateforme de données ou d’analyse plus large peut ne pas prouver le flux de travail spécifique de la passerelle que vous prévoyez d’utiliser. |
| Période du rapport | Quelle plage de dates le rapport de Type II a-t-il testée, et une lettre de jonction est-elle nécessaire ? | Les achats veulent généralement des preuves d’exploitation actuelles, et pas seulement une déclaration historique ponctuelle. |
| Catégories de confiance | Quels critères des services de confiance sont couverts ? | La couverture de la sécurité ne signifie pas automatiquement la couverture de la disponibilité, de la confidentialité, de l’intégrité du traitement ou de la vie privée. |
| Exceptions | Des contrôles ont-ils été qualifiés, exceptés ou remédiés ? | Les exceptions peuvent affecter la gestion des clés, la journalisation, le contrôle des changements, la réponse aux incidents ou la surveillance des fournisseurs. |
| Organisations de services sous-traitantes | Quels services cloud, de fournisseur, d’observabilité et de paiement sont exclus ou inclus ? | Le risque d’une passerelle IA dépend souvent des fournisseurs de modèles et d’infrastructure en aval. |
La règle pratique est simple : si un acheteur ne peut pas relier le rapport SOC 2 au service exact de passerelle et au chemin du trafic, le rapport constitue une preuve de présélection, pas une preuve d’achat finale.
Mapper les critères SOC 2 aux contrôles de la passerelle IA
Les critères de services de confiance de l’AICPA couvrent la sécurité, la disponibilité, l’intégrité du traitement, la confidentialité et la vie privée. Un dossier de preuves pour une passerelle d’API IA SOC 2 doit traduire ces grandes catégories en contrôles concrets de la passerelle.
| Control Topic | Evidence To Verify | Related SOC 2 Concern |
|---|---|---|
| Propriété des clés API | Les clés sont associées à des propriétaires, des environnements, des applications et des workflows ; la création et la révocation des clés sont auditables. | Accès logique, responsabilité, contrôle des changements et confinement des incidents. |
| Approbation des routes et des modèles | Les fournisseurs approuvés, les familles d’endpoint, les lignes de modèle, les règles de repli et les enregistrements de changement sont consultables. | Gestion des changements, surveillance des fournisseurs, intégrité du traitement et confidentialité. |
| Journaux d’audit | Les journaux indiquent l’horodatage, la clé ou le projet, la route, le fournisseur, le modèle, la famille d’endpoint, le statut, la classe d’erreur, les unités d’utilisation et les changements administratifs. | Surveillance, réponse aux incidents, revue des accès et preuves opérationnelles. |
| Gestion des charges utiles | Le mode de journalisation des prompts/outputs, la rédaction, la restriction d’accès, la période de conservation et le chemin de suppression sont documentés. | Confidentialité, vie privée et minimisation des données. |
| Utilisation et facturation | Les enregistrements d’utilisation et de facturation sont séparés des charges utiles brutes et reliés au propriétaire, au modèle, à la route et au centre de coûts. | Intégrité du traitement, responsabilité et support à l’examen financier. |
| Revue des incidents | Les événements de sécurité, les défaillances des fournisseurs, les usages suspects, les clés divulguées, les boucles de repli et les événements de dépassement de limite disposent d’un runbook et d’un chemin d’exportation. | Surveillance de la sécurité, réponse et remédiation. |
| Changements de fournisseur et de prestataire | Les ajouts, suppressions, changements régionaux et modifications de la politique d’utilisation des données des fournisseurs déclenchent une nouvelle revue. | Surveillance de l’organisation de sous-service et évaluation des risques. |
C’est ici que les passerelles IA diffèrent des passerelles API génériques. La route n’est pas seulement une décision d’hôte/chemin. Elle peut déterminer quel fournisseur de modèles voit les prompts, quelle politique de données s’applique, quelle règle de conservation s’applique, quel chemin de repli est autorisé et quelle unité d’utilisation est facturée.
Preuves Flatkey à vérifier avant l’achat
Flatkey dispose d’éléments publics utiles pour une première revue d’une passerelle d’API IA SOC 2. Le site public indique que Flatkey unifie l’accès aux modèles, le routage, la facturation, les analyses d’utilisation et les contrôles opérationnels pour les équipes qui livrent des produits d’IA. Le pied de page renvoie vers une recherche Cert Assure SOC 2 Type II pour VOC AI Inc., certificat `USA-SOC2-220513`, avec une période indiquée du 15 juillet 2025 au 14 juillet 2026 et un statut actif au moment de la consultation. Le même pied de page renvoie vers une recherche ISO 27001:2022 pour VOC AI Inc., certificat `USA-I-270513`, avec une période indiquée du 1er mai 2024 au 30 avril 2027 et un statut actif au moment de la consultation.
Utilisez ces pages publiques comme point de départ, puis vérifiez directement ces éléments auprès de Flatkey avant l’achat :
| Vérification Flatkey | Éléments à relever | Garde-fou |
|---|---|---|
| Demande de rapport SOC 2 | Rapport actuel, auditeur, période, périmètre, critères couverts, exceptions, organisations de sous-traitance de service et lettre de pont si nécessaire. | Ne vous fiez pas uniquement au badge public ou à la recherche du certificat. |
| Vérification croisée ISO 27001:2022 | Entité du certificat, périmètre d’activité, dates et toute déclaration d’applicabilité ou vue d’ensemble de la sécurité disponible dans le cadre de l’examen de confiance. | La certification ISO soutient un examen du SMSI, mais ne remplace pas le rapport SOC 2 ni la validation du routage IA. |
| Catalogue et prise en charge des points de terminaison | Ligne de modèle actuelle, fournisseur, famille de points de terminaison, état de disponibilité et unité de tarification depuis Tarification Flatkey. | Le nombre de modèles, de fournisseurs et la disponibilité peuvent changer ; vérifiez le jour où vous approuvez le routage. |
| Preuves du tableau de bord | Responsable clé, route, modèle, fournisseur, statut, unité d’utilisation, enregistrement de facturation et tout chemin d’exportation dans le tableau de bord Flatkey actuel. | Ne présumez pas des libellés exacts du tableau de bord à partir du texte marketing public. |
| Journaux et conservation | Champs de métadonnées, comportement de journalisation des charges utiles, période de conservation, permissions des lecteurs, gestion des données de support et processus de suppression/export. | La politique de confidentialité publique de Flatkey mentionne les métadonnées des requêtes, les enregistrements d’erreurs, les enregistrements d’utilisation, les journaux nécessaires et les supports de support, mais un acheteur a besoin de conditions spécifiques au compte. |
| Politique de routage des fournisseurs | Fournisseurs approuvés, contraintes de repli, conditions d’utilisation des données par le fournisseur et qui peut modifier les routes. | Le repli pour la fiabilité peut devenir un changement de risque fournisseur si le fournisseur en aval change. |
Comment tester la passerelle avant l’approbation de sécurité
N’attendez pas le trafic client en production pour découvrir si vos preuves de passerelle API IA SOC 2 sont complètes. Exécutez un test de fumée contrôlé par route et enregistrez le dossier de revue.
- Créer des identifiants de route non secrets : utilisez des clés ou des projets distincts pour le staging, la production, les lots, le trafic orienté client et le trafic d’évaluation.
- Choisir une route de modèle à faible risque : consignez le fournisseur, la ligne du modèle, la famille de points de terminaison, l’unité de tarification et la classe de données attendue.
- Envoyer une requête de test inoffensive : évitez les données clients réelles, les données personnelles, les secrets ou le contenu réglementé.
- Examiner l’enregistrement du journal : confirmez l’horodatage, la clé/le projet, le propriétaire, la route, le fournisseur, le modèle, le statut, les unités d’utilisation, la classe d’erreur et la visibilité des coûts.
- Examiner les preuves administratives : confirmez qui a créé la clé, qui a approuvé la route, qui peut modifier le repli et où les changements sont consignés.
- Tester un chemin de refus : essayez un modèle interdit, une classe de données bloquée, une clé expirée ou une limite de quota et enregistrez le résultat.
- Documenter la rétention : identifiez où les métadonnées, les charges utiles le cas échéant, les tickets d’assistance, les dossiers de facturation et les journaux de sécurité sont conservés.
- Joindre les documents d’approvisionnement : rapport SOC 2, lettre de pont, preuves ISO, politique de confidentialité, conditions, chemin DPA, revue du fournisseur et votre note de déploiement.
- Répéter lors des changements : relancez le dossier lorsque le fournisseur, le modèle, la famille de points de terminaison, le repli, la classe de données, le mode de journalisation ou les conditions contractuelles changent.
- Séparer les preuves publiques et privées : les pages publiques aident au triage ; le rapport privé et la validation spécifique au compte finalisent l’achat.
La SOC 2 n’est qu’une couche de l’examen de la passerelle d’IA
Un examen de passerelle d’API IA SOC 2 doit s’ajouter à ISO 27001, au RGPD, à la sécurité des applications et aux vérifications du risque fournisseur. Ces cadres sont liés, mais ils répondent à des questions différentes.
| Framework Or Source | What It Helps Verify | What It Does Not Prove By Itself |
|---|---|---|
| SOC 2 | Examen indépendant des contrôles pour le système décrit et les critères des Trust Services Criteria couverts pendant la période du rapport. | Cela ne prouve pas que chaque fonctionnalité Flatkey, chaque paramètre de compte client, chaque route de modèle en aval ou chaque flux de travail d’acheteur est couvert. |
| ISO/IEC 27001:2022 | Périmètre du système de management de la sécurité de l’information, gestion des risques et statut de certification. | Cela ne remplace pas un rapport SOC 2 et ne prouve pas un schéma spécifique de journal des requêtes IA. |
| GDPR | Examen du sous-traitant, sécurité du traitement, minimisation des données, conservation, garanties de transfert et cartographie des rôles pour les données personnelles. | Cela n’est pas satisfait simplement parce qu’une passerelle a été examinée SOC 2. |
| OWASP logging guidance | Conception pratique des journaux, attributs des événements, données à exclure, protection des journaux et considérations de surveillance. | Cela ne définit pas la politique de conservation de votre fournisseur et ne prouve pas que votre traitement des prompts/sorties est acceptable. |
| Buyer controls | Votre taxonomie des clés, l’accès utilisateur, l’approbation des routes, la classification des données, le repli du modèle, la conservation et l’examen des incidents. | Elles ne remplacent pas les contrôles du fournisseur ; elles rendent les éléments de preuve du fournisseur utilisables dans votre environnement. |
Utilisez la checklist de passerelle d’API IA d’entreprise adjacente de Flatkey pour la pile d’approvisionnement plus large et les journaux d’audit pour l’utilisation des API IA pour les champs de preuve que les équipes de sécurité demandent généralement.
Modèle de dossier de preuves pour les achats
Le résultat le plus utile d’une revue de passerelle API IA SOC 2 est un dossier compact que les équipes d’ingénierie commerciale, de sécurité, juridique et de plateforme peuvent toutes lire.
| Section du dossier | Champs à inclure | Responsable |
|---|---|---|
| Identité du fournisseur | Entité juridique, entité contractante, contact support, chemin du portail de confiance, liens de consultation du certificat et statut actuel. | Achats |
| Dossier SOC 2 | Type de rapport, période, auditeur, périmètre du système, critères des services de confiance, exceptions, organisations de sous-traitance, CUEC et lettre de continuité. | Sécurité |
| Dossier des routes de la passerelle | Fournisseurs approuvés, modèles, familles de points de terminaison, règles de bascule, classes de données, responsable de la route et approbateur des changements. | Ingénierie de plateforme |
| Dossier des journaux et des preuves | Champs de métadonnées des requêtes, journaux administratifs, politique de charge utile, classe de conservation, méthode d’export et liste des accès des lecteurs. | Opérations de sécurité |
| Dossier de protection des données | Chemin du DPA, politique de confidentialité, conditions, examen de l’utilisation des données par le fournisseur, emplacements de traitement, liste des sous-traitants ultérieurs et notes sur les rôles GDPR. | Juridique et confidentialité |
| Contrôles côté acheteur | Taxonomie des clés, cadence de revue des accès, processus de modification des routes, politique de quotas, procédure de gestion des incidents et déclencheurs de nouvelle revue. | Plateforme et gouvernance |
| Approbation de lancement | Approbateur final, cas d’usage approuvés, classes de données bloquées, date de lancement, date de revue et risques résiduels. | Sécurité et produit |
Signaux d’alerte pendant l’examen
Suspendez l’approvisionnement si les éléments de preuve du SOC 2 AI API gateway laissent ces lacunes non résolues :
- Réponse fondée uniquement sur un badge : le fournisseur renvoie à un badge mais ne peut pas fournir le rapport SOC 2 actuel sous NDA ou avec accès de confiance.
- Inadéquation du périmètre : le rapport couvre un produit, une entité, une frontière d’infrastructure ou une période différents de ceux de la passerelle faisant l’objet de l’achat.
- Aucun plan CUEC : le rapport énumère les responsabilités du client, mais l’acheteur ne les a pas attribuées en interne.
- Sous-organisations de services opaques : les fournisseurs de modèles en aval, les outils de support, les outils de journalisation ou les fournisseurs cloud ne sont pas traités clairement.
- Aucune preuve de changement de route : l’équipe ne peut pas montrer qui a ajouté un fournisseur, modifié un modèle ou activé un mécanisme de secours.
- Ambiguïté sur la journalisation des charges utiles : les prompts et les sorties peuvent être stockés, mais la conservation, l’accès et la suppression ne sont pas clairs.
- Preuve limitée au tableau de bord : des captures d’écran existent, mais il n’existe aucun fichier de preuve exportable ou examinable pour la revue de sécurité.
- Aucun déclencheur de nouvelle revue : de nouveaux modèles, régions, familles de points de terminaison et changements de politique des fournisseurs peuvent survenir sans revue des achats/de la sécurité.
Questions fréquentes
Qu’est-ce que la preuve d’une passerelle d’API d’IA SOC 2 ?
La preuve d’une passerelle d’API d’IA SOC 2 est l’ensemble des documents, journaux, enregistrements de routes, cartographies des contrôles et notes côté acheteur qui montrent comment les contrôles d’une passerelle d’IA soutiennent l’examen des achats. Elle comprend le rapport SOC 2 du fournisseur, l’examen du périmètre, la gestion des organisations de services secondaires, les journaux d’audit, la propriété des clés, les approbations de routes, la politique de conservation et les responsabilités du client.
Un badge SOC 2 suffit-il pour approuver une passerelle d’API d’IA ?
Non. Un badge peut aider au tri initial, mais les achats doivent vérifier le rapport SOC 2 en cours, le système couvert, la période du rapport, les critères, les exceptions, les organisations de services secondaires et les contrôles complémentaires de l’entité utilisatrice. Le rapport privé et le test de route de l’acheteur comptent davantage que le badge seul.
Le SOC 2 doit-il couvrir chaque fournisseur de modèle derrière une passerelle ?
Pas nécessairement. Les rapports SOC 2 décrivent le système de l’organisation de services et la manière dont les organisations de services secondaires sont gérées, souvent par des méthodes de type carve-out ou inclusive. Les acheteurs devraient vérifier comment les fournisseurs de modèles, les services cloud, les outils de support et les services d’observabilité sont représentés, puis examiner les propres conditions de données et de sécurité de chaque fournisseur.
Comment le SOC 2 et le RGPD se connectent-ils pour une passerelle d’API d’IA ?
Le SOC 2 peut soutenir la preuve des contrôles de sécurité, tandis que l’examen RGPD se concentre sur les rôles de traitement, la base juridique, la minimisation des données, les conditions des sous-traitants, les transferts, la conservation et les droits des personnes concernées. Une passerelle d’API d’IA SOC 2 peut centraliser des preuves utiles, mais elle ne résout pas automatiquement les obligations RGPD.
Que dois-je vérifier dans Flatkey avant d’acheter ?
Vérifiez le rapport SOC 2 actuel de Flatkey, les détails du certificat ISO 27001, l’entité juridique, les conditions signées, le parcours DPA, la route du modèle/fournisseur, la famille de points de terminaison, les champs de preuve du tableau de bord, la conservation des journaux, le traitement des charges utiles, le traitement des données de support et le comportement de repli. Confirmez également la ligne de modèle actuelle et l’unité de tarification le jour où vous approuvez l’utilisation en production.
Dernière étape d’approvisionnement
Avant d’approuver une passerelle d’API IA SOC 2, constituez le dossier de preuves de la même manière qu’un auditeur ou un acheteur d’entreprise l’examinera : entité, périmètre du rapport, critères, période, exceptions, organisations de sous-traitance, journaux, contrôles d’accès, modifications de routage, traitement des données et responsabilités du client. Flatkey peut centraliser l’accès aux modèles, le routage, la visibilité d’utilisation et les contrôles opérationnels, mais votre dossier d’achat doit tout de même vérifier le rapport en cours et le chemin exact que vous allez utiliser.
Obtenez une clé lorsque vous êtes prêt à centraliser l’accès aux modèles, le routage, la visibilité d’utilisation et les preuves examinées par l’acheteur derrière une seule passerelle d’API IA.
