Lifecycle stage — Build
The AI that runs inside a physical system is a different engineering problem from the AI that runs in a cloud. A model deployed on a PLC in a production line, an ECU in a vehicle, a compute node at a substation, or a flight controller in a drone has to hold real-time SLAs, survive network partitions, respect safety envelopes your certification engineers will review, and run on hardware whose cost has to clear what operations accounting will approve. Generic cloud AI consultancies cannot do this work — the reference architectures do not apply and the teams have not met a safety engineer. This is the Build and Ship stages of the Hyperion Lifecycle, adapted for physical systems: a 16-week embedded engagement that takes an edge AI pilot through safety discovery, model design for constrained hardware, integration with the industrial or vehicle stack, and operational handoff. I serve as French Government AI Ambassador for Finance and Business Digital Transformation — a designation that matters for sovereign infrastructure and strategic-industry work — and I've shipped 10 AI ventures including work on autonomous systems. The deliverable is a deployment your operations team will run, not a demo your data team will abandon.
Your cloud-first data platform was never designed to push a model to a robotics cell PLC, a vehicle ECU, an AGV fleet controller, or a substation compute node — and retrofitting it is a three-quarter project on its own. The MLOps stack your team built assumes elastic cloud inference, network connectivity, and hardware you can overprovision. None of those assumptions hold at the edge. The model your data team trained runs on hardware your operations team controls, with constraints your MLOps pipeline cannot express.
Safety and certification engineers have veto power and you have no process that produces the evidence they need. The model works in simulation. Your safety engineer asks for the hazard analysis, the failure mode coverage, the envelope violation testing, and the evidence chain that will survive a certification review under ISO 26262 (ASIL), IEC 61508 (SIL), DO-178C for drone avionics, or ISO 10218 for robot safety — and your data team has never produced any of those artifacts. The project stalls in a review your data team did not know existed until week ten.
Your AI team and your operations team use different languages, and their ticket systems do not talk. The data scientists speak in F1 scores, validation sets, and model cards. The operations engineers speak in OEE, MTBF, PLC scan cycles, vehicle bus timing, and AGV path-conflict rates. Without a shared language and a shared operating rhythm, the model your team delivered is never accepted by the operations team that has to run it. The project does not fail technically; it fails socially.
The model works at bench scale and falls over the first time it meets a real sensor with the wrong calibration drift. Training data was clean. The production robotics cell has a thermal bias nobody modeled, a firmware version your team did not know existed, and an intermittent encoder fault the maintenance team has tolerated for three years. That ambiguity is where edge AI projects go to die.
The engagement runs in four four-week phases. I work on site for the first and last phases and embedded remotely in between. Your engineering, safety, and operations teams all have assigned time — this is not a delivery a data team can carry alone. The output is a deployment running on the production hardware, under the safety regime, integrated with the operational stack.
Structured sessions with the safety engineering team, the certification lead, the operations engineers who will run the system, and the ML team who built the pilot. We document the safety envelope, the failure modes that matter, the certification artifacts required (per ISO 26262 / IEC 61508 / DO-178C / ISO 10218 / EU AI Act Annex III as applicable), the hardware constraints (compute, memory, thermal, power), the network topology and partition behavior, and the operational SLAs the model has to meet. By end of week four we have a written constraint document the safety engineer will sign and the ML team can build against.
The model architecture and training recipe are redesigned for the hardware and safety envelope: quantization strategy, latency budget, memory footprint, deterministic behavior where safety requires it, graceful degradation under sensor fault. We run ablations on real hardware — the target robotics controller, the vehicle ECU, the AGV compute board — not in simulation. We also build the evidence chain — hazard analysis, failure mode coverage, envelope violation tests — that the certification review will require. The model produced in this phase is the one that will deploy.
The model integrates with the industrial or vehicle stack on real hardware — PLC programming environment, OT network, vehicle CAN/Ethernet bus, AGV fleet management system, UAS flight controller interface, or substation automation relay. The operations team's monitoring system receives the alerts the model will produce. The firmware update path, the model rollback mechanism, and the deployment pipeline (over-the-air or over-the-wire as appropriate) are built and tested. By end of week twelve the model runs on production hardware in a controlled pilot zone.
The operations team owns the deployment. We build the runbooks they will use, the alerting thresholds that match their existing operational rhythm, the model performance dashboards they can read without ML training, and the rollback playbooks for when a firmware update goes wrong at 2am. We expand from the pilot zone to the production footprint — robotics cell by cell, AGV by AGV, vehicle by vehicle, site by site — with the safety engineer signing off each expansion. When I leave, the operations team runs the system.
Manufacturers deploying AI into robotics cells or AGV/AMR fleets. Automotive OEMs and Tier-1 suppliers integrating AI into ADAS or AD stacks under ISO 26262 and UNECE R155/R156. Energy utilities deploying predictive AI at substation or grid-edge under IEC 62443. Aerospace and defence primes integrating AI into UAS autonomy stacks under DO-178C or EASA frameworks. Any operator where the head of engineering already knows the gap between cloud AI and physical AI is real, has a certification and safety regime the project must clear, and needs an outside voice who has shipped AI into physical systems before. This is not for pure software companies — those need the Agentic System Engineering service. It is also not for organisations without a pilot already running; the engagement assumes an existing model and an operations team to hand it to.
Alongside them, with clear scope boundaries. Your automation partner owns the PLC programming environment, the OT network, and the operational integration layer. I own the model architecture, the edge inference deployment, the certification evidence chain, and the safety process. We meet weekly during the engagement so the work products reconcile. I have done this alongside large industrial automation firms and the boundary works cleanly when both sides respect it.
The engagement produces the certification evidence chain — hazard analysis, failure mode coverage, envelope violation testing — mapped to the standard your safety engineer is working to. I am not a certification body and I do not replace your safety engineer; I build the evidence in the structure they need so the review does not stall. For EU AI Act high-risk classifications specifically, the evidence chain is designed against Annex III requirements. I do not conflate cyber standards (UNECE R155/R156) with functional-safety standards (ISO 26262/IEC 61508); they govern different failure domains and require different evidence.
Yes — and often must. A model running on a vehicle ECU, a remote substation, an AGV in a GPS-denied warehouse zone, or a UAS operating beyond radio-link range has to operate during network partitions and sync state when the link returns. The architecture handles this explicitly: on-device inference, local state management, conflict resolution when telemetry reaches the central platform, and graceful degradation when a dependent service is unreachable.
Whatever your operations team is going to approve and maintain for the next ten years. In week one we identify the realistic hardware envelope — what procurement will buy, what operations will install, what maintenance will service. I have worked across Jetson, Intel, AMD, and custom silicon. The model design is informed by the hardware constraints, not the other way around.
Not meaningfully. The four phases each represent a different discipline — safety, ML engineering, industrial integration, operations — and each needs the time it needs. Compressing the safety phase produces a deployment that fails certification. Compressing the integration phase produces a deployment the operations team rejects. The one place I can sometimes save time is when an existing industrial automation partner has already done significant integration work; the engagement then focuses on the model and safety layers and the integration phase may compress to two weeks. I will tell you in week one whether that applies.
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.