Manufacturing vertical · EU AI Act · EU Machinery Regulation · IEC 62443

How to use the manufacturing schema

Five steps for Plant AI Safety Officers, OT Security Teams, and Product Compliance Managers: classify AI systems by risk tier and operating model, map SRF personas to manufacturing roles, trace responsibility splits, set tier parameters, and assemble the EU AI Act evidence package.

For Plant AI Safety Officer · OT Security Team · Product Compliance Manager · OT/MES Engineer
Experimental schema. This vertical is a proposed extension of the CoSAI Shared Responsibility Framework, developed independently to demonstrate the approach. It is not part of CoSAI SRF v1.0 and has not been endorsed by CoSAI, the European Commission, ISA, IEC, or any standards body or government agency. EU AI Act and EU Machinery Regulation references must be verified against current regulatory text before use in compliance submissions.

  1. Classify AI systems by EU AI Act risk tier and operating model

    Start with the EU AI Act risk classification. Every AI system must be assigned one of four risk tiers: prohibited (banned), high-risk, limited-risk, or minimal-risk. For manufacturing, the high-risk determination is the critical question.

    A system is automatically high-risk if it is a safety component under EU Machinery Regulation 2023/1230 Annex I items 5 or 6: that is, if it uses machine learning to ensure a safety function, or if it is machinery that embeds such a component. This classification is triggered by the function, not by the label; an AI visual inspection system that gates safety-critical assembly steps qualifies.

    A system is high-risk under EU AI Act Annex III if it operates in critical infrastructure, involves employment or worker management decisions, or affects access to essential services. AI used for predictive maintenance on equipment whose failure could cause harm, or AI-driven workforce scheduling with consequential outcomes, should be evaluated against Annex III.

    Assign each system one of four operating models: AI-SaaS (cloud AI for IT-side manufacturing), OT-Edge (AI deployed within OT/ICS security zones), Product-Embedded (AI in machinery or products placed on the EU market), or AI-PaaS (digital twin, IIoT, or MES platform infrastructure). Record both the risk class and operating model in the AI use case inventory (control SRF-L1-DES-003).

    EU Machinery Regulation note: The January 20, 2027 deadline for EU Machinery Regulation 2023/1230 follows the August 2, 2026 EU AI Act high-risk deadline by less than six months. The compliance work overlaps substantially. A safety component classification under the Machinery Regulation is automatic high-risk classification under the AI Act, so conformity assessment and technical file preparation should address both simultaneously.

  2. Map SRF personas to manufacturing roles

    The SRF uses six cross-industry personas. Each maps to specific manufacturing roles. Assign the persona for each control to the role that holds operational accountability in your organization. For controls marked shared, document the split explicitly rather than leaving it undefined.

    SRF persona Manufacturing role Typical office or team
    ai-system-governance Plant AI Safety Officer or VP Manufacturing with AI governance mandate EHS, Operations, or Chief Digital Officer organization
    data-provider OT Data Manager or Historian Administrator IT/OT integration team or plant automation engineering
    application-developer OT/MES Engineer or Product Application Engineer Manufacturing engineering, MES team, or product development
    agentic-platform-provider Automation Platform Owner or Robotics Systems Engineer Advanced manufacturing or automation center of excellence
    ai-platform-provider OT Infrastructure Lead or ICS Security Team OT network operations, ICS security, or plant IT
    model-provider AI Model Vendor or Equipment OEM (external); AI model team (internal) Procurement contract counterparty or internal AI center of excellence

    For controls owned by external parties (model vendor, equipment OEM, system integrator), verify that procurement contracts assign the obligation explicitly. The schema's responsibility_split field on every control indicates the expected owner; use this as a contract checklist during supplier negotiations.

  3. Trace responsibility splits by operating model

    The schema uses five responsibility split values. Each control carries exactly one. For shared controls, the accountable party (usually the manufacturer) must document the split and assign sub-obligations to the relevant parties.

    Split value Scope Typical contract mechanism
    manufacturer The manufacturing organization deploying or placing the AI system on the market. Full accountability; no delegation. Internal policy and procedure
    equipment-oem The OEM supplying the AI-enabled machine, robot, or system. Accountable for product-side obligations including technical file and EU declaration of conformity. Supply contract with EU AI Act compliance annex
    ai-vendor The AI software or model vendor. Accountable for model artifacts, BoAIM, vulnerability disclosure SLA, and portability documentation. Software license or AI services agreement with SRF annex
    system-integrator The SI who integrated AI into the plant or product. Accountable for integration quality, zone segmentation, and acceptance testing scope. Professional services contract with FAT/SAT and IEC 62443 deliverable requirements
    shared Split across parties. The accountable party (the manufacturer, unless otherwise designated) must document who owns each sub-obligation. Responsibility matrix (RACI) attached to the relevant contracts

    Use the controls browser with the "Responsibility split" filter to export a view of controls by party. Run this view in contract review to verify coverage.

  4. Set tier parameters by operating model and EU AI Act risk class

    Controls of type tier-configurable carry a threshold parameter name (e.g., TIER_INPUT_PSI_THRESHOLD) rather than a hard-coded value. Your organization sets these parameters by operating model and risk class. The table below provides starting points; adjust based on your process criticality and regulatory risk appetite.

    Parameter AI-SaaS / AI-PaaS (IT-side) OT-Edge / Product-Embedded (high-risk)
    TIER_AI_REGISTRY_COVERAGE_PCT 100% 100%
    TIER_INVENTORY_STALENESS_DAYS 30 days 14 days
    TIER_INPUT_PSI_THRESHOLD 0.2 (PSI alert threshold) 0.1 (tighter; process drift is safety-relevant)
    TIER_LOG_RETENTION_DAYS 180 days (EU AI Act minimum) 365 days recommended for safety-critical deployments
    TIER_OT_ANOMALY_DETECTION_COVERAGE_PCT N/A (IT-only parameter) 100% for safety zones; 80% minimum for non-safety zones
    TIER_OT_SIEM_COVERAGE_PCT N/A (OT-only parameter) 100%
    TIER_CHANGE_RECORD_COMPLETENESS_PCT 95% 100% for safety-critical OT AI
    TIER_MODEL_PERFORMANCE_FLOOR Defined per use case (e.g., 95% accuracy for quality inspection) Same, but with tighter monitoring window; process criticality determines floor
    TIER_VULN_SLA_DAYS_CRITICAL 30 days 90 days (OT change cycle constraint); compensating control required if longer
    TIER_AI_AVAILABILITY_PCT 99.5% for business-critical; lower for non-critical 99.9% for AI in the critical production path

    Document tier parameters in a policy annex or configuration management record. Reference them from the controls assessment workpaper so auditors can trace each threshold to its source.

    OT change management note: OT-edge AI systems cannot be patched on an IT cycle. The TIER_VULN_SLA_DAYS_CRITICAL parameter for OT-edge deployments must account for the change management cycle: version freeze windows aligned to production shutdowns, safety re-validation before deployment, and rollback verification. A 90-day SLA is a common starting point; supplement it with a compensating control requirement (network isolation, input validation, anomaly detection) for vulnerabilities that cannot be patched within the SLA.

  5. Assemble the evidence package

    The manufacturing evidence package differs from other verticals in two ways: the EU AI Act technical file has a 10-year retention requirement for high-risk systems, and safety case documents for AI in safety-instrumented systems may be confidential. The list below covers the required artifacts by category.

    EU AI Act technical file (per high-risk system):

    • General system description, including intended purpose and operating model
    • Design documentation: architecture, training methodology, dataset descriptions, data quality assessment
    • Testing and validation information: pre-deployment test plan and results, FAT/SAT report with AI-specific test cases
    • Conformity assessment record (self-assessment or notified-body certificate)
    • EU declaration of conformity (signed, with CE marking reference for machinery)
    • EU AI database registration confirmation
    • Instructions for use (including human oversight requirements and operator override procedure)
    • Post-market monitoring plan
    • Fundamental Rights Impact Assessment (where applicable under Article 27)
    • Change log for all substantive system modifications

    OT-specific artifacts:

    • IEC 62443 zone-and-conduit design document with OT security review sign-off
    • OT change management records for each AI system update (change record, safety impact assessment, rollback test result)
    • OT-edge hardware security baseline configuration audit report
    • Conduit traversal audit log for data flows between OT and IT/cloud
    • OT SIEM or anomaly detection coverage report
    • Remote access session logs (monthly review record)
    • SBOM/AIBOM for each OT-deployed AI component

    Safety-critical artifacts (access-restricted; maintain with functional safety engineer):

    • Safety case document (custodian: functional safety engineer or plant safety officer)
    • SIL assessment record for AI in safety-instrumented systems, per IEC 61508 (custodian: functional safety engineer)
    • Safety interlock integration test record
    IEC 61508 evidence note: Safety case documents and SIL assessment records are often confidential under corporate security and functional safety management policies. Do not publish document URLs or include document content in publicly accessible systems. Record document type, custodian role, and access path only. For market surveillance authority requests, the deploying manufacturer must have an internal retrieval process for these artifacts.

    Supplier documentation (per third-party AI system):

    • EU declaration of conformity from the model provider or equipment OEM
    • Supplier technical file completeness checklist with review sign-off
    • Bill of AI Materials (BoAIM) with artifact signature verification record
    • Supplier vulnerability disclosure SLA document
    • Supplier due diligence report with OT security review sign-off
    • Model portability documentation

    Download the manufacturing compliance workpaper to track all 45 controls, assign owners, log evidence artifact status, and record tier parameter values in a single auditor-ready file.