Lifecycle stage — Govern
The EU AI Act is enforceable, and the penalties are not symbolic. Deploying a prohibited AI system carries fines up to €35 million or 7% of global annual turnover. Non-compliance on high-risk systems reaches €15 million or 3% of turnover. For industrial operators, automotive OEMs, autonomous-system developers, and energy utilities, the stakes are particularly acute: Annex III explicitly names safety components in machinery, transport, and critical infrastructure — and the technical file required for a physical deployment is substantially more demanding than the documentation required for a software application. I serve as French Government AI Ambassador for Finance and Business Digital Transformation — I have spent years inside the policy side of this regulation, reading the text with the people who shaped its implementation. That perspective is what this engagement brings to your compliance program.
You do not know which of your systems are high-risk under Annex III — and for physical deployments, the classification is more likely to go high-risk than you expect. The AI Act defines high-risk systems by use case, not by technology. For physical AI, the relevant Annex III categories include: safety components of machinery (robots, autonomous guided vehicles), AI in transport (ADAS, autonomous vehicles, UAS), safety components of critical infrastructure (energy, water, gas), and employment-related AI. A predictive maintenance model that feeds into a safety-critical maintenance decision is not minimal-risk — it may be a safety component of machinery under Annex III, point 2.
The Annex IV technical documentation for a physical deployment is substantially harder than for a software application. For a software AI system, Annex IV requires design documentation, training methodology, data governance, evaluation metrics, and known limitations. For a physical AI system — a robot safety component, an ADAS system, an autonomous industrial vehicle — it also requires the integration architecture with the physical system, the safety envelope specification, the hazard analysis, the failure mode documentation, the envelope violation test results, the hardware and firmware version management records, and the post-market monitoring plan for field-deployed hardware. Most engineering documentation for physical AI does not survive contact with this standard.
The conformity assessment for a high-risk physical-AI system involves a notified body and takes months. Teams scope it as a paperwork exercise. In practice, for a high-risk physical system, the first formal submission to a notified body triggers a clarification cycle that runs for months — and every clarification request requires your engineering team to produce evidence that, if it does not already exist, must be created from scratch. Starting the conformity assessment documentation when the product is already in pre-production is too late.
Post-market monitoring for physically deployed AI is operationally complex. The Act requires a written post-market monitoring plan and active monitoring in production. For software AI, this is primarily about model drift and accuracy monitoring. For physically deployed AI — a fleet of AGVs, a robotics cell, an ADAS stack across thousands of vehicles — post-market monitoring requires field data collection from deployed hardware, OTA update management, field incident reporting with tight regulatory deadlines, and hardware-level monitoring that most software-AI observability stacks cannot provide.
The engagement scope depends on the size of your AI footprint and the number of high-risk systems in scope. Twelve weeks covers a single high-risk system; twenty-four weeks covers a portfolio of three to five systems with shared governance infrastructure. For physical-AI deployments, the safety and technical documentation phases run alongside your engineering and certification teams, not separately.
We build a written inventory of every AI system in your organisation — production, pilot, prototype — with each one classified against the AI Act's risk categories. For physical deployments, this includes explicit analysis against Annex III categories: safety components in machinery (ISO 10218, Machinery Directive), transport AI (UNECE R155/R156, vehicle type approval), critical infrastructure AI (IEC 62443, NIS2), and other applicable categories. The classification is documented with the reasoning and the article references. Systems that were deployed without classification get retroactive review.
For each high-risk system we build the compliance artifacts in parallel. For physical-AI systems, this includes the integration architecture with the physical system, the safety envelope specification, the hazard analysis, the failure mode coverage document, envelope violation test results, and the hardware and firmware version management records — in addition to the standard Annex IV software documentation. I work with your engineering and safety teams to produce these documents to the notified body standard, drawing on the physical-AI safety documentation methodology I use in the Physical AI Deployment engagement.
We stand up the post-market monitoring program adapted for physical deployments: the written plan, field data collection architecture from deployed hardware, OTA update management and version tracking, incident classification criteria for field incidents involving physical-system interaction, and reporting workflows with the regulatory deadlines. For large-scale physical deployments (AGV fleets, vehicle programs, multi-site robotics), the monitoring architecture must handle field data at scale, not just cloud-model drift.
We build the governance infrastructure for the long term — the AI governance committee charter, the intake process for new AI systems (with physical-deployment classification fast-path), the recurring review cycle, the staff training program, and the vendor management approach for third-party AI components embedded in physical systems. The program needs to run without me once the engagement ends.
Manufacturers deploying AI safety components in machinery or autonomous guided vehicles under Annex III point 2. Automotive OEMs and Tier-1 suppliers with ADAS or AD stacks under vehicle type approval and UNECE R155/R156. Autonomous-system developers (UAS, robotics) whose products are safety components under the Machinery Regulation or relevant sector regulation. Energy utilities deploying AI in safety components of critical infrastructure under IEC 62443 and NIS2. Any organisation with an AI footprint that includes physical deployments where the Annex III classification is clearly high-risk or genuinely ambiguous. This is not a substitute for external legal counsel on regulatory strategy; I engineer the compliance program, and your general counsel handles the legal positioning.
Your law firm tells you what the regulation requires; I build the program that implements it. For physical-AI deployments, that gap is enormous: the law firm cannot write your Annex IV technical documentation for a robotics safety component, design your human-in-the-loop controls for an AGV fleet, or stand up your post-market monitoring architecture for a vehicle program. That is engineering and program management, which is what this engagement delivers.
Not automatically, but more often than software teams expect. The classification turns on the use case. A computer-vision model that identifies objects for a robot's path planning is probably a safety component of machinery under Annex III point 2. An ADAS system is high-risk under Annex III point 4. A predictive maintenance model that feeds into a maintenance decision for safety-critical equipment may be a safety component under Annex III point 2. I do not conflate the cyber standards (UNECE R155/R156, which govern cybersecurity for vehicle type approval) with the functional-safety standards (ISO 26262/IEC 61508, which govern safety integrity levels for safety-critical functions) — they apply to different failure domains and the Annex IV documentation for each is different.
The staged enforcement timeline is legislated. Prohibitions have been enforceable since February 2025, general-purpose AI rules since August 2025, and the high-risk obligations land in August 2026. For physical-AI systems that require a notified body review, starting the conformity assessment documentation now is not optional — the notified body engagement, clarification cycle, and remediation work collectively take months, and any program that starts the documentation work in Q1 2026 for an August 2026 deadline is behind schedule.
These standards are complementary, not competing. ISO 26262 governs functional safety for automotive — the ASIL classification, the safety case, the verification and validation evidence. IEC 61508 governs functional safety for industrial systems — the SIL classification. IEC 62443 governs OT cybersecurity. The EU AI Act Annex IV technical documentation for a physical AI system draws on and references the evidence produced for these standards — the hazard analysis, the FMEA, the safety case — but adds AI-specific requirements: training data governance, model performance metrics, known limitations, and human oversight design. Running these programs in parallel rather than sequentially is the only way to meet the 2026 deadline without duplicating evidence.
Explore other services that complement this offering
30 minutes. I diagnose your situation, tell you honestly whether this service fits — and if it doesn't, what does.