Getting Generative AI Past the Pilot

A striking number of enterprise generative AI projects reach a working demo and stop there. The model does the thing. Executives are impressed. Then eight months pass and it is still not in front of a customer.

The reasons are consistent, and almost none of them are about the model. They are about the difference between something that works when you try it and something an organisation is willing to be accountable for.

The pilot measured the wrong thing

Pilots are usually judged by whether the output looks good to the people who built it. That is a real signal and a weak one: it is a handful of examples, chosen by people who know what the system is good at, assessed by people who want it to work.

What production needs is a number you can defend. On a held-out set nobody tuned against, how often is the output acceptable, and what does the failure distribution look like? Not the average — the tail. A system that is excellent 95% of the time and confidently wrong 5% of the time is fine for drafting and unacceptable for anything a customer sees unreviewed.

Build the evaluation set before the pilot, not after. Two hundred real cases with agreed answers is enough to change the conversation, and gathering them forces the question of what correct means — which is usually the conversation the project has been avoiding.

Data access is the real critical path

The demo ran on an export somebody pulled. Production needs a live path to the same data, with permissions that match the user asking.

That is where the months go. The system has to respect the entitlements the source systems enforce, which means the retrieval layer needs identity context, not just a query. Teams that skip this build something that answers questions from documents the asker was never allowed to read, and discover it during security review.

Plan for the permission model in week one. It shapes the architecture, and it is the single most common cause of a pilot that cannot be promoted.

Nobody owns the output

Ask who is accountable when the system is wrong in front of a customer. In a stalled project, there is no answer.

This is an organisational blocker wearing technical clothing. It resolves by choosing a posture explicitly. Either a human approves before anything leaves the building, and you have designed a drafting tool with a review queue you must staff. Or the system acts unreviewed within a bounded scope, and you have accepted a defined error rate with a named owner and a rollback path.

Both are legitimate. What does not work is leaving it undecided, because an undecided system defaults to nobody approving the launch.

Cost arrives later than value

Pilot costs are trivial and misleading. Production costs scale with usage, and usage is the thing you were hoping for.

Model the unit economics before launch: tokens per interaction including retrieved context, interactions per user per day, and the realistic adoption curve. Then ask whether the value per interaction exceeds it. For workflows replacing skilled minutes, the answer is usually comfortable. For high-volume, low-value interactions it frequently is not, and the honest outcome is to narrow the scope rather than launch something that becomes a cost problem at exactly the moment it becomes popular.

The failure mode: the horizontal assistant

The most common shape that never ships is the general assistant for everyone. It has no owner, no evaluation set that means anything, no bounded failure mode and no obvious success measure. It demos beautifully because it demos on whatever the presenter asks.

Narrow systems ship. One workflow, one team, one measurable outcome. They are less impressive in a steering committee and enormously more likely to exist in six months. The organisation also learns something concrete, which the horizontal version never delivers.

When we would advise against building

If the workflow is fully specified and deterministic, generative AI is the wrong tool. Rules are cheaper, faster, testable and explainable. We have seen teams reach for a model to do work a decision table did better, largely because the model was the funded initiative.

Also stop if the underlying data is bad. A model over inconsistent, undocumented, contradictory source data produces fluent output built on it. The generative layer is not a data-quality strategy, and building it first tends to postpone the work that would actually help.

Security review will ask three things

Every enterprise GenAI launch meets a security review, and the questions are predictable enough to build for.

Where does the data go, and does the provider train on it? You need the contractual answer in writing, and the architectural answer — which fields leave your boundary, and which are redacted before they do.

What stops the system revealing something the user should not see? This is the entitlement question again, and it is where most reviews stall. "The prompt tells it not to" is not a control; the retrieval layer has to be incapable of returning the document.

What happens when someone tries to make it misbehave? You will be asked about prompt injection, particularly if the system reads untrusted content such as inbound email or uploaded files. The credible answer is architectural: the model has no authority to act on its own output, and every consequential action goes through a check that does not trust the text.

Answering these takes a week if the design anticipated them and a redesign if it did not.

What a shippable version looks like

One workflow with a named owner. An evaluation set built from real cases, run on every change. A permission model matching the source systems. A defined posture on review, with the queue staffed if a human is in the loop. Unit economics that hold at ten times current volume. And a kill switch someone is willing to use.

That list is unglamorous, and it is the difference between a pilot and a system. More on how we run this in AI engineering, and on the economics in what RAG costs in production.