EU AI Act Registration Guide: Article 49, Article 71, and Annex VIII

Timing note: check the current text before relying on deadlines¶

The published EU AI Act says the Regulation applies from August 2, 2026, with phased exceptions. As of May 2026, EU institutions had also reached a provisional political agreement on Digital Omnibus changes. The Council announcement says the agreement would move standalone high-risk AI system rules to December 2, 2027 and high-risk AI systems embedded in products to August 2, 2028.

The same Council announcement says the provisional agreement reinstates provider registration obligations where providers consider their systems exempt from high-risk classification. Until the final legislative text is formally adopted and published, compliance teams should check the Official Journal text before relying on amended dates.

The practical takeaway is simple: do not wait for the portal or final deadline. The data required by Annex VIII depends on upstream governance work that takes months to assemble.

What Article 49 registration is for¶

Article 49 is about registration of certain AI systems before they are placed on the market, put into service, or used. It mainly applies to AI systems listed in Annex III, the standalone high-risk use cases: biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration and border control, and administration of justice and democratic processes.

The registration regime is tied to high-risk classification under Article 6. A system can be high-risk because it is a product or safety component covered by Annex I legislation and requires third-party conformity assessment, or because it falls within an Annex III use case. Article 6(3) also creates a narrow route for some Annex III systems to be treated as not high-risk, but profiling of natural persons remains high-risk.

That means registration is not just a disclosure exercise. It is the public or regulatory-facing endpoint of a classification decision.

What Article 71 does¶

Article 71 establishes the EU database for high-risk AI systems listed in Annex III. The Commission, working with Member States, must set up and maintain it. The database contains high-risk systems registered under Articles 49 and 60, plus systems that providers say are not high-risk under Article 6(3) but must still register under Article 49.

Article 71 splits submission responsibility across providers and certain deployers. Providers or authorised representatives enter Annex VIII Sections A and B. Deployers that are public authorities, EU bodies, agencies, or persons acting on their behalf enter Section C.

By default, Article 71 says Article 49 database information should be publicly accessible, user-friendly, easily navigable, and machine-readable, except for restricted sections such as sensitive law enforcement and migration-related use cases.

Registration is not the same as technical documentation¶

Do not confuse Annex VIII registration data with Annex IV technical documentation. Annex VIII is the public or regulatory database entry. It contains concise identifying, status, purpose, conformity, and deployer-use information. Annex IV is the deeper technical documentation package: system description, development process, architecture, data requirements, human oversight, validation and testing, cybersecurity, risk management, lifecycle changes, standards, declaration of conformity, and post-market monitoring plan.

The two should be linked, but they are not the same artifact. Annex IV is the detailed compliance dossier. Annex VIII is the registration payload. Article 49 is the legal trigger. Article 71 is the database mechanism. Your internal AI registry is the system of record that should generate and support all of the above.

Who needs to register?¶

The answer depends on role, classification, Annex III point, and deployment context. A vendor registration alone may not be enough if a public-sector organisation deploys the system. A not-high-risk Article 6(3) conclusion may also create its own registration trail.

What Annex VIII requires from providers and deployers¶

Annex VIII is not a huge list, but the fields are loaded. Intended purpose, operating logic, status, certificate, EU declaration of conformity, instructions for use, and Member State availability all depend on upstream governance work.

If your intended purpose is vague, your registration will be vague. If product versioning is weak, traceability will be weak. If conformity documentation is not release-bound, the team may not know which declaration belongs to which system version.

The practical Article 49 decision tree¶

Start with the system, not the vendor. Registration depends on classification and use, not on whether the product is marketed as a platform, assistant, model wrapper, copilot, or agent.

A practical routing review should answer eight questions: whether the system is in scope, whether Article 6(1) applies, whether Annex III applies, whether Article 6(3) is used, whether Annex III point 2 moves it to national registration, whether restricted sections apply, whether the deployer is a public authority or acting for one, and whether the team can keep registration up to date.

• If the system is outside the Act, record the rationale and stop.
• If Article 6(1) applies, confirm product-sector and registration implications.
• If Annex III does not apply, Article 49 EU database registration may not apply; keep the classification record.
• If Annex III applies and the system is high-risk, prepare Article 49(1) provider registration.
• If Annex III applies and the provider relies on Article 6(3), prepare Article 49(2) registration and the rationale.
• If Annex III point 2 applies, check the national registration route.
• If Annex III points 1, 6, or 7 apply in sensitive law enforcement or border contexts, check the secure non-public section.
• If the deployer is a public authority or acting on behalf of one, prepare the Section C deployer-use record.

What to prepare before registration¶

A strong registration process starts long before database submission. Build the internal package first, then generate the registration payload from the governed record.

Use a versioned internal data model¶

A registration-ready AI system record should be versioned, owned, reviewed, and tied to runtime use. The exact schema can vary, but it should connect identity, classification, intended purpose, supported functions, inputs, operating logic, market status, conformity evidence, and registration route.

For public-authority deployers, add a deployer-use record with the provider database entry URL, use context, FRIA summary, DPIA summary where applicable, and submission status. The provider may own the system entry, but the deployer owns the context of use.

Registration and change management¶

Annex VIII requires submitted information to be kept up to date. That creates an operational question: what changes require review or update? The compliance team should not discover a registration-relevant change after production deployment.

Build registration review into release management, model changes, new country launches, product renaming, certificate updates, instructions-for-use changes, and workflow expansions.

• The intended purpose changes or the system starts processing new input categories.
• The system enters a new Member State or moves from testing to in service.
• The system is withdrawn, recalled, or no longer offered.
• The trade name, provider, or authorised representative changes.
• The operating logic materially changes or the system becomes an agentic workflow.
• The system begins profiling natural persons or the Article 6(3) rationale changes.
• A certificate is issued, updated, suspended, or expires.
• A public-authority deployment starts, stops, or changes context.
• A FRIA, DPIA, or instructions-for-use document is updated.

Registration for AI agents and copilots¶

Article 49 was not written only for static machine-learning products. It applies based on legal classification, intended purpose, and context of use. An internal productivity copilot may not be high-risk, but the same architecture used to screen candidates, score students, triage emergency calls, assess benefit eligibility, or support law enforcement may fall within Annex III.

An agent adds another layer. It may call tools, retrieve data, update records, route cases, recommend actions, or trigger workflows. That can change the intended purpose and the material influence of the system.

• Keep a tool inventory and action inventory.
• Record human approval points and decision influence analysis.
• Map affected persons, input/output lineage, runtime policy controls, and escalation paths.
• Version instructions for use and monitor drift from the registered intended purpose.
• Avoid generic intended-purpose language such as "AI assistant for case management" when the system actually triages claims, drafts legal conclusions, or routes high-risk cases.

What regulators and the public may learn from the database¶

Article 71 says Article 49 database information should generally be publicly accessible, user-friendly, easily navigable, and machine-readable, except for restricted sections. Registration therefore becomes part of the public trust surface.

Providers may expose who provides the system, what it is called, its intended purpose, supported functions, high-level data and inputs, where it is available, whether it is on the market or recalled, whether conformity documents exist, and how deployers can access instructions for use. Public-authority deployers may expose which authority uses the system, which provider system is used, and summaries of FRIA and DPIA findings.

Annex VIII summaries should be accurate, clear, and defensible. They should not leak trade secrets unnecessarily, but they also should not be so vague that they undermine trust.

Common mistakes¶

The recurring mistakes are not caused by Annex VIII being too long. They happen when teams treat registration as a legal formality instead of an output of product, engineering, privacy, security, compliance, deployment context, and runtime evidence.

Minimum evidence pack for Article 49 registration¶

Before submitting or approving registration, assemble an exportable evidence pack. The person submitting to the EU database should not need to chase five teams to answer one Annex VIII field.

• AI system inventory record, provider/deployer role analysis, Article 6 classification assessment, and Annex III mapping.
• Article 6(3) non-high-risk assessment, if applicable.
• Intended purpose statement, system version, release record, status record, Member State availability list, high-level data/input description, operating-logic summary, and supported functions.
• EU declaration of conformity, notified-body certificate details where applicable, electronic instructions for use, and public information URL if used.
• FRIA summary and DPIA summary where deployer Section C applies.
• Approval record, change-management trigger list, and named owner for keeping registration updated.

How KLA would operationalize this¶

The core problem is not that Annex VIII has too many fields. It does not. The problem is that each field points to a control that must remain true over time.

KLA should make registration a governed output of the AI control plane: maintain a canonical inventory, map each system to Article 6, Annex III, Article 49, and Annex VIII, store intended purpose and deployment context, route high-risk classifications and Article 6(3) exceptions for approval, attach conformity documents and impact assessments, detect runtime drift, record agent actions and approvals, and export evidence for audit, procurement, regulators, or database submission.

That is the difference between "we filled in the EU database once" and "we can prove the registered system is still the system running in production."

Registration readiness checklist¶

Before a high-risk AI system launch, ask these questions. If any answer is unclear, the system is not registration-ready.

• Have we identified whether Article 6(1), Article 6(2), or Article 6(3) applies?
• Have we mapped the system to the correct Annex III point and checked whether point 2 requires national registration?
• Have we checked whether the system belongs in a secure non-public section?
• Have we identified whether we are provider, authorised representative, deployer, or acting for a public authority?
• Have we prepared Annex VIII Sections A, B, or C as applicable?
• Do we have a stable intended purpose, operating logic summary, input-data description, instructions for use, conformity evidence, and Member State list?
• Do we have a process to keep registration updated and reconstruct the evidence behind every submitted field?
• Can runtime logs prove the system is operating within its registered intended purpose?

Penalties and enforcement risk¶

Article 99 requires Member States to lay down effective, proportionate, and dissuasive penalties. Several operator-obligation infringements can lead to administrative fines of up to EUR 15 million or 3% of total worldwide annual turnover, whichever is higher. Supplying incorrect, incomplete, or misleading information to notified bodies or national competent authorities in response to a request can lead to fines of up to EUR 7.5 million or 1% of total worldwide annual turnover, whichever is higher.

Registration is also an enforcement signal. Article 80 says market surveillance authorities may perform checks while taking into account information stored in the EU database. The risk is not only failure to register. The bigger risk is inconsistency: the public database entry says one thing, technical documentation says another, and the production system does something else.