Digital Omnibus and EU AI Act high-risk AI registration: what is adopted, what applies, what is open

Where the Digital Omnibus stands

The Commission's Digital Omnibus proposal presented its AI Act amendments in a separate legal proposal. That proposal has since been followed by an adopted act: Regulation (EU) 2026/1744 of the European Parliament and of the Council, dated 8 July 2026, which amends Regulation (EU) 2024/1689 as well as Regulations (EU) 2018/1139 and (EU) 2023/1230. Internal guidance that still describes the AI amendments as a pending proposal should be updated.

The Omnibus sets staggered application for Chapter III. Systems classified as high-risk under Article 6(2) and Annex III apply from 2 December 2027. Systems classified as high-risk under Article 6(1) and Annex I apply from 2 August 2028.

On registration specifically, the recitals say that registration of systems referred to in Article 6(3) should be simplified and made more proportionate. They also say registration in the EU database remains crucial for effective market surveillance and public accountability. The recitals describe the direction of change. Compliance teams should therefore avoid treating the recital language as a description of a finished procedure.

Current AI Act text compared with the Omnibus

The table separates what the consolidated AI Act of 27 July 2026 shows from what the Omnibus recitals state. Each row carries a status label so that internal guidance can reuse the same wording.

• Registration by providers of high-risk systems: Current text: providers must comply with the Article 49(1) registration obligations, alongside Article 43 conformity assessment and CE marking. Omnibus: recitals restate that registration remains crucial for market surveillance and public accountability. Status: in force.
• Provider-assessed Article 6(3) systems: Current text: a provider that considers an Annex III system not high-risk must document the assessment before placing it on the market or putting it into service, and is subject to Article 49(2). Omnibus: recitals say registration should be simplified and made more proportionate. Status: direction adopted, mechanics to be confirmed.
• Assessment documentation: Current text: the provider must be able to give the assessment documentation to national competent authorities on request. Omnibus: recitals describe Article 6(3) systems as those that do not pose a significant risk of harm to health, safety or fundamental rights. Status: in force.
• Application dates: Omnibus: Chapter III applies from 2 December 2027 for Article 6(2) and Annex III systems, and from 2 August 2028 for Article 6(1) and Annex I systems. Whether each registration duty follows these dates is a legal determination. Status: adopted for Chapter III.
• Deployer position: Current recitals: deployers take technical and organisational measures to use systems according to instructions, monitor functioning and keep records as appropriate. No deployer registration change should be assumed. Status: open.

Providers, deployers and Article 6(3) systems

Under the current text, the registration entry is made by the provider. Recital 131 says the EU database is established and managed by the Commission, and that providers of high-risk systems, other than those tied to products under existing Union harmonisation legislation, must register themselves and information about their system. Providers relying on the not-high-risk derogation must do the same.

The Article 6(3) route is the point where the Omnibus recitals focus. A provider that relies on it takes on a documented assessment, made before market placement or putting into service, and still carries a registration obligation under Article 49(2). The recitals describe a lighter, more proportionate approach to that registration. Until the operative wording is confirmed in the consolidated text, the safest working assumption is that the documented assessment and the registration duty both remain part of the provider's file.

Role matters. If a distributor, importer or deployer becomes a provider under the AI Act, provider obligations apply, including Article 49(1). Role analysis should therefore be recorded per system and revisited when an enterprise modifies, rebrands or repurposes a system. Deployer registration treatment remains an open question and should be handled as a legal review item rather than an assumption.

What registration does not cover

Registration sits beside other obligations that stay in force. Providers of high-risk systems must keep the automatically generated logs referred to in Article 19 when those logs are under their control, ensure conformity assessment under Article 43 and affix the CE marking. The recitals also say deployers should monitor the functioning of high-risk systems and keep records, as appropriate.

These are different evidence sets. Registration data describes the system and is filed once and updated as the system changes. Logs, monitoring records and evidence of use in accordance with instructions are produced during operation, and they come from the environment where the system runs. A registry entry contains none of them. A national competent authority that asks for documentation will not be satisfied by a registry reference alone, so the enterprise needs to know where operational records live and who controls them.

This separation is also a useful test of readiness. If a team can complete a registry entry but cannot say where the Article 19 logs for the same system are held, the registration work is ahead of the evidence work.

Where runtime enforcement supports the record

Trussed does not file registrations and does not make classification decisions. Those remain legal and compliance decisions for the enterprise or its provider.

Trussed operates in the execution path. It enforces policy at runtime, not reviewed after the fact, across models, agents, tools and MCP servers, with actions that include allow, redact, block, rate limit and escalate for human approval. The scope is individual interactions and tool calls. That enforcement generates continuous, audit-ready evidence mapped to the EU AI Act, among other frameworks. For a regulated enterprise, this supports the operational records a regulator may request after a system is registered, such as what a system was allowed to do and what happened. It can be deployed self-managed in the customer cloud, with configurable retention and data residency.