Deployment Environment Test

Every AI feature assumes a deployment environment: network coverage, identity and who is permitted on, device capability, latency tolerance, and where data is allowed to live. The vendor does not own that environment, the buyer is rarely asked to provide it, and a demo does not test it.

The test is two questions, asked early enough to matter. They are the same two questions from either side of the table.

The two questions

Who will use this? A building holds three populations: the people who work in it, the people who work on it, and the people it works for. Connectivity was provisioned for the first. AI features are increasingly built for all three.

Where? At a desk, in covered space, on the floors that got a coverage heat map. Or in the plant room, the sub-basement, the loading dock, the shaft, the field.

If the answer is your own staff at their desks, there is no problem to solve. That covers a great deal of enterprise AI and it is worth establishing before anybody spends a sprint on it.

Exposure begins when either answer moves. Staff in the hard rooms fail on coverage: they belong to the network and cannot reach it. Non-staff anywhere fail on membership: they can reach the signal and are not permitted on it.

The four follow-ups

Once either answer has moved, four questions make the dependency specific.

Which parts run in the cloud, which on the device, and which need something else on site?
What does the feature do when it cannot reach the model? A clear failure is a design decision. A spinner is the absence of one.
Does authentication survive the same conditions?
Whose budget does the assumption land in, and has it been said out loud?
When to run it

In the demo, not the pilot. The pilot will be run by enthusiasts in good conditions, it will succeed, and the requirement will still be invisible at signature. In the demo the answer costs a conversation. After signature it is a variation order or a deployment nobody uses.