Exporting embodied AI and robotics to the EU: Machinery Regulation, embedded high-risk AI and the CE route

Stages (30–51 weeks, estimate)

1. 1. Stage 1 — Mapping the product’s applicable legislation and high-risk classification

   3–5 weeks

   Draw the machine’s “regulatory stack”: the Machinery Regulation, the GPSR safety net, any overlapping radio/EMC/low-voltage legislation, and the AI Act embedded high-risk route. The core determination is whether the product contains a self-evolving machine-learning safety component listed in Annex I Part A — if it does, conformity assessment must be performed by a third party, whether or not that component is placed on the market separately. The AI Omnibus clarifications on “safety component” and high-risk classification require the determination to be redone once against the new wording.

   Obligations in this stage

   • Carry out Annex III risk assessment and risk reduction covering foreseeable self-evolving behaviourEU Machinery Regulation · Annex III；Art. 10(1) · Severity Critical
   • High-risk classification assessment and registration of a not-high-risk conclusionEU Artificial Intelligence Act · Art. 6, Art. 49(2), Art. 113 · Severity Critical
   • Re-running the safety-component and high-risk classification under the clarified rulesAI Omnibus (Digital Omnibus on AI) · Art. 1(8) inserting AI Act Art. 6(1a)-(1c); Art. 1(41) amending Annex I · Severity High
   • Complete an internal risk analysis and technical documentation before placing on the market, kept for 10 yearsEU General Product Safety Regulation · Art. 9(1)–(3)；Art. 5；Art. 7–8 · Severity High

   Deliverables

   EU AI Act Annex IV technical documentation for a high-risk AI system

   Evidence to retain

   • · Applicable-legislation matrix (each instrument × applies/does not apply × reasoning)
   • · Safety-function inventory and implementation note (separating fixed logic from learning/self-evolving logic)
   • · Annex I Part A comparison record (whether mandatory third-party conformity assessment is triggered)
   • · High-risk classification memorandum (including the re-check against the AI Omnibus clarifications)

   Common blockers

   • · Treating “our AI only perceives, it does not decide” as an exclusion: if perception output drives stopping or obstacle avoidance, it is part of a safety function.
   • · Ignoring OTA capability: a product that cannot learn at shipment but can gain learning capability through an update must be classified on the state it can reach.
   • · Reading the Machinery Regulation without the AI Act: the two technical-documentation requirements overlap but differ, and discovering this late means reworking both.

2. 2. Stage 2 — Safety risk assessment, standards selection and design freeze

   6–10 weeks

   Complete risk assessment and risk reduction under Machinery Regulation Annex III, explicitly covering the foreseeable evolution of self-evolving behaviour — the piece most often missed by traditional machinery risk assessments. On the robotics side, complete the migration to the 2025 edition of the ISO 10218 series and the integration-level (robot cell) risk assessment; note that the series applies to industrial robots and excludes service, medical, care and consumer robots, and applying the wrong standard is worse than applying none. On the AI side, stand up the lifecycle risk management system and the human-oversight design, fixing the oversight interaction model now — changing hardware later is prohibitively expensive.

   Obligations in this stage

   • Carry out Annex III risk assessment and risk reduction covering foreseeable self-evolving behaviourEU Machinery Regulation · Annex III；Art. 10(1) · Severity Critical
   • Run a clause-level gap analysis and migrate from the 2011 to the 2025 editionsISO 10218 series on industrial robot safety (2025 editions) · ISO 10218-1:2025；ISO 10218-2:2025 · Severity High
   • Perform integration-level risk assessment of robot applications and cells under Part 2ISO 10218 series on industrial robot safety (2025 editions) · ISO 10218-2:2025 · Severity High
   • Check the scope boundary: service, medical, healthcare and consumer robots are out of scopeISO 10218 series on industrial robot safety (2025 editions) · ISO 10218-1:2025 Scope · Severity Medium
   • Lifecycle risk management system for high-risk AI systemsEU Artificial Intelligence Act · Art. 9 · Severity Critical
   • Human oversight design for high-risk systemsEU Artificial Intelligence Act · Art. 14, Art. 26(2) · Severity Critical

   Deliverables

   EU AI Act Annex IV technical documentation for a high-risk AI system

   Evidence to retain

   • · Risk assessment and risk reduction report (with a dedicated section on self-evolving behaviour evolution scenarios)
   • · Clause-level gap analysis against ISO 10218-1/-2:2025 and closure records
   • · Scope-boundary check record (confirming the product is / is not within the industrial-robot scope)
   • · Human-oversight design note (operator competence requirements, takeover latency, failure behaviour)
   • · AI risk management system documentation (closed loop of identify–assess–mitigate–verify)

   Common blockers

   • · Still designing against the 2011 edition of ISO 10218: the 2025 edition changes collaborative-operation and integration-level requirements substantively, and the migration gap analysis must precede design freeze.
   • · Reducing human oversight to “the operator can hit e-stop”: the requirement is that the overseer can understand system output, spot anomalies and intervene effectively; e-stop is one element of that.
   • · Risk assessment covering only the as-shipped state: behavioural drift after a model update must be inside the foreseeable-misuse and foreseeable-evolution analysis.

3. 3. Stage 3 — Technical file, data governance and logging capability

   6–9 weeks

   Produce two technical files from one shared working set: the Machinery Regulation Annex IV technical file (retained for 10 years, with source code or programming logic to be provided to the authority on reasoned request) and the AI Act Annex IV technical documentation. On the data side, implement training, validation and testing data governance, and build automatic logging into the product — logging is not an ops feature bolted on later, it is a regulated product capability and it ties directly to evidence retention under the new Product Liability Directive. On the Cyber Resilience Act side, produce the software bill of materials (SBOM) and the vulnerability-handling process.

   Obligations in this stage

   • Draw up Annex IV technical documentation, keep it 10 years and produce source code or programming logic on requestEU Machinery Regulation · Art. 10(2)–(3)；Annex IV Part A · Severity High
   • High-risk system technical documentation (Annex IV)EU Artificial Intelligence Act · Art. 11, Annex IV · Severity Critical
   • Data governance for training, validation and testing datasetsEU Artificial Intelligence Act · Art. 10, Art. 4a · Severity Critical
   • Automatic event logging capability and log retention for high-risk systemsEU Artificial Intelligence Act · Art. 12, Art. 19, Art. 26(6) · Severity High
   • Accuracy, robustness and cybersecurity of high-risk systemsEU Artificial Intelligence Act · Art. 15, Art. 42(3) · Severity Critical
   • Vulnerability handling process and software bill of materialsEU Cyber Resilience Act · Art. 13, Annex I Part II · Severity High
   • Retaining technical evidence in anticipation of the disclosure regimeEU revised Product Liability Directive (covering software and AI systems) · Art. 9 · Severity Medium

   Deliverables

   EU AI Act Annex IV technical documentation for a high-risk AI systemData Card — datasheet for a training, validation or test datasetModel Card

   Evidence to retain

   • · Machinery Regulation Annex IV technical file (with the 10-year retention arrangement and named custodian)
   • · AI Act Annex IV technical documentation
   • · Training/validation/testing dataset documentation (data cards) and data governance procedures
   • · Logging specification (recorded fields, time base, retention period, export method)
   • · Software bill of materials (SBOM) and vulnerability-handling process document
   • · Accuracy, robustness and cybersecurity test reports

   Common blockers

   • · Reading the source-code duty as “we must publish our source code”: it is provision on a reasoned request from the authority, which calls for a pre-arranged escrow and confidentiality process rather than refusal.
   • · Logging business events but not decision inputs: incident reconstruction and liability defence need the perception inputs and model outputs as they were at the time.
   • · An SBOM covering only in-house code: third-party inference frameworks and drivers are where reportable vulnerabilities actually cluster and must be in the list.

4. 4. Stage 4 — Conformity assessment, notified body and CE marking

   8–16 weeks

   Select and execute the conformity assessment route. If the product contains a self-evolving machine-learning safety component listed in Annex I Part A, third-party assessment is mandatory — which means first finding, in the EU notified-bodies database, a body designated for that legislation and product category with an available slot, then queuing. The quality management system (the Machinery and AI Act requirements can be integrated) must have been running long enough before audit to have generated records. The output is the EU declaration of conformity and the CE marking; note that a digital declaration must still be genuinely accessible. This stage is the long pole, and under-scheduling it is the single most common cause of programme delay.

   Obligations in this stage

   • Mandatory third-party conformity assessment for self-evolving machine-learning safety componentsEU Machinery Regulation · Annex I Part A, items 5–6；Art. 25(1)–(2) · Severity Critical
   • Draw up the EU declaration of conformity and affix the CE marking, including digital availabilityEU Machinery Regulation · Art. 10(2), 10(8), 21, 23, 24；Annex V Part A · Severity High
   • Provide instructions for use and safety information, with digital and paper conditionsEU Machinery Regulation · Art. 10(7)；Annex III · Severity Medium
   • Conformity assessment, EU declaration of conformity and CE markingEU Artificial Intelligence Act · Art. 43, Art. 47, Art. 48, Annex V, Annex VI, Annex VII · Severity Critical
   • Quality management system for providers of high-risk systemsEU Artificial Intelligence Act · Art. 17 · Severity High
   • Transparency towards deployers and instructions for useEU Artificial Intelligence Act · Art. 13 · Severity High
   • Conformity assessment route, technical documentation and CE markingEU Cyber Resilience Act · Art. 32, Art. 28, Art. 31, Annex III, Annex VII, Annex VIII · Severity Critical

   Deliverables

   EU AI Act Annex IV technical documentation for a high-risk AI systemISO/IEC 42001 AI management system implementation and certification readiness checklist

   Evidence to retain

   • · Notified-body selection record (scope of designation checked, slot confirmed, quotation and contract)
   • · Quality management system documentation and operating records covering the window required for audit
   • · Conformity assessment report and certificate
   • · EU declaration of conformity (including the arrangement for accessibility of the digital version)
   • · Instructions for use (how the conditions for digital provision and the paper obligation are met)

   Common blockers

   • · Engaging a notified body whose designation does not cover that product category under that legislation: discovering this after the certificate issues means starting over.
   • · A quality management system “built for the audit”: auditors look at operating records, and a system whose documents were issued days before the audit invites immediate challenge.
   • · Shipping digital-only instructions: the regulation attaches conditions to digital provision and still requires paper in defined circumstances.

5. 5. Stage 5 — EU responsible operator, registration and channel chain

   3–5 weeks

   Put “who answers for this machine in the EU” on paper: the responsible economic operator and authorised representative under the Machinery Regulation, the Article 16 “responsible person” under the GPSR, the authorised representative and EU database registration under the AI Act, and the liable-operator chain plus internal recourse arrangements under the Product Liability Directive. These roles rest on different legal bases; one company may hold several but each needs its own mandate. On the channel side, write importer and distributor duties into the distribution agreement, or their omissions come back to the manufacturer.

   Obligations in this stage

   • Put in place an EU-established responsible economic operator and an authorised representativeEU Machinery Regulation · Art. 10(6), 12, 13；Regulation (EU) 2019/1020 Art. 4(3) · Severity High
   • Appoint an EU-established responsible person and run the periodic checksEU General Product Safety Regulation · Art. 16(1)–(3)；Regulation (EU) 2019/1020 Art. 4(3) · Severity Critical
   • Establish internal product safety processes and complete product identification and informationEU General Product Safety Regulation · Art. 14；Art. 9(5)–(7)；Art. 13 · Severity Medium
   • EU authorised representative for third-country providers of high-risk systemsEU Artificial Intelligence Act · Art. 22 · Severity Critical
   • Registration of high-risk systems in the EU databaseEU Artificial Intelligence Act · Art. 49, Art. 71, Annex VIII · Severity High
   • Mapping the EU liability chain and agreeing recourse arrangementsEU revised Product Liability Directive (covering software and AI systems) · Art. 8 · Severity High
   • EU authorised representative and importer or distributor channel managementEU Cyber Resilience Act · Art. 18, Art. 19, Art. 20, Art. 28, Art. 31 · Severity High

   Evidence to retain

   • · Written mandates for each role (separate authorisations under the Machinery Regulation, GPSR, AI Act and CRA)
   • · EU database registration receipt and a backup of the registered content
   • · Product identification and information scheme (type, batch, manufacturer and responsible-person contact details)
   • · Compliance obligation clauses in distribution agreements and the annual verification arrangement
   • · Liability-chain diagram and internal recourse arrangements

   Common blockers

   • · One mandate covering all legislation: each instrument defines the representative’s remit differently, and a generic mandate is found incomplete on inspection.
   • · Handing the authorised-representative role to a logistics provider: the representative must hold the technical file and communicate with authorities, which a pure logistics vendor cannot do.
   • · Registration entries inconsistent with the technical file: database entries are used for market-surveillance comparison and version drift triggers questions immediately.

6. 6. Stage 6 — Post-market monitoring, OTA updates and substantial-modification governance

   4–6 weeks

   Stand up three things and move to steady state: the post-market monitoring system and plan; the outbound reporting channels for accidents and serious incidents (Machinery, AI Act, GPSR and CRA each have different recipients and deadlines — GPSR runs through the Safety Business Gateway, and the CRA sets 24-hour / 72-hour / 14-day stages for actively exploited vulnerabilities); and the internal rule for identifying a “substantial modification”. For embodied AI the realistic risk is that a single OTA model update legally turns you back into the manufacturer and requires conformity assessment to be redone. That rule must live inside the release process with joint engineering and compliance sign-off.

   Obligations in this stage

   • Identify substantial modifications and take on manufacturer obligations, including for OTA and model updatesEU Machinery Regulation · Art. 18；Art. 25(2)–(4) · Severity High
   • Post-market monitoring system and plan for high-risk systemsEU Artificial Intelligence Act · Art. 72 · Severity High
   • Serious incident reporting (15-day, 10-day and 2-day deadlines)EU Artificial Intelligence Act · Art. 73 · Severity Critical
   • Notify product accidents through the Safety Business Gateway without undue delayEU General Product Safety Regulation · Art. 20(1)–(4)；Art. 27 · Severity High
   • Corrective action, recall notice and minimum remedies for dangerous productsEU General Product Safety Regulation · Art. 9(8)；Art. 35；Art. 36；Art. 37 · Severity Critical
   • Safety lifecycle management for continuous learning and software updatesEU revised Product Liability Directive (covering software and AI systems) · Art. 7(2)(c), Art. 11(2) · Severity High
   • Reporting actively exploited vulnerabilities at 24 hours, 72 hours and 14 daysEU Cyber Resilience Act · Art. 14(1)-(2), Art. 16 · Severity Critical

   Deliverables

   AI incident and serious incident reporting record (register plus report drafts)

   Evidence to retain

   • · Post-market monitoring plan and data-collection list
   • · Incident register (recipients and deadlines listed per instrument) plus one rehearsal record
   • · Substantial-modification decision rule and release checklist with joint engineering/compliance sign-off
   • · Recall and corrective-action playbook (minimum remedies and consumer notification templates)
   • · Vulnerability reporting records and the published support-period statement

   Common blockers

   • · Treating OTA as a pure engineering action: an update that changes safety-relevant behaviour can constitute a substantial modification, with the legal consequence of re-assuming manufacturer duties.
   • · Applying the domestic habit of “investigate internally first, report later”: most EU channels start the clock at awareness, and finishing the investigation first usually means missing the deadline.
   • · No published support period: the CRA requires the support period to be determined, published and recorded in the technical documentation, and it cannot be back-filled.