Article 49 EU database registration: what it requires

Article 49 registration in the EU database: what the requirement asks for

If your team is about to place a high-risk AI system on the EU market or put it into service, the first question is whether Article 49 requires you to register it in the EU database before it goes live. For providers, the answer is generally yes for each Annex III high-risk system, with one important exception: systems that fall under critical infrastructure are registered at national level instead. Providers that have concluded under Article 6(3) that an Annex III system is not high-risk must still register that conclusion. Public authority deployers, and those acting on their behalf, have a separate duty to register themselves and the use of the system before putting it into service. The timing is fixed, so the registration entry should be ready as a release gate, not as a post-launch task.

Registration is a public transparency duty. For most systems, the entries are publicly accessible and machine-readable, so regulators, researchers, journalists and affected people can see which systems exist, who provides them and what they are used for. Article 71 places the database under the Commission's control. The secure, non-public section for law enforcement, migration, asylum and border control systems is the exception, and access to it is restricted. Because the entry is public, the information you submit must match your technical documentation, your declaration of conformity and your instructions for use. Inconsistencies between these records are easy for an authority to spot.

Three problems make registration harder than it looks. The first is classification: the team must decide whether a system is high-risk at all, and for borderline uses this decision needs written reasoning before anyone fills in a form. The second is scattered data: the fields in Annex VIII draw on information held by engineering, legal, procurement and HR, and no single team usually holds all of it. The third is role confusion: a company that rebrands a system, changes its intended purpose or substantially modifies it may become the provider, while the original supplier stops being one. Before work starts, confirm in writing who is the provider, who is the deployer, and who signs the entry. An implementation partner can help assemble the data and records, but the organization owns the registration and an independent authority or the Commission's systems hold the record.

Which systems and organizations must register

Article 49 sorts registration duties by who you are and how the system was scoped. The high-risk or not-high-risk decision comes first, because a system you have concluded is outside Annex III may still need registration if you made that conclusion under Article 6(3), and a system you never classify as high-risk may need no entry at all.

Providers of Annex III systems

Article 49(1) requires a provider to register itself and each Annex III high-risk system in the EU database before the system is placed on the market or put into service. Critical infrastructure systems are excluded from this route and handled nationally. Check that each system in your inventory is mapped to a specific Annex III point, and that the registration is completed before the first customer or internal user receives it. A registration gap is found at launch, so build the step into the release gate.

Providers who concluded not high-risk

Article 49(2) applies when a provider has concluded under Article 6(3) that an Annex III system is not high-risk, and it still requires registration of that system. The duty exists because the provider's own assessment must be visible to authorities. Document the reasoning behind the exemption, the date it was made and who approved it, then register the system with the Annex VIII Section B data. Skipping registration because the system is "probably not high-risk" is a common error.

Public authority deployers

Article 49(3) requires public authorities, and those acting on their behalf, to register themselves, select the system from the database and register its use before putting it into service. This is a deployer duty, not a provider duty, so a public body that buys a high-risk system must complete its own entry even if the provider has already registered the system. Confirm with procurement which entity will file, and make the filing a condition in the contract.

Law enforcement, migration and border systems

Systems in Annex III points 1, 6 and 7, covering law enforcement, migration, asylum and border control, are registered in a secure non-public section of the database rather than the public register. Article 71 makes the Commission the controller of the database and requires public entries to be machine-readable, with this secure section excepted. Organizations in these sectors should confirm with their national authority how access to the secure section is granted and who inside the organization may file.

Critical infrastructure systems

Systems in Annex III point 2, covering critical infrastructure, are not registered in the EU database. They are registered at national level under Article 49(5). Operators in energy, water, transport and digital infrastructure should ask their national market surveillance authority which register applies, what form it takes and whether it accepts the same Annex VIII data. Keep the national filing reference with the system's technical documentation so that it can be produced on request.

Authorised representatives for non-EU providers

A provider established outside the EU can appoint an authorised representative established in the Union to carry out registration on its behalf. The mandate should be written and should name the systems covered, the data to be filed and who signs the entries. Confirm that the representative holds the registration credentials, that updates to Annex VIII data are routed back to the provider, and that the provider can still see its own entries. The representative files, but the provider remains responsible for the accuracy of the content.

How an assessor tests registration

This table sets out the registration checks an assessor is likely to run, what each check samples, the evidence that passes and the findings that come up most often. Read it as a test plan: prepare the inventory, the Article 6(3) records and the registration receipts before the assessor asks for them.

Test step	What the assessor samples or asks for	Evidence that passes	Common findings
Pre-use listing	Each system in scope, with its registration record date compared to the date it was placed on the market or put into service	Database entry dated before first use, with the system name and version matching the deployed release	Registration completed after go-live, or the entry covers an earlier version only
Inventory match	A sample of database entries traced back to the internal AI system inventory and the risk classification file	Same system identifier, purpose, intended use and provider details in all three records	Inventory lists systems that have no database entry, or entries that describe a different purpose
Article 6(3) decisions	Systems registered as not high-risk under Article 49(2), with the signed assessment that supports the decision	Dated written assessment explaining why the Annex III criteria do not apply, reviewed when the system changes	Decision record missing, undated, or written after the registration
Public authority deployer registrations	Whether public bodies, or those acting for them, registered themselves, selected the system and registered its use before deployment	Deployer registration showing the body, the selected system and the use before the system went live	Only the provider registered, so the deployment use was never recorded
Secure section routing	Annex III point 1, 6 and 7 systems for law enforcement, migration, asylum and border control	Entries held in the secure non-public section, with no public record of sensitive details	Sensitive systems entered in the public register, or no decision on which route applies
National route routing	Annex III point 2 critical infrastructure systems and their registration at national level	Proof of national registration with the relevant national authority, and a matching internal record	Critical infrastructure systems registered in the EU database only, or not registered anywhere
Data completeness	A sample of entries checked against the Annex VIII items for the role (provider, Article 6(3) or deployer)	Every required item present, with fundamental rights and data protection summaries attached where the deployer must provide them	Missing items, outdated contact details, or summaries that do not match the current impact assessment
Change control	Records of updates after substantial modification or changes to the registered purpose	Dated update entries that show the database was amended when the system changed	Entries left unchanged after the system was retrained, repurposed or redeployed

What Annex VIII asks you to submit

Annex VIII sets three separate data sets, and the one you need depends on your role and on how you classified the system. Section A lists the 13 items a provider submits for an Annex III high-risk system. These describe the provider and the system: legal identity and contact details, any authorised representative, the system's trade name and intended purpose, its market status and the conformity assessment route. Section B covers the data a provider submits when it concluded under Article 6(3) that an Annex III system is not high-risk. Two items were deleted from Section B in 2026, so do not reuse an older checklist. Confirm the current item wording in the consolidated Annex VIII text before you file.

Section C is for deployers, including public authorities registering their use of a system, and sets five items. Two of them are summaries of documents you produce elsewhere: the fundamental rights impact assessment and, where one applies, the data protection impact assessment under the GDPR. The registry entry is only as reliable as the assessment behind it. Write each summary from the completed assessment, record the version and date it reflects, and check that it matches what your organization told the market surveillance authority. Confirm with counsel or your data protection officer which of the remaining items apply to your use case.

Gathering the data is mainly a mapping exercise. Provider items come from the technical file, the instructions for use and the risk management documentation: the intended purpose and limits in the instructions, the residual risk conclusions, and the conformity route recorded in the quality management system. Keep a register worksheet that maps each Annex VIII item to the document, section and named owner that supplies it, and record the document version. Registration must happen before the system is placed on the market or put into service, so the data should come from approved final documents, and each entry should show which version it came from.

Steps to build a registration process that holds up

This sequence turns the Article 49 duty into a repeatable process: each system's classification is settled first, the right registrant is named, and the Annex VIII data is gathered and checked before anything is filed. Each step leaves a record that an assessor or authority can follow back to the original decision.

Record the classification decision for each system
Start with an inventory of every AI system the organization develops, places on the market, puts into service or uses. For each one, record whether it falls under Annex III, whether it is an Annex I product system, and, for any Annex III system the provider considers not high-risk, the reasoning under the Article 6(3) exemption. Have a named accountable person and a legal or compliance reviewer sign the record. The output is a classification record per system. The step is complete when every system has a decision and a date, and no system is left as 'to be determined'.
Assign the registrant and authorised representative
Decide who files. For a provider, the registrant is normally the provider itself, and a non-EU provider must act through an EU authorised representative under Article 22. For a public authority deployer, the deployer registers itself, selects the system and registers its use. Confirm that the person or entity holding the filing account has the authority to submit on the organization's behalf. The output is a registrant assignment sheet naming the legal entity, the filing contact and, where relevant, the signed mandate for the authorised representative.
Map Annex VIII fields to existing documents
Go through the Annex VIII data items for the applicable section (provider Section A, Article 6(3) data in Section B, or deployer Section C) and identify the source document for each item. Typical sources include the technical documentation, the instructions for use, the fundamental rights impact assessment summary and the data protection impact assessment summary. Mark any item with no source as a gap. Confirm the current wording of Annex VIII against the consolidated text, since the 2026 amendment changed Section B. The output is a field mapping sheet that lists each item, its owner and its source document.
Collect and reconcile the registration data
Gather the content for every mapped field and check that the values agree with each other and with the technical file. Product names, version numbers, intended purpose, system identifiers and contact details are the usual sources of conflict, for example when a deployed version differs from the version in the documentation. Resolve each mismatch and keep a short log of the change and who approved it. Where the organization uses an asset inventory or wiki, export the approved values from there so the filing reflects one source of truth. The output is a reconciled data pack with a change log.
Route secure and national registrations correctly
Check whether any system falls into an exception route. Annex III points 1, 6 and 7 (law enforcement, migration, asylum and border control) are registered in the secure non-public section rather than the public part. Critical infrastructure systems in Annex III point 2 are registered at national level. Confirm with the relevant national authority which filing channel applies and what format it expects. The output is a routing note for each affected system that states the section or national authority used.
File before placing on the market or putting into service
Submit the registration in the EU database before the system is placed on the market or put into service. Keep a copy of the exact submitted data, the submission date and the confirmation the database returns. Do not release the system for use until the filing is complete, because the timing is part of the obligation. Public registrations are publicly accessible and machine-readable under Article 71, so check the text for any content that should not be published. The output is a filed submission and a stored copy of what was sent.
Record the filing reference and link it to the system
Enter the database registration reference against the system's entry in the inventory, the classification record and the technical file. Store the confirmation in the document repository with restricted edit rights, so the record cannot be altered after filing without a trace. Tell the teams that operate the system which reference applies. The output is a registration register entry that connects the filing to the system and its evidence.
Set a review trigger for substantial modification
Define the events that require the registration to be reviewed and, where the data has changed, updated. These include a substantial modification of the system, a change to its intended purpose, a new deployment context or a change to the classification reasoning. Assign an owner for monitoring these triggers and schedule a recurring check of the register against the inventory. Keep an update log that records each review, the outcome and the new filing where one was made. The output is a review trigger rule and an update log that shows the registration stayed current.

Evidence that shows a system was registered

Article 49 registration is proven by records you can produce on request, not by the act of filing alone. The cards below cover the artifacts an assessor or market surveillance authority is likely to ask for, and each one names the owner who keeps it current between audits.

Database registration confirmation

For each Annex III high-risk system, keep the confirmation or database entry showing the registration was made before the system was placed on the market or put into service. Store the entry with the system's identifier, the date of registration, and the version of the system it describes. Check that the entry still matches the live product after each release. Owner: the provider's compliance lead, with the product owner confirming scope.

Article 6(3) not-high-risk assessment record

Where a provider concludes that an Annex III system is not high-risk, Article 49(2) still requires registration. Keep the written assessment that reached that conclusion, the reasoning against each Annex III category, the date, and the approver. Re-open the assessment whenever the system's purpose or data changes, since the conclusion depends on those facts. Owner: the provider's legal or compliance function, signed off by a named accountable executive.

Annex VIII data mapping

Maintain a field-by-field map that links each Annex VIII data item to the internal source that holds it, such as the technical file, the instructions for use, or the quality management records. An assessor can then trace every registered value to a document. Review the map at each change to the registered information so that the database entry and internal records never diverge. Owner: the compliance lead, with engineering supplying technical values.

Deployer Section C filings

Where you deploy a high-risk system as a public authority, or on behalf of one, keep filed copies of the Section C data, including the summaries of the fundamental rights impact assessment and the data protection impact assessment where they apply. Record the date of each filing and the system version it covered. Confirm with counsel which deployer role you hold before you file, because the duty depends on it. Owner: the deployer's public sector registration lead.

Public authority registration record

Article 49(3) requires a public authority deployer to register itself, select the system, and register its use before the system goes live. Keep the record of that registration, the selected system reference, and the proof that the use was registered before first operation. Re-check the record when the use changes or the system is replaced. Owner: the authority's data protection or AI governance office.

Registration change log

Keep a dated history of every update filed against a registered entry, with the reason, the person who filed it, and the link to the approved change record. Public entries are visible to others, so gaps between the product and the registry are easy to spot. Use a wiki or document system with version history so that each change can be compared and restored. Owner: the compliance lead, reviewed quarterly by internal audit.

What meeting Article 49 costs in money and effort

This table breaks down the cost components of Article 49 registration by who is paid, whether the cost is one-time or recurring, and what moves it up or down. Use it to structure a quote request and to see where self-hosted open-source tools reduce spend. No fees or durations are given because none are supplied, so the reader should ask for them in writing.

Cost component	One-time or recurring	What drives it up or down, and how to keep it down
Internal engineering and compliance time to gather Annex VIII data	One-time per system, then recurring on updates	Drives up: many systems, scattered records, no single inventory. Keep down: maintain one asset and documentation register so each registration draws on existing records.
Legal or Article 6(3) classification review	One-time per system, recurring when use changes	Drives up: borderline use cases and unclear provider or deployer roles. Keep down: record the classification rationale once in a version-controlled document and cite it in each registration.
Authorised representative fees, where applicable	Recurring for the mandate period	Drives up: non-EU providers must appoint an EU representative for high-risk systems. Keep down: ask for the fee basis, scope of tasks and notice terms in writing before signing.
Asset and documentation tooling	Recurring licence or hosting, or none for open source	Drives up: commercial inventory and wiki subscriptions scale with users or assets. Keep down: self-hosted GLPI, Wazuh, XWiki and BookStack remove licence spend for inventory and documentation, though hosting and staff time remain.
Setup and integration of inventory and records systems	One-time, fixed scope	Drives up: number of data sources to connect and custom fields needed for Annex VIII. Keep down: agree the field list and sources in the written scope before work starts.
Updates after substantial modification	Recurring, triggered by change events	Drives up: frequent model or intended-purpose changes and weak change logs. Keep down: link registration updates to change management so each substantial change prompts a review.
Public authority deployer registration effort	Recurring per system used	Drives up: many deployed systems and manual selection steps. Keep down: standardize the registration checklist so each use is registered with the same evidence.
Assessor time sampling registrations	Recurring at each assessment or inspection	Drives up: incomplete or inconsistent entries that require follow-up. Keep down: keep registrations traceable to current technical documentation and dated records.

Which self-hosted tools can hold registration evidence

Article 49 filings happen in the EU database, but the facts behind each entry must come from somewhere your organization can show an assessor. The four tools below can hold or support parts of that record, and each one covers a different piece of it. None of them files anything or replaces the database entry itself.

GLPI asset records

GLPI's Assets module tracks computers, software, network equipment, peripherals and other hardware, entered manually or pushed by the GLPI Agent through native inventory built into GLPI since version 10. For Article 49, it can show which servers, endpoints and hosts run each registered system, which supports the deployment location and component details you record. Confirm which fields it can hold for AI systems and whether you need custom asset types, since a tool built for hardware does not describe AI systems by default. Licensed under GPL-3.0-or-later.

Wazuh software inventory

The Wazuh Syscollector module collects hardware, operating system, installed software, services, users and open ports from each endpoint and stores them in the Wazuh indexer, with views and reports in the dashboard. Its output can corroborate that the software environment described in your registration matches what actually runs on the infrastructure. Syscollector covers endpoints, not every AI service or cloud-hosted model endpoint, so confirm coverage for the systems you register. Licensed under GPL-2.0-only.

XWiki version history

XWiki keeps every change to a page under version control, recording what changed, when and by whom, and lets reviewers compare versions or roll back. This suits the Annex VIII data you prepare before filing, since you can show when each registration field was drafted, reviewed and approved. Keep the filed submission and its confirmation in the EU database record, and keep the XWiki page as the internal source. Licensed under LGPL-2.1-or-later.

BookStack access controls

BookStack assigns abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. Use this to limit who can edit the registration pages, which prevents unreviewed changes to Annex VIII content and keeps the approver's role separate from the drafter's. Confirm that your deployment's role design supports separation of duties before relying on it as evidence. Licensed under MIT.

Who does what: your team, a partner and the auditor

Your compliance and engineering team owns the classification decision, the registration filing and the data inside it. Whether a system falls under Annex III, whether an Article 6(3) conclusion applies, and whether your organization acts as provider or deployer are determinations you must make and record. The registration is made by the provider or its authorised representative, or by a public authority deployer, so the entries must be traceable to people inside the organization.

Classification decision: Record the Annex III category, the reasoning and any Article 6(3) conclusion before anyone completes a registration form.
Registration filing: Submit the provider entry or the deployer entry before the system is placed on the market, put into service or used, as Article 49 requires.
Annex VIII data ownership: Name an owner for each of the 13 provider items or 5 deployer items, including the fundamental rights and data protection impact assessment summaries.
Record keeping: Keep the classification memo, the filed entries and their dates alongside the technical file so they can be produced on request.

Check that every registered system has a named owner who can answer questions about its data, its classification and the date it was first used.

Questions buyers ask about Article 49 registration

How much effort does registering one high-risk AI system take?

The filing is a data entry step, but most of the effort lies in assembling the data it requires before submission. Annex VIII sets 13 items for providers in Section A, Article 6(3) data in Section B, and 5 items for deployers in Section C, including summaries of the fundamental rights and data protection impact assessments. The effort rises with the number of Annex VIII sections that apply, how settled the intended purpose and instructions for use are, whether the classification decision is documented, and how many people must confirm each fact. Ask any quote to list the Annex VIII items it covers, who supplies each one, and what happens if a fact changes after filing.

Can a consultant or partner file the registration for us?

A partner can prepare the data and evidence, but the legal registration remains the provider's responsibility. Under Article 49, the provider or its authorised representative makes the filing, and non-EU providers must appoint an EU-based authorised representative in writing under Article 22. DeployOpen is not an authorised representative, and it does not file on an organization's behalf unless the engagement says so in writing. Confirm with your legal counsel whether a third party may submit under your mandate and which role carries the legal liability for the content of the filing.

What does the organization need to provide for registration?

The organization supplies the decisions and facts that only it can confirm. Expect to provide named system owners, the technical documentation for the system, the classification record, and the instructions for use that describe its intended purpose. Providers that concluded under Article 6(3) that an Annex III system is not high-risk must register that system as well, so the written assessment behind that conclusion is needed. Deployers that are public authorities need the selection record and the fundamental rights and data protection summaries. Assign one accountable owner per system and agree who approves each data item before work starts.

How long does registration preparation take, and what drives it?

The duration depends on how mature the documentation already is, not on the filing itself. Preparation runs longer when the classification of a system is disputed, when several systems share components and need separate records, or when sign-off cycles between legal, security and business owners are slow. Registration also depends on where the system sits: systems in Annex III points 1, 6 and 7 go to a secure non-public section, and critical infrastructure systems in point 2 are registered at national level. Ask for milestones tied to each system and each Annex VIII section in the written scope, rather than a single end date.

Can open-source tools hold the evidence for AI Act registration?

Open-source tools can hold the source records behind a registration, although they do not submit the filing to the EU database. GLPI's Assets module can record the hardware, software and racks that host a system, and its native inventory can be fed automatically by the GLPI Agent. Wazuh's Syscollector collects operating system, installed software and services from each endpoint into its indexer, which supports evidence of the deployed environment. XWiki keeps every change to a page with who changed it and when, which helps show how technical documentation evolved. BookStack's role-based permissions can limit who edits system records. Confirm that each tool's output meets your Annex VIII and audit needs before you rely on it.

What happens to the registration when a system is substantially modified?

A substantial modification can trigger a new conformity assessment under Article 43, so the registered record should reflect the system as it is placed on the market. The Act's update rules for registration data should be confirmed against Article 49 and Annex VIII for your specific case, including whether a change requires a new filing or an amendment. Treat each change as a controlled step: record the change, its reason, the affected Annex VIII items and the approver, and keep the earlier version so you can show what was registered at each point in time. Ask any partner how change control will feed the registration.

Who checks the registration, and what happens if it is wrong?

No independent certifier approves a registration as part of Article 49, so the content is the provider's statement. The Commission is the controller of the EU database under Article 71, and public registrations must be publicly accessible and machine-readable, except the secure section. National market surveillance authorities enforce the Act, so an incomplete or inaccurate filing can draw their attention during supervision. Fines for most operator obligations can reach EUR 15 million or 3% of worldwide annual turnover, whichever is higher, under Article 99. Confirm with counsel which penalty category applies to a registration failure in your situation.

How DeployOpen prepares registration evidence

DeployOpen works on Article 49 registration as a fixed-scope implementation engagement inside your own infrastructure. We prepare the systems and records that hold registration data, while your organization remains responsible for what it registers and an independent process handles any submission decision.

How we scope

The written scope lists which systems, roles and registrations are covered, including provider, authorised representative or public authority deployer entries.
We confirm with you whether each system is Annex III, falls under the Article 6(3) route, or is critical infrastructure registered nationally.
The scope names the Annex VIII data fields to be sourced from each tool, and who in your organization signs off each field.

How we build

We configure GLPI or your existing asset register so each AI system has a record linked to its owner, version and hosting location.
We set up Wazuh or your inventory tooling to capture the infrastructure facts that support registration data, where that fits the environment.
We structure XWiki or BookStack pages with restricted permissions, so registration summaries stay controlled and traceable to their authors.

How we hand over

You receive a documented registration data map showing each Annex VIII item, its source system and its owner.
Version history and change records are handed over in a form your compliance team can present to an auditor or authority on request.
The handover includes a runbook for updating registrations when a system changes, along with a list of items you must confirm yourselves before submission.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so registration records can be kept current after go-live.
We can review changes to a registered system and flag where a new registration or update may be needed, with the final call remaining with your organization.
Questions about the secure non-public section or national registration are routed to the authorities or advisers you confirm are responsible.