2026-06-04·5 min read·sota.io Team

Provider vs. Deployer EUDB Registration: Who Must Register What Under EU AI Act Art.51

Post #1485 in the sota.io EU AI Act Compliance Series — EU-AI-ACT-EUDB-REGISTRATION-2026 #4/5

Provider vs. deployer EUDB registration obligations under EU AI Act Art.51

One of the most common EU AI Act compliance mistakes is confusing the registration obligations of providers and deployers. Both roles interact with the EU database under Art.51, but they register different information, at different points in the AI system lifecycle, and under different conditions. Getting the role classification wrong means either registering information you are not required to provide — or, worse, failing to register when you legally must.

This guide breaks down who registers what, which Annex VIII fields apply to each role, and the specific deployer condition that most compliance teams miss entirely.


The Two-Role Model in EU AI Act Registration

The EU AI Act creates a clear distinction between two categories of economic actors relevant to EUDB registration:

Providers are entities that develop a high-risk AI system and place it on the EU market or put it into service. This includes software companies that build AI-powered SaaS products, in-house AI development teams at large enterprises, and model developers who supply components to downstream product builders.

Deployers are entities that use a high-risk AI system in their professional activities. A bank using an AI credit scoring model supplied by a third-party vendor is a deployer. A hospital using an AI diagnostic tool is a deployer. A government agency using an AI screening system is a deployer.

The critical insight: providers always bear the primary registration burden. Deployers bear a registration burden only in a specific narrow circumstance.


When Providers Must Register (Art.51, Para 1)

Providers of high-risk AI systems listed in Annex III must register themselves and their systems in the EUDB before placing the system on the market or putting it into service in the EU. This is a pre-market obligation — registration must be completed before the first commercial deployment, not after.

The Annex III list covers high-risk use cases across eight domains:

If your AI system falls into any of these categories and you place it on the EU market, you are a provider with a mandatory registration obligation. There are no exemptions for company size under current provisions — SMEs and startups developing high-risk AI systems have the same registration obligation as large enterprises.

What providers register: Annex VIII, Section A fields, which include the provider's identity and contact details, the AI system's intended purpose and functional description, the conformity assessment procedure used, and the reference number of the EU declaration of conformity (Art.47).


When Deployers Must Register (Art.51, Para 2)

Here is the provision that most compliance programmes overlook: deployers are only required to register in the EUDB when they deploy a high-risk AI system under Annex III and the system is used by a public authority, or by a body acting on behalf of a public authority.

This means:

The line is drawn at public authority use, not at sensitive application. A private company can deploy a high-risk AI system in employment decisions, credit scoring, or insurance risk assessment without a EUDB registration obligation — the regulatory burden falls on the provider of that system.

What deployers register: Annex VIII, Section B fields, which are narrower than Section A. Deployers register their identity, the intended purpose of deployment, any modifications made to the system, and their contact information for the competent authority. They do not register conformity assessment details — those remain with the provider.


The Provider-Deployer Role Overlap Problem

A third scenario creates significant compliance complexity: the integrated deployer-provider.

Consider a large financial institution that procures an AI credit risk model from a vendor (making it a deployer) but then substantially modifies the model's training data, retrains it on proprietary data, and customises its decision logic before deployment. Under EU AI Act provisions, substantive modifications that change the original conformity assessment scope can make the financial institution a provider for the modified system — not merely a deployer.

In this scenario, the financial institution must:

  1. Register as a provider, not merely as a deployer
  2. Complete its own conformity assessment (Art.43) for the modified system
  3. Issue an EU declaration of conformity (Art.47) for the modified version
  4. Register under Annex VIII Section A rather than Section B

The threshold for modification that triggers provider status is not simply cosmetic. Fine-tuning on a small domain-specific dataset generally does not trigger re-classification. Replacing the underlying model architecture, fundamentally changing the training data composition, or altering the decision logic in ways that change the risk profile generally does.


Annex VIII Fields: Section A vs Section B

Annex VIII Section A — Provider Registration Fields

The provider registration form includes:

Annex VIII Section B — Deployer Registration Fields

The deployer registration form is substantially shorter:

The Section B structure reflects that deployers are users, not conformity holders. The deployer does not certify the system — the provider's Art.47 declaration covers that — but the deployer's registration creates accountability for the specific deployment context.


Timing: Provider Registration Precedes Deployer Registration

There is an implicit sequencing requirement that Annex VIII makes explicit through its reference field structure:

  1. Provider registers first — creating the EUDB entry for the AI system
  2. Deployer registers second — referencing the provider's entry

A public authority deployer cannot complete their registration until the provider's entry exists to reference. This creates a dependency that many public sector procurement timelines fail to account for. If a public authority signs a contract with an AI vendor in April 2026 for a system to be deployed in July 2026, the vendor must have completed EUDB registration before the system goes live.

Procurement contracts for AI systems covered by Annex III that will be deployed by public authorities should include a contractual obligation on the provider to complete EUDB registration before any deployment date. The deployer cannot satisfy its own compliance obligation if the provider has not registered.


The EUDB Registration Deadline and the August 2, 2026 Gate

The August 2, 2026 application date for the high-risk AI system provisions (Title III, Chapter III) sets the effective deadline for both provider and deployer registration.

Systems already placed on the market before August 2, 2026 have a specific transition provision: providers have until August 2, 2027 to complete conformity assessment and register, provided the system has not been substantively modified since its first deployment. New systems placed on the market on or after August 2, 2026 must be registered before that first placement.

For public sector deployers, the transition provision applies symmetrically: deployers using systems already in service before August 2, 2026 have until August 2, 2027 to complete their registration. Deployers of newly procured systems must complete registration before deployment.


Common Registration Mistakes to Avoid

Mistake 1: Providers registering under Section B fields. Some compliance teams mistakenly register providers using the shorter Section B (deployer) fields, leaving conformity assessment documentation unrecorded. This creates an incomplete entry that will not satisfy regulatory inspection.

Mistake 2: Private sector deployers registering when they are not required to. A private company deploying a high-risk AI system in a non-public-authority context does not have a EUDB registration obligation. Voluntary registration is not prohibited but consumes compliance resources unnecessarily and may create regulatory expectations that do not exist in the applicable legal framework.

Mistake 3: Assuming EUDB registration certifies the system for deployment. EUDB registration records that a system has been assessed and declared conformant — it is not an approval or authorisation to deploy. The EU AI Act does not operate a pre-market authorisation regime for most high-risk AI systems. Registration is a transparency mechanism, not a green light.

Mistake 4: Failing to update registrations after modifications. If a provider substantially modifies a registered system — updating the model, changing the intended purpose, extending to new Member States — the EUDB entry must be updated. Stale registration entries that no longer reflect the deployed system's characteristics can constitute a compliance failure independent of whether the modification required a new conformity assessment.


What This Means for SaaS Teams Building on sota.io

If you are building a SaaS product on sota.io that incorporates high-risk AI functionality under Annex III, you are a provider. Your obligations are heavier than a deployer's: conformity assessment under Art.43, an EU declaration of conformity under Art.47, and EUDB registration under Section A.

If you are deploying a third-party high-risk AI system as part of your product offering to public sector customers, you may also be a deployer with Section B registration obligations once your customers are public authorities. In this scenario you bear both provider obligations (for the overall product) and deployer obligations (for the third-party AI component), and registration is required on both counts.

Hosting on EU-native infrastructure — data centres that are not subject to the US CLOUD Act, with full GDPR compliance and data residency in Germany — does not change your registration obligations, but it does simplify the Annex VIII Section A fields related to data handling, security measures, and competent authority access. A provider using EU-sovereign infrastructure can document their data location and access controls without the jurisdictional complications that arise from US-parent or US-cloud hosting.

The registration deadline is fixed. The dependencies between provider and deployer registration make early action more important than most compliance timelines assume.


Next in the EU-AI-ACT-EUDB-REGISTRATION-2026 series: Post #1486 — EUDB Registration Finale: Complete August 2026 Registration Checklist (the full step-by-step guide with all fields and verification steps).

EU-Native Hosting

Ready to move to EU-sovereign infrastructure?

sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.