What Is the EU AI Act? Requirements and the Digital Omnibus as Adopted

What the EU AI Act is, in plain English

The EU AI Act sets risk-based rules on placing certain AI systems on the market, putting them into service and using them. It applies to public and private actors inside and outside the EU that place an AI system or general-purpose AI model on the EU market, or that put an AI system into service or use it in the EU. Being headquartered elsewhere does not remove a company from scope.

The structure has three parts that matter for planning. First, obligations scale with risk, so the Act separates prohibited practices, high-risk AI systems and other uses. Second, obligations attach to roles. A provider is, for example, the developer of a CV-screening tool. A deployer is, for example, a bank using that tool. Providers of general-purpose AI models carry their own set of obligations. Third, application is phased, so different parts of the Act apply on different dates.

For a regulated enterprise, the practical consequence is that one organization often holds several roles at once. It may deploy third-party systems, build its own, and consume general-purpose models. Each system needs its own classification and role determination before anyone can say which obligations apply.

What already applies

Some rules have applied since 2 August 2025. These include the governance structure, the penalties and the obligations for providers of general-purpose AI models. A general-purpose model that meets the applicable threshold for high-impact capabilities is presumed to be a model with systemic risk, and its provider carries additional risk-management and cybersecurity obligations.

If your organization consumes general-purpose models rather than providing them, the provider obligations sit mainly with your suppliers. Your exposure comes through the systems you build on those models and how you classify and use them.

High-risk systems are where most regulated enterprise effort concentrates. They must comply with the Act's requirements, taking into account their intended purpose and the state of the art. Two requirements are central. Risk management is a continuous, iterative process planned and run throughout the system's lifecycle, aimed at identifying and mitigating risks to health, safety and fundamental rights. Human oversight is a design requirement: systems must be built so that natural persons can effectively oversee them while in use, with appropriate human-machine interface tools.

The Digital Omnibus on AI: what changed and when

Earlier planning assumed the Digital Omnibus was a proposal. It is not. The Commission proposed it on 19 November 2025, the Council and Parliament reached a provisional agreement on 7 May 2026, and it was adopted as Regulation (EU) 2026/1744 of 8 July 2026. The Commission states that it entered into force on 27 July 2026. It amends the AI Act, and a consolidated text of the Act dated 27 July 2026 exists.

The most important change for compliance leaders is the high-risk timeline. The original date of 2 August 2026 is no longer the planning date. The Commission said that date was at risk because standards were delayed. Its original proposal tied the timeline to confirmation that standards and tools were available, with an adjustment of up to 16 months. The adopted position uses fixed dates instead.

• 19 November 2025: Commission proposes the Digital Omnibus on AI.
• 7 May 2026: Council and Parliament reach a provisional agreement.
• 8 July 2026: Regulation (EU) 2026/1744 is adopted.
• 27 July 2026: The Commission states the amending regulation entered into force.
• 2 December 2027: Application date for stand-alone high-risk AI systems.
• 2 August 2028: Application date for high-risk AI systems embedded in products.

Other changes in the amending regulation

The Omnibus is not only a date change. It added prohibited practices covering non-consensual intimate material and child sexual abuse material. It clarified how the Act interacts with EU product safety rules. It gave further simplification to SMEs and to small mid-caps. It revised the AI literacy obligation. It also strengthened the AI Office's supervisory and enforcement powers.

Two of these deserve a direct check against current use cases. The new prohibited practices matter for any system that generates or processes images or similar content. The revised AI literacy obligation matters for any organization that has already built training around the earlier wording.

The Commission has also published guidelines for providers and deployers of high-risk AI systems. They clarify how classification as high-risk works and give practical examples. The Commission attributes readiness problems to delays in standards, in designating national competent authorities and in designating conformity assessment bodies. National authority designation is ongoing, so supervisory contact can come from more than one direction.

What stays constant whatever the dates

The Omnibus moved dates and adjusted some provisions. It did not change the risk-based structure, the split between providers and deployers, the lifecycle risk management requirement or the human oversight requirement. Moving a deadline by roughly sixteen months changes the schedule. It does not change what the work consists of.

A planning inference follows from the oversight and risk-management requirements. If people must be able to oversee a system effectively while it is in use, then the deployer needs a point at which a person can intervene during operation, and a way to show afterward that the intervention was available and used. A regulator or auditor reviewing a high-risk system would reasonably ask what the system was permitted to do and what it actually did. Policies written in a document and reviewed after the fact answer the first question weakly and the second not at all.

This is why uncertainty about dates is a poor reason to wait. The evidence a regulated enterprise will need is generated during operation. It cannot be reconstructed later for a period when nothing was recorded. Confirm the exact record-keeping and logging content against the Act text for each system, then design the evidence trail to meet it.

Where runtime policy enforcement fits

Trussed addresses one part of this work: the part that happens while AI is running. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Enforcement decisions are allow, redact, block, rate limit, or escalate for human approval. The scope is individual interactions and tool calls. Because policy is enforced at runtime, not reviewed after the fact, the enforcement itself produces continuous, audit-ready evidence, mapped to the EU AI Act among other frameworks. Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency.

This does not replace the classification, role determination and ownership decisions above. Those remain organizational judgments. It supports the operational question a regulated enterprise will face: showing a regulator what its AI was allowed to do and what it did.