Un examen de la portée SOC 2 d’une passerelle API IA ne devrait pas commencer par le badge. Il devrait commencer par une question simple : quel système, quelle période, quels contrôles, quelles dépendances et quelles responsabilités assumées par l’acheteur le rapport a-t-il réellement couverts ?
Cette distinction compte pour le routage des modèles. Une passerelle API IA peut se situer entre votre application et plusieurs fournisseurs de modèles, familles d’API, journaux, flux de support, enregistrements de facturation et chemins de repli. Un rapport SOC 2 Type 2 peut constituer une preuve utile du système décrit par le fournisseur de la passerelle et des critères de services de confiance couverts. Il ne doit pas être considéré comme la preuve que chaque fournisseur de modèle en amont, chaque route, chaque paramètre de conservation des invites, chaque configuration de compte de l’acheteur ou chaque futur changement de modèle est approuvé.
Utilisez cette liste de contrôle de la portée SOC 2 d’une passerelle API IA lorsque les équipes achats, sécurité, juridique et ingénierie de plateforme doivent décider ce que le rapport doit prouver, ce qu’il ne doit pas prouver, et quelles preuves de suivi doivent figurer dans le dossier d’approbation.
Flatkey est pertinent pour cet examen car le site public actuel présente flatkey.ai comme une passerelle API IA et une plateforme d’opérations de modèles pour acheminer le trafic officiel GPT, Claude, Gemini et d’autres modèles via une seule clé, avec des surfaces de tableau de bord, de facturation, de routage, d’utilisation et de preuve opérationnelle. Les pages publiques de Flatkey et les pages de recherche de certificats ne constituent que des preuves de présélection datées. Pour une approbation en production, demandez le rapport SOC 2 privé, le contrat/DPA signé le cas échéant, les paramètres de compte, la configuration des routes et une confirmation du support pour la charge de travail que vous allez exécuter.
Pour un contexte d’achat plus large, associez cet article à la liste de contrôle des preuves SOC 2 d’une passerelle API IA, au dossier de preuves d’achat d’une passerelle IA et à l’évaluation des risques d’un fournisseur d’API IA.
Portée SOC 2 d’une passerelle API IA : tableau de décision rapide
La première page de l’examen devrait séparer les preuves du rapport des preuves de suivi de l’acheteur.
| Domaine d’examen | Ce que le rapport SOC 2 devrait aider à prouver | Ce qu’il ne devrait pas prouver à lui seul |
|---|---|---|
| Entité juridique | Quelle organisation de services a été examinée | Que chaque société affiliée, revendeur ou fournisseur de modèle en amont est couvert |
| Périmètre du système | Quelle plateforme, quels services, quels emplacements, quelle infrastructure, quelles personnes et quels processus font partie du système décrit | Que chaque fonctionnalité du tableau de bord, famille d’API, route client ou future intégration est dans le périmètre |
| Période du rapport | La période couverte par l’examen Type 2 | Que les contrôles actuels n’ont pas changé après la fin de la période |
| Catégories de services de confiance | Quels critères ont été couverts, comme la sécurité, la disponibilité, la confidentialité, l’intégrité du traitement ou la vie privée | Que les catégories non sélectionnées ont été examinées |
| Contrôles testés | Quels contrôles l’auditeur a testés et les résultats pour la période | Que la configuration de l’acheteur, la politique de route ou la classe de données de la charge de travail ont été testées |
| Exceptions | Si des exceptions de contrôle ont été signalées et comment la direction a réagi | Que les exceptions sont sans importance pour votre charge de travail spécifique |
| Organisations de services tiers | Si les dépendances majeures sont incluses, exclues ou traitées par d’autres rapports | Que la conservation, l’entraînement, la journalisation ou le comportement régional du fournisseur de modèle en amont sont couverts |
| CUEC | Quels contrôles complémentaires de l’entité utilisatrice l’acheteur doit mettre en œuvre | Que le fournisseur est responsable du stockage des clés de l’acheteur, de la rédaction, des listes d’autorisation des fournisseurs ou de la classification des données au niveau de l’application |
C’est la règle essentielle de la portée SOC 2 d’une passerelle API IA : le rapport est une preuve concernant un système d’organisation de services décrit pendant une période définie. Ce n’est pas une approbation générale de chaque route IA que votre équipe pourrait créer.
Verrouillez les cinq champs de portée avant de lire les contrôles
Ne commencez pas par rechercher un avis sans réserve. Commencez par cinq champs.
| Champ | Question de l’acheteur | Preuve à conserver |
|---|---|---|
| Entité | Quelle est l’organisation de services auditée ? | Page de couverture du rapport, entité juridique, contrepartie contractuelle, recherche de certificat si publique |
| Système | Quels services, quelle infrastructure, quelles équipes, quels processus et quels flux de données sont inclus ? | Description du système, liste des produits/services, schéma de périmètre du système |
| Période | Quelle période Type 2 le rapport a-t-il couverte ? | Date de début, date de fin, lettre de transition si nécessaire |
| Critères | Quelles catégories de services de confiance ont été incluses ? | Sécurité, disponibilité, intégrité du traitement, confidentialité, périmètre de confidentialité |
| Dépendances | Quelles organisations de services tiers et quels CUEC affectent l’opinion ? | Méthode inclusive/exclue, liste des sous-services, liste des contrôles de l’acheteur |
Pour une passerelle IA, le champ système mérite le plus d’attention. « Passerelle API » peut signifier uniquement le routage par URL de base, ou aussi inclure l’accès au tableau de bord, le catalogue de modèles, le solde du compte, la mesure de l’utilisation, les journaux de requêtes, les alertes, les flux de support, la réponse aux incidents et la gestion des clés. Le rapport privé devrait vous indiquer ce qui figurait dans la description du système. Si ce n’est pas le cas, demandez au fournisseur de faire correspondre la portée du rapport à la route exacte que vous prévoyez d’utiliser.
Ce qu’un rapport SOC 2 devrait prouver pour une passerelle IA
Un rapport SOC 2 Type 2 cadré devrait aider un acheteur à répondre à ces questions.
| Zone de preuve | Preuves SOC 2 utiles | Traduction pour une passerelle IA |
|---|---|---|
| Conception et fonctionnement des contrôles | Contrôles testés sur la période de rapport | Si les contrôles d’accès, de gestion des changements, de surveillance, de réponse aux incidents, de gestion des fournisseurs et les contrôles associés ont fonctionné pour le système de passerelle décrit |
| Périmètre de disponibilité | Critères de disponibilité, surveillance proche d’un SLA, processus d’incident s’ils sont inclus | Si le service couvert disposait de contrôles définis de surveillance et de réponse, et non si chaque fournisseur de modèle restera disponible |
| Périmètre de confidentialité et de protection de la vie privée | Critères et contrôles si ces catégories sont incluses | Si les contrôles de traitement des données clients ont été examinés pour le système décrit, et non si chaque fonctionnalité d’un fournisseur applique le même paramètre de conservation |
| Gestion des changements | Contrôles testés de mise en production, d’approbation et de changement | Si les changements de code/configuration de la passerelle étaient contrôlés, et non si une route approuvée par l’acheteur ne peut pas être modifiée plus tard par l’acheteur |
| Contrôles d’accès | Accès du personnel, accès privilégié, revue d’administration, contrôles de gestion des comptes | Si l’accès côté fournisseur était contrôlé, et non si l’acheteur stockait les clés API de manière sécurisée |
| Sécurité logique | Contrôles d’authentification, d’autorisation, de journalisation, de vulnérabilités et de surveillance | Si les contrôles de sécurité décrits de la passerelle existaient, et non si les applications de l’acheteur masquent les secrets avant d’envoyer les prompts |
| Gestion des fournisseurs | Organisation de services complémentaires et contrôles de surveillance des fournisseurs | Si les dépendances fournisseurs étaient gérées, et non si chaque SOC 2, DPA ou paramètre de rétention d’un fournisseur en amont couvre votre route |
C’est là que le périmètre SOC 2 d’une passerelle API IA devient concret. Le rapport peut appuyer le filtrage du risque fournisseur. Il doit néanmoins être traduit en faits de route : famille de point de terminaison, classe de données, liste blanche de fournisseurs, politique de repli, journalisation des prompts/sorties, conservation des métadonnées, accès du support et chemin de suppression.
Ce que le rapport ne doit pas prouver
L’erreur d’achat la plus fréquente consiste à laisser un rapport SOC 2 se substituer à des décisions pour lesquelles il n’a pas été conçu.
N’utilisez pas le rapport, à lui seul, pour prouver :
| Affirmation | Pourquoi un complément est nécessaire |
|---|---|
| « Tous les fournisseurs de modèles sont couverts. » | Les fournisseurs en amont peuvent être des organisations de services complémentaires, exclus du périmètre, ou hors du rapport de la passerelle. Demandez la cartographie des fournisseurs et les preuves applicables pour chacun. |
| « Aucun prompt ni aucune sortie n’est stocké nulle part. » | Les journaux de la passerelle, les journaux de surveillance d’abus des fournisseurs, l’état de l’application, les tickets de support et les sauvegardes peuvent avoir des comportements de conservation différents. |
| « Aucune formation ne s’applique à chaque route. » | Les engagements de formation et de conservation sont souvent spécifiques au fournisseur, au compte, au point de terminaison et à la fonctionnalité. Conservez les preuves au niveau du compte. |
| « Le mode de repli est approuvé. » | Une route de repli peut envoyer des données vers un autre fournisseur ou une autre région. L’enregistrement d’approbation doit nommer les fournisseurs de repli autorisés. |
| « L’application de l’acheteur est conforme. » | SOC 2 porte sur les contrôles de l’organisation de services. Le masquage par l’acheteur, le stockage des clés, la classification des données et les contrôles d’accès de l’application relèvent des responsabilités de l’acheteur. |
| « La revue de confidentialité ou de DPA est effectuée. » | SOC 2 n’est pas un DPA signé, une évaluation des transferts de données, une politique de confidentialité, un BAA ou un engagement de traitement régional. |
| « L’état actuel est identique à la période du rapport. » | La période du rapport peut s’être terminée il y a plusieurs mois. Demandez des lettres de continuité, les politiques actuelles, la configuration actuelle des routes et des preuves récentes. |
| « Les prix, la disponibilité du modèle et les résultats SLA sont garantis. » | Les catalogues de modèles, les prix, les limites de débit des fournisseurs et la disponibilité de tiers peuvent changer en dehors du rapport SOC 2. |
Si un fournisseur affirme « SOC 2 couvre cela », demandez-lui de pointer précisément la section, le libellé de la frontière du système, le critère couvert, le contrôle, le résultat du test et toute note CUEC ou d’organisation de services complémentaires.
Lire les organisations de services complémentaires avant d’approuver des fournisseurs
Une passerelle IA peut dépendre de l’hébergement cloud, des systèmes de paiement, des outils d’analyse, des outils de support, des fournisseurs d’observabilité, des outils de sécurité et des fournisseurs de modèles en amont. Le rapport SOC 2 doit expliquer comment les organisations de services complémentaires sont gérées. Les acheteurs voient généralement l’une des deux approches suivantes :
| Méthode | Ce que cela signifie pour l’acheteur |
|---|---|
| Méthode inclusive | Les contrôles pertinents de l’organisation de services complémentaires sont inclus dans le périmètre du rapport. Examinez quels contrôles sont inclus. |
| Méthode d’exclusion | L’organisation de services complémentaires est exclue du périmètre du rapport. Examinez les preuves séparées et les contrôles complémentaires de l’organisation de services complémentaires. |
Pour le routage de modèles, les exclusions comptent. Le rapport SOC 2 d’une passerelle peut couvrir les contrôles de gestion des fournisseurs de la passerelle tout en laissant OpenAI, Anthropic, Google ou un autre fournisseur en amont en dehors du système audité. Cela ne rend pas le rapport inutile. Cela signifie que l’examen du périmètre SOC 2 d’une passerelle API IA doit inclure une ligne de preuves fournisseur pour chaque route approuvée.
La documentation du fournisseur montre pourquoi cela ne peut pas être déduit. La documentation des contrôles de données de l’API d’OpenAI distingue les journaux de surveillance des abus, l’état de l’application, la conservation nulle des données (Zero Data Retention), la surveillance des abus modifiée et les comportements spécifiques aux points de terminaison. La documentation d’Anthropic sur la conservation des données de l’API explique que différentes API et fonctionnalités ont des besoins de stockage différents et que le ZDR est un dispositif que les clients demandent pour les cas d’utilisation éligibles. La documentation de journalisation de Cloudflare AI Gateway montre comment une passerelle peut exposer les prompts, les réponses, le fournisseur, l’horodatage, l’utilisation des jetons, les coûts, la durée, les actions DLP et des contrôles de journalisation au niveau des charges utiles. Ce sont des exemples de surfaces de contrôle qu’un acheteur doit examiner pour tout chemin de passerelle, et non des affirmations sur la portée du rapport privé de Flatkey.
Traitez les CUEC comme un travail de l’acheteur, pas comme du remplissage
Les contrôles complémentaires de l’entité utilisatrice ne sont pas du remplissage. Ce sont les contrôles que l’acheteur doit mettre en œuvre pour que les contrôles de l’organisation de service aient du sens.
Pour une passerelle d’IA, les travaux CUEC côté acheteur courants comprennent :
| Contrôle détenu par l’acheteur | Preuve à conserver |
|---|---|
| Stockage et rotation des clés | Chemin du gestionnaire de secrets, propriétaire, date de rotation, procédure d’intervention pour rotation d’urgence |
| Approbation de route | Familles de points de terminaison approuvées, liste d’autorisation des fournisseurs, politique de repli, classes de données |
| Rédaction des prompts | Règles de rédaction au niveau de l’application, transcript de test, exemples de champs bloqués |
| Revue des accès | Liste des administrateurs, propriétaires des clés, dossier de départ, revue des accès au tableau de bord |
| Politique de journalisation | Détermination de la conservation ou non des prompts et des sorties, règle de métadonnées uniquement, calendrier de rétention |
| Surveillance de l’utilisation | Propriétaire du budget, paramètres de quota, seuils d’alerte, cadence de revue financière |
| Flux de gestion des incidents | Identifiants de requête, chemin d’escalade vers le support, dossier de preuves, propriétaires des notifications |
| Déclencheur de renouvellement | Date de revue et déclencheurs pour de nouveaux fournisseurs, familles de points de terminaison, classes de données ou changements de journalisation |
Une bonne note de portée SOC 2 d’une passerelle API IA devrait rattacher la liste CUEC au travail d’ingénierie. Si l’acheteur doit masquer des secrets avant d’envoyer des prompts, l’approbation devrait renvoyer au test de rédaction. Si l’acheteur doit approuver les fournisseurs de modèles, la configuration de route devrait montrer la liste d’autorisation.
Preuves de présélection spécifiques à Flatkey à demander et à conserver
Les pages publiques actuelles de Flatkey, vérifiées le 11 juillet 2026, soutiennent l’utilisation de Flatkey dans ce flux d’approvisionnement, mais elles ne remplacent pas des preuves propres au compte.
| Preuve | Ce que la vérification publique a montré | Comment l’utiliser |
|---|---|---|
| Page d’accueil | Flatkey positionne publiquement le service autour des API officielles GPT, Claude et Gemini via une seule clé, le routage des modèles, la revue du tableau de bord, la visibilité sur l’utilisation, les coûts, le routage et les erreurs. | À utiliser comme preuve de présélection du produit datée. Ne pas la considérer comme la portée privée du rapport SOC 2. |
| Page de tarification et API de tarification | Les surfaces publiques de tarification/catalogue ont renvoyé une page de tarification en direct et une réponse d’API de tarification avec 158 lignes de modèles et des familles de points de terminaison incluant openai, openai-response, anthropic, image-generation et openai-video. |
À utiliser uniquement comme instantané daté du catalogue. La disponibilité des modèles et des points de terminaison peut changer. |
| Page SLA | Le SLA précise qu’il s’applique au tableau de bord hébergé exploité par Flatkey, à la passerelle API, au routage, à la mesure et aux services de compte, et exclut les fournisseurs tiers de modèles d’IA et autres systèmes externes. | À utiliser pour cadrer ce que Flatkey exploite directement par rapport aux dépendances tierces. |
| Pages de confidentialité et de conditions | Les pages de politique publiques abordent l’accès à l’API, le routage des modèles, les enregistrements d’utilisation, la facturation, le support, les fournisseurs tiers de modèles et la modification des règles relatives aux modèles/fournisseurs. | À utiliser comme preuve de présélection ; l’approbation finale nécessite toujours des conditions signées et une preuve de traitement des données propre à la route. |
| Recherche de certificat | La recherche publique CAI a montré le certificat VOC AI Inc. USA-SOC2-220513, SOC 2 Type II, actif, période du 15 juillet 2025 au 14 juillet 2026. |
À utiliser uniquement comme recherche publique. Demander le rapport SOC 2 réel et confirmer le système couvert, les critères, la période, les exceptions, les CUEC et le traitement des sous-traitants de service. |
Pour Flatkey ou toute passerelle API IA, l’approbation devrait dire : « Pages publiques vérifiées ; rapport privé demandé ; preuves de route jointes ; hypothèses non prises en charge listées. »
Construisez un dossier de preuves de la portée à la route
Le résultat de cette revue devrait être un petit dossier de preuves, et non une approbation vague.
| Élément du dossier | Fichier à conserver | Responsable |
|---|---|---|
| Rapport SOC 2 | Rapport privé, période du rapport, critères, opinion, exceptions, lettre de pont si nécessaire | Achats/sécurité |
| Carte du périmètre | Limite du système du rapport cartographiée vers le tableau de bord, la passerelle, l’API, la métrologie, les journaux, le support et la configuration des routes | Ingénierie de plateforme |
| Carte des fournisseurs | Fournisseurs approuvés, ordre de repli, traitement des sous-services, preuves séparées des fournisseurs | Sécurité/plateforme |
| Carte des données | Prompts, sorties, fichiers, métadonnées, enregistrements de facturation, journaux, tickets de support, sauvegardes | Sécurité/juridique |
| Matrice de conservation | Conservation de la passerelle, du fournisseur, de l’application, du support et des sauvegardes par famille de points de terminaison | Sécurité/juridique |
| Enregistrement des CUEC | Contrôles de l’acheteur et preuve que chacun est mis en œuvre | Plateforme/sécurité |
| Preuves de test | Une requête à faible risque réussie et une défaillance attendue avec les ID de requête et des journaux masqués | Ingénierie de plateforme |
| Mémo d’approbation | Périmètre, restrictions, risques ouverts, noms des relecteurs, déclencheur de renouvellement | Responsable métier/achats |
Ce dossier sert aussi de pont entre l’examen SOC 2 et les opérations d’ingénierie. Lorsqu’un nouveau fournisseur, une nouvelle classe de modèle, un nouveau mode de journalisation ou une nouvelle classe de données est ajouté, l’équipe doit savoir quels fichiers doivent être mis à jour.
Signaux d’alerte qui devraient suspendre l’approbation
Suspendez l’approbation si l’un de ces points n’est pas résolu :
- Le rapport SOC 2 n’est pas उपलब्ध et seul un badge ou une consultation de certificat est fourni.
- La période du rapport est terminée et aucune lettre de pont ni preuve actuelle n’est disponible.
- La description du système n’inclut pas clairement le chemin de passerelle que vous prévoyez d’utiliser.
- Le rapport exclut des organisations de services auxiliaires pertinentes et aucune preuve séparée du fournisseur n’est jointe.
- Les catégories de services de confiance sélectionnées ne correspondent pas au risque déclaré par l’acheteur, comme la confidentialité ou la protection des données.
- Les CUEC exigent des contrôles de l’acheteur qui n’ont pas été mis en œuvre.
- On suppose que la journalisation des prompts/sorties est désactivée, mais aucune preuve de compte ou de route ne le démontre.
- Le repli peut envoyer des données à un fournisseur non approuvé.
- Le support peut inspecter le contenu des requêtes, mais l’accès du support, la conservation des tickets et le masquage ne sont pas documentés.
- L’approbation n’a pas de responsable, de date d’expiration ni de déclencheur de changement de route.
Ces signaux d’alerte ne signifient pas toujours que le fournisseur est en échec. Ils signifient que l’examen de la portée SOC 2 d’une passerelle API IA n’est pas terminé.
Une formulation d’approbation pratique
Une formulation d’approbation utile est courte, précise et vérifiable :
| Champ | Exemple de formulation |
|---|---|
| Preuve du rapport | "Rapport SOC 2 de type 2 examiné pour le fournisseur X, période A à B, critères de sécurité et de disponibilité, aucune exception non acceptée pour cette route." |
| Portée approuvée | "Flux de support textuel de production via l’URL de base de passerelle approuvée et le point de terminaison de chat." |
| Fournisseurs | "Fournisseur A en principal, fournisseur B en repli ; aucun point de terminaison image, vidéo, fichier, recherche web ou lot." |
| Classe de données | "Texte de support client après masquage au niveau de l’application ; aucune donnée de paiement, secret, PHI ou dossier réglementé." |
| Journalisation | "Journaux de métadonnées de la passerelle autorisés ; journalisation brute des prompts/sorties désactivée ou approuvée séparément ; preuves de conservation du fournisseur jointes." |
| Contrôles de l’acheteur | "Clés stockées dans un gestionnaire de secrets, revue d’accès trimestrielle, liste d’autorisation des routes, revue mensuelle de l’utilisation, responsable d’incident désigné." |
| Déclencheur de renouvellement | "Actualiser avant d’ajouter des fournisseurs, d’activer de nouvelles familles de points de terminaison, de modifier la journalisation, d’acheminer des données réglementées ou après l’expiration de la période SOC 2." |
C’est cela que « approuvé » devrait signifier. Les développeurs savent quelle route ils peuvent utiliser. Les achats savent quelles preuves ont été examinées. La sécurité sait quoi surveiller. Le juridique sait quelles hypothèses nécessitent encore une rédaction contractuelle.
En bref
Un examen de la portée SOC 2 d’une passerelle API IA est utile lorsqu’il reste précis. Le rapport doit aider à prouver le système décrit de l’organisation de services auditée, les critères couverts, le fonctionnement des contrôles, la période du rapport, les exceptions, le traitement des sous-services et les responsabilités de l’acheteur. Il ne doit pas être étendu pour prouver chaque route, fournisseur, paramètre de conservation, comportement de repli, clause DPA, affirmation de résidence des données ou configuration de l’acheteur.
Pour Flatkey, commencez par les preuves publiques actuelles, puis demandez le rapport SOC 2 privé et mappez-le à la route que votre équipe utilisera réellement. Si vous souhaitez une seule clé API et un seul tableau de bord pour un accès multi-modèles, obtenez une clé, joignez la liste de contrôle de portée SOC 2 d’une passerelle API IA au dossier d’achat et approuvez chaque route de production avec des preuves explicites du fournisseur, de la journalisation, de la conservation et des CUEC.
Questions fréquentes
Qu’est-ce que la portée SOC 2 d’une passerelle API IA ?
La portée SOC 2 d’une passerelle API IA est la limite du rapport SOC 2 telle qu’elle s’applique à une passerelle API IA. Elle comprend l’entité auditée, le système décrit, la période du rapport, les catégories de services de confiance, les contrôles testés, les organisations de services auxiliaires, les exclusions et les CUEC appartenant à l’acheteur.
Le SOC 2 prouve-t-il que chaque fournisseur de modèle d’IA est couvert ?
Non. SOC 2 peut montrer comment le fournisseur de la passerelle gère le système décrit et ses dépendances, mais les fournisseurs de modèles en amont peuvent être inclus, exclus du périmètre ou couverts par des éléments de preuve distincts. Les acheteurs devraient conserver une cartographie des fournisseurs pour chaque route approuvée.
Un rapport SOC 2 Type 2 prouve-t-il l’absence de conservation des prompts ?
Pas à lui seul. La conservation des prompts et des sorties peut différer selon la passerelle, les fournisseurs en amont, l’état de l’application, les tickets de support, les journaux et les sauvegardes. L’acheteur doit vérifier des preuves de conservation spécifiques au point de terminaison, au compte et à la route.
Que doit demander les achats après avoir vu un badge SOC 2 ?
Demandez le rapport SOC 2 privé, la période couverte par le rapport, les critères couverts, la description du système, les exceptions, le traitement des organisations de services complémentaires, les CUEC, la lettre de transition si nécessaire, la cartographie des fournisseurs, la configuration des routes, les paramètres de journalisation, la matrice de conservation et, le cas échéant, des preuves contractuelles signées et du DPA.
À quelle fréquence l’examen du périmètre doit-il être actualisé ?
Actualisez l’examen du périmètre de la passerelle API IA SOC 2 lorsque la période couverte par le rapport expire, lorsque le fournisseur fournit un nouveau rapport, avant d’ajouter un fournisseur ou une famille de points de terminaison, avant d’acheminer une nouvelle classe de données, lorsque la journalisation ou la conservation changent, et après des incidents matériels.
Sources à examiner
- Page d’accueil Flatkey
- Tarifs Flatkey
- Politique de confidentialité de Flatkey
- Conditions d’utilisation de Flatkey
- Accord de niveau de service de Flatkey
- Recherche de certificat SOC 2 CAI pour USA-SOC2-220513
- Suite de services SOC de l’AICPA
- Critères de services de confiance 2017 de l’AICPA avec points d’attention révisés
- Critères de description SOC 2 2018 de l’AICPA
- Contrôles des données de l’API OpenAI
- API Anthropic et conservation des données
- Journalisation de Cloudflare AI Gateway
