Registering in the EU AI Database: What Article 49 Registration Actually Requires You to Publish

Every other obligation in the EU AI Act is something you demonstrate to a regulator behind closed doors. Article 49 registration is the one you publish to everyone — competitors, journalists, and litigators included.

Most of the AI Act generates internal artefacts: a risk management file, a quality management system, technical documentation, logs. A supervisor may ask to see them, but they live inside the firm. Article 49 is different. It requires providers of high-risk AI systems to register the system, and themselves, in an EU-wide database — and the bulk of that database is deliberately public and machine-readable. The description you write is not a compliance form filed and forgotten. It is a standing, searchable, public statement about what your system is and what it does. That changes how you should write it, and who should review it before it goes anywhere near the register.

What Article 49 actually asks you to publish

The registration content is set out in Annex VIII, not in Article 49 itself. Article 49 tells you who registers and when; Annex VIII tells you what fields you fill in. For a provider of a high-risk system, Section A of Annex VIII expects, among other things:

• The name, address and contact details of the provider, and of an authorised representative where one is appointed.
• The trade name of the system and any additional reference that allows it to be identified and traced.
• A description of the intended purpose, together with the components and functions the system supports.
• A basic, concise description of the information the system uses — its data and inputs — and its operating logic.
• The status of the system: on the market, in service, withdrawn, or recalled.
• Certificate details from a notified body where applicable, and a copy of the EU declaration of conformity.
• The electronic instructions for use, and the Member States where the system is or has been available.

None of that is onerous to assemble if the underlying work exists. The catch is in two of those fields — the intended purpose and the description of data and operating logic — because they are prose, they are public, and they have to be true. A vague, aspirational paragraph written by marketing will read very differently from the same system’s technical documentation, and that gap is exactly what a supervisor, or a well-briefed competitor, will notice first.

Who actually has to register — and who does not

The obligation falls mainly on providers. If you place a high-risk system listed in Annex III on the EU market, or put it into service, you register before you do so. There are three distinctions worth getting right early, because they change whether you register at all and where the entry goes.

Providers who have self-assessed out of high-risk still register. If you conclude that an Annex III system is not high-risk by relying on the derogation in Article 6(3), you do not simply walk away. Annex VIII has a separate, lighter registration section for exactly that situation — you record the system, the condition you relied on, and a short rationale. The decision to declassify is itself a public act. Whether your system even reaches this question is the subject of a proper Annex III scoping exercise, which should come before any registration work.

Most deployers do not register; public-sector ones do. A private firm deploying someone else’s high-risk system generally has no Article 49 registration duty. But a public authority, or a Union institution, body, office or agency, must register itself and its use of the system in Section C of the database before putting it into use. If you sell into the public sector, your customers inherit an obligation you should be ready to help them meet.

Some systems go to a restricted section, and one category registers nationally. High-risk systems in law enforcement, migration, asylum and border control are registered in a secure, non-public part of the database that only the Commission and designated national authorities can see. And critical-infrastructure systems under Annex III point 2 are registered at national level rather than in the EU database at all. Know which bucket each of your systems falls into before you draft a single field.

The date has moved — and that is not a reprieve

The original application date for the high-risk regime, including registration, was 2 August 2026. That has changed. Under the Digital Omnibus package agreed in 2026, the obligations attaching to Annex III high-risk systems have been deferred to 2 December 2027, and high-risk systems that are safety components of products already covered by Union harmonisation legislation (the Annex I route) move to 2 August 2028. Verify the exact dates against the amending regulation as published in the Official Journal before you plan around them; the postponement was moving through formal adoption during 2026 and the final text governs.

The extension buys time. It does not change the work. Your registration entry is downstream of your conformity assessment and your technical documentation — you cannot write an honest intended-purpose statement or declaration-of-conformity reference until those exist. Firms that treat the later date as permission to defer everything will arrive at the new deadline with the same problem, compressed. The sensible reading of the deferral is that you now have room to draft the public content carefully rather than under duress.

The real risk is inconsistency, not incompleteness

A missing field gets flagged and fixed. A description that contradicts your own documentation is harder to walk back, because it is on the record. The same system is described in at least four places: the registration entry, the technical documentation, the instructions for use, and whatever your sales and marketing teams say in public. Article 49 makes the first of those visible next to the last. If the register says the system is a decision-support tool while the marketing site calls it an automated decision engine, you have handed a supervisor an opening question and a competitor a talking point.

The discipline that closes this gap is the same one that runs your quality management system: a single source of truth for what the system is, with the register, the documentation and the customer-facing copy all drawn from it rather than written independently. Intended purpose in particular should be defined once, precisely, and reused verbatim. When it changes — a new function, a new deployment context — every downstream statement changes with it, including the public entry.

What to do now

1. Produce the inventory: every AI system in scope, classified as high-risk, self-declassified under Article 6(3), or out of scope, with the reasoning recorded.
2. For each in-scope system, draft the Annex VIII fields against the technical documentation, not from memory — especially intended purpose and the data-and-operating-logic description.
3. Run an internal review that reads the draft entry alongside your public marketing and your instructions for use, and reconcile any divergence before it is published.
4. Assign an owner for the register entry who is also accountable for keeping it current as status changes, because “withdrawn” and “recalled” are fields you will one day have to update honestly.

Treat the registration entry as a published claim rather than a form, and the drafting effort shifts from the compliance team’s inbox to where it belongs — with the people who can actually vouch for what the system does. The register does not test whether you completed the fields. It tests whether what you wrote survives being read by someone who was hoping it would not.