The easy part is the part everyone sees

Here is the claim worth arguing: the API call is the cheapest, easiest, most visible five percent of an enterprise GenAI system, and treating it as the project is why so many of these systems impress in a demo and disappoint in production.

Adopting a large language model has never been easier. A developer signs up, pastes a key, and within an hour has something that answers questions in fluent prose about the company’s own documents. The speed is real and it is seductive, and it produces a particular illusion: that because the hard-looking part, the model, arrived ready-made, the system is largely built. It is not. The model is the one part you did not have to build. Everything that makes it safe, correct, affordable and durable in your specific setting is still ahead of you, and almost none of it is visible in the demo that got the project funded.

What the demo does not show

A demo runs once, for a friendly audience, on a question someone chose. Production runs continuously, for strangers, on questions nobody anticipated, and the gap between those two conditions is where the real work lives.

The demo does not show what happens when the source documents go stale and the system keeps answering confidently from last quarter’s policy. It does not show the cost when a hundred internal users become ten thousand and every query bills by the token. It does not show the wrong-but-fluent answer that no one catches because it arrived with a citation attached. It does not show the question the system handles badly, because nobody asked it on stage. The demo is an existence proof that the easy part works. It says nothing about the expensive part, which is keeping it working, correctly, for everyone, at cost, for years.

Two failures that arrive before a line of code

In practice the trouble usually starts before any engineering, in two decisions that are not technical at all.

The first is who is doing the evaluating. The field has changed in a way the org charts have not caught up with: many capable people now working with data and models arrived from other roles, and the tooling has made it possible to produce a working pipeline without the background that lets you interrogate it. A developer can call an embedding model without knowing what an embedding is, deploy a forecast without knowing what stationarity assumes, or ship a classifier without knowing what its confidence score does and does not mean. This is not a failing of the individuals, who are often excellent at the building. It is a structural gap: the libraries advanced faster than the understanding required to question their output, and a system nobody on the team can evaluate is a system running on hope.

The second is who priced the life of the thing. Enthusiasm for new technology is an asset, and development teams are right to want to work with it; the failure is when management, reasonably trusting that enthusiasm, approves a build whose ongoing cost and maintenance were never put on the table. RAG is the clearest case. A team scopes the retriever, ships the pilot, and only later discovers the parts no one estimated: the documents must be re-indexed as they change, the chunks re-embedded when the model updates, the retrieval quality re-evaluated as the corpus grows, the token bill watched as usage climbs, and someone must own all of it indefinitely. None of that appears in the cost of the API call. All of it appears in the cost of the system, and discovering it after launch is how a project that looked cheap becomes one that cannot be afforded or maintained.

The iceberg, named

If it helps to make the invisible part concrete, here is what sits beneath the call, roughly in the order it bites:

The data you feed it: its quality, its freshness, who is allowed to write to it, and who keeps it current. The evaluation: how you know, in numbers, whether answers are right, and who looks when they are not. The cost model: what a query costs now that it scales, and what you do when it climbs. The failure modes: the stale source, the confident-wrong answer, the question outside the system’s competence, and what each one does to whoever is on the other end. The maintenance: the re-indexing, re-embedding, re-evaluation and retraining that a living system needs, with an owner and a schedule. And the accountability: who decided this was fit to ship, on what evidence, and who answers when it is wrong. The API gives you none of these. They are the project.

Why this matters more for GenAI than for the software before it

Worth being fair to the obvious objection: every technology looks easy in a demo and harder in production, so what is special here? Two things. First, the gap between how easy GenAI is to start and how hard it is to run well is wider than almost any technology before it, because the starting cost has fallen nearly to zero while the running discipline has not fallen at all. Second, the failure is quieter. A traditional system that breaks tends to stop, visibly; a GenAI system that is failing keeps producing fluent, plausible, confident output while being wrong, and a failure that does not announce itself is one an organisation can run on for a long time before it learns the cost. The ease hides the difficulty, and the fluency hides the failure. That combination is what makes this worth saying out loud.

The line worth keeping

GenAI rewards the organisation that treats the model as the beginning of the work and frustrates the one that treats it as the end of it. Calling the API is not the project: it is the moment the project becomes possible, and everything that determines whether it succeeds (the data, the evaluation, the cost, the failure modes, the maintenance, the accountability) is the part that was always going to be hard and is still, reliably, where the difficulty lives. The technique is mature. The discipline of running it well is the part still being learned, and the part worth building before you ship.

So before your team celebrates the working demo, ask the question the demo cannot answer: not whether you can call the model, but whether you have costed, evaluated, and assigned an owner to everything that has to be true for the answer to be right at scale, for someone you will never meet. Who owns that, and did anyone price it before you began?