Checklist DPA pour une passerelle IA : questions sur le traitement des données pour les acheteurs de model routing

Une checklist DPA pour une passerelle IA doit faire plus que confirmer qu’un fournisseur dispose d’une page juridique. Pour les acheteurs de model routing, la vraie question est de savoir si l’accord de traitement des données signé correspond au chemin que votre application utilisera réellement : journaux de la passerelle, fournisseurs de modèles en amont, accès du support, routage régional, contrôles de rétention, droits de suppression et notification d’incident.

Utilisez cette checklist DPA pour passerelle IA avant d’approuver une couche d’accès unifiée aux modèles, un DPA de passerelle LLM ou un accord de traitement des données pour une API IA. Ceci n’est pas un conseil juridique. C’est une liste de preuves pratique pour les équipes plateforme, sécurité, achats et juridique qui ont besoin que le DPA soit aligné sur le comportement technique de routage.

Flatkey s’inscrit dans cette revue car le site public actuel positionne flatkey.ai autour d’une seule clé API, d’une URL de base compatible OpenAI à https://router.flatkey.ai/v1, de la visibilité sur l’utilisation et les coûts, des journaux de requêtes, du routage de modèles et de l’accès aux fournisseurs via un seul tableau de bord. Traitez ces pages produit comme des preuves de présélection datées. Pour l’approbation, joignez votre bon de commande signé, votre DPA, les paramètres de votre compte et toute confirmation du support qui contrôle votre charge de travail réelle.

Si vous construisez l’ensemble de contrôle plus large, associez cette revue avec la checklist GDPR pour passerelle API IA, la checklist d’entreprise pour passerelle API IA, la checklist de rétention des données pour API IA et la tarification actuelle de Flatkey.

Checklist DPA pour passerelle IA : commencez par le chemin

La première erreur consiste à examiner le fournisseur de manière générale. Le DPA doit correspondre à un chemin précis. Un chatbot de support, un classificateur de documents par lots, un assistant de codage et un flux de travail multimodal média peuvent avoir des classes de données, des points de terminaison, des conditions de fournisseur, des comportements de stockage et des accès du support différents.

Avant l’examen juridique, figez ces éléments du chemin :

La checklist DPA pour passerelle IA doit se conclure par un enregistrement d’approbation spécifique au chemin, et non par une déclaration générale selon laquelle « l’IA est approuvée ».

Les dix questions sur le traitement des données que les acheteurs doivent poser

Utilisez ces questions comme la checklist DPA de base pour tout fournisseur d’IA lors de l’achat d’une solution de model routing.

Si la réponse change selon l'endpoint, la fonctionnalité, le fournisseur ou le niveau de compte, consignez cette exception dans la checklist DPA de la passerelle IA au lieu de la lisser.

Faire correspondre le langage du DPA au traitement technique

Les contrats de sous-traitance de type article 28 se concentrent sur l'objet, la durée, la nature, la finalité, les catégories de données, les droits du responsable, les instructions du sous-traitant, la confidentialité, la sécurité, les sous-traitants ultérieurs, la suppression ou la restitution, et l'assistance pour les droits des personnes concernées. Ce sont des termes juridiques. Un acheteur de passerelle doit encore les traduire en faits d'ingénierie.

Utilisez cette correspondance :

C'est là que de nombreux examens des accords de traitement des données des API IA échouent. Le DPA peut indiquer qu'un sous-traitant agit sur instruction, tandis que la route du produit permet discrètement un fallback vers plusieurs fournisseurs. L'enregistrement d'approbation devrait préciser quels fournisseurs sont autorisés, lesquels sont bloqués et qui peut modifier cette politique.

Vérifiez la rétention par endpoint et par fonctionnalité

Les contrôles de données des fournisseurs sont souvent spécifiques à une fonctionnalité. La documentation des contrôles de données de la plateforme d'OpenAI décrit les restrictions d'entraînement de l'API, la rétention par défaut de la surveillance des abus, les contrôles Zero Data Retention ou Modified Abuse Monitoring approuvés, ainsi que le comportement de l'état d'application spécifique à l'endpoint. La documentation d'Anthropic sur la rétention des données API sépare le traitement de l'API Claude du traitement via les places de marché cloud et explique l'éligibilité au ZDR selon la fonctionnalité. La documentation ZDR de Gemini Developer API de Google explique les restrictions d'entraînement pour les services payants et les cas, au niveau des fonctionnalités, où les prompts, réponses, fichiers, grounding, état ou comportement du cache peuvent encore compter.

Cela signifie que « nous avons le ZDR » ne suffit pas pour un DPA de passerelle LLM. Demandez :

• L’endpoint exact est-il éligible au contrôle de rétention ?
• Le projet, l’organisation ou le compte exact est-il approuvé ?
• Le routage de secours renvoie-t-il vers un fournisseur ou une fonctionnalité qui n’est pas couvert(e) ?
• Les fichiers, images, audio, vidéo, outils, recherche web, exécution de code, mise en cache du contexte, traitements par lots ou conversations avec état modifient-ils la rétention ?
• Les journaux de surveillance des abus, l’état de l’application, les journaux de la passerelle, les dossiers de support, les dossiers de facturation et les sauvegardes sont-ils traités séparément ?

Pour un routage en production, conservez une matrice de rétention sur une seule ligne :

La checklist DPA pour une passerelle IA n’est complète que lorsque chaque copie conservée a un propriétaire, une raison, ainsi qu’un chemin de suppression ou d’expiration.

Examiner les journaux de la passerelle séparément des conditions du fournisseur

Les journaux de la passerelle sont utiles pour la fiabilité, la maîtrise des coûts, le débogage et la revue d’audit. Ils constituent aussi une surface distincte de traitement des données. La documentation publique des passerelles fournie par les fournisseurs d’infrastructure montre pourquoi les acheteurs devraient poser la question explicitement : les journaux de requêtes peuvent inclure les invites utilisateur, les réponses du modèle, le fournisseur, l’horodatage, le statut, l’utilisation des jetons, le coût, la durée et les métadonnées client, et les limites de conservation des journaux persistants peuvent varier selon le forfait.

Posez ces questions sur la journalisation avant de signer :

• La passerelle peut-elle stocker les invites ou les sorties complètes, ou seulement des métadonnées ?
• La journalisation des invites et des réponses peut-elle être désactivée par routage, environnement, espace de travail ou client ?
• Les champs sensibles peuvent-ils être omis, masqués, hachés ou expurgés avant la journalisation ?
• Les journaux sont-ils copiés dans des outils d’analytique, des entrepôts de données, des alertes, des tickets de support ou des exports ?
• Qui peut consulter les journaux, et chaque accès est-il journalisé ?
• Les journaux peuvent-ils être supprimés plus tôt, exportés pour audit ou exclus des flux de support ?
• Le DPA couvre-t-il les journaux en tant que données client, données système, ou les deux ?

C’est la différence entre un examen juridique du DPA et une checklist opérationnelle DPA pour passerelle IA. Si votre politique de sécurité indique que les invites ne doivent pas être stockées, le routage doit prouver que la passerelle, le fournisseur et les parcours de support respectent la même règle.

Vérifier les sous-traitants et le basculement de fournisseur

Un compte fournisseur direct a généralement une seule chaîne principale de sous-traitants. Un routeur de modèles peut avoir une chaîne plus longue, car une route d’application peut toucher une passerelle, un fournisseur en amont, des outils d’observabilité, une infrastructure de paiement, des outils de support et un hébergement cloud. Si le basculement est activé, une requête peut être envoyée à un second fournisseur lorsque le premier échoue.

Le package DPA devrait répondre à :

Pour les acheteurs de Flatkey, combinez les preuves publiques de la route et des tarifs avec les contrôles spécifiques au compte. Si votre route utilise une seule clé pour plusieurs modèles, les preuves DPA doivent tout de même préciser quels fournisseurs en amont peuvent traiter chaque classe de données approuvée.

Demander des preuves de support, d’incident et d’audit

L’accès au support est facile à négliger parce qu’il intervient généralement après qu’un problème survient. Pour un examen DPA de passerelle, le support fait partie du traitement.

Demandez :

• Le contact support et le chemin d’escalade pour les incidents de sécurité ou de confidentialité.
• Si le personnel de support peut voir les invites, les sorties, les journaux, les fichiers téléchargés, les captures d’écran ou les métadonnées client.
• Si l’accès du support est limité dans le temps, approuvé et journalisé.
• Si des enregistrements de transparence d’accès sont disponibles pour les comptes éligibles.
• Comment les tickets de support sont expurgés lorsqu’ils contiennent des exemples d’invite ou de sortie.
• Quel délai de notification d’incident s’applique selon le DPA, les conditions, le SLA ou l’addendum de sécurité.
• Si le fournisseur aidera pour les demandes des personnes concernées, la suppression, l’exportation et les demandes des régulateurs.

Le cadre de gestion des risques liés à l’IA du NIST est utile ici comme référence de gouvernance, car il encourage les organisations à gouverner, cartographier, mesurer et gérer les risques liés à l’IA au lieu d’approuver un routage une fois pour toutes puis de l’oublier. Pour un routeur de modèles, cela signifie que l’examen du DPA doit être renouvelable. Fixez une date de révision, désignez des responsables des preuves et vérifiez à nouveau les conditions du fournisseur avant des changements majeurs de routage.

Constituer le dossier de preuves

Le résultat pratique est un petit dossier de preuves que les équipes juridiques, sécurité, achats et plateforme peuvent toutes lire.

Pour Flatkey, ajoutez les preuves publiques actuelles depuis la page d’accueil, la politique de confidentialité, la page tarifaire, les conditions, le SLA et le tableau de bord du compte. Les pages publiques peuvent aider les acheteurs à évaluer le service, mais les preuves spécifiques au compte doivent déterminer la décision finale.

Signaux d’alerte qui devraient suspendre l’approbation

Suspendez l’examen du routage si l’un des points suivants reste non résolu :

• Le DPA nomme le fournisseur de la passerelle mais pas le chemin amont du fournisseur de modèle.
• Le repli peut envoyer des données sensibles à un fournisseur non approuvé.
• Les logs de prompts ou de réponses sont activés, mais le DPA ou l’examen de sécurité ne les couvre pas.
• Le fournisseur affirme « pas d’entraînement », mais ne peut pas répondre sur la conservation, l’accès du support, la suppression ou les sous-traitants.
• Le ZDR est promis de manière générale, mais le point de terminaison, la fonctionnalité ou le compte sélectionné n’y est pas éligible.
• Les tickets de support peuvent inclure des prompts bruts sans processus de masquage.
• Les changements de sous-traitants n’ont aucun chemin de notification.
• Le routage régional est supposé mais n’est pas prouvé par le contrat, le paramètre du compte ou des preuves d’utilisation.
• Les exports de tarification, de logs et d’utilisation contiennent des identifiants client qui n’étaient pas inclus dans la carte des données.
• L’approbation n’a ni propriétaire ni date de révision.

Ces signaux d’alerte ne signifient pas toujours que le fournisseur est inutilisable. Ils signifient que la checklist DPA de la passerelle IA n’est pas terminée.

À quoi ressemble une bonne approbation

Un bon dossier d’approbation est court et vérifiable :

Ce format rend le DPA opérationnel. Les développeurs savent ce qu’ils peuvent router. Les achats savent ce qui a été approuvé. La sécurité sait quoi surveiller. Le juridique dispose de preuves plutôt que de promesses dispersées.

Checklist finale DPA de passerelle IA

Avant d’acheter ou d’étendre un routeur de modèles, confirmez les éléments suivants :

• La checklist DPA de la passerelle IA nomme la route exacte, le point de terminaison, la liste des fournisseurs, la politique de repli et la classe de données.
• L’accord de traitement des données de l’API IA couvre les prompts, les réponses, les fichiers, les logs, les métadonnées, les tickets de support, les enregistrements de facturation et les sous-traitants le cas échéant.
• La journalisation de la passerelle et la conservation chez le fournisseur sont examinées comme des systèmes distincts.
• Les affirmations ZDR, absence d’entraînement ou conservation modifiée sont liées au compte, projet, point de terminaison et fonctionnalité exacts.
• Le changement de fournisseur dispose d’une liste d’autorisation, d’un responsable et d’un déclencheur de révision.
• La suppression, l’export, l’accès du support, la notification d’incident et la notification de changement de sous-traitant sont documentés.
• Les pages publiques du fournisseur sont traitées comme des preuves de présélection datées, et non comme un substitut au DPA signé.
• L’approbation a un propriétaire, une date d’expiration et une règle pour les changements de route.

Si votre équipe veut une seule clé API et un seul tableau de bord pour un accès multi-modèles, commencez avec Flatkey et gardez cette checklist DPA de passerelle IA à côté de l’examen technique du routage. Obtenez une clé, confirmez les contrôles de compte actuels et approuvez chaque route avec la même rigueur que pour tout autre sous-traitant de données de production.

Sources à examiner

• Page d’accueil Flatkey
• Tarifs Flatkey
• Politique de confidentialité de Flatkey
• Conditions d’utilisation de Flatkey
• Accord de niveau de service Flatkey
• Guide de l’ICO sur les contrats
• Contrôles des données OpenAI
• Addendum sur le traitement des données d’OpenAI
• API Anthropic et conservation des données
• Rétention zéro des données de l’API Gemini Developer
• Journalisation de Cloudflare AI Gateway
• Tarification de Cloudflare AI Gateway et journaux persistants
• Cadre de gestion des risques liés à l’IA du NIST