Physical AI teams can misclassify a system by asking only whether it appears in Annex III. The EU AI Act has two high-risk routes, and the 2026 Digital Omnibus changed both the application timeline and the treatment of machinery. The right unit of analysis is the AI system's intended purpose, role in the physical product and effect on people—not the model family or whether inference runs at the edge.
Legal and evidence boundary — source-reviewed 2 August 2026. This article is informational product-and-architecture analysis, not legal advice or a conformity determination. It uses the official text of Regulation (EU) 2024/1689, the in-force amending Regulation (EU) 2026/1744 and European Commission implementation pages. Classification remains fact-specific; obtain qualified legal and conformity-assessment advice for a real system.
What changed in July 2026
Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026. It set different application dates for the high-risk rules in Chapter III, Sections 1–3:
- 2 December 2027 for systems classified under Article 6(2) and Annex III;
- 2 August 2028 for systems classified under Article 6(1) and Annex I.
The amending Regulation also moved the Machinery Regulation (EU) 2023/1230 from Annex I Section A to Section B. For Section B products, the horizontal AI Act applies only in the limited way stated in amended Article 2(2), while AI-specific health and safety requirements are to be integrated into the Machinery Regulation through delegated acts that apply by 2 August 2028. A machinery team should therefore not reuse a pre-Omnibus classification memo without checking this changed legal path.
The Commission's AI Act implementation page reflects the new timeline. The official texts remain the authority.
The two high-risk routes
Route A — Article 6(1) and Annex I products
Under Article 6(1), an AI system is high-risk when both conditions hold:
- it is intended as a safety component of a product—or is itself a product—covered by Union harmonisation legislation listed in Annex I; and
- that product is required to undergo a third-party conformity assessment before being placed on the market or put into service under the listed legislation.
This route matters to Physical AI because Annex I covers regulated product families. But do not collapse all machines, robots or vehicles into one answer. Identify the exact host product, applicable sector legislation, the AI function and whether it is in the safety path. After the 2026 amendment, also identify whether that legislation sits in Annex I Section A or Section B and which AI Act provisions apply through that route.
A model used only to generate maintenance prose is not automatically a safety component. A learned function whose failure can endanger health or safety may be. The intended purpose, technical authority and foreseeable failure consequence need to be documented before a label is assigned.
Route B — Article 6(2) and Annex III use cases
Annex III lists use cases in eight areas: biometrics; critical infrastructure; education and vocational training; employment and worker management; access to essential private/public services and benefits; law enforcement; migration/asylum/border control; and administration of justice and democratic processes.
Industrial teams most often need to inspect at least three boundaries:
- critical infrastructure: whether the AI is intended as a safety component in managing or operating critical digital infrastructure, road traffic, or water, gas, heating or electricity supply;
- employment and worker management: whether it is intended to recruit/select people, decide conditions or termination, allocate tasks based on individual behaviour or traits, or monitor/evaluate worker performance or behaviour;
- biometrics: whether it performs a listed remote identification, sensitive-attribute categorisation or emotion-recognition function, subject to the Act's wording and other applicable law.
An industrial label such as predictive maintenance, digital twin or operator assistant does not decide the classification. Intended use and effect do. A maintenance model that predicts equipment state is not automatically an employment system; a product workflow that uses its output to allocate work based on individual behaviour or characteristics may enter the Annex III employment analysis.
The Article 6(3) exception is a documented decision, not a shortcut
An Annex III-listed system may be treated as not high-risk under Article 6(3) when it does not pose a significant risk of harm to health, safety or fundamental rights, including by not materially influencing a decision outcome, and one of the specified conditions applies: a narrow procedural task; improvement of a previously completed human activity; detection of decision patterns/deviations without replacing or influencing the completed human assessment absent proper human review; or a preparatory task.
The exception does not apply when the system profiles natural persons. A provider relying on it must document the assessment before market placement or putting into service and remains subject to the registration obligation described in Article 6(4)/Article 49.
The evidence packet should therefore state:
- the exact Annex III entry considered;
- intended purpose, users and affected persons;
- inputs, outputs and downstream decisions;
- why the output does or does not materially influence an outcome;
- which Article 6(3) condition is relied on;
- human authority and review in the real workflow;
- profiling assessment;
- foreseeable misuse and change triggers;
- approver and date.
If the product later gains new decision authority, the assessment must be revisited.
Five Physical AI scenarios—how to ask the question
These are classification prompts, not legal conclusions.
| Scenario | First classification question | Evidence needed |
|---|---|---|
| Vision quality inspection that routes parts to rework | Does the AI sit in a safety function or an Annex III use case, or is it a product-quality function only? | Intended purpose, actuator authority, consequence of error, host-product law |
| Robot perception used in a protective function | Is it a safety component of a regulated product, and which post-Omnibus sector path applies? | Safety architecture, product legislation, conformity route, failure response |
| AI scheduling maintenance technicians | Is task allocation based on individual behaviour or traits, or is the tool only planning equipment work? | Worker data, allocation logic, human authority, effect on employment decisions |
| AI supporting electricity-network operation | Is it intended as a safety component in management/operation of electricity supply? | Infrastructure boundary, system authority, safe state, operator role |
| Multimodal maintenance assistant | Does it merely retrieve/summarise approved information, or can its output command equipment or materially decide a listed outcome? | Knowledge sources, tool permissions, action boundary, oversight and logs |
The exercise is to make the system boundary testable. AI assistant and decision support are not exemptions; they are descriptions that need to be unpacked.
A role map comes before an obligation map
The Act assigns obligations by role, including provider, deployer, importer, distributor, authorised representative and product manufacturer. A company can become a provider when it develops an AI system or has one developed and places it on the market or puts it into service under its name or trademark. Contracts and architecture should therefore identify who controls intended purpose, substantial modification, model/system release, instructions for use and post-market monitoring.
For a system built on a general-purpose model, keep the layers distinct:
- the GPAI model provider has model-level obligations;
- the company integrating it into a specific system still has to classify that system and determine its own role;
- a model card or vendor compliance statement is an input, not a conformity assessment for the downstream product.
The timeline product teams should use
| Date | What the official timeline says | Product implication |
|---|---|---|
| 2 February 2025 | Chapters I and II began applying, subject to the later dates added for specific new prohibitions by Regulation 2026/1744; AI-literacy obligations apply | Maintain role-based AI literacy evidence and check prohibited-practice boundaries now |
| 2 August 2025 | Governance, penalties and GPAI provisions began applying under the original phased schedule | Model-provider and value-chain evidence cannot wait for high-risk dates |
| 27 July 2026 | Regulation (EU) 2026/1744 entered into force | Replace outdated timeline and machinery assumptions |
| 2 August 2026 | The general application date and Article 50 transparency regime apply, subject to specific transitions | Review user disclosure and synthetic-content marking obligations |
| 2 December 2026 | Transitional deadline in amended Article 111(4) for Article 50(2) marking by systems placed on the market before 2 August 2026; specific added prohibitions also apply | Separate machine-readable marking from user-facing disclosure and track the relevant product cohort |
| 2 December 2027 | Chapter III Sections 1–3 apply to Article 6(2)/Annex III high-risk systems | Build classification, risk, data, documentation, logging, transparency, oversight and assurance evidence before this date |
| 2 August 2028 | The same sections apply to Article 6(1)/Annex I high-risk systems; machinery integration is aligned through delegated acts | Coordinate AI evidence with the sector product-conformity path |
Do not turn this table into one generic compliance deadline. Different provisions, roles and product cohorts have different dates and transitions.
From classification to an engineering evidence pack
When a high-risk path applies, convert the legal requirements into owned artefacts rather than a late binder exercise. Chapter III covers, among other things, risk management (Article 9), data and data governance (Article 10), technical documentation (Article 11 and Annex IV), record-keeping (Article 12), transparency/instructions for deployers (Article 13), human oversight (Article 14), and accuracy, robustness and cybersecurity (Article 15). Provider/deployer obligations and post-market requirements sit elsewhere in the Act and must also be mapped.
A product-ready evidence pack links each obligation to:
- intended purpose and system boundary;
- accountable role and decision owner;
- requirement and acceptance criterion;
- architecture/control implementing it;
- test or operational evidence;
- residual risk and human authority;
- release/version identity;
- change trigger and review cadence.
This is where product management and architecture converge. Classification affects requirements, data, interfaces, human roles, release gates, supplier contracts and lifecycle cost. It cannot be delegated to a one-time legal memo after the architecture freezes.
The decision sequence
- Inventory the actual system, including model, sensors, software, hardware, human workflow and downstream action.
- Write the intended purpose and prohibited uses in operational terms.
- Map the exact product law and Annex I section, including the 2026 machinery change.
- Test every relevant Annex III entry against the real workflow.
- Assess Article 6(3) only with a written evidence record.
- Map provider/deployer and value-chain roles.
- Apply the provision-specific timeline.
- Turn obligations into product and architecture artefacts.
- Define change triggers for new models, permissions, users, sites, product variants and laws.
- Revalidate against official sources on a risk-based cadence.
The Physical AI Product System places that sequence inside product strategy, discovery, productisation, launch and scale. For a bounded classification and evidence decision, use the Product Decision Review; for the current legal interpretation of a live case, include qualified counsel and the relevant conformity-assessment expertise.
