A vision system for defect detection goes live on a packaging line after two training calls and a shared login. Three weeks in, it starts flagging good product as defective, and only on the night shift, the one shift nobody ran the demo on. The vendor's fix arrives by email: adjust a threshold value in a settings panel. Nobody who wrote that email has stood on that line.
A July 2026 Manufacturing Digital roundup on physical AI and supply chain names a shift already underway at Hitachi: sending engineers to work alongside customer operations teams on-site for physical AI deployments, instead of handing over a system and a support queue. The role has a name borrowed from enterprise software, Forward Deployed Engineer, and it matters more on a factory floor than it ever did rendering a dashboard in a browser.
Physical AI is AI that perceives and acts in physical space, machine vision on a line, robotics, predictive maintenance sensors, instead of only processing data behind a screen. A misconfigured dashboard produces a wrong number someone can quietly correct later. A misconfigured physical AI system produces a wrong physical action on your product, in front of your operators, at your line speed. That difference is why the SaaS deployment model doesn't transfer.
Board conversations about physical AI still default to the software playbook: pick a vendor, sign a contract, get a login, ramp usage over a quarter. That playbook works for a CRM. It assumes the product behaves the same in every environment it's installed in. A vision system doesn't. Line speed, lighting, product variance, and shift patterns differ at every site, and sometimes differ on the same line between a 6am run and a 2pm run. A team calibrating against a demo video has no way to see that variance, let alone correct for it, before it starts producing false positives your operators quietly learn to route around.
From the work
Written from 5+ manufacturing deployment engagements across Business Central, Epicor, and Infor environments, 2022–2026, where deployment failed or succeeded based on how much time was spent on the floor before configuration started.
Why physical AI manufacturing deployment fails when delivery stays remote
The failure isn't in the model's accuracy. Most physical AI systems ship with genuinely strong out-of-box detection rates on the manufacturer's own test data. The failure shows up in the gap between that test data and your floor: a different camera angle than the reference install, a product SKU with more surface variance than the ones the model was tuned on, a shift that runs the line ten percent faster to hit a Friday cutoff. None of that shows up in a spec sheet. All of it shows up the first week the system runs unsupervised.
An operator recognizes this failure by its symptoms, not by a root-cause report: alerts that cluster around a specific shift or time of day, a "temporary" manual override that quietly becomes the permanent process, a supervisor who stops trusting the system's flags and starts double-checking everything it approves. Each of those is cheaper to prevent during deployment than to unwind six months later, once the operators have already decided the system doesn't work and stopped reporting problems to anyone who could fix them.
The cost compounds because trust, once lost on a floor, doesn't reset with a software patch. A supervisor who caught the system wrong twice will keep checking its output manually for months after the underlying issue is fixed, because the fix arrived by email from someone they've never met.
What Hitachi's Forward Deployed Engineers model confirms about physical AI deployment
The Forward Deployed Engineer title started in enterprise software, built to solve a version of the same problem: a product too complex to configure correctly from a features list alone, deployed into environments the vendor's engineering team had never seen. What Hitachi's move into physical AI confirms is that the problem gets harder, not easier, once the AI is acting on a physical process instead of a data pipeline. A misread signal in a data pipeline gets logged and reviewed. A misread signal on a packaging line produces a defective unit that's already shipped by the time anyone reviews it.
The pattern matters less as a single vendor's org chart decision and more as an industry admission: physical AI vendors are discovering that domain expertise on-site isn't a service add-on, it's the deployment mechanism. Software can be documented well enough to onboard remotely. A shop floor's specific combination of line speed, product mix, and shift culture can't be captured in documentation someone reads before they've seen it.
IQ's 2-week embedded deployment model, across Business Central, Epicor, Infor, and custom ERPs
The embedded model isn't a slower version of a remote rollout. It's a different sequence: floor time before configuration, not configuration followed by a floor visit if something breaks.
The engagement starts on the floor, not in a project kickoff deck. That means shadowing shift supervisors through a full changeover, watching how a production order actually moves against how it's recorded in Business Central, Epicor, Infor, or whatever custom ERP is running the plant, and documenting every place the physical process and the system of record already disagree. Most plants have three or four of these gaps running quietly for years: a scrap rate that's tracked differently than it's counted, a changeover time that's faster on paper than on the floor.
This week produces a specific, site-level list, not a generic requirements doc. It's the difference between configuring against what the ERP says happens and configuring against what a supervisor who's run this line for six years says actually happens.
Configuration happens against live production data, with the operators who'll use the system in the room, not a lab environment built from a sample dataset. Every threshold gets checked against a real shift, including the one the vendor's demo skipped. The system runs in parallel with the existing manual process until the operators, not the deployment team, confirm it's catching what they'd have caught themselves.
The engagement closes with a named handoff to a specific process owner inside the plant, someone who watched the configuration happen and can explain a threshold decision six months from now without opening a ticket. There's no "the vendor will get back to you" step. The person who can answer the question already works there.
Two weeks is short enough to keep the deployment tied to one plant's actual conditions and long enough to catch the shift-pattern and product-variance gaps that only show up once you've watched a full production cycle, not a demo run.
| Deployment dimension | Remote software delivery | Embedded deployment |
|---|---|---|
| Week 1 activity | Kickoff call, requirements doc, demo environment | On-site shadowing of shift supervisors and live ERP data |
| Who calibrates the system | Vendor engineer working from a spec sheet | Vendor engineer working from what the floor actually does |
| Shift-pattern variance | Discovered after go-live, via support ticket | Mapped in week one, before configuration starts |
| Validation | Vendor's own test data | Parallel run, confirmed by the operators who'll use it |
| Handoff | Support ticket queue | Named process owner, present during configuration |
The deployment mechanism is what makes physical AI a decision infrastructure question and not just a model-accuracy question. A system that's correctly calibrated but has no named owner on the floor is the same underlying gap covered in decision infrastructure vs. decision intelligence: the technology can be right and the outcome still fails, because nobody owns what happens after the signal fires.
Frequently asked questions
What is physical AI and how is deploying it different from software AI in manufacturing?
Physical AI is AI that perceives and acts in physical space, machine vision on a packaging line, robotics, predictive maintenance sensors, instead of only processing data behind a screen. A misconfigured dashboard produces a wrong number someone can quietly correct. A misconfigured physical AI system produces a wrong physical action on your product, in front of your operators, at your line speed. That difference is why the SaaS deployment model, a login and a support ticket queue, doesn't transfer.
Why can't physical AI be deployed remotely in manufacturing?
Because the variables that determine whether it works, line speed, lighting, product variance, shift patterns, are different at every site and sometimes different on the same line between a 6am and a 2pm shift. A remote team calibrating against a demo video or a spec sheet has no way to observe that variance or catch it before it produces false positives on the floor. Someone has to be present to see the gap between what the system was configured for and what the floor actually does.
What does an embedded physical AI deployment actually involve?
Direct time on the floor before configuration starts: shadowing shift supervisors, watching how a production order actually moves versus how the ERP records it, and identifying where the physical process and the system of record already disagree. Configuration then happens against live data with the operators who will use the system in the room, not a lab environment or a demo dataset, followed by a named handoff to a specific process owner rather than a support ticket queue.
How long does an embedded physical AI deployment take?
IntelliConnectQ runs a 2-week embedded model: week one is on-site discovery and shadowing against the live ERP environment (Business Central, Epicor, Infor, or a custom system), week two is configuration and validation with the actual operators and a named handoff. The timeline is short because the person doing the configuring is the same person who spent week one learning what the floor actually does, not a second team working from someone else's notes.
The deployment model is the decision infrastructure question
The Hitachi shift is a data point, not a strategy. What it confirms is something operators already sense every time a vendor demo runs perfectly and the production install doesn't: physical AI's hardest problem was never the model. It's who's standing on the floor when the model meets a shift, a product variant, and a supervisor it's never seen before.