Souveraineté des données et outils de processus IA : quatorze questions à poser à tout fournisseur avant d'uploader un seul document

Les évaluations de fournisseurs IA tendent à se noyer dans des checklists de sécurité génériques qui ont été écrites pour les outils SaaS traditionnels en 2015. La plus grande partie de cette checklist est soit obsolète, soit déjà couverte par SOC 2. Les questions qui discriminent réellement entre les fournisseurs IA sérieux et les autres tombent dans quatre catégories spécifiques, et ce sont les questions auxquelles les fournisseurs faibles peinent à répondre clairement.

Les catégories : résidence des données (où vos données vivent physiquement), entraînement (si vos données sont utilisées pour améliorer les modèles du fournisseur), rétention et suppression (combien de temps les données restent et comment vous les récupérez), accès et violation (qui peut les voir à l'intérieur du fournisseur et ce qui se passe si cela tourne mal). Toute autre question sur le fournisseur est soit en aval de ces quatre, soit une distraction.

• Catégorie 1 : résidence des données (questions 1 à 4). Où, sous quelle juridiction, avec quels sous-traitants.
• Catégorie 2 : entraînement et traitement des modèles (questions 5 à 8). Vos données sont-elles utilisées pour l'entraînement, comment le contexte est-il isolé, qu'en est-il du vector store.
• Catégorie 3 : rétention et suppression (questions 9 à 11). Combien de temps, à quelle vitesse pouvez-vous les récupérer, quelle preuve de suppression.
• Catégorie 4 : accès, audit, violation (questions 12 à 14). Qui les voit en interne, quels journaux existent, ce qui se passe quand quelque chose tourne mal.

La résidence des données est le premier mur de l'évaluation parce que c'est le plus facile à clarifier pour les fournisseurs, et la clarté de la réponse est un signal. Les fournisseurs qui tergiversent ici vous disent qu'ils n'y ont pas pensé, ou qu'ils y ont pensé et n'aiment pas la réponse qu'ils doivent donner.

Question 1 : Dans quels pays nos données sont-elles physiquement stockées au repos ?

La bonne réponse : régions spécifiques, fournisseurs cloud spécifiques, data centers spécifiques si pertinent. Pour un client UE : « Vos données sont stockées dans les régions Frankfurt et Paris d'AWS, avec des sauvegardes dans la région Dublin ». La réponse vague : « Nous utilisons une infrastructure cloud de qualité entreprise ». La seconde réponse est un échec.

Question 2 : Dans quels pays nos données sont-elles traitées, par opposition à stockées ?

Le traitement inclut les appels d'inférence au modèle IA, qui routent souvent par des régions différentes du stockage. Un fournisseur peut stocker à Frankfurt et router l'inférence par une région US, ce qui crée un transfert de données transfrontalier chaque fois que l'IA est utilisée. La bonne réponse nomme les deux localisations séparément et explique la base légale de tout transfert.

Question 3 : Proposez-vous un déploiement UE uniquement ou régional au choix du client ?

Pour les industries réglementées (santé, services financiers, juridique) ou les clients du secteur public UE, le pinning régional est souvent une exigence dure. La bonne réponse : « Oui, sur notre tier Pro et au-dessus, tout le stockage et le traitement se font dans la région UE de votre choix ». La réponse marginale : « Nous pouvons discuter d'arrangements sur mesure en Enterprise ». La mauvaise réponse : « Toute notre infrastructure est aux États-Unis ». La dernière peut rester acceptable pour des cas d'usage internes sans PII, mais vous devriez le savoir.

Question 4 : Qui sont vos sous-traitants, et sous quelle juridiction ?

Chaque fournisseur IA a des sous-traitants : le fournisseur LLM sous-jacent (OpenAI, Anthropic, Google), l'hébergeur, les services spécialisés. Le fournisseur doit maintenir une liste publique ou sur demande. Pour les clients UE, la juridiction de chaque sous-traitant détermine si des clauses contractuelles types ou des décisions d'adéquation s'appliquent. Une bonne réponse inclut la liste complète ; une mauvaise réponse tergiverse autour de « partenaires de confiance ».

Les questions d'entraînement sont là où les réponses des fournisseurs s'effondrent le plus souvent, parce que la réponse honnête est souvent que la politique du fournisseur LLM sous-jacent gouverne, pas celle du fournisseur lui-même. Le fournisseur ne ment pas toujours quand il dit « nous n'entraînons pas sur vos données », mais l'image complète nécessite généralement deux niveaux de réponse : ce que fait le fournisseur, et ce que fait le fournisseur du modèle sous-jacent.

Question 5 : Nos données sont-elles utilisées pour entraîner, fine-tuner ou améliorer vos modèles ?

La seule réponse acceptable pour des cas d'usage business avec des données sensibles est un « non, par défaut, pour tous les clients » clair. Pas « non si vous optez pour le retrait » (qui est une réponse d'ère 2022). Pas « non sauf si anonymisées » (qui est généralement impossible à vérifier). Pas « seulement avec votre consentement » (qui est une échappatoire). Un « non » par défaut clair avec l'engagement dans le DPA est la barre.

Question 6 : Votre fournisseur LLM amont s'entraîne-t-il sur nos données ?

Le fournisseur doit avoir un contrat avec OpenAI, Anthropic, Google, ou qui qu'il utilise, et ce contrat doit interdire l'entraînement sur les données client passées. La bonne réponse nomme le fournisseur, référence le tier API zero-training, et fournit la ligne dans les ToS sous-jacentes. La mauvaise réponse est « nous faisons confiance à notre fournisseur », ce qui ne vous dit rien.

Question 7 : Comment le contexte est-il isolé entre clients au moment de l'inférence ?

Chaque outil IA a une forme de contexte ou de mémoire. Les pipelines RAG ont des vector stores. Les outils de chat ont un historique de conversation. Les outils d'agent ont des journaux d'appels d'outils. La question est de savoir si ceux-ci sont strictement scopés par client (ou par workspace, ou par utilisateur) à chaque couche, y compris les caches et les index. La bonne réponse est spécifique : « Chaque workspace a son propre namespace vectoriel, clé sur l'ID de workspace, sans récupération inter-workspace possible ». La mauvaise réponse est « notre architecture assure l'isolation ».

Question 8 : Si nous fine-tunons un modèle sur nos données, qu'advient-il de ce modèle fine-tuné ?

Si le fournisseur propose du fine-tuning, les poids fine-tunés sont vos données. Ils doivent être scopés à votre compte, utilisables uniquement par votre compte, et supprimables sur demande. Une réponse particulièrement mauvaise ici : « Les modèles fine-tunés bénéficient à tous les clients via des modèles de base améliorés ». C'est le fournisseur qui blanchit vos données dans son avantage concurrentiel.

Les questions de rétention sont celles dont votre équipe conformité a besoin pour le DPA, et celles dont votre équipe ops a besoin pour le jour où vous décidez de changer de fournisseur. Les deux publics ont besoin de chiffres spécifiques et de mécanismes spécifiques, pas de bonnes intentions.

Question 9 : Quelle est la durée de rétention par défaut pour les données client, et est-elle configurable ?

La bonne réponse est une durée spécifique (par exemple, « 30 jours pour les journaux, indéfinie pour les artefacts créés par le client jusqu'à demande de suppression ») avec une configurabilité sur les tiers Pro et Enterprise. La rétention devrait être minimisée pour les journaux, en particulier les journaux de prompts et de complétions qui contiennent du contenu client. Une longue rétention des journaux de prompts est une source courante d'accumulation de données fantômes.

Question 10 : Comment exportons-nous toutes nos données si nous décidons de partir ?

La bonne réponse : export en self-service documenté dans des formats lisibles par machine (JSON, CSV, formats de documents standards), livré dans 48 heures maximum, couvrant tous les artefacts créés par le client. La mauvaise réponse : « Contactez le support, nous pouvons discuter des options d'export ». Le verrouillage par obfuscation est un drapeau rouge que vous devez faire ressortir avant la signature, pas après.

Question 11 : Quand nous demandons la suppression, qu'est-ce qui est exactement supprimé, et selon quel calendrier ?

« Suppression » a des significations variables dans les systèmes cloud. Demandez spécifiquement : les sauvegardes sont-elles purgées dans la fenêtre de rétention, ou le cycle standard de sauvegarde de 30 jours signifie-t-il que des copies résiduelles persistent jusqu'à 30 jours ? Les embeddings vectoriels dérivés de vos données sont-ils supprimés en même temps que les données brutes ? Les journaux dans les systèmes d'observabilité (Datadog, Splunk) sont-ils effacés ? Le bon fournisseur a une procédure de suppression de données écrite et peut citer le calendrier de bout en bout. Le fournisseur vague dit « dans un délai raisonnable ».

Les trois dernières questions portent sur ce qui se passe quand des humains sont impliqués : les salariés du fournisseur accédant aux données client, les auditeurs vérifiant les contrôles, et l'inévitable réponse à incident. Ce sont les questions les plus susceptibles de révéler un écart entre le marketing du fournisseur et son opération réelle.

Question 12 : Qui à l'intérieur de votre entreprise peut accéder à nos données, et dans quelles circonstances ?

La bonne réponse : un rôle nommé minimal (par exemple, « SRE d'astreinte ») avec un accès conditionné à des tickets de support initiés par le client, journalisé en temps réel, et revu trimestriellement. Les ingénieurs n'ont pas d'accès permanent aux données client. Le personnel de support peut voir les métadonnées, pas le contenu, sauf si le client l'autorise explicitement pour un ticket spécifique. La mauvaise réponse : « Nos salariés sont liés par des obligations de confidentialité ». C'est le plancher, pas une politique.

Question 13 : Quels journaux d'audit existent, pouvons-nous y accéder, et pour combien de temps ?

Les journaux d'audit devraient capturer chaque accès aux données client, chaque action administrative, chaque appel API avec portée client. Les clients sur le tier Enterprise devraient pouvoir tirer leurs propres journaux via API ou export pour leur propre SIEM. Une rétention de six mois est le plancher ; douze est mieux. « Nous avons une journalisation complète » sans interface accessible au client est une réponse à cocher, pas un contrôle.

Question 14 : Quel est votre calendrier et processus de notification de violation ?

Pour les clients UE, le RGPD impose une notification au régulateur dans les 72 heures. Pour les clients en industries réglementées, des délais contractuels plus courts s'appliquent souvent. Le fournisseur devrait s'engager à vous notifier dans les 24 à 72 heures après la découverte d'une violation confirmée affectant vos données, avec un processus documenté pour fournir les informations dont vous avez besoin pour mener votre propre analyse de violation. Des délais plus longs, ou « nous notifierons si légalement requis », sont inadéquats.

Sur les quatorze questions, les réponses peuvent raisonnablement varier selon le fournisseur et le tier. Vous pouvez accepter une résidence de données US uniquement pour un cas d'usage interne sans données régulées. Vous pouvez accepter 30 jours de résidus de sauvegarde dans le cadre de l'hygiène cloud standard. Vous pouvez accepter des index vectoriels partagés s'ils sont strictement namespaced. Mais quelques réponses sont toujours rédhibitoires, et si l'une d'elles apparaît, vous partez, quel que soit le prix.

1. Le fournisseur s'entraîne sur vos données par défaut, et l'opt-out n'est pas disponible ou n'est pas dans le DPA.
2. Le fournisseur LLM sous-jacent conserve un droit d'entraînement plus large que ce que les ToS du fournisseur admettent.
3. Il n'y a pas d'export de données en self-service documenté, ou l'export est conditionné à une négociation ou à des frais.
4. L'accès des salariés aux données client est permanent plutôt que juste-à-temps et journalisé.
5. La notification de violation est « selon les exigences légales » sans engagement contractuel de 24 à 72 heures.

Une seule de ces réponses suffit à partir. Deux et vous devriez vous demander pourquoi le fournisseur est encore sur le marché. Le prix de le découvrir plus tard, une fois vos données déjà dans leur système, est toujours plus élevé que le prix d'une conversation d'achat plus dure maintenant.

Un accord de traitement des données est vingt à soixante pages de langage juridique qui a l'air intimidant et est en fait formulaïque. Si vous savez quelles cinq sections lire et quoi y chercher, un opérateur compétent peut évaluer tout DPA en dix minutes. Vous n'avez pas besoin d'un avocat pour la première passe, vous en avez besoin pour les cas limites que la première passe identifie.

1. Finalités de traitement : lisez la liste des finalités spécifiques pour lesquelles le fournisseur traite vos données. « Amélioration du service » et « analytique interne » sont les phrases qui peuvent cacher des usages d'entraînement.
2. Sous-traitants : trouvez la liste des sous-traitants (généralement en annexe). Vérifiez chaque nom. Toute surprise est un drapeau rouge.
3. Transferts transfrontaliers : trouvez le mécanisme de transfert (CCT, décision d'adéquation, consentement de la personne concernée). Si vous êtes UE et que le transfert est vers un pays non adéquat, les CCT doivent être explicitement référencées.
4. Rétention et suppression : trouvez le tableau de rétention. Comparez avec les affirmations marketing du fournisseur. Toute divergence est un drapeau rouge.
5. Notification de violation : trouvez le calendrier et la méthode de notification. Tout ce qui dépasse 72 heures ou est moins spécifique qu'un « e-mail direct à un contact client » est inadéquat.

Si les cinq sections sont propres et spécifiques, le DPA est probablement correct et vous passez le temps restant sur les termes commerciaux (pricing, SLA, sortie). Si l'une des cinq a une clause vague ou hors marché, c'est là que la revue juridique doit se concentrer. Payer un avocat pour revoir un bon DPA de bout en bout est généralement un gaspillage. Payer un avocat pour négocier les deux sections qui ont réellement des problèmes est de l'argent bien dépensé.