A working AI demo can hide a lot of unfinished engineering.
That is the part I keep coming back to when people ask why enterprise AI POCs do not automatically become production systems.
The POC usually proves one narrow thing: the model can do something useful with a controlled input.
Production asks a different set of questions.
Who is allowed to use it?
What data can each user see?
Where does the workload run?
What happens when a dependency is unavailable?
How do we know a prompt, model, document, or retrieval change did not make the behavior worse?
Who owns the cost?
Who gets paged when it fails?
Those questions are not model questions. They are system questions.
That is why the gap between POC and production feels familiar to me from platform engineering.
A cloud application that works in one developer account is not automatically an enterprise platform either. Before teams depend on it, identity, networking, policy, observability, delivery, recovery, cost, support, and ownership have to become explicit.
AI adds another set of moving parts on top of that.
A RAG demo may use a small clean document set. Production has to deal with document lifecycle, permissions, stale content, parsing failures, retrieval quality, citations, and users who are allowed to see different evidence.
An agent demo may successfully call a tool. Production has to decide which tools are available for which principal, validate the arguments, control credentials, handle retries, trace what happened, and put approval around high-impact actions.
A model endpoint may respond correctly in a test. Production still has latency, concurrency, quotas, failure handling, rollout, rollback, and cost to manage.
None of this means every AI experiment needs a giant platform before anyone can learn from it.
It means I want to know which production constraints matter before the architecture becomes difficult to change.
I usually ask a few questions early:
- What business workflow is this changing?
- What data does it require?
- Who can see or change that data?
- What happens when the answer is wrong?
- What latency and availability actually matter?
- How will we evaluate a change?
- Who owns the service after the demo?
- What will make us stop the experiment?
That last question matters too.
Sometimes the problem is not that the team failed to productionize a good AI idea.
Sometimes AI was the wrong system in the first place.
A deterministic rule, a search index, SQL, a workflow engine, or traditional ML may solve the problem with less cost and less behavioral uncertainty.
So for me the first production decision is not which model to use.
It is whether the problem deserves this kind of system at all.
The rest of this series is about that path: choosing the problem, letting constraints shape the architecture, getting the system into production, and then proving that it still behaves the way we expect after it changes.