Unit 6.6: AI Sovereignty and the EU AI Act
Introduction
Unit 6.5 established managed inference on AI Model Hub as the enterprise default: you consume models through an OpenAI-compatible API, and the platform retains nothing. This unit answers the compliance question that sits underneath that choice. What exactly makes a hosted AI service admissible for a regulated workload, and where do your obligations end and the platform's begin? The answer has two parts: the data-sovereignty boundary the AI tier sits behind, which is the same boundary Units 1.4 and 2.x made a design input, and the EU AI Act's allocation of duties by role across the value chain. Neither is a feature you switch on. Both are properties you reason about when you decide to place a workload on the platform's AI tier at all.
1. The Data-Sovereignty Boundary
The reason AI Model Hub qualifies for a regulated workload at all is the boundary it sits behind, and it is the same boundary Unit 1.4 set as a filter over every later decision. Three properties define it.
First, in-country processing. For AI Model Hub, all data processing and inference occur exclusively in Germany; the service and its managed vector databases run in ISO 27001-certified German data centers (scope the credential to that service and location rather than generalising it across the platform). Prompts, inputs, and any documents uploaded for retrieval never leave that jurisdiction.
Second, statelessness. AI Model Hub operates as a stateless service: prompts and outputs are discarded at the end of each session and are not logged, not recorded, and not reused for model training. Each session stands alone. This is what lets you place sensitive prompts through the hub without creating a new retention surface to govern.
Third, no training on customer data. Customer data is not used for training under any circumstance. This is the property that separates a sovereign EU AI service from the common hyperscaler concern that prompts feed a vendor's model improvement. The inference plane consumes your input to produce an answer and keeps nothing that could fold your data into a shared model.
Scope each of these precisely, as Unit 6.5 insisted for the ISO 27001 claim. They attach to the managed inference service in its German data centers; they are not a blanket statement about everything the platform runs. When you document the control for an auditor, name the service and the location, not "the platform".
2. EU AI Act Roles Across the Value Chain
The EU AI Act assigns obligations by role, and the platform documents its position explicitly so you can reason about your own. The corpus covers this in detail, so the roles below are documented rather than inferred.
As the customer building on the service, you are a Deployer, and you may become a Provider of your own AI system. The responsibility that follows is yours: you must conduct your own risk assessment to determine whether your specific application is Limited-Risk or High-Risk under the Act, and implement the controls that classification requires. The platform supplies the technical foundation (API-level logging hooks you can wire to your own audit trail, and APIs flexible enough to build human-in-the-loop oversight), but it does not make the classification for you.
The platform itself holds one of two roles depending on the model:
| Model on the platform | Platform's EU AI Act role | What that obligation means |
|---|---|---|
| Unmodified open-source model (the majority) | Distributor / intermediary | Transparency in the supply chain: each model page summarises the model and links to the original developer's official model card and license, so you can reach the authoritative training-data and capability information. |
| Model the platform modifies (for example FP8 quantization) | AI Provider | The platform assumes additional transparency obligations for its own modification: documentation identifying the base model and the nature of the change, plus its own technical documentation for the modified model. |
The architecturally important point is the shift in the second row. The moment the platform changes a model, for instance by quantizing it to FP8 to run more efficiently, it stops being a passthrough distributor and becomes a Provider for that specific model, taking on transparency duties it does not carry for unmodified models. When you select a model, check which role applies: a modified model comes with platform-authored documentation of the change, whereas an unmodified model points you to the upstream developer's documentation as the authoritative source. Either way, your downstream Deployer obligations remain yours; the platform's role determines only where the authoritative model documentation comes from.
Enterprise Case Study (FinCorp)
FinCorp's customer-facing assistant, designed in Unit 6.5, runs as RAG on AI Model Hub: a stock model grounded in FinCorp's own corpus, with nothing retained between sessions and all processing in Germany. The sovereignty boundary is what makes that admissible under FinCorp's GDPR and BSI posture: prompts carrying customer data never leave German jurisdiction, the stateless plane creates no new retention surface, and nothing FinCorp sends is used to train a shared model.
The compliance decisions that follow are role decisions. For the EU AI Act, FinCorp is the Deployer of a customer-facing assistant and runs its own Limited-Risk versus High-Risk assessment; the platform does not classify the application for it. For the specific model it selects, FinCorp records whether the platform is acting as Distributor (an unmodified model, with authoritative documentation upstream) or, if it picked a quantized variant, as Provider (a platform-modified model, with platform-authored documentation of the change), and files the corresponding model documentation in its compliance record. The assistant stays on the hub, inside one sovereign, German-hosted boundary, and FinCorp's compliance file names the service, the location, and the model's provenance rather than a platform-wide "certified" claim.
Decision Summary
| Decision | Do this | When |
|---|---|---|
| Placing a regulated workload on the AI tier | Confirm the three-property boundary applies | Always. In-country (German) processing, stateless inference, and no training on customer data are what make the hub admissible. |
| Documenting the sovereignty control | Scope it to the service and location | Always. The ISO 27001 and processing claims attach to AI Model Hub in its German data centers, not to the platform as a whole. |
| EU AI Act, your role | Deployer (or Provider of your own system) | Always. Run your own Limited-Risk vs High-Risk assessment; the platform does not classify your application. |
| EU AI Act, model selection | Record the platform's role for the chosen model | Always. Distributor (unmodified, upstream docs) vs Provider (platform-modified, e.g. FP8 quantization, platform-authored docs). |
Summary
AI Model Hub qualifies for a regulated workload because of the boundary it sits behind, the same boundary the course has carried since Unit 1.4: processing confined to German data centers, a stateless inference plane that retains nothing, and an absolute guarantee that customer data is never used to train shared models. Scope those properties to the service and location rather than reading them as a platform-wide certification. Under the EU AI Act you are the Deployer and own your risk assessment, while the platform is a Distributor for unmodified models and a Provider for those it modifies, the latter being the case where its transparency obligations expand and where the authoritative model documentation becomes platform-authored rather than upstream.
Key Points:
- The sovereignty boundary is three properties: in-country (German) processing, a stateless inference service that retains nothing, and no use of customer data for training under any circumstance.
- Scope the sovereignty and ISO 27001 claims to AI Model Hub in its German data centers; they are not a platform-wide statement.
- Under the EU AI Act you are the Deployer and own the Limited-Risk vs High-Risk classification of your application; the platform does not make it for you.
- The platform is a Distributor for unmodified models (pointing to upstream documentation) and becomes a Provider, with added transparency obligations, for models it modifies such as FP8 quantization.
- Which role applies determines only where authoritative model documentation comes from; your downstream Deployer obligations remain yours either way.
Important Terminology:
- Data-sovereignty boundary: the combination of in-country processing, statelessness, and no-training-on-customer-data that qualifies the managed AI service for a regulated workload.
- Statelessness: the property that prompts and outputs are discarded per session and never logged, recorded, or reused for training.
- Deployer (EU AI Act): the entity that puts an AI system into use and owns the risk classification and downstream obligations for its application.
- Distributor vs Provider (EU AI Act): the platform's role per model; Distributor for unmodified models (links to upstream documentation), Provider for models it modifies (authors its own transparency documentation).
Further Reading
- Unit 6.5: AI Inference (Managed Model Hub) - the inference service whose sovereignty and compliance posture this unit examines
- Unit 1.4: Sovereignty and Compliance as Design Inputs, and Module 2 governance units - the sovereignty foundation reinforced here