EU Machinery Regulation 2023/1230: AI Compliance Before January 2027

On 20 January 2027, parts of your AI agent code become regulated industrial products under Regulation (EU) 2023/1230. Most teams building agents have heard of the EU AI Act. Far fewer have read the Machinery Regulation that replaces the 2006 Machinery Directive. It quietly redefines a slice of agent software as a safety component, and routes that slice through a stricter conformity-assessment regime than the AI Act alone requires.

If your software decides when a robot moves, when a manufacturing line stops, when a drone descends, or when a person is too close to an active piece of equipment, this regulation almost certainly applies to you. The product brochure can say "AI agent" rather than "safety component." The regulator looks at function, not branding.

Companion pieces: EU AI Act Article 14: Human Oversight in Agent Code · Article 15: Robustness for AI Agents · EU AI Act Compliance Checklist for AI Agent Developers.

What the Machinery Regulation actually says

Regulation (EU) 2023/1230 was published in the Official Journal on 29 June 2023 and applies from 20 January 2027. It replaces Directive 2006/42/EC and updates the regime that gives industrial machinery its CE mark.

Three things changed that matter for anyone writing AI.

First, the essential health and safety requirements moved from Annex I of the old Directive to Annex III of the new Regulation. Annex III is now the foundation document every machine in scope must meet.

Second, AI safety components are a named high-risk category. Annex I, Part A lists categories that must go through third-party (Notified Body) conformity assessment. Item 5 is "Safety components with fully or partially self-evolving behaviour using machine learning approaches ensuring safety functions." Item 6 is the machinery that embeds such components.

Third, cybersecurity is in scope. Annex III §1.1.9 ("protection against corruption") and §1.2.1 ("safety and reliability of control systems") now require that control logic withstand "reasonably foreseeable malicious attempts." That phrase explicitly contemplates adversarial input.

The interesting consequence: a software component that historically lived in a model registry or a Git repo is, on 20 January 2027, a regulated industrial product.

Who actually falls under this

The regulation says machinery. Most AI teams hear that word and assume it does not apply to them. The scope is broader than the word suggests. The following describe systems that are in scope:

• Autonomous mobile robots and AGVs/AMRs in warehouses, logistics, last-mile.
• Robot arms and cobots with adaptive control or learned grasping.
• Drones and ground robots with autonomous navigation or obstacle avoidance.
• Vision systems that decide whether a person is in a hazardous zone (lockout/tagout, fenceless robots).
• Predictive-maintenance agents that autonomously trip a shutdown.
• Fleet orchestration agents for AGVs, conveyors, or process equipment.
• AI components that gate a safety function. Anomaly detectors that suppress an alarm. Classifiers that override an interlock. RL policies that tune a torque limit.

You are not in scope if your agent only writes emails, summarises documents, or generates code. You are in scope if a wrong decision from your model can hurt someone or break something.

Recital 55 narrows the new Notified Body track further. It applies to systems "fully or partially self-evolving … using machine learning approaches." Pure rule-based software stays in the 2006 regime. Pre-trained models count. A model frozen before deployment is still "self-evolving" under the regulation's capability-based reading, because the model was trained on data and could be retrained tomorrow.

The four code-level requirements

Annex III is long. For AI agents in safety-relevant positions, four obligations dominate.

1. Declared capability and bounded autonomy

Annex III §1.1.6 (operator/machinery interface) and the new requirements in §1.2.1 (control systems) require the system's intended behaviour, its limits, and its level of autonomy to be declared. They cannot be implicit in the model weights.

Failing pattern. Autonomy declared by the LLM at runtime:

# control_agent.py: the agent decides what it is allowed to do
system_prompt = """
You are a warehouse robot controller. Decide whether to move,
slow down, or stop. Use the available tools.
"""

tools = [move, slow, stop, set_speed, override_interlock]
agent = AgentExecutor(agent=react, tools=tools, max_iterations=None)

Nothing in this code says which tools are safety-critical, which require human acknowledgement, or what the maximum permitted speed is. A Notified Body cannot certify what is not declared.

Passing pattern. Declared scope, separated from the prompt:

# agent_capabilities.yaml: read by humans and by Inkog
agent: warehouse_amr_controller
purpose: "Adjust route and speed of a Class A AMR within bounded envelopes."
intended_evolution: "Online learning disabled in production. Model is frozen."
tools:
  - name: set_speed
    effect: SAFETY_CRITICAL
    bounds: { min_mps: 0.0, max_mps: 1.4 }     # plant-floor limit
  - name: move
    effect: SAFETY_RELEVANT
    requires: ["interlock_clear", "no_person_in_zone"]
  - name: override_interlock
    effect: PROHIBITED                         # never permitted to the agent

The capability manifest is the artefact the Notified Body reads. The runtime then has to honour it. Inkog's existing missing_oversight and excessive_permissions rules flag agent code that does not separate declared scope from runtime behaviour.

2. Safe stop, interlock, and intervention

Annex III §1.2.1 requires control systems to "prevent hazardous situations" and to withstand "intended and unintended external influences, including reasonably foreseeable malicious attempts." For an agent, that maps to three concrete things. A bounded execution loop. An external kill switch that cannot be reasoned away. A clean separation between the LLM's reasoning and the actuator command.

Failing pattern. Actuator commanded directly by LLM output:

def control_step(observation):
    decision = llm.invoke(f"Given: {observation}. Output JSON: action, speed.")
    action = json.loads(decision.content)
    motor.command(action["action"], speed=action["speed"])

The motor takes any string the LLM produces. An adversarial observation (a sticker on a forklift, a poisoned camera frame) is one prompt-injection step away from speed=99.

Passing pattern. Validated intent, hard-bounded actuation:

class ControlIntent(BaseModel):
    action: Literal["hold", "creep", "move", "stop"]
    target_speed_mps: float

    @validator("target_speed_mps")
    def within_envelope(cls, v):
        if not 0.0 <= v <= 1.4:
            raise ValueError("speed outside certified envelope")
        return v

def control_step(observation):
    intent = ControlIntent.model_validate_json(llm.invoke(...).content)
    if interlock_clear() and no_person_in_zone():
        motor.command(intent.action, speed=intent.target_speed_mps)
    else:
        motor.command("stop")

The LLM proposes an intent. The application checks the envelope, the interlock, and the safety condition. The motor obeys only the validated command. An emergency stop is not negotiable. It is wired outside the agent's reach.

Inkog's output_validation and infinite_loop rules flag the failing shape. The same rule that catches an unguarded db.execute(suggested_sql) catches an unguarded motor.command(speed=...). Static analysis does not care which kind of side effect lives on the other side of the call.

3. Cybersecurity of safety functions

Annex III §1.1.9 ("protection against corruption") and §1.2.1 are the cybersecurity teeth of the regulation. For AI components the practical translation is: a tampered prompt, a poisoned model file, or a hostile MCP server cannot be allowed to cause a hazardous output.

Failing pattern. System prompt rebuilt from external sources every step:

context = read_remote_config("s3://configs/runtime.md")
system = f"{base_prompt}\n\nPLANT POLICY:\n{context}"
agent.run(system=system, observation=obs)

The system prompt is now mutable by anyone with write access to that bucket. The AGENTS.md supply chain attack post walks through what happens when the upstream is hostile. The mechanism is identical for an industrial agent.

Passing pattern. Signed, pinned, and validated context:

context = fetch_and_verify(
    uri="s3://configs/runtime.md",
    expected_sha256=PINNED_DIGEST,
    signed_by=PLANT_SIGNING_KEY,
)
system = SYSTEM_TEMPLATE.format(plant_policy=strip_instructions(context))

Three protections at once. Integrity via the digest. Authenticity via the signature. Intent isolation, because the policy text is treated as data, not as instructions injected into the model.

Inkog's supply_chain and system_prompt_leak rules trace data flow from network sources to LLM system prompts and flag every unverified path.

4. Documented intended evolution

Recital 32 requires the manufacturer's risk assessment to account for "future updates or developments of software" and the "intended evolution of [the system's] behaviour." A Notified Body will ask, at certification time, for two artefacts. A description of the learning regime. A record of what changed and when.

Failing pattern. No record of what is in production:

# deploy.sh
aws s3 cp ./model.bin s3://prod-models/model.bin
kubectl rollout restart deployment/controller

There is no signed manifest, no version, no record of the training data, no record of the eval that was passed.

Passing pattern. Model card and signed registry entry:

register_model(
    name="amr_controller",
    version="2026.05.12",
    digest=hashlib.sha256(model_bytes).hexdigest(),
    training_data_manifest="s3://datasets/amr-v3/MANIFEST.signed.json",
    evaluation_report="reports/amr_2026_05_12.pdf",
    signed_by=PLANT_SIGNING_KEY,
    intended_evolution="Frozen post-deployment. Re-training requires re-certification.",
)

The model is now an auditable artefact. A change to the file changes the digest, which changes the registry entry, which is the trigger for a re-assessment under Annex III. Inkog's supply_chain rule catches the broader pattern: artefacts pulled into a production agent without a verifiable signature or pinned digest.

The Notified Body track

For most categories of machinery the manufacturer can self-assess and apply CE marking. For AI safety components that path is closed. Annex I, Part A items 5 and 6 force the manufacturer through one of three procedures with Notified Body involvement. EU Type-Examination (Module B). Full Quality Assurance (Module H). Conformity Based on Unit Verification (Module G).

This matters in three ways.

You need a Notified Body engagement before you ship. TÜV SÜD became the first Notified Body designated under the new Regulation in September 2024, and the list is growing, but capacity is finite. Treat it like a long-lead-time dependency, not a paperwork formality.

The technical file is a real artefact, not a binder you assemble the week before audit. Capability manifests, model cards, eval reports, evidence of input validation, evidence of safe-stop logic, and a record of the development lifecycle all go in. The same artefacts a developer produces while coding feed directly into it.

Re-certification is triggered by behavioural change. A model swap, a tool added, a prompt rewrite, anything that changes the system's intended evolution can re-open conformity assessment. This is the strongest argument for static analysis in CI. Every PR is a chance to catch a re-certification trigger before it ships.

The overlap with the EU AI Act

The two regulations are deliberately stitched together. Annex I of the EU AI Act lists the Machinery Regulation as Union harmonisation legislation. The consequence, under Article 6 of the AI Act, is that an AI system which is a safety component under the Machinery Regulation is automatically a high-risk AI system under the AI Act. It inherits all of Title III. Risk management (Art. 9), data governance (Art. 10), technical documentation (Art. 11), record-keeping (Art. 12), transparency (Art. 13), human oversight (Art. 14), accuracy and robustness and cybersecurity (Art. 15).

Practical reading: if you are in scope of Regulation (EU) 2023/1230, you are also in scope of the AI Act for that component. Plan for both. The good news is that the controls overlap heavily. Declared capabilities, bounded autonomy, audit trails, and input/output validation satisfy both regimes.

Penalties

Article 50 leaves the level of penalties to Member States, with the standard EU formula: "effective, proportionate and dissuasive," with the option of criminal sanctions for serious infringements. Article 50(1) has been applicable since 14 October 2023. The legal framework for sanctions is already in force, even though the substantive obligations bite on 20 January 2027.

National implementations vary. Germany's draft transposition (BAuA) signals fines in the same order as Machinery Directive enforcement under the Produktsicherheitsgesetz, with parallel exposure under product-liability and OSH legislation.

For AI safety components there is a second penalty stack. The EU AI Act caps fines at €35M or 7% of global annual turnover for prohibited practices, and at €15M or 3% for breaches of high-risk obligations.

What an audit asks for

When a Notified Body or a Market Surveillance Authority opens a file on an AI safety component, the typical request set is:

1. The capability declaration. What the system can do, where its envelope sits, what is prohibited.
2. The technical file. Model card, training data manifest, evaluation report, risk assessment, intended evolution statement.
3. The integration evidence. Proof of bounded autonomy, safe-stop, interlock independence, input validation, output validation.
4. The cybersecurity case. Protection of the system prompt, the model file, the tool registry, and the actuation path against tampering.
5. The change record. Every model swap, prompt change, or tool addition, with the assessment that accompanied it.

Items 1 and 2 are organisational. Items 3, 4, and 5 live in the codebase. Inkog scans that part automatically:

npx -y @inkog-io/cli scan . --policy governance --output sarif

What Inkog produces is a SARIF file with eight categories of finding that correspond directly to items 3 and 4. Each finding already carries the EU AI Act article and OWASP LLM Top 10 category it maps to. For a Machinery Regulation technical file, you (or your auditor) map the same finding onto the matching Annex III subsection. The control evidence is the same. SARIF output is consumable by GitHub Security, GitLab, and most enterprise audit tooling.

What Inkog covers, honestly

Compliance is not a tool purchase. It is risk assessment, technical file, quality management system, Notified Body assessment, declaration of conformity, CE mark. No scanner replaces any of that.

What a scanner can do is produce reproducible, line-numbered evidence for the code-level parts of the technical file. Inkog detects eight patterns that line up with Annex III §1.1.6, §1.1.9, and §1.2.1: missing oversight, output validation, overreliance on LLM output, infinite loops, token bombing, missing rate limits, system prompt leak, supply chain corruption. Each is mapped to the corresponding EU AI Act article and OWASP category in SARIF output. Mapping onto Annex III is the auditor's job, and the mapping is one-to-one for these eight controls.

What it will not do is write your risk assessment, run your QMS, or stand in for a Module B examination. Treat it as one input to the technical file, alongside testing evidence, change management, and the human work of safety engineering.

Find your gaps today

Scan your agent code:

npx -y @inkog-io/cli scan . --policy governance

The scanner will surface, with file and line number, the patterns above. The first scan takes 30 seconds. The output is the same shape a Notified Body asks for during a Module B or Module H assessment.

Going deeper

• EU AI Act Article 14: Human Oversight in Agent Code. The oversight half of the AI Act, and how it lines up with Annex III §1.1.6 and §1.2.1.
• EU AI Act Article 15: Robustness for AI Agents. Input validation, error handling, resource limits. The parts that map cleanly onto Annex III cybersecurity.
• EU AI Act Compliance Checklist for AI Agent Developers. The top-level checklist that sits above both regulations.
• NIST AI Agent Standards Initiative. The US counterpart now consolidating around the same controls.

Inkog is a static analysis scanner for AI agent code. It maps every finding to EU AI Act articles, NIST AI RMF functions, and OWASP LLM Top 10 categories. The eight controls above feed directly into the code-level evidence section of a Machinery Regulation technical file. Free CLI, 30-second scan:

npx -y @inkog-io/cli scan . --policy eu-ai-act