On-Site vs Remote Delivery: When Do Enterprise AI Projects Need Engineers on the Ground?

Last winter, we had two RAG knowledge systems projects running in parallel. One at a precision manufacturing facility in Hsinchu, the other at a SaaS company in Taipei. Same tech stack, same team, same budget tier. The only difference: we embedded two engineers on-site for six weeks at the factory, while keeping the SaaS project fully remote.

Three months later, the manufacturing system went live and shop floor engineers were actually using it every day. The SaaS system? We delivered it beautifully via remote work, but the primary contact left the company, and the system sat unused.

This seems counterintuitive. Software companies should understand technology better, so remote should work more smoothly. But whether an AI project needs on-site engineering has nothing to do with the client's technical maturity. It depends entirely on how high the project's site-dependency density is.

Start with a framework you can use immediately

The dividing line between on-site and remote AI delivery is not project size. It's the strength of three signals: edge-case density, data sensitivity, and internal knowledge stickiness. If two of these are high, go on-site. If all three are low, remote is fine.

These three signals came from our experience across more than a dozen projects. Here's how each works.

Signal one: edge-case density

Edge-case density measures how heavily exceptions, situations outside the standard rules, factor into daily operations at a company.

SaaS support tickets follow a standard template 90% of the time. Exceptions are easy to categorize and label, so you can train remotely with a dataset pull. Manufacturing is different. A single "anomalous shutdown" splits into a dozen scenarios in a seasoned operator's head: tool wear, batch material issue, or vibration interference from an adjacent line? These branches never make it into SOPs. They live only in people's minds.

When edge-case density is high, the core problem with remote delivery is that you can't ask the right questions. Engineers on the other end of a screen only hear about the cases clients think matter, while the scenarios that actually break the system are always the ones nobody thought to mention. On-site, you overhear in the break room: "Oh that one? We just manually fix it."

Signal two: data sensitivity

This is the easiest signal to spot but often overlooked in importance.

Whether data can leave the premises determines where engineers work. Medical records, underwriting data, wafer yields, unreleased financials. This data usually stays locked to the internal network. Even a screenshot violates policy. Remote delivery turns into painful back-and-forth: the client runs a query, pastes results, you guess what went wrong remotely, and one iteration takes three days.

We saw this with a knowledge system at a healthcare organization. Two weeks remote, and each problem's verification cycle ran 48 hours minimum. Once an engineer brought a laptop into the hospital, sitting in their isolated network segment, we cleared the same batch of issues in a single afternoon. High data sensitivity does not necessarily mean hard technical work, but it almost always lengthens the remote feedback loop. Most AI projects fail because the feedback loop runs too long and the client loses patience before we've tuned it right.

Signal three: internal knowledge stickiness

This is the least visible signal, yet it most determines whether anyone actually uses the system after launch.

Internal knowledge stickiness measures how much undocumented, person-bound knowledge a system needs to absorb to be useful. Some processes are documented clearly in Confluence, so stickiness is low. Other critical decisions live only in senior staff intuition, so stickiness is high.

With high stickiness, remote delivery produces a system that's technically correct but operationally unrecognized. Adoption is fundamentally a trust problem. Whether people will delegate their judgment to the system depends on whether they witnessed its development. The real value of on-site engineers is not usually writing code. It's sitting beside users, feeding back each complaint of "that's wrong" into the model, while they watch the system improve day by day. You can't do this remotely.

All three signals in one table

The rule is simple: if two or more boxes align right, send engineers on-site. If all three align left, remote delivery is not only sufficient but also more economical. Forcing people on-site is just wasting everyone's time.

The overlooked middle ground

In practice, most projects are not black-and-white. They're "front-loaded, then lighter."

Our default now is this: for high-signal projects, go on-site for the first four to six weeks to excavate all edge cases, compress the data-verification loop to single-day turnaround, and build trust with power users. Once the system crosses the line of "someone uses it daily," shift back to remote for long-term operations and iteration. On-site work is not permanent residency. It's labor-intensive work through the riskiest, most location-dependent phase.

We do this because we believe one thing: a beautiful demo does not count. Launch with daily users is what counts. To move AI from demo to adoption, start with these three signals. Then decide whether to buy the plane ticket.