Scope: which systems and actors fall under Article 49
Article 49 is a market-access control for high-risk AI, not a general AI inventory rule. Providers must register high-risk AI systems referred to in Article 6(2), meaning systems listed in Annex III, in the EU database established by Article 71 before placing the system on the market or putting it into service. That registration obligation sits alongside provider duties in Articles 16 to 27 and depends on a defensible high-risk classification under Article 6.
Providers of high-risk AI systems covered by Annex I product legislation (Article 6(1)) register in the EU database only where those systems are placed on the market or put into service without undergoing a third-party conformity assessment under that product law, subject to the conditions in Article 49. Prohibited practices under Article 5 and general-purpose AI model rules are outside Article 49 registration scope.
Deployers that are public authorities, Union institutions, bodies, offices, or agencies, or that act on their behalf, must register use of specified high-risk AI systems under Article 49(3). Private enterprise deployers should still determine whether they are also providers in law (for example through substantial modification or own-name placing on the market), because role determination drives who files what.
For high-risk AI systems in Annex III points 1, 6, and 7 in law enforcement, migration, asylum, and border control management, only a limited non-sensitive subset of Annex VIII data is made publicly accessible. Other data remain available to the Commission and national authorities. Enterprises operating in those domains need dual handling: internal records that are complete for audit, and controlled public-facing fields that match statutory visibility limits.
The AI Act entered into force on 1 August 2024. Obligations apply on a phased timeline. Most high-risk system duties, including database registration, apply from 2 August 2026 unless a specific earlier or later date applies to a given requirement.
| Actor / system | Registration duty |
|---|---|
| Provider, Annex III (Art. 6(2)) | Register self and system in EU database before market placement or putting into service |
| Provider, Annex I product AI (Art. 6(1)) | Register only when placed on the market or put into service without third-party conformity assessment under that product law |
| Public-authority deployer (Art. 49(3)) | Register use of specified high-risk systems |
| Article 5 prohibited practices / GPAI models | Outside Article 49 registration scope |
What must be submitted and how it connects to conformity
Information submitted on registration is set out in Annex VIII, Sections A to C. In practical terms, fields cover provider identity and contact data, system identification and versioning, intended purpose, conformity-related information, and deployer registration data where Article 49(3) applies. These fields map directly to elements already required in Annex IV technical documentation: system identity, intended purpose, version control, conformity route, and provider particulars.
Registration is administratively linked to completion of conformity assessment (Article 43), drawing up the EU declaration of conformity (Article 47), and CE marking where required (Article 48). Registration should not be treated as a standalone form. The database entry must be consistent with the declaration of conformity and with technical documentation kept up to date. If declared purpose, system identity, or conformity route diverge from Annex IV records, market-surveillance review will treat that inconsistency as a compliance failure, not a clerical mismatch.
Article 71 establishes the EU database, managed by the Commission, with public accessibility of registered information except where Article 49 restricts visibility for sensitive law-enforcement and migration systems. Operational detail of the Commission-operated interface, APIs, and submission workflows may continue to evolve in implementing guidance. Enterprise programs should therefore store canonical registration payloads and submission evidence internally, independent of any single portal workflow.
After initial registration, providers must ensure that registration information remains complete, correct, and up to date. That continuing duty connects to post-market monitoring and to substantial modification analysis. A change that alters intended purpose, risk profile, or the system as placed on the market can require registration updates and, where applicable, renewed conformity assessment.
Treat Annex VIII as a published view of Annex IV, Article 43 outcomes, and the EU declaration of conformity. Any gap between those artifacts and the database entry is a compliance risk.
Governance processes that keep registration accurate
Article 49 is an ongoing accuracy and lifecycle control duty, not a one-time filing at go-live. Enterprises need a system inventory keyed to Annex III and Article 6 classification, with unique system and version identifiers reused in technical documentation, declarations of conformity, and database submissions. Without stable identity, registration becomes a snapshot that drifts from the system actually operated.
Accountable ownership should be explicit for every registrable system: legal provider entity, technical owner, and compliance approver. Dual-control validation before submission reduces the risk that marketing descriptions, engineering nicknames, or incomplete intended-purpose statements enter the official record. Registration records should link in a controlled configuration store to technical documentation repositories, conformity-assessment outcomes, and EU declarations of conformity so reviewers can trace each Annex VIII field to an approved source artifact.
Change management must treat substantial modification and intended-purpose changes as compliance events. Metadata for model updates, capability expansion, deployment environment changes, and new tool integrations should trigger a registration accuracy review. Where the change is substantial under the Act, renewed conformity work and database updates are part of the same control path, not sequential afterthoughts.
Cross-functional operating rhythm is required among legal, AI governance, security, engineering, and audit. Legal owns role determination and exclusion rationales, such as why a given Annex I product path does not require EU database registration after third-party assessment. Governance owns the inventory and release gate. Engineering owns version identity and environment controls. Audit owns evidence retention for market surveillance: classification rationale, Annex IV packages, declarations of conformity, registration submission receipts, and change logs.
For law-enforcement and migration-related Annex III systems, separate public versus restricted data handling so internal records exceed what is publicly listed while still meeting authority-access needs. Document the legal basis for restricted visibility rather than relying on informal redaction.