Has your AI provider ever stood on a shop floor?

Most AI providers can show you a convincing demonstration on a laptop. Fewer have watched that demonstration meet a loading bay at six in the morning, with a scanner in one hand, a glove on the other and no signal past the third aisle. For work that happens away from a desk, that difference decides the project, and it is visible in the first meeting if you know what to ask.

First, check that you need a field specialist

Not every system used outside head office is a field system. If the people who will use it sit at desks with reliable connectivity, this is ordinary application engineering, and you should buy it as such.

You are in the field when the work happens on a shop floor, in a vehicle, on a construction site, at a substation or out in the fields; when connectivity is patchy and the current answer is paper; when an office-built system has already been rejected by the people who were meant to use it; or when inference has to run locally because of latency, cost or where the data is allowed to go.

And one boundary worth knowing before any meeting: if the system has to act on equipment inside a safety function, you need a specialist supplier working under functional-safety obligations. A provider that offers to do that as part of a business-system project is telling you something useful about itself.

The questions that separate the two

“When do you come to site, and for how long?” The right answer is before anything is specified, for at least part of a shift, with the people who will use it. If the site visit is scheduled for installation week, the requirements were written in a meeting room.

“What happens when the connection drops halfway through a task?” Listen for local storage, queued operations, conflict rules decided in advance, and an interface that always shows whether something has synced. Be wary of “the system retries” — that is a system treating offline as an error, and it fails in its first bad week.

“Which hardware do you recommend, and do you sell it?” A provider with a hardware margin has a reason to recommend hardware. One without can let the environment decide — rugged tablet, industrial handheld, phone in a case, fixed panel — and should be able to say why.

“How will the devices be managed a year from now?” Enrolment, updates, remote wipe, health monitoring. If the answer is that your IT team will handle it, ask whether anybody has asked your IT team.

“What does the pilot look like?” One crew or one line, watched closely, with a route back to the old process. A pilot that goes to every site at once is a rollout under another name.

“What will you do if the crew rejects it?” A good answer describes the route back and how complaints will turn into changes to the system. A weak one describes more training.

“What is your definition of done?” The useful answer is not a feature list. It is that a crew can complete a full shift without having to think about the system.

Infographic

Questions for the first meeting

  • Site visit timingBefore specification, with the crew who will use it.
  • Dropped connectionLocal storage, queued operations, conflict rules, visible sync state.
  • Hardware independenceThe environment chooses the device, not a reseller margin.
  • Device managementEnrolment, updates, remote wipe and health monitoring, with a named owner.
  • Pilot shapeOne crew or one line, with a route back.
  • Definition of doneA full shift completed without thinking about the system.
  • Safety boundaryA clear no for anything inside a safety function.
Every answer should be specific. A general reassurance is also an answer.

What it will cost you in attention

A field project asks more of the operation than an office one does, and it is better to budget for that openly. Expect to provide access to a site and a crew, an operations lead who can make decisions about the process, someone from IT for devices and networks, and patience during a pilot that will generate complaints.

Those complaints are the point. A provider who treats them as noise will build the same system for the rollout. One who treats them as the specification will build a better one.

Warning signs

A proposal with screenshots and no site assessment. An architecture that assumes a connection everywhere. A plan with no line for device management. A timeline in which the site work is a footnote, although it is usually the part that gets underestimated. And any confident claim about how a model will perform on the device that was taken from a datasheet rather than measured in your conditions.

Where we stand

In field deployment AI engineering we answer these questions the way we would want them answered: site first, offline as the normal state, no hardware resale, one crew before everybody, and a clear no for anything inside a safety function. Our systems read and advise; they do not actuate.