What Makes a Delay Work
The Digital Omnibus does more than move the EU AI Act’s high-risk dates. It also tries to build the standards, authorities, assessment routes, sandboxes, and testing options that make those dates workable. This chapter follows that implementation chain and explains the practical judgment it supports: a later deadline reduces pressure only if the supporting infrastructure arrives in time, and a sandbox or testing framework helps an operator prepare without suspending the underlying law.
The delayed date is a capacity problem
The final regulation’s recitals identify a specific failure mode in the original timetable. Harmonised standards—which give providers technical ways to demonstrate conformity—were being prepared later than expected. National governance and conformity-assessment frameworks were also delayed. The result, according to the legislative explanation, was a compliance burden heavier than anticipated and a risk that the high-risk rules would formally apply before companies and authorities had reliable ways to implement them.
That explanation is more concrete than saying that the rules were “too difficult.” A regulation can be clear in principle and still be hard to apply if the surrounding institutions are missing. A provider may know that a high-risk system needs risk management, data controls, technical documentation, quality management, and monitoring, yet still lack a standard that translates those obligations into accepted technical evidence. An assessment body may understand the legal requirements but not yet have a designation covering the type of AI system. A national authority may be responsible for supervision without an operational framework for coordinating with a product regulator or a data-protection authority.
The Digital Omnibus responds by treating implementation as a network rather than a single provider task. It asks the Commission to request standardisation deliverables, including where appropriate harmonised standards, that facilitate joint compliance with the AI Act and relevant Union product legislation. It also directs attention to complementary risk and quality-management systems. The point is to avoid making an operator maintain two disconnected compliance worlds when one integrated process can address overlapping risks.
Integration does not mean that a product risk assessment automatically proves AI conformity. It means that the legal and technical work can be organized so that the same evidence, controls, and governance structures address requirements that genuinely overlap. The comparison still has to be made. A product safety test may say little about the quality of training data, the robustness of model outputs, or the transparency needed for an AI-specific risk. Conversely, a model evaluation may not establish that a physical machine remains safe under the operating conditions required by product law.
The act therefore preserves the distinction between a legal requirement and the instrument used to show compliance. Harmonised standards can support a presumption of conformity where the relevant conditions are met, but a standard is not the AI Act itself. Guidance can explain how to apply a rule, but guidance is not proof that a provider’s system meets the rule. A unified assessment can reduce repeated designation work, but it does not remove the need for a competent assessment. The intended simplification is a better interface between these layers.