Machinery Regulation vs EU AI Act Where machinery safety and AI compliance overlap

Start with the product: machinery, related product, partly completed machinery, safety component, or embedded system. Software can be part of the machinery analysis when it is a safety component or needed to verify EHSR compliance.

Start a separate AI Act screen only where the machinery facts include an AI system, especially a machine-learning system used to ensure a safety function.

Use one intake record with two conclusions: the machinery classification and the AI-system classification. Shared facts are fine; merged legal conclusions are not.

Annex I Part A machinery categories include safety components and embedded systems with fully or partially self-evolving behaviour using machine-learning approaches to ensure safety functions.

The machinery standardisation request describes these machinery products as the AI Act overlap: high-risk AI systems in machinery products where systems ensure safety functions with fully or partially self-evolving machine-learning behaviour.

Escalate these products early for conformity-route, notified-body, standards and AI Act scoping review. Do not wait until the AI feature is treated as a generic software update.

The machinery file must show applicable EHSRs, risk analysis, design and operation evidence, conformity assessment, technical documentation, instructions and declarations. Where relevant, source code or programming logic may be needed for authorities to check EHSR compliance.

AI Act work may reuse machinery evidence only if the same system boundary, model version, safety function, control and requirement are identified.

Create a cross-reference table rather than copying the whole technical file into the AI Act file. Each row should identify the document, product version, safety function, law supported and open gap.

Machinery sources identify cyber-safety provisions for safety control systems and compliance-related software and data, plus protection against corruption and reasonably foreseeable malicious attacks where they affect safety.

The AI Act side should not be used as the sole cyber-safety record. Cyber and software evidence must still show how machinery safety requirements are met.

Keep software architecture, update controls, logging, data-recording design, malicious-attack assumptions and validation tests in the machinery evidence set, then reference them from AI Act work only where they answer an AI-specific question.

Machinery conformity planning depends heavily on harmonised standards and the gap analysis against Regulation (EU) 2023/1230 EHSRs.

The machinery standardisation request context says standards for machinery products should take account of AI Act standardisation work where relevant, so overlap can be handled coherently rather than duplicated.

When relying on a standard, document whether it supports Machinery Regulation EHSRs, AI Act work, both, or neither. A standard citation should not silently stand in for a missing legal assessment.

A complete machinery file can show product-safety conformity, but it is scoped to the Machinery Regulation and its EHSRs.

A complete AI Act file may still be needed for the AI system, provider or deployer context, and post-market AI controls; those details are outside what the machinery grounding supports here.

Use this page as an overlap map. For detailed AI Act obligations, use AI Act grounding and a separate AI Act assessment.

Under the Machinery Regulation, enforcement starts with whether the product falls in scope and whether the technical file shows compliance with the relevant EHSRs and conformity route.

Under the AI Act, the separate question is whether the machinery contains an AI system that triggers AI-specific obligations beyond the machinery file.

Keep the enforcement questions in two lanes: product scope and EHSR compliance on one side, AI-system scoping and obligations on the other.

The machinery file should be the master record for product scope, EHSR mapping, test evidence, instructions, declarations, and any source-code or programming-logic access needed for compliance checks.

The AI Act file can reuse those records only after they are re-labelled for the AI system boundary, model version, and provider or deployer role.

Reuse the evidence, not the conclusion. If a record does not clearly show which regime it supports, add that label before moving it across files.

If the product can be classified and assessed under the Machinery Regulation without any AI function analysis, stay in the machinery file first and document the EHSR route.

If the machinery contains a machine-learning safety function or other AI system, open a separate AI Act screen so the AI-specific obligations are not lost inside the product file.

Use a two-step triage: decide the machinery route first, then decide whether the AI Act also needs its own file and owner.