Quel hébergeur de modèle peut voir les documents de vos clients ?

Un jour ou l’autre, un responsable de la protection des données (DPO) de votre client vous pose cette question : lorsque votre produit lit nos politiques, contrats et fichiers fournisseurs, qui d’autre y a accès ? Si votre réponse se limite à « nous utilisons un fournisseur de LLM », la négociation s’enlise. La réponse attendue doit nommer chaque entreprise de la chaîne, son lieu d’hébergement, la durée de conservation du texte et le contrat qui la couvre. Ce guide explique comment obtenir cette réponse et comment nous nous y tenons avant qu’une fonctionnalité lisant des documents ne soit proposée à un client.

Commencez par définir votre rôle

Dans la plupart des produits de conformité, votre client est le responsable de traitement des documents qu’il téléverse, et vous traitez ces données sur ses instructions. Vous êtes donc un sous-traitant, et toute entreprise que vous engagez pour manipuler ces documents devient un sous-traitant supplémentaire, agissant pour le compte de votre client. Si vous utilisez également ces documents à vos propres fins, par exemple pour améliorer vos modèles, vous devenez responsable de traitement pour ce traitement, et le reste de ce guide ne s’applique plus. Décidez quel rôle vous endossez et consignez-le dans votre accord de traitement des données.

La chaîne est plus longue que vous ne le pensez

Un document envoyé par votre produit à un modèle traverse généralement trois entreprises. Votre propre hébergement le reçoit en premier. Un routeur peut ensuite le recevoir, si vous en utilisez un pour accéder à plusieurs modèles via une seule API (OpenRouter est un cas courant). Enfin, un hébergeur d’inférence exécute le modèle et voit l’intégralité du texte. Avec les modèles à poids ouverts, l’hébergeur n’est souvent pas l’entreprise qui a formé le modèle : un même modèle peut être servi par plusieurs hébergeurs dans différents pays, et le routeur peut en choisir un différent à chaque requête, sauf si vous l’en empêchez.

Chacun de ces acteurs qui peut voir le texte est un sous-traitant. Les politiques et les contrats fournisseurs contiennent souvent des données personnelles : un nom d’entreprise seul n’en est pas, mais les signataires, approbateurs et contacts nommés derrière celui-ci le sont, même dans un cadre purement professionnel.

Quatre registres par hébergeur

Il figure sur votre liste de sous-traitants, avec sa localisation, son rôle et le mécanisme de transfert. Si vos clients vous ont donné une autorisation écrite générale pour cette liste dans votre accord de traitement des données (RGPD, art. 28(2)), ajouter un hébergeur qui n’y figure pas signifie que vous devez les en informer à l’avance afin qu’ils puissent s’y opposer, dans le délai de préavis défini par votre accord. Selon l’art. 28(4), vous restez pleinement responsable envers votre client de la performance de chaque sous-traitant.

Vous connaissez le contrat qui le lie et pouvez le produire. Il s’agit soit de votre propre accord avec l’hébergeur, soit de l’accord du routeur qui impose les mêmes obligations de l’art. 28(3) à cet hébergeur. Lisez-le pour vérifier ces obligations : instructions documentées, confidentialité, sécurité, assistance en cas de demandes des personnes concernées ou de violations, suppression à la fin du service, droits d’audit. Demandez également son certificat ISO 27001 ou son rapport SOC 2 ; les DPO des clients les demandent souvent avant même le texte du contrat. Si l’hébergeur est situé en dehors de l’EEE, vérifiez la base juridique du transfert : une décision d’adéquation d’abord (pour un hébergeur américain, vérifiez s’il est certifié dans le cadre du EU-US Data Privacy Framework), sinon les Clauses Contractuelles Types (CCT) de 2021 (Module 3 entre sous-traitants), avec une évaluation d’impact des transferts dans les deux cas pour les CCT.

Vous connaissez sa politique de conservation et d’entraînement des données, ainsi que leur source. La conservation zéro des données (ZDR) signifie que l’hébergeur ne conserve aucune copie de l’invite ou de la réponse après le traitement. Vérifiez si cela provient d’un contrat, d’un paramètre de compte sur le routeur ou d’un flag dans chaque requête. Les trois sont utiles ; ils ne constituent pas les mêmes preuves, et un auditeur vous le demandera. Il en va de même pour « pas d’entraînement sur vos données ». La conservation zéro est également l’une des mesures complémentaires que votre évaluation d’impact des transferts peut citer.

Il apparaît dans vos registres des activités de traitement (RGPD, art. 30(2) pour un sous-traitant, y compris tout transfert en dehors de l’EEE et ses garanties), afin que les registres, la liste des sous-traitants et les contrats racontent la même histoire.

Verrouillez la route, puis prouvez qu’elle est verrouillée

La plupart des routeurs choisissent un hébergeur pour vous et basculent vers un autre lorsqu’il est occupé. C’est pratique pour la disponibilité, mais problématique pour les quatre registres ci-dessus : un basculement vers un hébergeur que vous n’avez jamais listé équivaut à un traitement par un sous-traitant non autorisé, pas seulement à un simple problème de journalisation. Trois paramètres permettent de combler cette faille sur un routeur comme OpenRouter : verrouillez les fournisseurs que vous avez vérifiés, désactivez les basculements vers d’autres fournisseurs, et envoyez les contrôles de données dans chaque requête (pas de collecte de données pour l’entraînement, seuls les points de terminaison à conservation zéro), afin qu’une requête ne pouvant être traitée selon ces conditions échoue plutôt que d’être redirigée ailleurs.

Ensuite, prouvez le verrouillage là où cela compte, en production. Votre configuration indique ce que vous avez prévu ; le fournisseur nommé dans la réponse ou dans vos propres journaux d’appels indique ce qui s’est réellement produit. Consignez lequel vous avez vérifié et quand.

Comment nous procédons avant qu’une fonctionnalité n’atteigne les clients

Cette semaine, nous avons activé l’examen de documents dans ISMS Copilot uniquement pour notre propre compte de test, avant de le proposer aux clients : vous téléversez une politique, un modèle l’examine, et toute conclusion ne reprenant pas mot pour mot le texte du document est supprimée. La fonctionnalité envoie l’intégralité du texte d’un document à un modèle, donc elle passe deux portes avant d’atteindre un compte client. La première s’applique au commit de release exact : chaque hébergeur de modèle configuré pour la route d’examen doit déjà figurer dans la section des sous-traitants de notre accord de traitement des données, dans nos registres des activités de traitement et dans notre inventaire des accords de traitement des données, sinon la release est bloquée et la question remonte au PDG. La seconde vérifie, pour chaque hébergeur qui recevra des documents clients, quel accord le couvre et si nous pouvons le produire sur demande. Les modèles d’examen sont verrouillés sur un hébergeur unique dont l’addendum au traitement des données figure dans nos dossiers, le premier appel de modèle en production a été journalisé comme étant servi par cet hébergeur, et modifier une route implique de repasser par la première porte.

Nous avons rédigé cette porte avec Claude et demandé à ISMS Copilot de l’examiner comme le ferait un auditeur. Il a remis en question une ligne : une décision de risque enregistrée explique pourquoi une lacune est acceptée, mais ce n’est ni un contrat ni une garantie de transfert. Cette distinction est désormais intégrée à la porte.

Si vos clients ont besoin d’un traitement exclusivement dans l’UE

Certains clients n’acceptent aucun transfert en dehors de l’UE pour ce type de contenu (nous avons écrit sur à quoi ressemble cette question pour un consultant en audit). La réponse propre est un fournisseur basé dans l’UE sur un point de terminaison dont l’engagement de traitement dans l’UE figure dans le contrat, et non seulement sur une page web, avec une conservation zéro. Un piège à éviter : un fournisseur peut être basé dans l’UE tout en ayant un point de terminaison par défaut ne précisant pas où s’effectue l’inférence. Mistral, par exemple, propose un point de terminaison global et un point de terminaison lié à l’UE (api.eu.mistral.ai) ; seul le second constitue une réponse de traitement dans l’UE. Orientez votre code vers le point de terminaison dont vous pouvez écrire la région, et faites échouer la requête bruyamment si quelqu’un le modifie.

Et envoyez moins de données. Lorsque la tâche le permet, supprimez ou remplacez les noms avant qu’un document ne quitte votre système (pseudonymisation, RGPD, art. 25 et art. 32). C’est souvent le moyen le moins coûteux de rendre un transfert plus facile à défendre.

Ce que l’API ISMS Copilot fait pour vous

Nous avons développé l’API ISMS Copilot pour les équipes souhaitant des réponses conformes dans leur propre produit sans avoir à reconstruire cette chaîne (comment les plateformes de conformité l’utilisent). Vous choisissez le chemin de traitement en fonction du nom du modèle que vous appelez :

• Mode UE (isms-fast-eu, isms-thinking-eu) : traité par Mistral AI sur son hébergeur d’inférence lié à l’UE, dans le cadre de notre accord commercial de conservation zéro des données avec Mistral, sans transfert du traitement du modèle en dehors de l’EEE.
• Mode global (isms-fast, isms-thinking, isms-mini) : routé via OpenRouter vers un ensemble fermé d’hébergeurs d’inférence, avec conservation zéro des données et pas d’entraînement.

Chaque réponse réussie inclut un en-tête x-isms-processing-region (eu ou global), afin que vous puissiez journaliser et alerter sur le mode de traitement de chaque requête (comment fonctionne la conservation zéro sur l’API). La liste des sous-traitants de l’API et l’accord de traitement des données de l’API sont publics dans notre centre de confiance, afin que vous puissiez copier les informations nécessaires dans votre propre liste au lieu de nous les demander. Les nouveaux comptes éligibles de l’API bénéficient de crédits gratuits pendant la durée de l’offre.

Une courte liste de vérification

1. Définissez votre rôle : sous-traitant pour vos clients, ou responsable de traitement pour toute utilisation que vous faites de leurs documents pour vos propres besoins.
2. Dessinez la chaîne pour chaque fonctionnalité envoyant des documents à un modèle : votre hébergement, le routeur, chaque hébergeur que le routeur peut choisir.
3. Pour chaque hébergeur, constituez les quatre registres : sur votre liste, le contrat qui le lie (avec sa base juridique de transfert), sa politique de conservation et d’entraînement des données avec sa source, dans vos registres des activités de traitement.
4. Verrouillez les hébergeurs que vous avez vérifiés, désactivez les basculements du routeur, envoyez les contrôles de données dans chaque requête, et relisez le verrouillage en production.
5. Proposez un chemin dédié à l’UE sur un point de terminaison lié à l’UE pour les clients qui en ont besoin, rendez ce chemin visible par requête, et envoyez moins de données personnelles lorsque c’est possible.

Si vous développez avec Claude, une première passe consiste à demander à Claude x ISMS Copilot : Claude lit votre code et rédige la liste des sous-traitants, puis ISMS Copilot l’examine et la challenge comme le ferait un auditeur. Vous décidez ensuite ce qui figure sur la liste.