AI in Machine Safety Functions — What the New EU Machinery Regulation Permits, and What It Doesn't

Illustrative design question: may a vision model replace a perimeter safeguard because it performs well on a person-detection dataset? That evidence alone is insufficient. Define the safety function, operating limits, fault responses and conformity route before changing the protective system. This is a design example, not a reported customer assessment.

This article separates binding machinery law, the revised AI Act relationship, a non-normative technical report and functional-safety design standards. Use the machine-safety standards index to distinguish legal applicability from a standard’s technical scope, and record the edition and legal text used for each safety function.

The four pieces of the framework

A surprising number of conversations about AI in machine safety conflate things that are different documents with different legal force. So before anything else, the map.

• Regulation (EU) 2023/1230. Main application from 20 January 2027, with Article 52 transitional provisions. Annex I Part A points 5 and 6 cover specified self-evolving ML safety components and embedded systems; Article 25(2) requires a notified-body route for those categories.
• ISO/IEC TR 5469:2024. Non-normative technical guidance on AI in functional safety, published January 2024; not a standalone product-conformity standard.
• Regulation (EU) 2024/1689, as amended in July 2026. Machinery now falls under Annex I Section B. Read Article 2(2), Article 6(1) and Article 113 together with Machinery Regulation Article 8; the old blanket 2026 high-risk deadline is not correct.
• ISO 13849-1 and IEC 62061. Functional-safety design and validation methods within their respective scopes. Check exact editions and harmonisation status; neither an algorithm label nor a component certificate establishes whole-machine conformity.

These documents have different roles. Applicable law sets obligations; technical reports provide guidance; standards can support the safety case within their scope. A standard is not automatically mandatory, and an ISO publication is not automatically an EN harmonised reference. Check the exact Official Journal citation and the product’s legal route.

What the new Machinery Regulation actually says about AI

The most-cited fact about Regulation (EU) 2023/1230 is that it mentions AI at all. That is correct but underwhelming on its own. The substance is in Annex III — the essential health and safety requirements — and in Annex I, which lists categories of machinery subject to specific conformity-assessment routes.

Annex III addresses interaction with self-evolving systems, protection against corruption and control-system behavior. Section 1.2.1 requires the risk assessment to establish safety-function limits and prevents changes that could create hazards, including during learning. Not every AI device is network-connected; examine its actual interfaces and update paths.

The phrase that matters most is the one about safety components with “fully or partially self-evolving behaviour using machine learning ensuring safety functions.” That phrase flags such components in Annex I as a category where the standard internal-conformity assessment under Module A is not available, and a notified-body route is required. In other words: you can put machine learning in a safety function, but not quietly — a notified body must be involved.

The Machinery Regulation’s main application date remains 20 January 2027. Article 52 preserves further supply of products already lawfully placed on the market before that date and specified Directive-era certificates until expiry; this is not blanket permission for new production to use the old Directive indefinitely. See the transition and evidence checklist.

ISO/IEC TR 5469: the technical map

The Machinery Regulation tells you that an AI safety function needs notified-body involvement; it does not tell you how to build one. ISO/IEC TR 5469:2024 is the most coherent attempt yet to answer that question. It is worth reading not because you certify against it — you do not — but because it gives you the vocabulary the notified body and your safety case will use.

TR 5469 identifies three distinct patterns of AI involvement in functional safety, and the requirements differ for each:

1. AI inside a safety function. A learned model participates directly in detecting a hazard or commanding a safe state. This is the case the Machinery Regulation flags as higher-risk, and the case TR 5469 spends most of its pages on.
2. Non-AI safety functions used to ensure the safety of AI- controlled equipment. The machine itself has AI in the control path, but the safety stop is implemented entirely by conventional certified devices. This is the architecture most machine builders will live in for years.
3. AI used to design or develop a safety function. A model is used at engineering time — for hazard identification, test generation, or code synthesis — but does not run on the deployed machine. Different problem: the evidence the AI produced has to be checked by humans against the same standards.

The report discusses AI-related risk factors and methods; it is not an approval matrix for deploying a particular learned model. Define the model’s safety contribution, input limitations, foreseeable distribution changes, update control and independent protective measures. Obtain the complete report for its detailed methods instead of using this summary as a conformity test.

Why ISO 13849 and IEC 62061 still bound the conversation

Determine the required safety performance from the machine risk assessment and applicable machine-specific requirements. ISO 13849-1 and IEC 62061 provide different design and verification methods. Hardware failure metrics are only part of the evidence: systematic failures, software, architecture and validation also matter.

Obtain the exact device’s safety data and limitations rather than assuming every light curtain, scanner or relay has the same rating. Assess the sensor–logic–final-element chain. A product certificate alone is not a certificate for the assembled machine function.

A learned model’s accuracy, false-negative rate and deployment assumptions require evidence appropriate to its safety role. A confusion matrix is not a hardware failure-rate model. Where an independent protective channel is used, demonstrate that AI failures and common dependencies cannot disable or weaken it.

For a proposed implementation, list which element makes each safety decision and which evidence supports it. A conventional protective channel can simplify an architecture, but it is not correct to say that a notified body must always demand a light curtain or that hardware certificates alone establish the resulting PL or SIL.

The EU AI Act adds a second layer of obligations

The AI Act consolidated on 27 July 2026 places Regulation 2023/1230 in Annex I Section B, point 21. For the Article 6(1) high-risk systems associated with those products, Article 2(2) limits direct application to the specified provisions. The old summary that every machinery AI system automatically acquires a second complete set of horizontal AI Act obligations is no longer accurate.

Under the amended Machinery Regulation Article 8, the Commission must integrate relevant AI Act requirements into Annex III through delegated acts applying by 2 August 2028. This covers the relevant safety, data, documentation, quality-management, logging and monitoring requirements specified there. Check the adopted sectoral acts and assessment route; this article does not assume that a future delegated act is already applicable.

The general AI Act application date remains 2 August 2026, but that is not the product high-risk deadline. Amended Article 113 sets 2 August 2028 for Article 6(1)/Annex I high-risk rules, while the machinery-specific Section B integration must be read with Article 2(2) and Machinery Regulation Article 8. Machinery’s main 20 January 2027 date remains distinct.

The four frameworks at a glance

Read the table as a scope map, not an instruction to certify against all four documents. Record the applicable law, product classification, technical method and conformity route separately.

What is permitted, in plain language

Permitted today, with care

• AI used to monitor a machine and raise warnings — predictive maintenance on a safety device, drift detection on an OSSD signal, anomaly detection on cycle data — provided the safety function itself remains in the conventional chain.
• AI used at design time for risk identification, test case generation, or assistance with technical documentation, provided the outputs are reviewed and signed off by competent humans against the relevant standards.
• AI used alongside protection must not be able to defeat the required safety function. A muting confirmation that authorizes continued hazardous motion is a safety dependency and requires assessment; calling it an extra vote does not make it advisory.

Permitted, but only via the notified-body route

• The specific self-evolving ML safety categories in Machinery Regulation Annex I Part A require an Article 25(2) route involving a notified body. Confirm classification and assessment scope; no cost or lead time is guaranteed.

Not permitted, in practice

• Do not replace a validated safeguard with vision-AI on the basis of a person-detection demo. Demonstrate the complete protective function and applicable conformity route first; this is not a claim that every possible AI architecture is legally prohibited.
• A self-evolving safety function that continues to learn in the field without bounding. The Regulation explicitly requires that self-evolving behaviour not be allowed to degrade the safety function — in practice that means learning has to be constrained, validated and re-evaluated, not continuous and unsupervised.
• Claiming a Performance Level from a machine-learning component on the basis of statistical validation alone. ISO 13849-1 does not currently support that calculation.

What notified bodies are publishing

A body’s published AI guidance can explain its services, but the legal notification must be checked in the official register for the precise act and product category. Accreditation, notification and commercial expertise are different facts; none can be inferred from a familiar certification-company name.

Before committing to an AI-dependent safety architecture, submit the intended use, system boundary and proposed evidence plan to a body whose relevant scope has been verified. Obtain written confirmation of assessment scope and schedule; no particular assessor capacity or lead time is asserted here.

How DAIDISIKE thinks about this, plainly

DAIDISIKE’s DQT4, DQA and DQSA pages describe distinct protective-device options. Select by exact-model documents and the validated safety function. In the LiDAR range, ST27 is the user-confirmed safety model (Type 3, PL d, SIL 2); DLD, SDLD, DLDS and JPTG are non-safety industrial LiDAR. Ordinary proximity switches likewise are not personnel-protection devices.

AI-assisted diagnostics and engineering tools may be useful when their outputs are checked and cannot undermine protection. Muting is different: if a model’s decision enables bypassing a safeguard, that role belongs inside the safety analysis. Do not present unvalidated AI, or an ordinary industrial sensor, as an approved protective substitute.

What to do in 2026

• Read the AI-relevant clauses of Regulation (EU) 2023/1230, specifically the parts of Annex III on ergonomics, control systems and safety functions, and the safety-component categorisation in Annex I.
• Get ISO/IEC TR 5469:2024 in front of the safety lead, even though you cannot certify against it. The vocabulary will appear in every notified-body conversation.
• Map each AI feature by its actual safety role and check whether it meets the specified Annex I Part A category. AI elsewhere on the machine does not automatically create that category, but dependencies on protection must still be analyzed.
• For planned launches, establish the relevant notification scope and evidence plan early. Keep the machinery and AI legal timelines separate and check sectoral delegated acts before declaring conformity.
• Select documented protective devices appropriate to the required safety function and validate the complete chain. Type 4, PL e and SIL 3 are not universal requirements for all machinery or interchangeable descriptions of a component.

The bottom line

The law recognizes specified self-evolving safety systems and assigns them a conformity route; it does not certify an algorithm. The July 2026 amendments also changed how high-risk AI requirements reach machinery. A useful design file separates this legal classification from the technical evidence for sensing, decision-making and stopping.

Choose a protective architecture that meets the actual risk reduction required, with traceable device evidence and whole-function validation. AI can be advisory or safety-related depending on what it controls. Its legal status cannot be decided solely by calling it “smart,” and neither model accuracy nor a conventional component certificate settles the complete safety case.