From General-Purpose to Production-Ready: What CTOs Must Solve Before Deploying Physical AI on the Factory Floor

The gap between a compelling robotics demonstration and a system that operates reliably in a live industrial environment is not a matter of iteration time - it is a matter of architectural category. General-purpose physical AI systems, including the humanoid and multi-task platforms attracting significant capital investment, are trained to adapt across task types using foundation model reasoning. That capability is real and technically meaningful. What the launch materials rarely address is the set of engineering constraints that govern whether that reasoning can actually close a control loop in a factory at production speed, under safety requirements, with auditability sufficient for regulatory and insurance purposes. CTOs evaluating these investments need to work through those constraints before procurement, not after pilot.

Companion piece to our broader work on moving AI systems from proof-of-concept to production. See Why Most Enterprise AI Agent Projects Never Leave the Pilot Stage for coverage of governance blockers, organisational readiness gaps, and the architectural decisions that separate operational deployments from perpetual pilots.

The Latency Problem Is Not Incidental

Physical AI systems that rely on large vision-language-action models for task reasoning introduce inference latency that is structurally incompatible with many industrial control requirements. A model generating the next motor command by passing sensor state through a transformer with billions of parameters will typically take tens to hundreds of milliseconds per inference step, depending on hardware and quantisation. In discrete pick-and-place operations with generous inter-cycle timing, that may be acceptable. In applications involving moving conveyor systems, collaborative assembly with human workers, or any process where the robot must react to an unexpected physical event within a defined window, it is not. The commercial implication is direct: a system that cannot meet the latency floor of the target process cannot be deployed in that process, regardless of its task generalisation capability.

The partial solution used in current production-adjacent systems is hierarchical control, where a fast low-level controller handles immediate motor commands using classical or learned reactive policies, while the AI reasoning layer operates at a slower cadence and sets higher-level goals. This architecture reduces the blast radius of inference latency but introduces its own failure mode: the two layers must remain coherent. If the high-level model issues a goal that the low-level controller cannot safely execute given current physical state, and there is no arbitration mechanism, the system will either stall or act on a stale instruction. Designing that arbitration layer is non-trivial and is typically where integration timelines extend beyond initial estimates.

Sensor-to-Decision Pipeline Integrity

A physical AI system is only as reliable as the data it receives from its sensors, and industrial environments are adversarial to sensors in ways that controlled demonstrations are not. Vibration, electromagnetic interference from machinery, variable lighting, occlusion from product stacking, and thermal drift in calibration all degrade sensor output in ways that are difficult to reproduce in pre-deployment testing. The consequence is that a model trained or fine-tuned on clean sensor data will encounter distribution shift on the factory floor, and the degradation in its outputs will not always be obvious from the robot's behaviour until a failure event occurs. This is not a hypothetical risk - it is the dominant failure mode we observe in industrial computer vision deployments, where models that perform well in controlled conditions produce silent errors under real operating conditions.

The engineering response is to treat sensor pipeline integrity as a first-class system requirement rather than an infrastructure assumption. That means building monitoring directly into the pipeline: statistical checks on sensor output distributions, anomaly detection on incoming data streams before they reach the inference model, and defined fallback behaviours when sensor confidence drops below a threshold. In our own work deploying computer vision systems in manufacturing environments - integrating YOLO-based object detection with live IP camera streams and PLC sensor data - we found that the reliability of the sensor ingestion and pre-processing layer was a stronger determinant of overall system performance than model architecture choices. A more capable model receiving degraded input will underperform a simpler model receiving clean, well-monitored input.

Safety Constraints Cannot Be Emergent

Industrial safety standards for collaborative robots - ISO 10218 and ISO/TS 15066 being the primary international frameworks - specify requirements for speed and force limits, protective stops, and workspace monitoring that must be enforced at the hardware and control layer, not delegated to the AI reasoning model. This distinction matters because AI models, including those with strong task generalisation, do not have guaranteed constraint satisfaction. A model that has learned to complete a task efficiently may, under novel conditions, select an action that violates a safety boundary. If the only constraint enforcement mechanism is the model's learned behaviour, that boundary is probabilistic rather than guaranteed. Regulatory bodies and industrial insurers do not accept probabilistic safety guarantees for physical systems operating near humans.

The practical requirement is a deterministic safety layer that operates independently of the AI model and can override or halt its outputs. This is architecturally similar to the monitoring layers used in safety-critical software systems, but with additional complexity because the interventions are physical and the timing constraints are tight. Defining the boundary between what the AI system is permitted to decide autonomously and what requires human authorisation or falls to a hardcoded constraint is a design decision that must be made explicitly, documented, and validated before deployment. It is also a decision that will need to be revisited as the system's task scope expands, because the safe operating envelope for a robot performing a narrow, well-characterised task is different from the envelope for one operating in a general-purpose mode.

The Human-Robot Handoff Protocol

In most realistic industrial deployments, the physical AI system will not operate in isolation. It will work alongside human operators, receive task assignments from human supervisors, and require human intervention when it encounters situations outside its operating envelope. The handoff protocol governing these interactions is an operational design problem, not a software feature, and it is frequently underspecified in early deployment planning. A robot that enters a safe stop state and waits for human intervention without communicating its state clearly, or that resumes operation without confirming that the human has cleared the workspace, creates a hazard that the AI capability itself cannot resolve.

Effective handoff design requires defining the full state space of human-robot interaction modes: normal autonomous operation, assisted operation where the human and robot share a task, supervised operation where the human monitors and can interrupt, and recovery operation after a fault. Each mode needs clear entry and exit conditions, defined communication signals to the human operator, and a log of state transitions for post-incident review. The operational overhead of designing and validating these protocols is not small, and it scales with the number of task types the system is expected to perform. A system deployed to perform one well-defined task has a manageable handoff design problem. A general-purpose system with a broad task repertoire has a combinatorially larger one.

Auditability of Autonomous Physical Actions

When a physical AI system causes a product defect, a line stoppage, or an injury, the first operational question is what the system decided and why. For software AI systems, auditability is already a significant engineering challenge. For physical AI systems, it is harder because the decision chain includes sensor state, model inference, control layer translation, and physical execution, and any of these stages can be the point of failure. Without structured logging across all four stages, incident investigation becomes guesswork, and guesswork is not acceptable to regulators, insurers, or the operations teams responsible for the line.

Building auditability into a physical AI system means logging sensor inputs at the time of each inference, recording model outputs and the confidence or uncertainty estimates associated with them, capturing control layer translations and any safety overrides that occurred, and timestamping physical actions against the log. The storage and retrieval infrastructure for this data is not trivial at production volumes, and the log format needs to be defined before deployment, not reconstructed after an incident. For organisations operating in regulated manufacturing sectors, this audit trail may also need to satisfy external requirements, which imposes additional constraints on retention periods, access controls, and data integrity verification.

The Operational Gap Between Task Adaptation and Outcome Ownership

General-purpose physical AI systems are marketed on their ability to adapt to new tasks with minimal reprogramming. That capability is genuine and represents a meaningful advance over traditional industrial robots, which require explicit programming for every motion. What it does not mean is that the system can be given a new task and trusted to own the outcome without validation. A model that has never encountered a specific product variant, a specific environmental configuration, or a specific failure mode will behave in ways that are difficult to predict from its performance on similar tasks. The distribution of real industrial tasks is long-tailed, and the tail is where failures concentrate.

The operational implication is that task adaptation capability shifts the validation burden rather than eliminating it. Instead of programming a new task, the team must define a validation protocol for each new task the system is asked to perform, characterise the conditions under which the system's performance is acceptable, and establish a monitoring regime to detect degradation over time. This is a different kind of work from traditional robot programming, but it is not less work, particularly in the early stages of deployment when the system's behaviour in the target environment is not yet well characterised. Organisations that treat general-purpose capability as a substitute for validation planning will discover the gap between task adaptation and outcome ownership at the worst possible time.

The Integration Architecture Decision

Before any of the above problems can be addressed in detail, the deployment team needs to resolve a foundational architectural question: how does the physical AI system connect to the existing operational technology stack. Most manufacturing environments run on a combination of PLCs, SCADA systems, MES platforms, and ERP integrations that were designed for deterministic, pre-programmed equipment. Introducing an AI system that generates variable outputs and requires bidirectional data exchange with these systems is not a plug-and-play integration. The communication protocols, data formats, and timing assumptions of OT systems are often incompatible with the interfaces that AI platforms expose, and bridging that gap requires engineering work that is specific to the site and the existing infrastructure.

The choice of integration architecture also has long-term consequences for system maintainability and vendor dependency. A tightly coupled integration where the physical AI platform is the only path through which certain operational data flows creates a single point of failure and a significant switching cost if the platform underperforms or the vendor changes pricing. A more loosely coupled architecture, where the AI system receives standardised inputs and produces standardised outputs that the existing OT stack can consume, is more resilient but typically requires more upfront engineering investment. For most industrial deployments, that investment is justified by the reduction in operational risk over a multi-year deployment horizon.