Compliance2026-11-0412 min readBy Abhishek Nair · Technology consultant for early-stage startups

New EU Robot Safety Rules Start on 20 January 2027: A Plain-English Guide for Robotics Startups

#EU Machinery Regulation#Robotics#CE Marking#EU AI Act#Robot Safety#Startups
Loading...

New EU Robot Safety Rules Start on 20 January 2027: A Plain-English Guide for Robotics Startups

What changes, where startups go wrong, and what to do now.

Reading time: 12 minutes | Difficulty: Beginner


If you sell robots in the EU, they need a CE mark. Since 2009 the rules behind that mark for machines, including robots, have come from the Machinery Directive. On 20 January 2027 that directive is replaced by the new Machinery Regulation, Regulation (EU) 2023/1230.

The new regulation adds rules for robots that use AI, get software updates, or move around on their own. In July 2026 the EU also decided that, for robots, the AI Act's high-risk AI rules will be added to this regulation by August 2028 instead of applying separately.

Below is what that means for a startup, with examples. The official texts are listed at the end, with the article for each rule.


Five terms you need

  • CE mark: the marking that says your product meets EU safety law. Without it you can't sell the robot in the EU.
  • Declaration of Conformity: the signed document where you, the manufacturer, state which EU laws your robot meets.
  • Technical file: your evidence. Risk assessment, design documents, test results.
  • Safety function: anything on the robot whose job is to stop it from hurting someone. Slowing down when a person comes close, stopping when a door opens, limiting force.
  • Notified body: an independent testing organisation approved by an EU country. For most robots you check compliance yourself. For machines on the regulation's high-risk list, one of these organisations has to be involved.

1. The date counts per robot, not per product

The new rules apply to every robot you first sell or hand over to a customer in the EU from 20 January 2027 onward. It doesn't matter when you designed the model or when you built the unit. EU product law counts each individual unit separately.

Example. A startup building inspection robots for factories finishes five units in December 2026 for a customer pilot that starts in February 2027. Those five robots are handed over after 20 January, so they must meet the new regulation, even though the design was finished a year earlier.

Units you already supplied under the old directive before that date can still be resold. Existing EC type-examination certificates stay valid until they expire.

Watch out for: paperwork that still names the old directive. Any robot you ship after the cutoff needs a Declaration of Conformity under Regulation (EU) 2023/1230.


2. The big question: does machine learning keep people safe on your robot?

The regulation has a high-risk list of machines (Annex I, Part A). If your machine is on it, you can't sign off on your own. A notified body has to be involved, even if you followed every standard.

Two entries on that list are new. They cover machine learning with "self-evolving behaviour" that provides a safety function, either as a separate safety component or as a system built into the machine. In the second case, the notified body assesses only that built-in system, not the whole robot.

AI on your robot is not a problem in itself. The question is whether it does a safety job.

Example: a warehouse robot, built two ways.

Design ADesign B
How it avoids hitting peopleA neural network watches the camera feed and tells the robot to slow down when it sees a personA safety laser scanner, built to a recognised safety standard, slows and stops the robot when anything enters its zone. The neural network only plans routes.
What keeps people safeThe neural networkThe safety scanner
Likely outcomeProbably on the high-risk list, so a notified body checks the networkProbably not on the high-risk list

Both robots use AI. Only Design A uses it for safety.

More examples:

  • A robot arm that uses a vision model to decide what to pick, while a separate safety controller limits its speed and force. The vision model is not the safety function.
  • A lawn robot that relies only on a trained model to recognise people and stop. The model is very likely the safety function.

Watch out for: the regulation does not define "self-evolving behaviour". It is unclear whether a model you train once and then freeze counts, or only one that keeps learning after delivery. At least one notified body reads it broadly, as software that uses machine learning to generalise from data. Until there is official guidance, treat any trained model that keeps people safe as covered.

What to do: keep the safety job in parts the AI cannot override:

  • a safety scanner or light curtain that triggers the stop by itself
  • a safety controller, a small dedicated computer built for safety logic, that enforces speed and force limits
  • an emergency stop that does not go through your AI software

The AI still does the useful work, inside limits it cannot change. The regulation already says that the robot, and its operators, must not be able to change the safety limits, including while the robot is learning, if the change could create a hazard.

If you are not on the high-risk list: for most machines you check compliance yourself. The regulation also has a second list (Annex I, Part B). Machines on that list can only check themselves if they follow official standards that cover every relevant requirement. Check both lists for your product.

If your product really needs machine learning for safety, for example a humanoid working close to people in an open space, plan for a notified body now. At least one notified body expects demand to rise and warns that availability may suffer, so contact one early. Assessors are likely to ask how you test a model against situations nobody planned for. When I trained a simulated humanoid to walk, it found ways to "succeed" that I never intended. You will need to show how you rule out that kind of behaviour.


3. Software is now part of safety, on every robot

These rules apply to every robot, with or without AI. They are safety requirements, so they belong in your risk assessment and technical file.

The robot must be able to show which software it needs to run safely, at any time. Example: a service technician or inspector can see the current safety software version in the robot's settings screen.

The robot must record when someone changes that software or its settings, whether the change was allowed or not. Example: someone changes the speed limit from your cloud dashboard. The robot records that the change happened.

The robot must withstand reasonably foreseeable attacks that could make it dangerous. Example: if your cloud dashboard can raise a speed limit, an attacker who gets into it could too. That belongs in your risk assessment as a safety risk.

The robot must keep a log of safety software updates and related changes for five years after each update. It is only for showing that the robot complies, and national authorities can ask for it with a reasoned request. Example: you push monthly updates to 40 robots. Each robot should be able to show which safety software versions it received and when.

Extra rules apply if your robot has learning ("self-evolving") behaviour and works with varying levels of autonomy.

  • It must not act outside its defined task and movement space.
  • Data on its safety-related decisions must be recorded and kept for one year, again only for authorities who ask.
  • It must always be possible to correct it so it stays safe.

A robot that drives itself but runs fixed, non-learning software is not caught by these three.


4. A big unplanned change after delivery can make someone else the manufacturer

The law calls a big unplanned change after delivery a substantial modification. A change counts only when all three of these are true:

  1. The manufacturer did not foresee or plan it.
  2. It creates a new hazard or makes an existing risk bigger.
  3. Making it safe again needs new guards or safety devices that force a change to the robot's safety controls, or extra measures to keep the machine stable or strong enough.

Software changes can count as well as hardware changes. Whoever makes a substantial modification is treated as the manufacturer of that robot, with all the duties and paperwork that come with it.

Example. A customer wants your mobile robot to drive faster in their warehouse. At the higher speed your safety scanner can't stop it in time, so their engineers add a second scanner and rewire the safety controller. You never planned for that. The customer may now count as the manufacturer of those robots.

What to do:

  • Write down in your risk assessment the kinds of changes you plan: which models you will retrain, which skills you may add, which settings customers may adjust, and which safety limits never change.
  • Plan your own updates the same way, so an update never takes the robot outside what you assessed.
  • Tell customers in writing what they must not change.

5. Robots that move around on their own

Supervision. Where relevant, a self-driving machine needs a supervisory function. It sends information to a person and lets that person stop it, restart it, or move it to a safe spot from a distance. Those controls may only work when the person can see the machine's movement and working area, directly or through cameras or sensors. If the supervisory function is not active, the machine must not operate.

Example: a mobile robot patrolling a large factory site at night needs a way for someone to see what it is doing and stop it remotely. "It runs overnight with no way for anyone to stop it" is unlikely to pass.

Communication. Where relevant, a robot with learning behaviour that works with varying autonomy should respond to people appropriately and tell its operators what it is about to do and why, in a way they can understand.

Example: a learning robot arm sharing a workbench with a worker shows on a screen, or with lights, which part it will reach for next.


6. Where the AI Act fits now

Until July 2026, AI acting as a safety component in machinery was headed for the EU AI Act's high-risk rules directly. The Digital Omnibus on AI, Regulation (EU) 2026/1744, changed that. It moved machinery out of the AI Act's main high-risk regime, so only a few AI Act provisions still apply directly to those systems. Instead, the Commission must add AI requirements to the Machinery Regulation itself, and they must apply by 2 August 2028.

These requirements cover AI that counts as high-risk under the AI Act. For robots that means AI used as a safety component in a machine that needs a notified body.

What this means for you:

  • If AI is not a safety function on your robot, these 2028 requirements should not reach it.
  • If AI is a safety function and your robot needs a notified body, expect the requirements from 2 August 2028. The Commission still has to write them. The Omnibus says they should reflect the AI Act's high-risk rules: risk management, training data, documentation, logging, information for users, human oversight, accuracy, robustness and cybersecurity, a quality management system, monitoring after sale, and reporting serious incidents. Start keeping those records while you build.

Watch out for: articles and slides written before July 2026 that say AI in robots falls directly under the AI Act's high-risk rules from August 2027. For machinery, that changed.


7. Don't wait for the official standards

Following an official ("harmonised") standard, one listed in the EU's Official Journal, is the easiest way to show you meet the law. Under the new regulation, that list has not been published yet. The European Commission says it is preparing it, that it will include the vast majority of standards used under the old directive, and that it expects the first list before the end of 2026. It also says some standards will be clarified where they don't yet fully cover the new requirements.

What to do: don't wait. For each new requirement in this guide, write down in your technical file how your robot meets it. Check yourself whether the standards you use cover the software and attack rules in section 3. Once the AI requirements exist, high-risk AI systems that follow the AI Act's official standards will be presumed to comply until machinery-specific ones are published.


Checklist

Do now:

  1. List every robot you will hand over on or after 20 January 2027, including pilot units and replacements.
  2. For each product, write down every safety function and what provides it. If it is a trained model, decide: change the design, or contact a notified body.
  3. Check whether your product is on either list in Annex I.
  4. Update your risk assessment for attacks, software updates, customer changes and how the robot behaves around people.
  5. Make sure each robot logs which safety software versions it received and any changes to them, for five years after each update.
  6. Issue a new Declaration of Conformity under Regulation (EU) 2023/1230 and update the technical file against the new requirements.
  7. If you supply manuals digitally, make them downloadable and printable, and keep them online for the robot's expected lifetime and at least 10 years after you supply it. Send a free paper copy within a month if a customer asks when buying. If you sell to consumers, essential safety information must also be on paper.

Watch out for:

  • A trained model being the only thing that stops your robot from hurting someone.
  • Updates that take the robot outside what your risk assessment covered.
  • Customers changing safety-relevant software, settings or hardware without you knowing.
  • Cloud dashboards or remote access that can change safety settings.
  • Advice based on the AI Act as it stood before July 2026.

Conclusion

The decision that matters most is made early: keep machine learning out of your safety functions where you can, and let it work inside limits enforced by safety-rated hardware and a safety controller. That keeps most robots off the high-risk list and outside the 2028 AI requirements.

The rest is software housekeeping: know what software is on each robot, log what changes, protect it against attacks, and write down which updates and customer changes you allow.

I led the engineering and CE compliance of care robots at Bearcover (ISO 13482) and deployed autonomous sweepers for customers at Enway. If you're not sure where your safety functions sit or which route applies to your robot, mapping that path into the design is part of my AI and robotics system design work.


How this was written: I wrote this article with the help of AI. I chose the topic, reviewed the text and compared the legal points with the official sources listed below. It is general information, not legal advice. If you spot a mistake, please tell me and I will correct it.


Sources

Abhishek Nair · Technology consultant for early-stage startups
Abhishek Nair · Technology consultant for early-stage startups
Robotics & AI Engineer
About & contact
Why trust this guide?