An impressive AI demo is easy to find. A prototype answers questions from company documents, an agent drafts tickets, a forecast looks sharp in a notebook — and months later, most of these systems are still demos.
Not because the model stopped working — because nobody ever drew the boundary between a thing that can work and a thing a business can depend on.
What the demo actually proves
A demo proves capability under favorable conditions: clean inputs, one happy path, a human watching who forgives mistakes. That is a real result, and it is worth getting to quickly.
But production asks different questions:
- Who owns the output? When the system drafts a wrong invoice or cites a policy that does not exist, whose decision was that?
- What happens on bad input? Real data arrives truncated, duplicated, stale, or adversarial. Demos run on the good rows.
- What does failure cost, and how is it noticed? A silent wrong answer is more expensive than a loud exception.
- What did it cost to run? Token spend, latency budgets, and infrastructure are invisible in a notebook and decisive in a budget review.
None of these are model questions. They are boundary questions: where the system starts and stops, what it may touch, who reviews it, and who is called when it drifts.
Boundaries we make explicit
When we take a prototype toward production, we write down five boundaries before scaling anything:
- Data access. Which sources the system reads, with what freshness, and who approved each one.
- Model authority. Decisions the model makes alone versus decisions that route to a human. This split is a product decision, not a technicality.
- Software responsibility. What ordinary code owns — validation, workflow state, integrations — so the model is used only where judgment is genuinely needed.
- Failure behavior. What the user sees when retrieval comes back empty, when the model is uncertain, when an upstream API is down.
- Ownership. One named owner per boundary. “The AI team” is not an owner.
Teams that skip this list do not avoid it. They discover each item as an incident.
The practical consequence
Framing the gap as a boundary problem changes where you invest. Instead of chasing another point of benchmark accuracy, you invest in evaluation against your own task, observability that notices drift before customers do, and software that degrades predictably.
That is unglamorous work. It is also the entire difference between a demo people remember and a system people rely on.
If you are holding a promising prototype and cannot name its five boundaries yet, that is the next milestone — not more model tuning.