← Back to insights

Who Registers a High-Risk AI System in the EU Database?

Route an AI Act Article 49 registration request by system category, provider or deployer role, triggering event, database section and Annex VIII evidence owner.

An AI Act Article 49 handoff routes the system, legal actor, trigger, database section and Annex VIII source owner
#EU AI Act#Article 49#High-Risk AI#EU Database

Signals to watch

  • A provider is approaching market placement or putting into service but no authorised owner has the Annex VIII registration fields
  • A public authority plans to use an Annex III high-risk system without a deployer registration handoff
  • A system is called exempt or non-high-risk under Article 6(3), but the provider has not preserved the assessment or registration record

For an Annex III high-risk AI system, registration ownership starts with the legal actor and event. Before market placement or putting into service, the provider—or its authorised representative where applicable—registers itself and the system, except for Annex III point 2 critical-infrastructure systems, which Article 49 sends to national-level registration. Covered public-sector deployers also have a separate registration step before use.

That answer prevents an AI-governance implementation service lead from selling “EU database setup” before the request has a route. In authorised AI-governance, public-procurement or regulated-product Telegram groups, a message such as “go-live is next month, who owns the database entry?” can arrive after conformity, procurement and operations teams have each assumed another team will file. Seeing it a day late can miss a launch-control meeting. It still does not prove that the system is high-risk, that Article 49 already applies to the facts or that the message author can buy services.

The binding text is Regulation (EU) 2024/1689. The Commission’s Article 49 page reproduces the provision and provides a non-binding explanation. The AI Act entered into force on 1 August 2024 and uses phased application dates; the applicable date and any later legislative change must be checked for the specific system rather than inferred from a project calendar.

Registration begins after classification, not before it

“High-risk” is not a project label. The provider must first identify the system and the route by which it falls within the AI Act’s high-risk rules. Annex III describes stand-alone use cases; Annex I concerns safety components or products governed through listed Union harmonisation legislation. Article 49 does not turn an uncertain classification into a high-risk finding.

Preserve the classification memorandum, intended purpose, product or use-case category, version, provider identity and the evidence supporting the conclusion. If the provider relies on Article 6(3) to conclude that an Annex III-listed use is not high-risk, Article 49(2) still requires the provider or authorised representative to register itself and that system in the Article 71 database. The underlying assessment must remain available; a database label is not the assessment.

The FRIA evidence map covers the separate fundamental-rights impact assessment duties for specified deployers. Do not merge a deployer FRIA with provider classification or database registration.

Put the actor and trigger on one handoff line

Build the request as a five-column handoff: system, legal actor, triggering event, registration route and source owner.

Provider or authorised representative

Article 49(1) covers a provider placing on the market or putting into service an Annex III high-risk system, other than point 2. Before that event, the provider or applicable authorised representative registers itself and the system in the EU database referred to in Article 71.

The file should identify the provider legal entity, any authorised representative, system trade name and version, intended purpose, Annex III point, status of conformity work, expected placement/service date, account owner and approval owner. “Vendor” is not a sufficient actor field; an importer, distributor and deployer have different roles.

Public-sector deployer

Article 49(3) names deployers that are public authorities, Union institutions, bodies, offices or agencies, or persons acting on their behalf. Before putting into service or using the covered Annex III system, they register themselves, select the system and register its use. A provider entry therefore does not automatically close the deployer’s row.

The handoff needs the deploying entity, authority basis, selected registered system, intended use, use date, account owner and evidence that the person completing the entry acts for that deployer. Whether a contractor is “acting on behalf” is a fact and legal question, not something to infer from a procurement chat.

The database destination changes with the Annex III point

The registration route is not always the same public page.

  • Annex III points other than point 2: providers follow Article 49(1), and the covered public-sector deployers follow paragraph 3, using the Article 71 EU database route.
  • Annex III points 1, 6 and 7: Article 49(4) places the relevant law-enforcement, migration, asylum and border-control registrations in a secure non-public section and specifies which Annex VIII fields are included.
  • Annex III point 2: Article 49(5) provides national-level registration for the critical-infrastructure category.

Do not promise a public URL until the Annex III point is confirmed. Do not paste operationally sensitive or personal information into a draft public record. The registration owner should work from the exact field set for the selected route and apply the relevant confidentiality and security controls.

Annex VIII is a source-data contract, not a copywriting brief

The Commission’s Annex VIII page sets out information for registration. The controlled source pack should map each required field to an owner and evidence version. Depending on the route, fields concern the provider or representative, system identification and purpose, status, Member States, electronic instructions, public contact and deployer/use information.

Do not let the web-form author invent a purpose statement from a sales page. Use the approved intended purpose and technical/regulatory record. Keep system version, model or product identifiers consistent with conformity and technical documentation. If a field changes, preserve the effective date, approved source and decision on whether the database record requires an update.

This field map is the observable completion standard for a registration-support engagement: every required field has a route, source, owner, approver and submission evidence. It does not mean the AI system complies with every AI Act duty.

Three incomplete requests have different owners

These are role examples derived from Article 49, not customer cases or records of real projects:

  1. A private provider plans to place an Annex III recruitment system on the market. The provider row and system entry are the first Article 49 handoff; the future customer’s registration depends on whether paragraph 3 covers that deployer.
  2. A public authority plans to use an already registered Annex III system. Selecting the provider’s record does not replace the authority’s deployer/use registration.
  3. A provider says an Annex III-listed use is not high-risk under Article 6(3). The assessment and the Article 49(2) registration record both need owners; “not high-risk” does not mean “no database record.”

Each request still needs exact classification, actor and transition-date review. The examples show routing, not legal conclusions.

For another AI Act actor handoff, the Article 50 transparency readiness article separates provider and deployer disclosures. The Article 4 literacy evidence handoff addresses personnel measures rather than system registration. The pricing page describes TOP Prospect subscriptions, not AI Act filing services.

A Telegram candidate cannot become the registration record

TOP Prospect can organise related fragments from Telegram groups the user has deliberately connected and is authorised to access, retaining original message, source, time and a reason for human review. The current matching-target interface saves configuration but does not automatically create new candidates. It cannot classify the system, access the EU database, complete Annex VIII, submit a registration or certify compliance.

A launch date plus an unassigned registration owner can justify earlier review. A score does not prove the system is high-risk or that the speaker is authorised. The implementation service lead must recover the controlled classification and project records before scoping or contacting anyone.

Key facts

  • Article 49 registration starts with the system category, legal actor and triggering event.
  • Providers or applicable authorised representatives register covered Annex III systems before market placement or putting into service, except point 2.
  • Covered public-sector deployers have their own registration-of-use step before use.
  • Annex III points 1, 6 and 7 use a secure non-public section; point 2 uses national-level registration.
  • A provider relying on Article 6(3) still has an Article 49(2) registration record.
  • Registration does not replace classification, conformity, technical documentation, FRIA, transparency or post-market duties.

FAQ

Who registers an Annex III high-risk system before market placement?

The provider or, where applicable, its authorised representative registers itself and the system under Article 49(1), except for Annex III point 2 systems.

Do all private deployers register their use under paragraph 3?

No. Paragraph 3 specifically names public authorities, Union institutions, bodies, offices or agencies and persons acting on their behalf.

Are law-enforcement and migration registrations public?

Article 49(4) routes Annex III points 1, 6 and 7 to a secure non-public section with a limited field set.

Does registration prove AI Act compliance?

No. It is one regulatory record and cannot substitute for the other applicable obligations or evidence.

Editorial review completed 22 August 2026 against the official text of Regulation (EU) 2024/1689, Article 49 and Annex VIII. Qualified AI Act, product, public-sector and legal reviewers must confirm classification, actor, application date and registration route.

Frequently asked questions

Who registers an Annex III high-risk AI system before market placement or putting into service?

Under Article 49(1), the provider or, where applicable, its authorised representative registers itself and the system, except for Annex III point 2 systems, which use national-level registration.

Do all private deployers register their use under Article 49(3)?

No. Paragraph 3 names public authorities, Union institutions, bodies, offices or agencies, and persons acting on their behalf, for the covered Annex III systems.

Are law-enforcement and migration registrations public?

Article 49(4) routes systems in Annex III points 1, 6 and 7 to a secure non-public section and limits the registered fields to the listed parts of Annex VIII.

Does registration prove that the system complies with the AI Act?

No. Registration is one regulatory record. It does not replace classification, conformity assessment, technical documentation, instructions, post-market monitoring or deployer duties.

Sources and further reading

RESEARCH & DEFINITIONS

How a Signal worth attention is found

See how Top Prospect finds and organizes Signals worth checking, keeps the original Telegram context, removes duplicates, and helps you decide what to review first. You decide whether to follow up and what to do next.

Open the methodology and core definitions

START WITH ONE MONITORED GROUP

Try the workflow free for seven days.

Open the product, connect one authorized group, and describe the Signal you want to find. If you need help choosing the scope, ask us on Telegram.

Back to homepage