Is Your Robot’s AI High-Risk Under the EU AI Act?
For AI embedded in products already covered by EU product legislation, which is where robots sit, the high-risk obligations now apply from 2 August 2028 rather than 2 August 2027 5. That sounds like breathing room until you notice the Machinery Regulation applies from 20 January 2027, eighteen months earlier, to the same robot. You will write a technical file for the first date. Whether it also serves the second is a decision you are making now, whether or not you know it.
Key takeaways
- The Digital Omnibus deferred the deadlines: Annex III standalone high-risk from 2 August 2026 to 2 December 2027, and Annex I embedded high-risk from 2 August 2027 to 2 August 2028 5.
- The new dates are fixed, not conditional. The originally proposed triggering mechanism was replaced with hard dates 5.
- Whether a robot is caught turns on Article 6(1), which is conjunctive, plus three paragraphs the Omnibus added 1.
- Paragraph 1a excludes AI used solely for non-safety purposes, and 1b immediately pulls back any AI whose failure would endanger health and safety 1. For a machine that moves mass near people, 1b usually decides it.
- Article 12: high-risk systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system" 2. That is a logging requirement written into product law.
What changed when the Digital Omnibus landed?
The high-risk deadlines moved, and it is worth being precise because a great deal of published commentary still quotes the original schedule. Annex III standalone high-risk systems moved from 2 August 2026 to 2 December 2027, and Annex I high-risk AI embedded in products already covered by sectoral legislation moved from 2 August 2027 to 2 August 2028 5. The AI Act Explorer now carries those same dates against each article, attributing them to Article 113(c) 123.
Two details matter more than the headline. First, the Article 50 transparency obligations were not deferred and remain on their original schedule from 2 August 2026, with only a short grace period for watermarking systems already on the market 5. If you read "the AI Act was delayed" and concluded nothing applies yet, that is wrong.
Second, the agreement "replaced the Commission's originally proposed conditional mechanism with fixed dates" 5. Earlier drafts would have tied the deferral to the availability of harmonised standards, which would have left the date genuinely uncertain. It is now a date. Plan against it rather than against a hope that it slips again.
Is your robot’s AI actually high-risk?
Article 6(1) sets a conjunctive test, and both limbs must be satisfied. An AI system is high-risk where "the AI system is intended to be used as a safety component of a product, or the AI system is itself a product, covered by the Union harmonisation legislation listed in Annex I", and that product "is required to undergo a third-party conformity assessment" under that legislation 1.
For robotics the first limb is usually straightforward, because the Machinery Regulation is Annex I harmonisation legislation and a robot is machinery. The interesting work happens in three paragraphs the Omnibus inserted, which appear to narrow the test and then substantially restore it.
| Paragraph | What it says | Effect on a robot |
|---|---|---|
| 6(1a) | AI used solely for non-safety aspects of user assistance, performance optimisation, service efficiency, automation, convenience or quality control does not qualify as a safety component 1 | Narrows scope, if the use really is solely non-safety |
| 6(1b) | Notwithstanding 1a, AI "the failure or malfunctioning of which would endanger health and safety shall qualify as safety components" 1 | Usually decisive for a mobile robot |
| 6(1c) | A product needing third-party assessment solely for non-health-and-safety risks, in particular radio spectrum or electromagnetic interference, does not satisfy 6(1)(b) 1 | A radio approval alone does not make you high-risk |
Read 1a and 1b together, because reading either alone produces the wrong answer. The word carrying the weight in 1a is "solely". A navigation stack could be described as automation, and a perception model as quality control, right up to the moment you ask what happens when either fails on a machine operating near a person. At that point 1b applies on its own terms.
Why does the radio-approval carve-out matter for robots?
Because robots collect radio approvals as a matter of course, and it would be easy to reason from the wrong one. Paragraph 1c provides that a product required to undergo third-party conformity assessment "solely due to risks other than risks to health and safety, in particular risks relating to the distribution of radio spectrum or electromagnetic interference that do not affect health and safety" does not thereby satisfy the second limb of Article 6(1) 1.
That is a sensible piece of drafting and a useful one. Every connected robot goes through radio conformity somewhere, and in the United States through FCC equipment authorization, which we covered in the analysis of the Covered List. Without 1c, the mere existence of a radio assessment could have been argued to drag products into high-risk classification for reasons having nothing to do with safety.
The practical consequence is that you should be able to name which third-party conformity assessment you rely on, and on what basis. If the answer is a machinery safety assessment, the limb is satisfied. If the answer is only a radio approval, 1c says it is not. That distinction is worth writing down while the reasoning is fresh.
What does Article 12 actually require you to log?
Automatic event recording across the life of the system. Article 12(1) states that high-risk AI systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system" 2. The word "technically" is doing real work: this is a design requirement on the product, not a policy the operator can adopt later.
Article 12(2) then sets what the logging must enable, "in order to ensure a level of traceability of the functioning of a high-risk AI system that is appropriate to the intended purpose": identifying situations that may result in the system presenting a risk within the meaning of Article 79(1) or in a substantial modification, facilitating post-market monitoring under Article 72, and monitoring the operation of the system as referred to in Article 26(5) 2.
Read that as an engineering brief rather than a compliance sentence. "Identifying situations that may result in the system presenting a risk" means the log has to capture enough to reconstruct why the machine did what it did, not merely that it did it. For a robot, a log recording that a motion completed is close to useless for that purpose. A record of what was requested, by whom, whether it was permitted, and what version was running is the thing that answers it, which is exactly what action provenance produces.
What does Article 15 require against attack?
Resilience, and it names the attack classes. Article 15(1) requires high-risk systems to achieve "an appropriate level of accuracy, robustness, and cybersecurity" and to "perform consistently in those respects throughout their lifecycle" 3. Article 15(5) is the security clause proper: such systems "shall be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities" 3.
The same paragraph goes further than most product legislation by naming specific AI failure modes. Technical solutions must include, where appropriate, measures to "prevent, detect, respond to, resolve and control for attacks trying to manipulate the training data set (data poisoning), or pre-trained components used in training (model poisoning), inputs designed to cause the AI model to make a mistake (adversarial examples or model evasion), confidentiality attacks or model flaws" 3.
Adversarial examples and model evasion is the statutory description of an attack class we have documented on this site as a physical problem: prompt injection against vision-language-action models, where text placed in the scene changes what the robot does. From 2 August 2028 that is not only a security concern for embedded high-risk systems, it is a conformity requirement.
Article 15(4) is worth noting for anyone shipping systems that keep learning. Systems that "continue to learn after being placed on the market or put into service" must be developed so as to reduce the risk of biased outputs influencing future inputs, and to address such feedback loops with mitigation measures 3.
What do fleet operators owe as deployers?
Obligations of their own, which is the part operators tend to assume sits with the manufacturer. Article 26(5) requires deployers to monitor the operation of the system on the basis of the instructions for use, and where they have reason to consider that use in accordance with those instructions may result in the system presenting a risk within the meaning of Article 79(1), to inform the provider or distributor and the market surveillance authority "without undue delay" and to suspend the use of that system 4.
"Suspend the use of that system" is a capability, not a sentiment. If suspending a robot means a firmware campaign or a physical trip to each unit, you cannot discharge that obligation at the speed the word implies. Revocation that a robot reads on its next command is what makes suspension an action rather than an intention, which is why we treat revocation as an operational control rather than a safety feature.
Article 26(6) adds retention: deployers "shall keep the logs automatically generated by that high-risk AI system to the extent such logs are under their control, for a period appropriate to the intended purpose of the high-risk AI system, of at least six months" 4.
Are logs in the vendor cloud "under your control"?
That qualifier in Article 26(6) is the most quietly consequential phrase in the deployer obligations. The retention duty attaches to logs "to the extent such logs are under their control" 4, which is a sensible limit and also an unintended incentive: an operator with no control over their robot logs has a smaller obligation and a much weaker position.
We have looked at both halves of that problem already. In the piece on robot telemetry, data a robot generates frequently lands in a vendor cloud under a binding the operator neither designed nor monitors. In the piece on decommissioning, that same binding turns out not to travel with the chassis when the robot changes hands. In both cases the question is the same one Article 26(6) raises: whose control is this actually under?
The honest reading is that the article does not require you to take control, and the rest of your exposure quietly does. A six-month retention duty you cannot discharge because the logs are somebody else's is also a six-month evidentiary gap when a market surveillance authority, an insurer, or a claimant under the Product Liability Directive asks what the machine was doing. Control is worth having for reasons that have little to do with this article.
How does this line up with the Machinery Regulation?
Badly, if you plan for them separately, and quite well if you do not. The Machinery Regulation applies from 20 January 2027 and requires that safety-related control systems resist corruption, with evidence retained in the technical file. AI Act obligations for embedded high-risk systems follow on 2 August 2028 5, roughly eighteen months later, on the same robot, assessed by the same organization, drawing on the same engineering.
| Date | Regime | What it wants evidenced |
|---|---|---|
| 2 August 2026 | AI Act Article 50 transparency, already live 5 | Disclosure obligations, unchanged by the Omnibus |
| 20 January 2027 | Machinery Regulation 2023/1230 | Safety functions resist corruption; evidence in the technical file |
| 2 December 2027 | AI Act Annex III standalone high-risk 5 | Separate route; a robot is usually not caught here |
| 2 August 2028 | AI Act Annex I embedded high-risk 15 | Logging (Art 12), robustness and cybersecurity (Art 15), and the rest of Chapter III |
The overlap is not a coincidence of drafting. Article 12 wants automatic logs that let you identify situations where the system presents a risk 2. The Machinery Regulation wants evidence that safety-related software resisted corruption. A record of which attested firmware and policy version was running, what was commanded, whether it was authorized and what happened, satisfies both descriptions without being built twice. Our standards map sets out how the whole set fits together.
The planning consequence is simple and it is the reason this article exists now rather than in 2028. The technical file for January 2027 is being scoped this year. Building it so that it also answers Articles 12 and 15 costs very little at design time and a great deal as a retrofit.
What should you do before the technical file is written?
Settle the classification question in writing, while the reasoning is fresh and cheap. Work through Article 6(1), then 1a, 1b and 1c, and record which third-party conformity assessment you are relying on and why. If you conclude the AI is used solely for non-safety purposes, say explicitly why 1b does not apply, because that is the paragraph an assessor will reach for.
Then check whether the logging you already plan for the Machinery Regulation would satisfy Article 12 as read above, and whether the logs your fleet generates are under your control in the sense Article 26(6) uses. The tool below walks the Article 6 test and produces a dated reading you can put in front of counsel. It is a reading aid, not a conformity assessment, and everything runs in your browser.
AI Act Article 6 Scope Reading
Walks the conjunctive test and the paragraphs the Omnibus added. A reading aid, not a conformity assessment. Nothing you enter leaves your browser.
Implements Article 6(1) and the paragraphs the Digital Omnibus added. It is a reading aid, not a conformity assessment.
Frequently asked questions about the EU AI Act and robots
When do EU AI Act high-risk obligations apply to robots?
For AI embedded in products already covered by EU sectoral legislation, which is where a robot sits under the Machinery Regulation, the obligations apply from 2 August 2028, deferred from 2 August 2027 by the Digital Omnibus 5. Standalone high-risk systems under Annex III moved from 2 August 2026 to 2 December 2027 5. The Article 50 transparency obligations were not deferred and have applied since 2 August 2026 5, so it is wrong to conclude that nothing applies yet.
Are the new AI Act deadlines conditional on harmonised standards?
No. Earlier proposals would have tied the deferral to a triggering mechanism, but the agreement "replaced the Commission's originally proposed conditional mechanism with fixed dates" 5. They are dates, not contingencies. Plan against 2 December 2027 and 2 August 2028 rather than against the possibility of a further slip.
Is a robot automatically high-risk under the AI Act?
No, the test is conjunctive. Under Article 6(1) the AI must be a safety component of, or itself be, a product covered by Annex I harmonisation legislation, and that product must be required to undergo third-party conformity assessment 1. Three paragraphs added by the Omnibus then refine it: 1a excludes AI used solely for non-safety purposes, 1b restores anything whose failure would endanger health and safety, and 1c provides that third-party assessment required solely for radio spectrum or electromagnetic interference does not satisfy the second limb 1.
Does a navigation or perception model count as a safety component?
Usually yes, on the strength of Article 6(1b). Paragraph 1a would exclude AI used solely for non-safety aspects such as performance optimisation or quality control, but 1b provides that AI whose failure or malfunctioning would endanger health and safety qualifies as a safety component notwithstanding that exclusion 1. For a machine with mass and momentum operating near people, a navigation or perception failure endangers health and safety fairly directly. If you conclude otherwise, document why 1b does not apply.
What logging does Article 12 require?
High-risk AI systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system" 2. Article 12(2) requires that logging enable recording of events relevant to identifying situations where the system may present a risk under Article 79(1) or undergo a substantial modification, to facilitating post-market monitoring under Article 72, and to monitoring operation under Article 26(5) 2. In practice that means the log must support reconstructing why the system behaved as it did, not merely that it did.
What are a fleet operator's obligations as a deployer?
Article 26(5) requires deployers to monitor operation per the instructions for use, to inform the provider or distributor and the market surveillance authority without undue delay where use may result in the system presenting a risk under Article 79(1), and to suspend use of the system 4. Article 26(6) requires deployers to keep automatically generated logs, to the extent those logs are under their control, for a period appropriate to the intended purpose and at least six months 4. Suspension at that speed is a capability question, not a policy one.
Does the AI Act require anything the Machinery Regulation does not?
It overlaps substantially and adds AI-specific requirements. Article 15(5) requires resilience against unauthorised third parties altering a system's use, outputs or performance, and names data poisoning, model poisoning, adversarial examples or model evasion, confidentiality attacks and model flaws as classes to address 3. The Machinery Regulation approaches corruption of safety-related software from the safety side. The evidence that satisfies both is largely the same: attested versions, authorization decisions, and a record of what the machine was asked to do and did.
References
- EU Artificial Intelligence Act (Regulation (EU) 2024/1689). Article 6, Classification Rules for High-Risk AI Systems, including paragraphs 1a, 1b and 1c, via the AI Act Explorer. 2024, as amended. artificialintelligenceact.eu/article/6/
- EU Artificial Intelligence Act (Regulation (EU) 2024/1689). Article 12, Record-Keeping, via the AI Act Explorer. 2024. artificialintelligenceact.eu/article/12/
- EU Artificial Intelligence Act (Regulation (EU) 2024/1689). Article 15, Accuracy, Robustness and Cybersecurity, via the AI Act Explorer. 2024. artificialintelligenceact.eu/article/15/
- EU Artificial Intelligence Act (Regulation (EU) 2024/1689). Article 26, Obligations of Deployers of High-Risk AI Systems, via the AI Act Explorer. 2024. artificialintelligenceact.eu/article/26/
- Gibson Dunn. EU AI Act Omnibus Agreement: Postponed High-Risk Deadlines and Other Key Changes. 2026. www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-hig
Keep exploring
Write the technical file once.
Attested versions, authorization decided off-robot, and logs that reconstruct why, not just what.
This article is for general information and does not constitute legal advice. It summarizes provisions of the EU Artificial Intelligence Act as amended, quoted from the AI Act Explorer reproduction of the regulation text; the authentic text is that published in the Official Journal. Classification under Article 6 depends on the specific product, its intended purpose and the conformity route that applies to it, and is a question for qualified counsel and your notified body. Dates reflect the deferrals reported for the Digital Omnibus and should be confirmed against the published instrument before being relied upon.