Unité 6.6 : Souveraineté de l'IA et le Règlement européen sur l'IA
Introduction
L'Unité 6.5 a établi l'inférence gérée sur AI Model Hub comme défaut en entreprise : vous consommez des modèles via une API compatible OpenAI, et la plateforme ne conserve rien. Cette unité répond à la question de conformité qui sous-tend ce choix. Qu'est-ce qui rend exactement un service d'IA hébergé admissible pour une charge de travail réglementée, et où vos obligations prennent-elles fin et celles de la plateforme commencent-elles ? La réponse comporte deux volets : la frontière de souveraineté des données derrière laquelle se situe la couche IA, qui est la même frontière que les Unités 1.4 et 2.x ont prise comme entrée de conception, et l'allocation des devoirs par rôle le long de la chaîne de valeur par le Règlement européen sur l'IA. Aucun des deux n'est une fonctionnalité que l'on active. Les deux sont des propriétés sur lesquelles vous raisonnez lorsque vous décidez de placer une charge de travail sur la couche IA de la plateforme.
1. La frontière de la souveraineté des données
La raison pour laquelle AI Model Hub est éligible à une charge de travail réglementée réside dans la frontière derrière laquelle il se situe, et c'est la même frontière que l'Unité 1.4 a définie comme filtre pour chaque décision ultérieure. Trois propriétés la définissent.
Premièrement, le traitement dans le pays. Pour AI Model Hub, tout le traitement des données et l'inférence se produisent exclusivement en Allemagne ; le service et ses bases de données vectorielles gérées s'exécutent dans des centres de données allemands certifiés ISO 27001 (limitez la portée de l'attestation à ce service et à cette localisation, plutôt que de la généraliser à l'ensemble de la plateforme). Les invites, les entrées et tout document téléversé pour la récupération ne quittent jamais cette juridiction.
Deuxièmement, l'absence d'état. AI Model Hub fonctionne en tant que service sans état : les invites et les sorties sont supprimées à la fin de chaque session et ne sont ni journalisées, ni enregistrées, ni réutilisées pour l'entraînement des modèles. Chaque session est autonome. C'est ce qui vous permet de transmettre des invites sensibles via le hub sans créer une nouvelle surface de rétention à gouverner.
Troisièmement, aucun entraînement sur les données clients. Les données clients ne sont utilisées pour l'entraînement dans aucune circonstance. C'est la propriété qui distingue un service d'IA souverain de l'UE de la préoccupation courante liée aux hyperscalers, à savoir que les invites alimentent l'amélioration du modèle d'un fournisseur. Le plan d'inférence consomme votre entrée pour produire une réponse et ne conserve rien qui pourrait intégrer vos données dans un modèle partagé.
Définissez précisément la portée de chacune de ces propriétés, comme l'Unité 6.5 l'a exigé pour l'affirmation ISO 27001. Elles s'appliquent au service d'inférence géré dans ses centres de données allemands ; elles ne constituent pas une déclaration générale concernant tout ce que la plateforme exécute. Lorsque vous documentez le contrôle pour un auditeur, nommez le service et la localisation, et non « la plateforme ».
2. Rôles de la loi européenne sur l'IA dans la chaîne de valeur
La loi européenne sur l'IA attribue des obligations selon le rôle, et la plateforme documente explicitement sa position afin que vous puissiez raisonner sur la vôtre. Le corpus aborde ce point en détail, les rôles ci-dessous sont donc documentés et non déduits.
En tant que client qui construit sur le service, vous êtes un Déployeur, et vous pouvez devenir un Fournisseur de votre propre système d'IA. La responsabilité qui en découle est la vôtre : vous devez mener votre propre évaluation des risques pour déterminer si votre application spécifique est à risque limité ou à risque élevé au titre de la loi, et mettre en œuvre les contrôles que cette classification exige. La plateforme fournit les fondations techniques (des points de journalisation au niveau de l'API que vous pouvez connecter à votre propre piste d'audit, et des API suffisamment flexibles pour construire une supervision avec intervention humaine), mais elle ne fait pas la classification à votre place.
La plateforme elle-même assume l'un des deux rôles suivants, selon le modèle :
| Modèle sur la plateforme | Rôle de la plateforme au titre de la loi européenne sur l'IA | Ce que cette obligation signifie |
|---|---|---|
| Modèle open source non modifié (la majorité) | Distributeur / intermédiaire | Transparence dans la chaîne d'approvisionnement : chaque page de modèle résume le modèle et renvoie vers la fiche modèle officielle et la licence du développeur d'origine, afin que vous puissiez accéder aux informations faisant autorité sur les données d'entraînement et les capacités. |
| Modèle modifié par la plateforme (par exemple, quantification FP8) | Fournisseur d'IA | La plateforme assume des obligations de transparence supplémentaires pour sa propre modification : une documentation identifiant le modèle de base et la nature de la modification, ainsi que sa propre documentation technique pour le modèle modifié. |
Le point architecturalement important est le changement dans la deuxième ligne. Dès que la plateforme modifie un modèle, par exemple en le quantifiant en FP8 pour un fonctionnement plus efficace, elle cesse d'être un distributeur de transit et devient un Fournisseur pour ce modèle spécifique, en assumant des obligations de transparence qu'elle ne porte pas pour les modèles non modifiés. Lorsque vous sélectionnez un modèle, vérifiez quel rôle s'applique : un modèle modifié est accompagné d'une documentation de la modification rédigée par la plateforme, tandis qu'un modèle non modifié vous renvoie vers la documentation du développeur amont comme source faisant autorité. Dans tous les cas, vos obligations en aval en tant que Déployeur restent les vôtres ; le rôle de la plateforme détermine uniquement d'où provient la documentation du modèle faisant autorité.
Étude de cas d'entreprise (FinCorp)
L'assistant destiné aux clients de FinCorp, conçu dans l'Unité 6.5, fonctionne en mode RAG sur AI Model Hub : il s'agit d'un modèle standard ancré dans le corpus propre à FinCorp, sans aucune donnée conservée entre les sessions et avec un traitement intégral effectué en Allemagne. C'est la frontière de souveraineté qui rend cette configuration admissible au regard de la posture RGPD et BSI de FinCorp : les requêtes contenant des données clients ne quittent jamais la juridiction allemande, le plan sans état ne crée aucune nouvelle surface de rétention, et rien de ce que FinCorp envoie n'est utilisé pour entraîner un modèle partagé.
Les décisions de conformité qui en découlent sont des décisions liées aux rôles. Au titre du Règlement européen sur l'IA, FinCorp est le Déployeur d'un assistant destiné aux clients et effectue elle-même son évaluation du risque limité par rapport au risque élevé ; la plateforme ne classe pas l'application à sa place. Pour le modèle spécifique qu'elle sélectionne, FinCorp consigne si la plateforme agit en tant que Distributeur (modèle non modifié, avec une documentation faisant autorité en amont) ou, s'il a choisi une variante quantifiée, en tant que Fournisseur (modèle modifié par la plateforme, avec une documentation rédigée par la plateforme décrivant la modification), et dépose la documentation du modèle correspondante dans son dossier de conformité. L'assistant reste sur le hub, à l'intérieur d'une frontière souveraine unique hébergée en Allemagne, et le dossier de conformité de FinCorp identifie le service, l'emplacement et la provenance du modèle, plutôt qu'une affirmation de « certification » à l'échelle de la plateforme.
Résumé des décisions
| Décision | À faire | Quand |
|---|---|---|
| Déploiement d'une charge de travail réglementée sur la couche IA | Vérifier que la frontière à trois propriétés s'applique | Toujours. Le traitement au sein du pays (Allemagne), l'inférence sans état et l'absence d'entraînement sur les données clients sont les éléments qui rendent le hub admissible. |
| Documentation du contrôle de souveraineté | En limiter le périmètre au service et à l'emplacement | Toujours. Les déclarations relatives à l'ISO 27001 et au traitement sont rattachées à AI Model Hub dans ses centres de données allemands, et non à la plateforme dans son ensemble. |
| Règlement européen sur l'IA, votre rôle | Déployeur (ou Fournisseur de votre propre système) | Toujours. Effectuez votre propre évaluation des risques limités par rapport aux risques élevés ; la plateforme ne classe pas votre application. |
| Règlement européen sur l'IA, sélection du modèle | Documenter le rôle de la plateforme pour le modèle choisi | Toujours. Distributeur (non modifié, documentation en amont) par rapport à Fournisseur (modifié par la plateforme, par exemple quantification FP8, documentation rédigée par la plateforme). |
Résumé
AI Model Hub est éligible à une charge de travail réglementée en raison de la limite qu'il franchit, la même limite que le cours a maintenue depuis l'Unité 1.4 : un traitement confiné aux centres de données allemands, un plan d'inférence sans état qui ne conserve rien, et une garantie absolue que les données des clients ne sont jamais utilisées pour entraîner des modèles partagés. Restreignez ces propriétés au service et à l'emplacement, plutôt que de les interpréter comme une certification à l'échelle de la plateforme. En vertu du Règlement européen sur l'IA, vous êtes le Déployeur et vous assumez votre évaluation des risques, tandis que la plateforme est un Distributeur pour les modèles non modifiés et un Fournisseur pour ceux qu'elle modifie, ce dernier cas étant celui où ses obligations de transparence s'étendent et où la documentation autorisée du modèle devient rédigée par la plateforme plutôt que par l'amont.
Points clés :
- La limite de souveraineté repose sur trois propriétés : un traitement dans le pays (Allemagne), un service d'inférence sans état qui ne conserve rien, et aucune utilisation des données des clients pour l'entraînement, dans aucune circonstance.
- Restreignez les affirmations de souveraineté et de conformité ISO 27001 à AI Model Hub dans ses centres de données allemands ; elles ne constituent pas une déclaration à l'échelle de la plateforme.
- En vertu du Règlement européen sur l'IA, vous êtes le Déployeur et vous assumez la classification de votre application en Risque Limité ou Risque Élevé ; la plateforme ne la fait pas à votre place.
- La plateforme est un Distributeur pour les modèles non modifiés (renvoyant vers la documentation amont) et devient un Fournisseur, avec des obligations de transparence supplémentaires, pour les modèles qu'elle modifie, tels que la quantification FP8.
- Le rôle applicable détermine uniquement la source de la documentation autorisée du modèle ; vos obligations en aval en tant que Déployeur vous incombent dans tous les cas.
Terminologie importante :
- Limite de souveraineté des données : la combinaison du traitement dans le pays, de l'absence d'état et de l'interdiction d'entraîner sur les données des clients, qui qualifie le service IA managé pour une charge de travail réglementée.
- Absence d'état : la propriété selon laquelle les requêtes et les sorties sont supprimées par session et ne sont jamais journalisées, enregistrées ou réutilisées pour l'entraînement.
- Déployeur (Règlement européen sur l'IA) : l'entité qui met un système d'IA en service et qui assume la classification des risques et les obligations en aval pour son application.
- Distributeur vs Fournisseur (Règlement européen sur l'IA) : le rôle de la plateforme par modèle ; Distributeur pour les modèles non modifiés (liens vers la documentation amont), Fournisseur pour les modèles qu'elle modifie (rédige sa propre documentation de transparence).
Lectures complémentaires
- Unité 6.5 : AI Inference (Managed Model Hub) : le service d'inférence dont l'attitude en matière de souveraineté et de conformité est examinée dans cette unité
- Unité 1.4 : La souveraineté et la conformité comme entrées de conception, et les unités de gouvernance du Module 2 : le fondement de la souveraineté renforcé ici