The fastest way to stall a physical AI pilot is to loop safety in after the fact. If a system's outputs can ever influence a stop, a hold, or a maintenance action tied to a hazard, your EHS and safety engineering teams are stakeholders from day one — not reviewers at the end.
Separate perception from action, explicitly
The clearest way to get safety buy-in early is to draw a hard line between what the system perceives and what it's allowed to do about it. In an initial pilot, perception should run in a purely advisory mode: it can flag a risk to an operator or engineer, but nothing physical happens automatically. Only after a defined trust period — typically measured in weeks of matched predictions against real outcomes — should any automated action be considered, and even then, only within a scoped safety envelope your team defines, not the vendor's.
Ask for the evidence trail, not just the alert
Every flagged event should come with the underlying sensor evidence that triggered it, not just a notification. This matters for two reasons: your team can independently verify whether the flag was correct, and if an incident ever does occur, you have a documented, auditable trail of what the system perceived and when — which is exactly what an internal investigation or regulator will ask for.
Define the override path before you need it
Every automated hold or stop needs a documented, physically accessible override that doesn't depend on the AI vendor's system being reachable. This sounds obvious, but it's the single most common gap we see in early pilots — teams design the happy path in detail and leave the failure path as an afterthought.
Bring safety into the vendor conversation directly
The vendors worth working with will want your safety engineers in the room during scoping, not just procurement and operations. If a vendor resists that conversation, or can't clearly describe how their system fails safe when a sensor goes offline, that's a signal worth taking seriously before you sign anything.