Un cabinet de services professionnels a déployé un assistant d'IA proposé par un fournisseur spécialisé, un produit qui aidait ses analystes à rédiger des rapports de recherche, à résumer des documents et à produire des communications destinées aux clients. Le produit du fournisseur avait été évalué selon le processus standard d'évaluation des fournisseurs du cabinet : le fournisseur avait fourni ses réponses au questionnaire de sécurité, confirmé sa conformité SOC 2 et s'était engagé, dans son accord de traitement des données, à chiffrer les transmissions et à ne conserver aucune donnée. L'évaluation était approfondie selon les critères traditionnels. Ce que l'évaluation n'avait pas abordé, c'était le moteur d'IA sous-jacent du fournisseur, le LLM qui faisait fonctionner le produit. Le produit du fournisseur reposait sur l'API GPT-4 d'OpenAI. Chaque requête envoyée par les analystes du cabinet au produit du fournisseur, y compris les documents clients téléversés pour être résumés, les projets de rapports en cours de rédaction et les données clients mentionnées dans les requêtes, était transmise à l'API d'OpenAI dans le cadre de l'appel d'inférence au LLM. L'DPA du fournisseur l'engageait à ne pas conserver lui-même les données. Il ne traitait pas des conditions de traitement des données d'OpenAI. Selon les conditions standard de l'API d'OpenAI en vigueur à l'époque, les entrées de l'API n'étaient pas utilisées par défaut pour l'entraînement, mais l'équipe juridique du cabinet n'avait jamais évalué les conditions d'OpenAI. Plus grave encore, le cabinet n'avait jamais réalisé d'évaluation des risques fournisseurs portant sur OpenAI, alors même que les données de ses clients transitaient par l'infrastructure d'OpenAI à chaque requête de ses analystes.
Qu'est-ce réellement que l'exposition à l'IA par API ?
L'exposition à l'IA par API est le risque pour les données et la sécurité qui apparaît lorsque le produit d'IA d'un fournisseur utilise une API de LLM tierce (comme GPT-4 d'OpenAI, Claude d'Anthropic, Gemini de Google ou Azure OpenAI) comme moteur d'inférence sous-jacent, de sorte que les données de l'entreprise soumises au produit du fournisseur transitent par l'infrastructure du fournisseur de LLM tiers et sont soumises à ses conditions d'utilisation, à ses pratiques de traitement des données et à ses contrôles de sécurité. L'entreprise évalue le fournisseur. Le fournisseur utilise un LLM tiers. Les données de l'entreprise sont transmises au fournisseur de LLM. Le fournisseur de LLM est une quatrième partie que l'entreprise n'a généralement jamais évaluée.
La dimension du risque lié aux quatrièmes parties relève du problème de la chaîne d'approvisionnement. Les cadres de TPRM traditionnels traitent de plus en plus le risque lié aux quatrièmes parties, c'est-à-dire le risque créé par les fournisseurs des fournisseurs. L'exposition à l'IA par API est un schéma de risque lié aux quatrièmes parties précis et en pleine expansion, dans lequel la quatrième partie est un grand fournisseur de LLM. Les obligations de l'entreprise en matière de traitement des données (GDPR, HIPAA, PCI-DSS, engagements contractuels de traitement des données envers ses propres clients) s'appliquent aux données quel que soit l'endroit où elles transitent. Lorsque ces données sont transmises à un fournisseur de LLM quatrième partie, les obligations de l'entreprise en matière de traitement des données s'attachent à une relation qu'elle n'a pas établie et qu'elle n'a peut-être pas évaluée.
Le problème de la localisation des données et du lieu de traitement constitue la dimension de conformité précise. Les fournisseurs d'API de LLM exploitent des centres de données dans plusieurs régions. Le lieu de traitement des appels d'inférence à l'API peut ne pas se situer dans la région qu'imposent les exigences de localisation des données de l'entreprise. Une entreprise soumise à des exigences de localisation des données au titre du GDPR qui transmet des données personnelles à un fournisseur d'API de LLM peut entraîner le traitement de données personnelles hors de l'UE sans que les mécanismes de transfert de données appropriés soient en place, que le traitement des données par le fournisseur lui-même satisfasse ou non aux exigences de localisation.
Le risque d'évolution des conditions d'utilisation est une dimension temporelle. Les conditions d'utilisation des fournisseurs de LLM évoluent au gré de leurs modèles économiques. Les conditions de traitement des données applicables lorsque le fournisseur a évalué son moteur sous-jacent peuvent avoir changé. Des conditions qui interdisaient l'entraînement sur les entrées de l'API à une période donnée peuvent avoir été modifiées lors de mises à jour ultérieures. L'entreprise qui a évalué le fournisseur à un moment donné n'a aucune visibilité continue sur l'éventuelle modification, depuis cette évaluation, des conditions du fournisseur de LLM, qui régissent pourtant le sort des données de l'entreprise.
Le risque de contribution à l'amélioration des modèles est la préoccupation précise à l'origine du scénario d'introduction. Les fournisseurs de LLM ont des incitations commerciales à utiliser les données qui transitent par leurs systèmes pour améliorer leurs modèles, car de meilleurs modèles attirent davantage de clients. Les paramètres par défaut applicables aux clients de l'API peuvent ou non prévoir l'utilisation des entrées de l'API pour l'entraînement, selon le fournisseur, le type de compte et la version des conditions en vigueur. Les entreprises dont les données sensibles ou propriétaires transitent par des API de LLM peuvent contribuer à l'entraînement de modèles de fondation avec ces données, à leur insu et sans leur consentement.
Pourquoi c’est important
L'exposition à l'IA par API est importante pour la TPRM, car l'adoption rapide de produits de fournisseurs fondés sur des LLM a créé une nouvelle catégorie de risque lié aux quatrièmes parties que la plupart des programmes de TPRM n'ont pas traitée de manière systématique. Chaque fournisseur dont le produit d'IA repose sur une API de LLM tierce crée un flux de données vers une quatrième partie que l'entreprise doit évaluer séparément du fournisseur. Dans un contexte où des centaines de fournisseurs de logiciels d'entreprise intègrent des capacités de LLM reposant sur un petit nombre de fournisseurs de LLM, le risque de concentration lié à ces quatrièmes parties est important.
Là où la plupart des équipes se trompent
L'erreur la plus constante consiste à mener à bien les évaluations des produits d'IA des fournisseurs sans demander si le produit utilise une API de LLM tierce, laquelle le cas échéant, et si l'accord de traitement des données conclu par l'entreprise avec le fournisseur couvre le traitement des données par le fournisseur de LLM.
- Évaluation du fournisseur réalisée sans divulgation du moteur LLM sous-jacent
- Fournisseur de LLM (quatrième partie) non évalué
- DPA couvrant le fournisseur mais pas le fournisseur de LLM
- Exigences de localisation des données non suivies à travers l'infrastructure du fournisseur de LLM
- Évolution des conditions du fournisseur de LLM non surveillée
À quoi ressemblent les bonnes pratiques
Les évaluations matures de l'exposition à l'IA par API demandent à chaque fournisseur d'IA de divulguer son moteur LLM sous-jacent, évaluent le fournisseur de LLM en tant que quatrième partie et veillent à ce que l'DPA du fournisseur comprenne des engagements sur le traitement des données par le fournisseur de LLM, notamment en matière de localisation des données, d'exclusion de l'entraînement et de notification des modifications des conditions.
- Exiger la divulgation du moteur LLM sous-jacent lors de l'évaluation des fournisseurs d'IA
- Évaluer le fournisseur de LLM en tant que quatrième partie
- DPA couvrant le traitement des données par le fournisseur de LLM : localisation, exclusion de l'entraînement
- Suivi de la localisation des données à travers l'infrastructure du fournisseur de LLM
- Exigence de notification des modifications des conditions : le fournisseur informe le client si les conditions du fournisseur de LLM changent
Outils
Évaluation du fournisseur de LLM : conditions entreprise d'OpenAI, conditions de l'API d'Anthropic, Azure OpenAI Service (avec DPA entreprise)
Les principaux fournisseurs de LLM proposent des niveaux d'API entreprise assortis d'engagements renforcés en matière de traitement des données, notamment l'exclusion de l'entraînement et des contrôles de localisation des données qui ne sont pas disponibles dans les niveaux d'API standard. Azure OpenAI Service, par exemple, offre les engagements de Microsoft en matière de traitement des données d'entreprise et des contrôles de localisation des données dans l'UE. Pour les professionnels de la TPRM, demander quel niveau de service du fournisseur de LLM le fournisseur utilise (standard ou entreprise) et si un DPA entreprise couvrant le traitement des données est en place constitue une question précise sur le traitement des données par les quatrièmes parties.
Enjeux de gouvernance
Le défi de gouvernance posé par l'exposition à l'IA par API est l'évolution rapide du paysage des fournisseurs. De nouveaux produits de fournisseurs fondés sur des LLM apparaissent en permanence, et les produits existants changent fréquemment de moteur LLM sous-jacent. Une évaluation réalisée aujourd'hui peut ne plus refléter la relation avec le fournisseur de LLM dans six mois. La réponse de gouvernance consiste à inclure la divulgation du moteur LLM sous-jacent comme champ standard des évaluations des risques fournisseurs et à faire de la notification de tout changement de fournisseur de LLM une obligation contractuelle.
- Inclure la divulgation du moteur LLM sous-jacent dans l'évaluation standard des fournisseurs d'IA
- Évaluer le fournisseur de LLM identifié en tant que risque lié aux quatrièmes parties
- Exiger un DPA couvrant le traitement des données par le fournisseur de LLM
- Exiger la notification de tout changement de fournisseur de LLM
- Vérifier l'existence d'un abonnement de niveau entreprise assorti de conditions renforcées de traitement des données
Si vous êtes une petite équipe
Pour chaque fournisseur d'IA, posez une question avant toute autre : votre produit utilise-t-il une API de LLM tierce et, si oui, de quel fournisseur et de quel niveau de service ? Si la réponse est oui, vous devez évaluer un flux de données vers une quatrième partie. Vérifiez si l'DPA du fournisseur couvre le traitement des données par le fournisseur de LLM, et plus précisément s'il comprend des engagements de localisation des données, une exclusion de l'entraînement et l'obligation de vous informer de tout changement de fournisseur de LLM. Ces trois engagements constituent la couverture minimale de l'DPA pour un fournisseur dont le produit transmet vos données à un LLM tiers.
- Demander si le produit utilise une API de LLM tierce et auprès de quel fournisseur
- Vérifier si l'DPA du fournisseur couvre le traitement des données par le fournisseur de LLM
- Vérifier l'existence d'un abonnement de niveau entreprise avec exclusion de l'entraînement
- Exiger la notification de tout changement de fournisseur de LLM
Ce qu’il faut exiger
Demandez directement :
« Votre produit d'IA utilise-t-il une API de LLM tierce et, si oui, de quel fournisseur et de quel niveau de service ? Votre accord de traitement des données conclu avec nous couvre-t-il le traitement de nos données par le fournisseur de LLM, notamment la localisation des données, l'exclusion de l'entraînement et la notification si vous changez de fournisseur de LLM ? »
Preuves attendues
- Divulgation du moteur LLM sous-jacent : fournisseur et niveau de service
- Couverture par l'DPA du traitement des données par le fournisseur de LLM
- Confirmation d'un abonnement de niveau entreprise assorti de conditions renforcées
- Engagement de notification de tout changement de fournisseur de LLM
Un fournisseur qui confirme la sécurité des données doit être invité à divulguer son moteur LLM sous-jacent. Les contrôles de sécurité du fournisseur protègent ses propres systèmes. Les conditions de traitement des données du fournisseur de LLM régissent le sort des données transmises lors de l'appel d'inférence.
Comment le prouver
- Documentation de divulgation du moteur LLM sous-jacent
- Registres d'évaluation du fournisseur de LLM en tant que quatrième partie
- Couverture du fournisseur de LLM par l'DPA
- Registres d'abonnement de niveau entreprise
À retenir
Le fournisseur était certifié SOC 2. Les données étaient chiffrées en transit. Le fournisseur ne conservait rien. Les données étaient transmises à l'API d'OpenAI à chaque appel d'inférence. L'entreprise n'avait jamais évalué OpenAI. L'DPA du fournisseur couvrait le traitement des données par le fournisseur. Les conditions d'OpenAI régissaient ce qui se passait lors de l'appel d'inférence. Les obligations de l'entreprise au titre du GDPR s'appliquaient aux données personnelles de ses clients, quelle que soit l'infrastructure par laquelle elles transitaient. L'exposition à l'IA par API est un risque lié aux quatrièmes parties qui découle du choix du moteur LLM sous-jacent par le fournisseur. Demandez quel est le fournisseur de LLM. Évaluez le fournisseur de LLM. Veillez à ce que l'DPA couvre l'appel d'inférence. La sécurité du fournisseur couvre l'enveloppe. Les conditions du fournisseur de LLM régissent le contenu.