Physical AI is often presented as the next stage of artificial intelligence: software that does not merely generate information but perceives conditions, makes decisions and influences machines or devices in the physical world. In the context of Embedd’s reported work, the term points particularly to the software infrastructure connecting AI capabilities with semiconductor-based hardware.
That distinction matters for industrial technology leaders. An AI-enabled machine is not a conventional software purchase. Its performance depends on processors, sensors, firmware, operating environments, communications and mechanical systems as well as models and applications. Failures can interrupt production, damage equipment or create safety risks. The relevant buying question is therefore not simply, “How capable is the AI?” It is, “Can the complete system be deployed, supported and changed reliably in our operating environment?”
EU-Startups reports that London-based Embedd raised €2.3 million to build software infrastructure for physical AI. The company provides a useful news hook for a wider procurement issue: infrastructure between AI software and physical hardware can determine how quickly projects move from demonstration to dependable operation. The funding announcement does not establish that one architecture or supplier is superior. It does highlight an infrastructure layer that industrial adopters should examine explicitly.
Start with the device and semiconductor boundary
Physical-AI due diligence should begin below the application layer. Buyers need an inventory of the target device’s processors, accelerators, microcontrollers, sensors, interfaces, firmware and operating systems. The supplier should identify which combinations it supports today, which are experimental and which require custom engineering.
Ask whether models run on the device, at an edge server, in the cloud or across several layers. Each choice changes latency, connectivity, data governance, energy consumption and recovery behaviour. A cloud-dependent design may be unsuitable where connectivity is intermittent or split-second responses are required. Fully on-device execution can improve autonomy but impose memory, thermal and compute constraints.
Compatibility claims require precision. “Supports the chipset family” is less useful than a tested matrix listing processor variants, board configurations, drivers, firmware versions and model formats. Establish who maintains drivers and hardware abstraction layers, and how quickly support follows a semiconductor vendor’s new release. A technically impressive application can become stranded if a required chip is discontinued, its toolchain changes or replacement boards behave differently.
Procurement teams should also map concentration risk. Determine whether the system depends on one accelerator vendor, proprietary compiler, device-management service or model runtime. Portability may cost more initially, but an architecture tightly bound to one semiconductor stack can increase redesign costs and weaken negotiating leverage later.
Inspect integration as a system, not an API
A laboratory device can appear self-contained; an industrial deployment rarely is. Physical AI may need to exchange data or commands with programmable logic controllers, supervisory control systems, manufacturing execution systems, maintenance platforms, identity services and data historians. Integration assessment must cover timing and operational authority, not only whether an API exists.
Document every input, output and dependency. Which system remains the authoritative source for production state? What happens when sensor timestamps differ? Can an AI recommendation be reviewed before execution, or does it directly control equipment? How are conflicting commands resolved? The answers should be expressed in interface specifications and failure-state diagrams.
Legacy equipment deserves particular attention. Older machines may use proprietary protocols, undocumented interfaces or control cycles that cannot tolerate additional latency. A gateway may bridge the gap, but it creates another component to secure, monitor and maintain. Before approving a pilot, estimate the engineering effort required for each machine type rather than extrapolating from the easiest integration.
Cybersecurity boundaries also shift when software can cause physical action. Require device identity, authenticated communications, role-based access, signed software, audit logs and a method for revoking compromised credentials. Network segmentation and safe local operation should be evaluated together: isolating a device must not leave machinery in an unsafe or undefined state.
Test where physical variability appears
Model accuracy measured on a curated dataset is not sufficient evidence of operational reliability. Real facilities introduce dust, glare, vibration, temperature changes, radio interference, worn components, unusual materials and inconsistent human behaviour. Tests should reproduce the operating envelope and its difficult edges.
Define acceptance criteria before deployment. Relevant measures may include false interventions, missed events, response latency, uptime, recovery time and performance across shifts or product variants. The appropriate metrics depend on the machine’s function and the consequences of an error. Include conventional controls or human procedures as baselines rather than evaluating the AI only against its own prior version.
Testing should progress from simulation and bench work to shadow mode, constrained operation and wider release. In shadow mode, the system observes and records proposed actions without controlling machinery. This can reveal distribution shifts and integration defects while limiting operational exposure. Constrained operation can then restrict speed, workspace, product types or decision authority until evidence supports expansion.
Demand tests of failure behaviour as well as normal performance. Disconnect networks, degrade sensor signals, exhaust storage, restart components and introduce incompatible data. Verify that the system fails safely, alerts the right person and preserves enough diagnostic information for investigation. For safety-relevant applications, independent engineering and compliance review may be necessary; supplier demonstrations are not a substitute.
Treat updates as operational changes
Physical-AI systems combine model versions, application code, runtimes, drivers, firmware and device configurations. Updating one layer can alter another. A model optimisation may change processor load; new firmware may affect sensor timing; a security patch may break a driver. Buyers need a versioned bill of materials and a compatibility policy covering the complete stack.
Ask how updates are signed, staged, monitored and rolled back. Can deployments be released to a small device group first? Is there an offline update method for restricted sites? What happens if power or connectivity fails mid-update? A rollback mechanism should restore a known-good combination, not merely an earlier application package.
Maintenance planning must include model behaviour. Define who detects drift, approves retraining and validates a changed model against operational and safety criteria. Logs should make it possible to reconstruct which software, firmware, model and configuration were active during an incident. Data retention should balance troubleshooting needs with confidentiality, privacy and storage limits.
Lifecycle commitments belong in the contract. Seek support periods for hardware variants, security-patch response expectations, end-of-life notice, migration assistance and access to documentation. Infrastructure choices affect scale because a fleet of heterogeneous devices can multiply validation work. Standardised deployment and observability can reduce that burden, but only if they genuinely support the adopter’s hardware mix.
Evaluate operating capability and supplier dependence
Physical AI needs joint ownership across operations, controls engineering, IT, cybersecurity, safety, maintenance and data or machine-learning teams. Assign responsibility for first-line diagnosis and clarify escalation paths. A system that requires scarce supplier engineers for routine configuration may remain a prolonged pilot even if its technical performance is acceptable.
Assess the internal skills needed to reproduce a deployment, interpret telemetry, replace hardware and recover after failure. Training should use realistic incidents, not only installation workflows. Spare-device strategy and maintenance procedures should reflect the possibility that a failed board may arrive with a different firmware or processor revision.
Supplier evaluation should separate current product capability from roadmap promises. Request architecture documentation, supported-hardware lists, reference deployments relevant to comparable conditions and evidence of release discipline. Review financial and organisational continuity without treating Embedd’s reported funding—or any funding announcement—as proof of technical superiority, long-term viability or deployment results.
Finally, identify exit paths. Can configurations, logs and models be exported in usable formats? Can another team maintain deployed devices? Which components are proprietary, and what must be rebuilt if the supplier changes direction? Source escrow, documentation rights or transition assistance may be appropriate for operationally critical systems.
A deployment gate for industrial adopters
Before moving beyond a controlled pilot, require clear answers to these questions:
- Is every processor, device, firmware and operating-system combination documented and tested?
- Can the system meet latency, connectivity, energy and data-location requirements?
- Are interfaces, command authority and safe failure states defined?
- Has performance been validated under realistic environmental and operational variation?
- Can updates be staged, audited and rolled back across the full software-hardware stack?
- Are drift monitoring, incident reconstruction and lifecycle ownership assigned?
- Can internal teams diagnose common faults and replace devices without exceptional supplier support?
- Are semiconductor concentration, supplier lock-in and end-of-life migration risks acceptable?
A successful evaluation should produce more than a model score or demonstration. It should yield a verified compatibility matrix, integration design, field-test record, maintenance plan and credible exit route. That evidence allows leaders to compare physical-AI projects on deployment time, operational resilience and fleet-scale support—not on AI capability alone.
