Do all high-risk systems require registration?

Almost all Annex III high-risk systems require registration under Article 49(1). The exception is Annex III point 2 (critical infrastructure) where the system is used for the management and operation of critical infrastructure; those have a separate regime under Article 49(5). Annex I high-risk systems (those subject to existing harmonization legislation) follow the registration rules of the relevant harmonization legislation, with the AI Act registration adding to those.

Do private-sector deployers register?

Only public-authority deployers and EU institution deployers have the Article 49(2) registration obligation. Private-sector deployers do not file under Article 49(2). Private-sector deployers that become providers under Article 25 file the provider-side registration.

When does the registration have to be filed?

Before the system is placed on the market or put into service. For Annex III systems entering the EU market after August 2, 2026, the registration is a precondition to lawful placement. Systems already on the market before August 2 have transitional provisions under Article 111.

What if our system later turns out not to be high-risk?

If the provider determines under Article 6(3) that the Annex III system does not pose significant risks to health, safety, or fundamental rights, the system can be derogated from the high-risk regime. The derogation has to be registered in the database under Article 49(3). The market surveillance authority can challenge the derogation under Article 80.

How public is the registration?

The Commission publishes a public version of the registration under Article 71(3). The public version includes provider identity, system name, intended purpose, basic functions, and member states of placement. Commercially sensitive information can be excluded under Article 71(4), but the public-interest data points remain visible.

Does the registration update when the system changes?

Material changes require an update to the registration. A change to the intended purpose, the basic functions, the risk classification, or the member states of placement should be reflected in the database. Minor changes (a configuration tweak that does not affect compliance or intended purpose) do not.

EU AI Act EU Database Registration: Article 49 Obligations for High-Risk Systems

EU AI Act Article 49 requires providers of most high-risk AI systems to register the system in the EU database for high-risk AI systems before placing it on the EU market or putting it into service. Article 49(2) creates a parallel obligation for public-authority deployers and certain EU institution deployers to register the systems they use. The database is maintained by the Commission under Article 71 and is publicly accessible for the information that is not commercially sensitive. With the August 2, 2026 high-risk enforcement date 34 days away, providers and in-scope deployers need a clear read on what gets registered, who registers it, and what the registration record actually contains. I want to walk through Article 49 as the regulation actually writes it, the data points the registration record requires, and the operational pattern that produces them.

What Article 49 actually requires

Article 49(1) requires the provider of a high-risk AI system listed in Annex III to register the system, and the provider itself, in the EU database before the system is placed on the market or put into service. The registration applies to all Annex III categories with the exception of point 2 (critical infrastructure), which has its own registration regime under Article 49(5) when the high-risk system is used for the management and operation of critical infrastructure.

Article 49(2) creates the deployer-side obligation. Where the deployer is a public authority, an agency or body of the Union, or a body acting on its behalf, the deployer must register itself and the use of the high-risk AI system in the database. Private-sector deployers do not have this obligation under Article 49(2).

Article 49(3) addresses the case where the provider has reasonable grounds to consider that an Annex III system is not high-risk under the Article 6(3) derogation. In that case the provider registers the system and the assessment that supported the derogation. The database is the place where the derogation is recorded.

Article 49(4) requires the registration to be completed before placement on the market or putting into service. A high-risk system placed on the market without registration is in breach of the Act and subject to the Article 99 penalties.

What data goes into the registration record

Annex VIII of the Act sets out the information that the provider provides for the registration. The list includes the name, address and contact details of the provider, the trade name and any unique identifier of the AI system, the intended purpose of the system, a description of the system's components and basic functions, instructions for use, the conformity assessment procedure followed, the EU declaration of conformity, the CE marking, the member states where the system is placed on the market, available languages, and a statement of compliance with the Union harmonization legislation that applies.

For Annex III high-risk systems where the deployer is in scope under Article 49(2), Annex VIII Section C lists the deployer-side data: the name, contact details and identifier of the deployer authority, a summary of the findings of the Article 27 Fundamental Rights Impact Assessment if applicable, and a summary of the data protection impact assessment under GDPR Article 35 where the system processes personal data.

The substantive registration record runs to 20-30 distinct data points across the Annex VIII sections. The record is filed once at registration and updated when material elements change.

Who actually files the registration

The provider files Section A and Section B for the system. The provider-side registration covers everything the provider has produced about the system as designed and as conformity-assessed.

The public-authority deployer files Section C for the use of the system. The deployer-side registration covers the use under the deployer's authority, including the operational scope and the fundamental-rights or data-protection assessments the deployer has performed.

In the integrated-deployer case, where the deployer has become a provider under Article 25 because of substantial modification, branding, or repurposing, the integrated entity files both sections. The provider-side registration covers the modified system; the deployer-side registration is not required for private-sector providers acting as their own deployer.

The interaction with conformity assessment

The Article 49 registration is the public artifact of the conformity assessment under Article 43. The conformity assessment produces the EU declaration of conformity under Article 47, the CE marking under Article 48, and the technical documentation under Article 11. The registration record references all three.

A provider that has not completed the conformity assessment cannot register. A provider that has not registered cannot place the system on the market. The chain is sequential: assess, declare, mark, register, place.

For Annex III systems where the provider uses an internal control conformity assessment (the most common case), the provider self-attests. For Annex III systems that require involvement of a notified body, the registration record includes the notified body's identification.

What the registration record exposes publicly

The Commission publishes a public version of the registration record under Article 71(3). The public information includes the identity of the provider, the trade name of the system, the intended purpose, the member states of placement, and the conformity assessment procedure. Information that the provider designates as commercially sensitive can be excluded from the public version under Article 71(4), but the data points in Annex VIII that bear on public scrutiny (intended purpose, basic functions, risk classification) remain public.

A provider that is uncomfortable with the public scrutiny of the intended purpose has a strategic question to answer about whether the system should be on the EU market at all. The public registration is a feature of the Act, not a side effect.

The technical workflow for filing

The Commission has built the EU database as a structured filing system. The provider creates an account, the provider-side data is filled in via the database interface, the supporting documents are attached (declaration of conformity, technical documentation summary), and the record is submitted. The Commission reviews the submission for completeness and publishes the public portion.

For the deployer-side registration under Article 49(2), the public authority deployer follows a parallel workflow. The deployer-side record is linked to the provider-side record for the same system.

The Commission expects the database interface to be operational ahead of the August 2 enforcement date. Providers planning to place high-risk systems on the EU market should plan the registration filing as a critical-path activity in the deployment timeline.

How the operational records support registration

The registration record contains static information about the system as designed and assessed. The supporting documents the provider submits, however, are derived from the operational record. The technical documentation under Article 11 references the post-market monitoring plan, the risk management system, the data governance procedures, and the human-oversight measures. Each of these is grounded in the operational architecture.

A provider preparing the registration submission needs the operational records as evidence. The Article 19 logs the deployer will retain are the substrate for the post-market monitoring plan that the technical documentation describes. The identity and authorization architecture that the system implements is the basis for the Article 14 human-oversight measures the technical documentation describes.

The registration is a document. The document points at an operational architecture. The auditor that reviews the registration can request the operational artifacts that back it up.

The pattern that breaks registration timelines

A common pattern that delays registration is the discovery during preparation that the operational architecture cannot support the claims the technical documentation needs to make. The technical documentation describes Article 14 human-oversight measures. The operational architecture turns out to lack the identity context required to make the oversight actionable. The provider has to choose between filing a registration that overstates the operational capability or delaying the placement until the architecture catches up.

The fix is to build the operational architecture first, then write the technical documentation that describes it, then file the registration. The order matters. Registrations that lead the architecture lead to corrective filings, regulatory inquiries, or worse.

DeepInspect

This is the operational substrate DeepInspect was built to provide for the architecture the registration documents. DeepInspect sits inline between authenticated users or agents and the LLMs that high-risk AI systems call, applies identity-bound per-route policies, and writes a per-decision audit record that the post-market monitoring plan and the Article 19 retention obligation depend on.

For Article 49 registration specifically, DeepInspect is not the system being registered; it is the layer that produces the operational evidence the technical documentation cites. The provider's registration record describes the system. The technical documentation describes the controls. The audit trail at the gateway is the evidence the controls produce.

If you are facing the August deadline and your registration timeline depends on operational architecture that is not yet in place, let's talk today.