Mapping the first EU regulation to classify AI software as a physical safety component. Digital safety attestation, substantial modification audit trails, and Notified Body conformity evidence for machinery with self-evolving behavior.
Who this is for: Machine safety engineers, industrial OEM compliance teams, robotics companies, Notified Body auditors (TUV, DEKRA, Bureau Veritas), and AI platform providers deploying on physical hardware.
Regulation (EU) 2023/1230 takes effect January 20, 2027. Unlike the previous Machinery Directive, this is a directly binding Regulation -- no national transposition, no varying interpretations, no grace period. Self-declaration of conformity is banned for machinery with self-evolving AI safety functions. Manufacturers must obtain third-party Notified Body EU Type-Examination before placing products on the EU market.
Regulation (EU) 2023/1230 replaces Directive 2006/42/EC and fundamentally changes how software and AI are treated in the machinery safety regime. Three shifts matter for AI providers and OEMs:
Industrial development cycles for machinery run 18 to 30 months. Manufacturers designing products today for 2027 market placement must incorporate compliant AI governance evidence into their development process now. The compliance design window is closing.
| Provision | Obligation | What It Means for AI |
|---|---|---|
| Article 3 (Definitions) | Safety component includes digital components and software | AI software controlling physical actuators, safety interlocks, or emergency systems is a regulated safety component |
| Article 5 | Manufacturers must complete conformity assessment before market placement | AI safety functions must be assessed and documented before the machine ships, not after deployment |
| Article 18 | Substantial modification makes the modifier the legal manufacturer | OTA model updates, fine-tuning, or reinforcement learning changes to safety logic trigger re-certification |
| Annex I Part A (5-6) | Mandatory NB EU Type-Examination for self-evolving AI safety functions | No self-declaration. Every robot, AMR, or cobot with ML-based safety functions needs a Notified Body audit |
| Annex III 1.1.9 | Protection against corruption: tamper-evidence logging for safety software | Every intervention in safety software must be logged. Logs must be retained for 5 years after upload. Accidental and intentional corruption must be resisted |
| Annex III 1.2.1 | Control system safety against malicious attempts | Safety-related control systems, including AI, must resist "reasonably foreseeable malicious attempts from third parties" |
| Annex III Section 3.6 | Mobile machinery and autonomous mobility requirements | Autonomous mobile robots (AMRs), warehouse vehicles, and autonomous excavators face specific safety requirements beyond general machinery rules |
Cybersecurity is now a physical safety requirement. Under Annex III 1.1.9, a cyberattack or corrupted software update that compromises a machine's safety function is treated as a physical safety failure -- not an IT incident. This means cybersecurity testing and monitoring evidence must appear in the machinery safety technical file alongside mechanical safety documentation.
Eighteen SWT3 procedures produce evidence relevant to EU Machinery Regulation compliance. Together, they cover safety state management, hardware attestation, software version governance, cybersecurity, human oversight, and post-deployment monitoring.
| SWT3 Procedure | Evidence Produced | Regulation Provision |
|---|---|---|
AI-EMRG.1 |
Emergency override lifecycle: trigger, authorization, fallback state | Annex III 1.2.1 (safe fallback), Art. 5 (conformity) |
AI-SAFE.1 |
Safe state transition: trigger type, suspended actions, recovery | Annex III 1.2.1 (control systems), Annex I Part A (5-6) |
AI-TOOL.1 |
Tool call witnessing: every read/write to physical actuators | Annex III 1.1.9 (tamper evidence), Art. 5 (documentation) |
AI-TOOL.2 |
Tool access control: authorization for hardware interaction | Annex III 1.2.1 (access to safety functions) |
AI-HITL.1 |
Human-in-the-loop approval for high-risk operations | Annex III 1.2.1 (operator intervention capability) |
AI-ENG.3 |
Safety-critical review gate: peer/regulatory/assessor approvals | Art. 5 (conformity assessment), Annex I Part A (NB review) |
AI-MDL.1 |
Model registration and inventory | Art. 5 (technical documentation), Annex IV (technical file) |
AI-MDL.2 |
Model version governance, lineage tracking | Art. 18 (substantial modification detection) |
AI-DRIFT.1 |
Statistical drift monitoring with threshold configuration | Annex I Part A (self-evolving behavior monitoring) |
AI-BASE.1 |
Baseline integrity: cryptographic fingerprint of validated state | Art. 18 (detecting deviation from certified parameters) |
AI-CHAIN.1 |
Multi-device orchestration chains with cycle IDs | Annex III 3.6 (autonomous mobile machinery coordination) |
AI-INCIDENT.1 |
Incident classification and response attestation | Art. 5 (post-market obligations), Annex III 1.1.9 |
AI-CYBER.1 |
Cybersecurity posture attestation | Annex III 1.1.9 (corruption protection), 1.2.1 (malicious attempts) |
AI-ROBUST.1 |
Adversarial robustness testing attestation | Annex III 1.1.9 (intentional corruption resistance) |
HBOM-INV.1 |
Hardware component inventory, manifest hash, baseline delta | Art. 5 (technical documentation), Annex IV (technical file) |
HBOM-THERM.1 |
Thermal profile attestation with threshold breach detection | Annex III 1.5 (thermal hazards), safety monitoring |
HBOM-SUPPLY.1 |
Hardware supply chain provenance and screening | Art. 5 (manufacturer obligations), component traceability |
HBOM-LIFE.1 |
Component lifecycle: installed, commissioned, maintained, degraded, decommissioned | Art. 18 (modification tracking), post-market monitoring |
When an autonomous robot triggers an emergency stop -- whether from an operator button press, a safety sensor activation, or an AI-initiated halt -- AI-EMRG.1 creates an immutable record of the entire event. The anchor captures what triggered the override, who or what authorized the transition, what fallback state the machine entered, and whether recovery was available.
Regulation mapping: Annex III 1.2.1 requires control systems to transition to a safe state when a hazardous condition is detected. AI-EMRG.1 proves that the transition occurred, how it was authorized, and that the machine reached a defined safe state rather than an undefined failure mode.
For NB EU Type-Examination, verify that AI-EMRG.1 anchors exist for every emergency override path documented in the risk assessment. Each identified hazardous scenario should have a corresponding tested override event with a witnessed fallback state. Missing coverage indicates an untested safety path.
AI-SAFE.1 witnesses state transitions below the emergency threshold: reduced-speed modes, restricted workspace boundaries, human-collaboration mode activation, and graceful degradation. These transitions are the first line of defense before an emergency stop is required.
Regulation mapping: Annex III 1.2.1 requires control systems to be designed so that "a hazardous situation cannot arise" from foreseeable conditions. AI-SAFE.1 proves the machine's control system can detect pre-hazardous conditions and transition to a safer operational mode without requiring a full emergency stop.
A continuous chain of AI-SAFE.1 anchors across operational sessions proves the safety state machine is active, not just implemented. Look for the ratio of safe-state transitions to emergency overrides -- a healthy system should show many AI-SAFE.1 events for every AI-EMRG.1 event, indicating hazards are caught early.
HBOM-INV.1 records the complete hardware bill of materials: component count, manifest hash, and delta from the certified baseline. For machinery subject to EU Type-Examination, this proves the physical configuration at the time of assessment matches the configuration in production.
Regulation mapping: Article 5 requires manufacturers to prepare technical documentation before market placement. Annex IV specifies the technical file contents. HBOM-INV.1 provides a verifiable hardware inventory that can be checked against the technical file at any point in the machine's lifecycle.
Compare the HBOM-INV.1 manifest hash from the initial EU Type-Examination against the current production manifest. Any delta indicates a hardware change that may require a new assessment under Article 18 if it affects safety functions. Automated delta detection eliminates manual inventory audits.
AI-MDL.2 is the primary procedure for detecting substantial modifications under Article 18. Each version anchor links to its predecessor, creating an unbroken chain from the certified model version through every subsequent change. When a model update occurs, the anchor captures what changed and whether the change was within the scope foreseen by the original manufacturer.
Regulation mapping: Article 18 defines a substantial modification as one "not foreseen or planned by the manufacturer" that "affects the safety" of the machine. AI-MDL.2 version anchors provide the evidence to determine whether a specific update crosses that threshold -- by comparing the update against the certified baseline (AI-BASE.1) and monitoring for behavioral drift (AI-DRIFT.1).
For any model update post-certification, trace the AI-MDL.2 chain to determine: (1) was the update type foreseen in the original risk assessment? (2) does the AI-BASE.1 baseline comparison show deviation beyond certified parameters? (3) does AI-DRIFT.1 show behavioral drift after the update? If any answer is yes, the update may constitute a substantial modification requiring re-assessment.
Annex III 1.1.9 treats cybersecurity as a physical safety requirement. AI-CYBER.1 attests that cybersecurity measures are active and that safety-critical software has been tested against corruption -- both accidental (bugs, data errors) and intentional (cyberattacks, adversarial manipulation).
Regulation mapping: Annex III 1.1.9 requires that "hardware and software components that affect safety must resist accidental and intentional corruption" and that the machine "must keep a tamper-evidence log." AI-CYBER.1 anchors prove cybersecurity testing occurred. The SWT3 witness ledger itself serves as the tamper-evidence log -- each anchor is cryptographically fingerprinted and independently verifiable.
Annex III 1.1.9 requires tamper-evidence logs to be retained for 5 years after safety software uploads. Verify that the witness anchor retention policy meets or exceeds this requirement. Check that AI-CYBER.1 + AI-ROBUST.1 anchors cover the full cybersecurity test plan documented in the technical file.
When multiple autonomous machines coordinate -- warehouse robot fleets, collaborative manufacturing cells, or autonomous vehicle convoys -- AI-CHAIN.1 links their actions through shared chain identifiers. Each device's witness anchors reference the same cycle ID, creating a forensic reconstruction path across the entire multi-device operation.
Regulation mapping: Annex III Section 3.6 imposes specific requirements on mobile machinery and autonomous mobile robots. When multiple autonomous machines operate in shared spaces, the safety case must address coordination failures. AI-CHAIN.1 proves that coordination events were witnessed and can be reconstructed if an incident occurs.
For multi-robot deployments, verify that every device in the fleet generates witness anchors with consistent cycle IDs during coordinated operations. Gaps in the chain -- devices that operated without witness coverage -- represent unattested coordination events that weaken the safety case.
Article 18 creates a legal tripwire for AI-enabled machinery: any software update that changes safety logic in a way not foreseen by the original manufacturer makes the updater the legal manufacturer -- with full conformity assessment obligations.
For AI systems that learn, adapt, or receive model updates, this raises a critical question: when does a routine update become a substantial modification?
Step 1: Version Chain. AI-MDL.2 records every model update with a link to the previous version. The version chain establishes what changed and when. If the update type was documented in the original risk assessment as a foreseeable change (e.g., "model weights may be updated quarterly with safety re-validation"), it may not constitute a substantial modification.
Step 2: Baseline Comparison. AI-BASE.1 holds the cryptographic fingerprint of the model state at the time of EU Type-Examination. After any update, comparing the new model state against this baseline reveals whether the system has deviated from its certified parameters. A model that stays within the validated performance envelope is less likely to trigger re-certification.
Step 3: Drift Monitoring. AI-DRIFT.1 provides continuous statistical monitoring after the update. If the model's behavior (accuracy, latency, output distribution) remains within the thresholds documented in the risk assessment, the update did not create a new hazard or increase an existing risk. If drift exceeds thresholds, the update may have crossed the Article 18 boundary.
The evidence chain matters in both directions. If an update IS a substantial modification, the version chain + baseline comparison + drift data document exactly what changed and why re-certification was triggered. If an update is NOT a substantial modification, the same evidence proves the system stayed within its certified safety envelope. Either way, the manufacturer has auditable evidence for the Notified Body.
The Machinery Regulation defines two conformity assessment routes depending on the risk classification of the machinery.
Machinery with self-evolving AI safety functions falls under Annex I Part A items 5 and 6. These categories must undergo EU Type-Examination by an accredited Notified Body (TUV SUD, TUV Rheinland, DEKRA, Bureau Veritas, Nemko, or equivalent). Self-declaration is not permitted.
What the NB expects: A technical file containing risk assessment, design specifications, test results, and evidence that safety functions operate as intended. SWT3 witness anchors provide the runtime evidence layer: proof that safety controls were active, tested, and monitored throughout development and testing. The anchors complement the static documentation (design drawings, risk assessment, test protocols) with dynamic execution evidence.
Machinery that does not fall under Part A may use self-certification -- but only if the manufacturer follows harmonized standards (e.g., ISO 12100, ISO 13849, IEC 62443). If the manufacturer deviates from harmonized standards, NB assessment is required even for Part B categories.
SWT3 role: For Part B self-certification, witness anchors serve as the evidence that harmonized standard requirements were implemented and validated. The manufacturer's declaration of conformity is strengthened by independently verifiable execution evidence rather than relying solely on internal documentation.
The Machinery Regulation Annex IV requires manufacturers to prepare a technical file containing design documentation, risk assessments, test results, and conformity evidence. SWT3 provides several export formats that map to these requirements.
| Export Endpoint | Format | Technical File Section |
|---|---|---|
/api/v1/annex-iv/export |
HTML (self-contained) | Risk management evidence, control attestation, testing records |
/api/v1/grc-feed/export |
JSON or CSV | Structured compliance data for integration with GRC platforms (ServiceNow, Splunk, Vanta) |
/api/v1/soa/export |
HTML (ISO 27001 SoA) | Statement of Applicability for information security controls (supports IEC 62443 alignment) |
/api/v1/passport/export?format=vc |
W3C Verifiable Credential | Cryptographically signed compliance summary for cross-border verification (Enclave+ tier) |
What the exports cover: Runtime governance evidence -- proof that safety controls were active, tested, and monitored. This complements the OEM's static documentation (mechanical drawings, FMEA, test protocols) with dynamic execution evidence that an NB can independently verify.
What remains OEM-specific: Mechanical design documentation, risk assessment methodology, harmonized standard analysis, and manufacturing quality records. SWT3 provides the software and AI governance evidence layer; the complete technical file integrates this with the OEM's engineering documentation.
For the Anthropic Model Hardware Standard integration pattern, see the MHS Governance Crosswalk.
SWT3 procedures mapped against seven key provisions of the Machinery Regulation.
| Procedure | Art. 3 (Safety Component) |
Art. 5 (Conformity) |
Art. 18 (Modification) |
Annex I (NB Audit) |
Annex III 1.1.9 (Cybersecurity) |
Annex III 1.2.1 (Control Systems) |
Annex III 3.6 (Mobile) |
|---|---|---|---|---|---|---|---|
AI-EMRG.1 |
✓ | ✓ | ✓ | ✓ | ✓ | ||
AI-SAFE.1 |
✓ | ✓ | ✓ | ✓ | ✓ | ||
AI-TOOL.1 |
✓ | ✓ | ✓ | ✓ | |||
AI-HITL.1 |
✓ | ✓ | ✓ | ||||
AI-MDL.2 |
✓ | ✓ | ✓ | ||||
AI-BASE.1 |
✓ | ✓ | ✓ | ||||
AI-DRIFT.1 |
✓ | ✓ | |||||
AI-CYBER.1 |
✓ | ✓ | ✓ | ||||
AI-ROBUST.1 |
✓ | ✓ | |||||
AI-CHAIN.1 |
✓ | ||||||
HBOM-INV.1 |
✓ | ✓ | ✓ | ✓ | |||
HBOM-THERM.1 |
✓ | ✓ | ✓ | ||||
HBOM-SUPPLY.1 |
✓ | ||||||
HBOM-LIFE.1 |
✓ |
Coverage summary: 14 SWT3 procedures across 7 regulatory provisions. Every provision is covered by at least 2 procedures. Annex III 1.2.1 (control system safety) has the deepest coverage with 6 procedures, reflecting its central role in AI-enabled machinery compliance.
from swt3_ai import Witness
witness = Witness(
endpoint="https://your-instance.example.com/api/v1/witness",
api_key="axm_your_key",
agent_id="cobot-controller-01",
jurisdiction="DE",
legal_basis="EU-2023-1230"
)
# Witness an emergency override
witness.witness_emergency(
trigger_type="safety_sensor",
authorization_level="automatic",
fallback_state="full_stop",
recovery_available=True
)
# Witness a hardware inventory attestation
witness.witness_hardware(
component_count=47,
manifest_hash="a3c9...",
baseline_delta=0
)
witness.flush()import { Witness } from '@tenova/swt3-ai';
const witness = new Witness({
endpoint: 'https://your-instance.example.com/api/v1/witness',
apiKey: 'axm_your_key',
agentId: 'amr-fleet-controller',
jurisdiction: 'DE',
legalBasis: 'EU-2023-1230'
});
// Witness a safe state transition
witness.witnessSafeState({
triggerType: 'proximity_threshold',
suspendedActions: ['actuator_write'],
recoveryAvailable: true
});
await witness.flush();