From AI proof of concept to production: what enterprises actually need

Building an impressive AI demonstration has become genuinely easy. A capable engineer can connect a model to a sample of company documents and produce something that surprises a leadership team inside a week. That experience is real, and it is also misleading, because almost none of the work that makes such a system dependable has been done yet.

The gap between the two is not a matter of polish. It is a specific set of engineering problems, and they are the same problems in most organisations.

Why demos are easy

A demo benefits from conditions that do not survive contact with production. The inputs are chosen, usually implicitly - the examples that worked are the ones that got shown. The data is a snapshot, clean enough because someone prepared it. There is one user, who knows what the system can handle. Failure is recoverable, because nothing depends on the output. And nobody has yet asked what happens to the cases the demo did not cover.

Production removes every one of those conditions at once.

Data: the constraint that decides feasibility

AI systems inherit the quality of the data they read, and present the result with the same confidence regardless.

In a pilot, someone exported a clean set of documents or records. In production the system reads from live sources containing duplicates, records that contradict each other, fields used for a purpose other than their label, and documents that were superseded but never removed. A retrieval system that surfaces an outdated policy is not making a mistake by its own logic - it found a matching document.

This has to be handled deliberately: deciding which source is authoritative for each type of information, excluding what is known to be stale, and accepting that some categories of question cannot be answered reliably until the underlying data is fixed.

Where the data foundation is the real constraint, the honest first project is a data project. That conversation is uncomfortable and considerably cheaper than discovering it in month five.

Integration: from an extract to the live business

A pilot reads a copy. A production system has to read the systems of record - ERP, CRM, document stores, internal applications - continuously and reliably.

That brings ordinary engineering problems that have nothing to do with AI: rate limits, authentication, schema changes made without notice, systems that are slow at month end, and network partitions. It also brings a design question about freshness: how recent must the information be for the answer to be safe to act on?

In practice, integration and data plumbing are usually the largest share of the engineering effort in a production AI system. The model is rarely the expensive part.

Permissions: the requirement most pilots ignore

In a pilot everyone sees everything. In production that is unacceptable, and retrofitting the fix is difficult.

The principle is simple to state: a user should never learn something through an AI system that they could not access directly. Implementing it means the system must evaluate access at query time, per user, against the permission model that already exists - not filter results afterwards, and not maintain a second copy of the access rules that will drift.

Related decisions belong to the business rather than to engineering: which data the system may read at all, whether inputs and outputs are retained, for how long, and who can review them. These should be recorded as decisions, not settings.

Evaluation: the difference between opinion and knowledge

This is the discipline that most clearly separates teams that ship AI successfully from teams that do not.

Traditional tests assert that a function returns an expected value. AI outputs do not work that way: there are many acceptable answers and many unacceptable ones, and the difference is often judgement. Without a systematic way to measure quality, every change becomes a matter of impression - and impressions are dominated by whatever was tried most recently.

A working evaluation setup has a few components. A representative case set of real inputs, including the ambiguous and awkward ones, with an agreed view of what a good response looks like. Explicit quality dimensions - correctness, completeness, tone, appropriate refusal, handling of uncertainty - scored separately, because collapsing them into one number hides exactly the regressions that matter. Repeatable execution, so that any change can be compared against the previous version. And a combination of automated scoring for coverage with human review for the cases automation judges poorly.

Building this is unglamorous and it is the investment that compounds. It converts “the new version feels better” into “the new version is better on these dimensions and worse on that one”.

Reliability and observability

Production systems need defined behaviour when things go wrong: when the model is slow, unavailable, returns something unusable, or produces output that fails validation. The unacceptable outcome is a system that silently substitutes a wrong answer for a missing one.

Observability for AI systems covers the usual operational signals - latency, error rates, throughput - plus several that are specific: cost per outcome, the distribution of inputs compared with what was evaluated, rates of fallback and escalation, and user behaviour such as how often a suggestion is accepted, edited or discarded. That last signal is frequently the most informative quality measure available, and it is free.

Something else changes in AI systems: the dependency can move underneath you. Model providers update models, and behaviour can shift without any change on your side. Continuous evaluation is what detects this. Without it, a system can degrade for weeks before anyone notices.

Human oversight as a design decision

The question is not whether to involve people, but where - and that should follow from the cost of being wrong.

Where errors are cheap and visible, full automation with sampling is reasonable. Where errors are expensive or hard to detect, a review step belongs in the flow. Where the decision carries regulatory or contractual weight, the system should assemble evidence and prepare a recommendation while a person decides.

Review has to be designed properly or it becomes theatre. A reviewer presented with a hundred items and no context will approve all of them. Useful review gives the reviewer what they need to judge quickly, shows the system's confidence and its sources, makes rejection as easy as approval, and captures the rejections as evaluation data.

Workflow design: where the value is won or lost

Most AI systems that fail in enterprises fail on adoption rather than on quality. A capable assistant that lives in a separate tab, which people must remember to open, will be abandoned within weeks.

The systems that survive are embedded where the work already happens - in the CRM, the internal application, the ticketing system, the inbox - and they fit the existing shape of the task rather than asking people to change how they work in order to receive help.

Ownership and measuring value

Two questions should be answered before a pilot begins, not after it succeeds. Who owns this system once the project ends? And how will we know whether it was worth it?

Ownership means a named team responsible for the evaluation set, the monitoring, the cost and the decision about when to change models. AI systems require more ongoing attention than conventional software because their environment changes independently of them.

Value measurement should be defined at the start, in the terms the process already uses: time per case, cases handled per person, error rates, cycle time, or the share of work completed without escalation. Defining the measure early also protects against the opposite failure - a system that is technically impressive, genuinely used, and not actually worth its running cost.

Related reading

• AI & Automation - how we build production AI systems
• AI product & evaluation systems - experience in AI testing and evaluation