AI Act "Omnibus": Industrial AI Leaves the Scope, but Traceability Stays Your Problem

During the night of 6 to 7 May 2026, after an inconclusive first trilogue in late April, the European Parliament and the Council reached a provisional agreement on simplifying the AI Act, as part of the "Digital Omnibus" package. The compromise, confirmed on 11 May, contains a provision the entire European industry had been waiting for: industrial AI leaves the direct scope of the AI Act, and the application of the provisions on high-risk systems is pushed back to the end of 2027.

Inside the engineering departments of robot makers, intelligent machine builders and autonomous system manufacturers, the first reaction was often relief. It is understandable. It is also, in large part, a misreading.

This article offers a contrarian analysis: the Omnibus does not reduce the traceability requirement that weighs on AI embedded in industrial products. It relocates it. And for makers of regulated hardware, that relocation makes structuring engineering data more urgent, not less.

What the agreement actually changes

Let us go back to the facts. The May 2026 agreement has four main components for industrial players.

First, the exemption of industrial AI from the direct scope of the regulation. AI systems integrated into industrial equipment and already covered by sector-specific legislation no longer fall directly under the AI Act, in order to avoid dual compliance regimes.

Second, the postponement of the high-risk deadlines. The obligations applicable to standalone high-risk AI systems in Annex III are pushed back to December 2027, and the national regulatory sandboxes to August 2027.

Third, a few targeted accelerations: the obligation to label AI-generated content sees its transition shortened to December 2026, and an explicit ban on "nudification" systems is introduced.

Fourth, an extension of the flexibility measures to "small and mid-caps," a category that covers a large share of European industrial mid-sized companies.

On paper, this is a victory for the line pushed by Germany and France, which argued for better consideration of sector-specific realities. But as several analysts note, behind the simplification label the agreement does not call into question the foundations of the regulation: it changes the way it is integrated into sector ecosystems.

That is where everything is decided for hardware makers.

The exemption that is not one

Take the case of a maker of autonomous mobile robots for logistics, or a machine-tool builder integrating AI-based vision for quality control. What does "leaving the direct scope of the AI Act" concretely mean?

It means that the compliance of the embedded AI will be assessed through the sector-specific legislation applicable to the product. For a robot or a machine, that legislation is the Machinery Regulation 2023/1230, applicable in January 2027. And this regulation, unlike the directive it replaces, explicitly addresses evolving-behavior and self-learning systems. It requires the manufacturer to document the safety logic, the limits of use, the data that determines the system's behavior, and to keep this documentation up to date throughout the entire life of the product.

For a medical device integrating AI, the sector-specific legislation is the MDR, whose ongoing revision fully maintains the requirements for technical documentation and post-market surveillance.

In other words: the substantive requirement has not disappeared. It has changed address. Instead of a horizontal AI Act regime that would have layered on top of the sector regimes, industrial players face sector regimes that absorb the requirements relating to AI. The dual compliance disappears, the compliance remains.

There is even an argument that the situation becomes more demanding. A horizontal regime would have produced generic guidelines, standardized documentation templates, a shared advisory ecosystem. Sector regimes, on the other hand, require each manufacturer to translate the principles of AI control themselves into the language of their own regulation, their own harmonized standards, their own notified body.

The real issue: behavior traceability

What makes AI so hard to document within a regulatory framework? It is not the code. It is the fact that the system's behavior no longer depends only on its design, but on its training data, its parameters, its model versions, and sometimes on its learning in operation.

The technical documentation of a classic machine describes a stable causal chain: this safety requirement is covered by this function, delivered by this component, verified by this test. The documentation of an intelligent machine must describe a moving causal chain: this safety requirement is covered by this function, delivered by this model in this version, trained on this dataset, with these measured performances, these known limits and these retraining conditions.

Every model update is potentially a change in the product's definition. Every change in definition must trigger an impact analysis: which requirements are affected, which tests must be re-run, which documentation must be revised, which already-delivered products are impacted.

Do the math. A robot maker that updates its perception models every quarter, across a range of three products declined into ten customer variants, generates a flow of impact analyses that manual documentation processes simply cannot absorb. This is not a question of the teams' rigor, it is a question of information architecture.

Why current tools are not enough

Most of the manufacturers concerned manage their compliance today with a combination of three tools: a CAD-oriented PLM for mechanical definitions, a ticket manager for software development, and an office suite for requirements and technical files.

This architecture has a structural flaw: the links between the worlds exist nowhere. The link between a safety requirement of the Machinery Regulation and the version of the vision model that satisfies it is written in no system. It lives in the head of the systems engineer, in an Excel correspondence table dating from the last certification, or in a paragraph of a validation report.

Yet this link is precisely what the notified body, the customer or the market surveillance authority will ask you to demonstrate. And it is this link that must be reassessed at every evolution of the model.

The architectural answer to this problem is known: represent engineering as a graph. Requirements, functions, hardware components, software models, datasets and verification evidence become nodes; the relationships of satisfaction, realization, verification and impact become edges. In this model, the impact analysis of a model update is a graph traversal, executed in seconds. The production of the technical file is a subgraph extraction, not a three-month project.

This is Koddex's stance: rather than adding one more tool to the archipelago, build the repository that connects every engineering object, from the regulatory need to the test evidence, with native traceability designed for European regulatory regimes.

Eighteen months to prepare, not to wait

Pushing the high-risk deadlines back to the end of 2027 creates an eighteen-month window. The temptation is to treat it as a reprieve. Three reasons argue for making it, on the contrary, a period of active structuring.

First, the Machinery Regulation does not wait: January 2027 is six months away. For makers of machines and robots integrating AI, it is this deadline that sizes the calendar, not the AI Act's.

Next, documentation cannot be caught up after the fact. A traceability repository is built along with the engineering; rebuilding it after the fact typically costs three to five times more and produces a less reliable result. Every development sprint carried out without structuring is debt that accumulates.

Finally, demonstrable compliance becomes a commercial argument. Integrators and end customers, themselves subject to deployer obligations, are starting to require documented guarantees from their suppliers on the control of embedded AI. The manufacturer able to produce in a few clicks the traceability matrix between safety requirements and model versions will win tenders against those who promise to produce it "within a few weeks."

Conclusion: the simplification is regulatory, not technical

The May 2026 Omnibus agreement simplifies the legal landscape. It does nothing to simplify the underlying technical problem: controlling and demonstrating the behavior of systems whose definition evolves permanently.

For the CTOs of European robotics and deeptech, the operational conclusion fits in one sentence: do not build your compliance roadmap on the AI Act's deadlines, build it on the structure of your engineering data. If that structure is a traceable graph, every future regulatory change will be one more query. If it is an archipelago of documents, every regulatory change will be one more crisis.

Europe has chosen to trust sector regimes to govern industrial AI. The industrial players who take that trust seriously will come out of it stronger.

Sources

- Artificial Intelligence: Council and Parliament agree to simplify and streamline rules (Council of the EU / Consilium, 7 May 2026)
- EU AI Act Omnibus Agreement: Postponed High-Risk Deadlines and Other Key Changes (Gibson Dunn, May 2026)
- EU agrees Digital Omnibus deal to simplify AI rules (White & Case, May 2026)
- Digital Omnibus on AI Regulation Proposal (European Commission, Shaping Europe's digital future, 19 November 2025)
- Artificial Intelligence: Council gives final green light to simplify and streamline rules (Council of the EU / Consilium, 29 June 2026)
- Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act) (EUR-Lex, Official Journal, 13 June 2024)

Koddex centralizes requirements, definitions, software versions and compliance evidence in a graph-based engineering repository designed for European regulated industries. Request a demonstration on the case of embedded AI.