The EU AI Act is in force and phasing in by category (prohibited practices since February 2025; GPAI since August 2025; high-risk from December 2027 for Annex III and August 2028 for Annex I), 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: the high-risk regime reaches safety components in machinery and transport through Article 6(1) and Annex I, and in critical infrastructure under Annex III — 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, and I bring deep familiarity with the regulation's technical requirements — reading the text closely and applying it in practice. That perspective is what this engagement brings to your compliance program.
You do not know which of your systems are high-risk — 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, through two routes: Annex III (stand-alone high-risk use cases) and Article 6(1) with Annex I (AI that is a safety component of a product already covered by EU harmonisation legislation). For physical AI, the categories that may apply, depending on role and use case, include: safety components of machinery (robots, autonomous guided vehicles) and AI in transport (ADAS, autonomous vehicles, UAS), which are governed as safety components of regulated products under Article 6(1) and Annex I; and safety components of critical infrastructure (energy, water, gas) and employment-related AI under Annex III. A predictive maintenance model is not automatically high-risk — but where it feeds a safety-critical maintenance decision it may qualify as a safety component of machinery under Article 6(1) and Annex I, depending on its role.
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 may require a notified body under Article 43 or applicable sector legislation, 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 the applicable high-risk regimes — Annex III, and Article 6(1) with Annex I for product-embedded systems: safety components in machinery (ISO 10218, Machinery Regulation) and transport AI (UNECE R155/R156, vehicle type approval) route through Article 6(1) and Annex I; critical infrastructure AI (IEC 62443, NIS2) falls under Annex III; 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 artefacts 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 standard a conformity assessment requires, 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 the Machinery Regulation and Article 6(1). 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 high-risk classification is clearly established 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 likely a safety component of machinery, governed under the Machinery Regulation and Article 6(1). An ADAS system is high-risk as a safety component of a regulated vehicle under Article 6(1) and Annex I. A predictive maintenance model is not automatically high-risk — where it feeds a maintenance decision for safety-critical equipment it may qualify as a safety component under Article 6(1) and Annex I, depending on its role. 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 set. Prohibitions have been enforceable since February 2025, general-purpose AI rules since August 2025, and the high-risk obligations apply from December 2027 for Annex III systems and August 2028 for Annex I product-embedded systems. 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 a December 2027 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 December 2027 deadline without duplicating evidence.
30 minutes. I diagnose your situation, tell you honestly whether this service fits — and if it doesn't, what does.