EU Machinery Regulation 2023/1230: what changes for AI and sensors

The EU Machinery Regulation 2023/1230 is the first rewrite of European machinery safety law since 2006, and the first that names machine learning explicitly. For anyone who builds machines with cameras, vibration sensors or AI models on board, the question is what actually changes and what stays the same.

This article goes through the parts of the Regulation that touch AI and sensing: the new high-risk categories, the essential requirements on corruption and logging, the special rules for systems that learn, and the 2026 amendments that link it to the AI Act. It is written from an engineering point of view and is not legal advice.

What the EU Machinery Regulation 2023/1230 is

Regulation (EU) 2023/1230 on machinery products replaces Directive 2006/42/EC. According to EUR-Lex, it was adopted on 14 June 2023, published on 29 June 2023 and entered into force on 19 July 2023.

The date that matters for manufacturers is the date of application. The European Commission states that the Regulation applies on a mandatory basis from 20 January 2027. The originally published text named 14 January 2027; a corrigendum corrected the application dates. Some provisions, for example on notified bodies, apply earlier.

Machinery placed on the EU market before 20 January 2027 must comply with the Directive. Because it is a regulation rather than a directive, it applies directly in all Member States without national transposition, which should reduce differences in interpretation.

Beyond AI, the Commission highlights cybersecurity for compliance-relevant software and safety control systems, clearer rules on when instructions and declarations of conformity may be digital, and a revised approach to conformity assessment for machinery with a higher risk factor. The European Parliament's summary of the Regulation notes that digital instructions become the default, with paper available on request.

The new high-risk categories for machine learning

Annex I of the Regulation lists categories of machinery that present a higher risk. Part A of that annex requires third-party conformity assessment by a notified body. It contains six categories, and two of them are new and specifically about machine learning:

• Item 5: Safety components with fully or partially self-evolving behaviour using machine learning approaches ensuring safety functions.
• Item 6: Machinery that has embedded systems with fully or partially self-evolving behaviour using machine learning approaches ensuring safety functions that have not been placed independently on the market, in respect only of those systems.

The wording is narrow on purpose. Recital 55 explains that third-party assessment of safety software should only apply to systems with self-evolving behaviour using machine learning that ensure safety functions, and not to software that is incapable of learning or evolving and is programmed only to execute certain automated functions.

Three conditions must therefore hold before the new categories apply: the system uses machine learning, its behaviour can evolve, and it ensures a safety function.

What that means in practice

The third row is where interpretation matters. A model trained offline and frozen does not evolve after placing on the market, which fits the recital's exclusion. But the Regulation does not define "self-evolving" in detail, and the Commission plans guidance. Until that exists, treat any machine-learning safety function as a case for early discussion with a notified body.

Protection against corruption: essential requirement 1.1.9

Annex III of the Regulation contains the essential health and safety requirements. Section 1.1.9, "Protection against corruption", is new and applies to all machinery, with or without AI. In summary, it requires that:

• connecting another device, directly or remotely, must not lead to a hazardous situation;
• hardware components that transmit signals or data relevant for access to compliance-critical software must be adequately protected against accidental or intentional corruption;
• software and data critical for compliance with the safety requirements must be identified and protected against corruption;
• the machine must identify the safety-relevant software installed on it and provide that information at all times in an easily accessible form;
• the machine must collect evidence of legitimate or illegitimate interventions in that software, its modifications and its configuration.

For sensor systems the consequence is clear. If a sensor or edge device can influence safety-related software or settings, it is part of the attack surface that 1.1.9 asks you to control. A monitoring device on a separate network that only reads data is in a much easier position than one that can write parameters to a safety controller.

The German occupational safety institutes IFA and BAuA describe the standards work behind this in KAN Brief 2/2025: prEN 50742 at CENELEC is intended to support the corruption-protection requirements, compatible with IEC 62443 and related standards, and a Commission guidance document is due by January 2027 at the latest.

Control systems and logs: essential requirement 1.2.1

Section 1.2.1 on the safety and reliability of control systems has been extended in three ways that matter for AI and sensors.

Malicious attempts. Control systems must withstand, where appropriate, reasonably foreseeable malicious attempts from third parties leading to a hazardous situation.

Tracing log. The tracing log of data generated in relation to an intervention, and of the versions of safety software uploaded after the machine is placed on the market, must be enabled for five years after such upload. Its purpose is limited to demonstrating conformity on a reasoned request from a national authority.

Learning systems. For control systems with fully or partially self-evolving behaviour, the Regulation adds that they must not cause the machine to act beyond its defined task and movement space; that data on the safety-related decision-making process must be recorded and kept for one year after collection; and that it must be possible at all times to correct the machine to maintain its inherent safety. Settings or rules generated during a learning phase must not be modifiable where that could lead to hazardous situations.

For engineers, this turns "we log what the model did" from good practice into a requirement wherever a learning system takes safety-related decisions. The log needs integrity, retention and a way to reconstruct which model version made which decision. Our article on time-stamping multimodal sensor data covers why reliable time references matter when you reconstruct events afterwards.

Substantial modification by software

The Regulation defines a substantial modification as a change, by physical or digital means, after the machine has been placed on the market or put into service, that the manufacturer did not foresee or plan and that affects safety by creating a new hazard or increasing an existing risk. The definition adds a further condition: the change must require either additional guards or protective devices that in turn need a modification of the existing safety control system, or additional protective measures for stability or mechanical strength.

A person who carries out a substantial modification is considered a manufacturer under Article 18 and takes on the manufacturer's obligations for that machine, including conformity assessment. Non-professional users modifying their own machine for their own use are excluded.

Because "digital means" are included, software changes can qualify. If you retrofit AI-based monitoring, ask whether it can influence the machine's behaviour, whether the original manufacturer foresaw the change, and whether it creates a hazard that needs new protective measures. A read-only sensor that never writes to the controls is unlikely to be a substantial modification; a system that adjusts process parameters needs a closer look.

Amended in 2026 for AI

The Machinery Regulation was amended before it even applies. Regulation (EU) 2026/1744, the Digital Omnibus on AI of 8 July 2026, in force since 27 July 2026, changed three of its articles:

• Article 8 now requires the Commission to adopt delegated acts amending Annex III by adding health and safety requirements for AI systems that are high-risk under Article 6(1) of the AI Act because they are a safety component of machinery, or are themselves machinery. Those requirements must reflect Chapter III, Section 2, and Articles 17, 19, 72 and 73 of the AI Act, and the delegated acts shall apply by 2 August 2028.
• Article 20(10) adds a presumption of conformity: until harmonised standards or common specifications on high-risk AI are referenced or adopted under the Machinery Regulation, high-risk AI systems that comply with the AI Act's harmonised standards or common specifications are presumed to meet the corresponding essential health and safety requirements in Annex III.
• Article 47 extends the delegation of power to cover these new delegated acts.

The application date of the Machinery Regulation itself, 20 January 2027, was not changed, and neither were the Annex I Part A categories or the essential requirements described above.

How it fits with the AI Act and other rules

Since the Digital Omnibus on AI, the AI Act lists the Machinery Regulation (EU) 2023/1230 in Section B of its Annex I, replacing the reference to the Machinery Directive in Section A. An AI safety component of machinery that needs third-party assessment is still classified as high-risk under Article 6(1) of the AI Act, but for Section B products only Article 6(1), Article 60a and Articles 102 to 112 of the AI Act apply directly. The AI Act's detailed requirements reach such systems through the Machinery Regulation: the delegated acts under Article 8 described above, which must apply by 2 August 2028, the same date from which the AI Act's Article 6(1) high-risk rules apply. In practice, the Machinery Regulation's Annex I Part A items 5 and 6 and the AI Act's high-risk route will capture largely the same systems. Our article on the EU AI Act and industrial quality inspection explains the AI Act side.

Cybersecurity requirements for connected products more broadly will come from the Cyber Resilience Act, which we cover separately in what the Cyber Resilience Act means for connected sensors.

A preparation checklist for machine builders

1. List every AI model and sensor-driven function on the machine, and mark which ones perform a safety function.
2. For each safety function using machine learning, decide whether its behaviour can evolve after placing on the market, and document the reasoning.
3. Identify safety-relevant software and data, and how the machine will report installed versions.
4. Design the tracing log for interventions and safety software versions, with five-year availability.
5. For learning systems, define the task and movement space, the decision data to record and the one-year retention.
6. Map every connection, including monitoring and service access, and assess whether it could corrupt safety-relevant software.
7. Review your update process against the definition of substantial modification.
8. Plan for digital instructions and declarations of conformity.
9. For machine-learning safety functions, follow the Commission's delegated acts under Article 8 on AI requirements, due to apply by 2 August 2028, and the AI Act harmonised standards that Article 20(10) lets you rely on in the meantime.

How NeuroControls approaches this

Our sensing systems are designed as monitoring and inspection tools, not as safety functions. Our models grade and report; they never act on the controller, an interlock or a safety function. Custom models are trained by our engineers on customer data. Keeping models to grading and reporting keeps the system's role clearly advisory, which is the simplest position under the new rules. The machine monitoring page shows typical applications.

The record-keeping principles behind 1.1.9 and 1.2.1 are already part of our recording software: a versioned manifest, per-segment SHA-256 hashes, an append-only journal, and power losses logged, alerted and reported rather than silently filled. Our cognitive sensors report their signal health and dropouts with the data. These are engineering choices, not a claim of compliance for your machine, which remains the machine builder's responsibility.