Unité 6.6 : Souveraineté de l'IA et le règlement UE sur l'IA
Introduction
L'unité 6.5 a établi l'inférence gérée sur AI Model Hub comme défaut d'entreprise : vous consommez des modèles via un API compatible OpenAI, et la plateforme ne conserve rien. Cette unité répond à la question de conformité qui se trouve sous-jacente à ce choix. Qu'est-ce qui rend exactement un service d'intelligence artificielle hébergé admissible pour une charge de travail réglementée, et où se terminent vos obligations et où commencent celles de la plateforme ? La réponse comporte deux parties : la limite de souveraineté numérique derrière laquelle se trouve le niveau d'intelligence artificielle, qui est la même limite que les unités 1.4 et 2.x ont prise en compte dans la conception, et l'allocation de tâches par rôle dans la chaîne de valeur de l'Acte de l'UE sur l'intelligence artificielle. Ni l'un ni l'autre n'est une fonctionnalité que vous activez. Les deux sont des propriétés que vous prenez en compte lorsque vous décidez de placer une charge de travail sur le niveau d'intelligence artificielle de la plateforme.
1. La limite de souveraineté numérique
La raison pour laquelle AI Model Hub répond aux exigences d'une charge de travail réglementée est la limite derrière laquelle il se situe, et c'est la même limite que l'unité 1.4 a définie comme filtre pour chaque décision ultérieure. Trois propriétés la définissent.
Tout d'abord, le traitement dans le pays. Pour AI Model Hub, tout le traitement et l'inférence des données se font exclusivement en Allemagne ; le service et ses bases de données vectorielles gérées fonctionnent dans des centres de données allemands certifiés ISO 27001 (limitez la créance à ce service et à cet emplacement plutôt que de la généraliser à l'ensemble de la plateforme). Les invites, les entrées et tout document téléchargé pour récupération ne quittent jamais cette juridiction.
Deuxièmement, l'étatlessness. AI Model Hub fonctionne comme un service sans état : les invites et les sorties sont supprimées à la fin de chaque session et ne sont pas enregistrées, ni consignées, ni réutilisées pour la formation de modèles. Chaque session se tient seule. C'est ce qui vous permet de placer des invites sensibles via le hub sans créer une nouvelle surface de rétention à gérer.
Troisièmement, pas de formation sur les données client. Les données client ne sont pas utilisées pour la formation dans aucune circonstance. C'est la propriété qui sépare un service d'intelligence artificielle souverain de l'UE d'une préoccupation courante des hyperscaleurs qui font que les invites alimentent l'amélioration d'un modèle de fournisseur. Le plan d'inférence consomme votre entrée pour produire une réponse et ne garde rien qui pourrait intégrer vos données dans un modèle partagé.
Définissez chacune de ces propriétés avec précision, comme l'a insisté l'unité 6.5 pour la revendication ISO 27001. Elles sont attachées au service d'inférence géré dans les centres de données allemands ; ce ne sont pas des déclarations générales sur tout ce que la plateforme exécute. Lorsque vous documentez le contrôle pour un auditeur, nommez le service et l'emplacement, et non "la plateforme".
2. Rôles de l'Acte IA de l'UE le long de la chaîne de valeur
L'Acte IA de l'UE attribue des obligations en fonction du rôle, et la plateforme documente explicitement sa position afin que vous puissiez raisonner sur la vôtre. Le corpus couvre cela en détail, donc les rôles ci-dessous sont documentés plutôt que 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 s'ensuit est la vôtre : vous devez effectuer votre propre évaluation des risques pour déterminer si votre application spécifique est à risque limité ou élevé en vertu de l'Acte, et mettre en œuvre les contrôles que cette classification nécessite. La plateforme fournit la base technique (hooks de journalisation de niveau API que vous pouvez connecter à votre propre trace d'audit, et des API suffisamment flexibles pour construire une surveillance humaine), mais elle ne fait pas la classification pour vous.
La plateforme elle-même occupe l'un des deux rôles suivants, en fonction du modèle :
| Modèle sur la plateforme | Rôle de l'Acte IA de l'UE de la plateforme | 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 contient des liens vers la carte de modèle officielle et la licence du développeur d'origine, afin que vous puissiez accéder aux informations autorisées sur les données de formation et les capacités. |
| Modèle que la plateforme modifie (par exemple, quantification FP8) | Fournisseur d'IA | La plateforme assume des obligations de transparence supplémentaires pour sa propre modification : documentation identifiant le modèle de base et la nature du changement, 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 l'instant où la plateforme modifie un modèle, par exemple en le quantifiant en FP8 pour qu'il fonctionne plus efficacement, 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 rédigée par la plateforme sur le changement, tandis qu'un modèle non modifié vous renvoie à la documentation du développeur en amont comme source autorisée. Dans les deux cas, vos obligations de Déployeur en aval restent les vôtres ; le rôle de la plateforme détermine uniquement d'où provient la documentation autorisée du modèle.
Étude de cas d'entreprise (FinCorp)
L'assistant de FinCorp pour les clients, conçu dans l'unité 6.5, s'exécute en tant que RAG sur AI Model Hub : un modèle de stock basé sur le corpus propre de FinCorp, sans rien retenir entre les sessions et tout le traitement se fait en Allemagne. La limite de souveraineté est ce qui le rend admissible en vertu de la posture GDPR et BSI de FinCorp : les invites transportant des données client ne quittent jamais la juridiction allemande, le plan sans état ne crée pas de nouvelle surface de rétention, et rien de ce que FinCorp envoie n'est utilisé pour former un modèle partagé.
Les décisions de conformité qui suivent sont des décisions de rôle. Pour le règlement de l'UE sur l'IA, FinCorp est le déployeur d'un assistant pour les clients et effectue sa propre évaluation Limited-Risk versus High-Risk ; la plateforme ne classe pas l'application pour cela. Pour le modèle spécifique qu'il sélectionne, FinCorp enregistre si la plateforme agit en tant que distributeur (un modèle non modifié, avec une documentation autoritaire en amont) ou, s'il a choisi une variante quantifiée, en tant que fournisseur (un modèle modifié par la plateforme, avec une documentation rédigée par la plateforme sur le changement), et classe la documentation correspondante du modèle dans son dossier de conformité. L'assistant reste sur le hub, à l'intérieur d'une limite souveraine, hébergée en Allemagne, et le dossier de conformité de FinCorp nomme le service, l'emplacement et la provenance du modèle plutôt qu'une revendication de "certifié" à l'échelle de la plateforme.
Résumé de la décision
| Décision | Faites ceci | Quand |
|---|---|---|
| Placement d'une charge de travail réglementée sur le niveau AI | Confirmer que la limite des trois propriétés s'applique | Toujours. Le traitement en pays (allemand), l'inférence sans état et l'absence de formation sur les données client sont ce qui rend le hub admissible. |
| Documentation du contrôle de souveraineté | Délimiter à l'étendue du service et de l'emplacement | Toujours. Les réclamations de ISO 27001 et de traitement s'attachent à AI Model Hub dans ses centres de données allemands, et non à la plateforme dans son ensemble. |
| Loi AI de l'UE, votre rôle | Déployeur (ou fournisseur de votre propre système) | Toujours. Exécutez votre propre évaluation Limited-Risk vs High-Risk ; la plateforme ne classe pas votre application. |
| Loi AI de l'UE, sélection de modèle | Enregistrer le rôle de la plateforme pour le modèle choisi | Toujours. Distributeur (documents en amont non modifiés) vs Fournisseur (plateforme modifiée, par exemple quantification FP8, documents rédigés par la plateforme). |
Résumé
AI Model Hub répond aux exigences d'une charge de travail réglementée en raison de la limite dans laquelle il se trouve, la même limite que le cours a maintenue depuis l'Unité 1.4 : le 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 former des modèles partagés. Appliquez ces propriétés au service et à l'emplacement plutôt que de les lire comme une certification à l'échelle de la plateforme. Selon l'Acte AI de l'UE, vous êtes le Déployeur et vous possédez 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 étant le cas où ses obligations de transparence s'étendent et où la documentation autoritaire du modèle devient rédigée par la plateforme plutôt que par l'amont.
Points clés :
- La limite de souveraineté est constituée de trois propriétés : le traitement dans le pays (allemand), un service d'inférence sans état qui ne conserve rien, et l'absence d'utilisation des données des clients pour la formation dans toute circonstance.
- Appliquez les revendications de souveraineté et de ISO 27001 à AI Model Hub dans ses centres de données allemands ; elles ne constituent pas une déclaration à l'échelle de la plateforme.
- Selon l'Acte AI de l'UE, vous êtes le Déployeur et vous possédez la classification Limited-Risk vs High-Risk de votre application ; la plateforme ne la fait pas pour vous.
- La plateforme est un Distributeur pour les modèles non modifiés (en référence à la documentation amont) et devient un Fournisseur, avec des obligations de transparence accrues, pour les modèles qu'elle modifie, tels que la quantification FP8.
- Le rôle applicable détermine uniquement l'origine de la documentation autoritaire du modèle ; vos obligations de Déployeur en aval restent les vôtres dans les deux cas.
Terminologie importante :
- Limite de souveraineté des données : la combinaison du traitement dans le pays, de l'absence d'état et de l'absence de formation sur les données des clients qui qualifie le service AI géré pour une charge de travail réglementée.
- Absence d'état : la propriété qui provoque la suppression des invites et des sorties par session et qui ne les enregistre jamais, ne les enregistre pas ou ne les réutilise pas pour la formation.
- Déployeur (Acte AI de l'UE) : l'entité qui met un système d'IA en service et possède la classification des risques et les obligations en aval pour son application.
- Distributeur vs Fournisseur (Acte AI de l'UE) : 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 (auteur de sa propre documentation de transparence).
Lecture supplémentaire
- Unité 6.5 : Inférence IA (AI Model Hub géré) - le service d'inférence dont la souveraineté et la posture de conformité que cette unité examine
- Unité 1.4 : Souveraineté et conformité en tant que données de conception, et unités de gouvernance du Module 2 - la base de la souveraineté renforcée ici