How to run an AI proof of concept that makes it to production

An AI proof of concept is a short, timeboxed test that answers one question with evidence: can AI handle this specific task well enough, on your real data, at a cost that could work in production? It is not a demo. A demo shows that something is possible. A proof of concept shows how often it works, where it fails, and what each run costs.

Run one when the answer is genuinely uncertain: messy inputs, unclear accuracy, unknown cost, or a workflow where mistakes matter. Skip it when the task is well understood and low risk, and build a small first version instead.

The proofs of concept that turn into systems are designed backwards from production. Pick a workflow someone will own, define pass and fail before writing code, test on the hard cases, and include a thin version of the integration. That is the difference between a system and a slide.

These terms get used interchangeably, which is how projects end up with a celebrated pilot and no plan. Each stage answers a different question and needs different evidence before you move on.

A proof of concept tests feasibility against a fixed set of real examples. A pilot tests the system inside the real workflow with real users, often in shadow mode, where its outputs are compared with what people actually did. An MVP is the smallest version you can run in production and support. Production adds the operating discipline to keep it working as inputs, models, and volume change. The table below sets out what each stage should prove.

Pick a use case that will matter if it works and can be judged quickly. Avoid starting with the most visible or most regulated workflow. Start with one where you can learn fast and recover from mistakes. Good candidates share these traits:

• Volume: the task happens hundreds of times a month, so small gains add up.
• A baseline: you know roughly how long it takes and how often it goes wrong today.
• Clear boundaries: inputs and correct outputs can be defined. Improve customer experience is not a use case; classify and route inbound support email is.
• Reachable data: you can get real examples and system access in the first week.
• Recoverable errors: a review step can catch mistakes before they reach a customer or a ledger.
• An owner: a named person or team who will run it in production if it works.

Write down what pass and fail look like before anyone writes a prompt. Otherwise the criteria drift toward whatever the demo happens to do well. Anthropic's evaluation guidance frames good criteria as specific, measurable, achievable, and relevant to the job, which is a useful test for each line you write.

Set an agreed threshold for each of these:

• Accuracy on the evaluation set, broken out by case type rather than one overall score.
• Review rate: the share of cases a person must check or correct.
• Time per case compared with the current process.
• Cost per transaction at expected production volume, including retries.
• Latency, when a person or customer is waiting on the answer.
• Hard limits: things the system must never do, such as quote a price, give legal advice, or write to a ledger without approval.

An evaluation set is a fixed collection of real inputs with known correct outputs, run against the system after every change. It turns looks good into a number that moves up or down. OpenAI's accuracy guidance makes the same starting point explicit: a prompt plus an evaluation set with ground-truth answers, before deciding whether the fix is better context or a different model.

Build it from production data, not hand-picked examples. Pull a random sample, then add the worst cases operators complain about: the scanned PDF, the email with three requests in it, the customer who writes in another language. Have the people who do the work label the correct answer. Roughly a hundred examples graded on a simple rubric is a reasonable start; add cases as you find new failure types.

Automate grading where you can: exact match for extracted fields, rules for formats, and a model-based grader checked against human labels for open-ended text. Hold back a slice that the person tuning prompts never sees. Real data often contains personal information, so agree on where it is stored and who can access it before the work starts.

A proof of concept needs a fixed end date and a decision at the end. This is the plan we would start with for a single workflow. Adjust the length to data access and review capacity, not to the enthusiasm in the room.

1. Before day one: name the production owner, get data access and security approval, and write the success criteria.
2. Week 1: build the evaluation set from real data and measure the current process as a baseline.
3. Week 2: build a first version with two or three candidate approaches or models, and score each against the evaluation set.
4. Week 3: study the failures, improve retrieval, instructions, or validation, rescore, and add a review path for low-confidence cases.
5. Week 4: connect a thin integration that reads from a real input and writes to a real destination in a test environment. Measure cost per transaction and latency.
6. Week 5: run in shadow on live inputs where possible, compare with what people did, and hold the go/no-go review against the criteria written before day one.

Pilots rarely stall because the model was not good enough. They stall in the handoff from demo to system. Our field note Why most AI pilots stall covers this in more depth. These are the most common failure modes and how to prevent each one.

• Data access: the pilot ran on a one-time export, and production access needs a security review, API credentials, or a vendor contract nobody started. Get real access approved before day one.
• No owner: the person who built the demo moves on and no team agrees to run it. Name the production owner first; if nobody will sign up, the project is not ready.
• Demo-grade evaluation: stakeholders approved outputs they looked at, not a score on hard cases. Use a real-data evaluation set with thresholds agreed up front.
• Scoped to the easy half: the pilot handled clean examples, while production is mostly the long tail. Put the worst real cases in the evaluation set from the start.
• No integration path: it worked in a notebook, but nobody planned authentication, queues, error handling, or which system it writes to. Build a thin integration inside the proof of concept.
• Cost surprises: per-call costs looked trivial at demo volume and became a budget problem at scale, often from retries, long context, or agents calling tools repeatedly. Measure cost per transaction and project it to ten times expected volume.

Chatbots and voice agents stall in their own ways. The demo uses scripted questions, and real customers do not follow scripts. They ask several things at once, change their minds mid-conversation, write with typos and slang, and ask about things outside the bot's scope. A pilot tested on clean, single-intent questions breaks on the first day of real traffic, so build the evaluation set from real transcripts, emails, or call logs.

The second failure is the dead end. If the bot cannot book an appointment, look up an order, or hand off to a person with the conversation attached, customers repeat themselves to a human anyway and the pilot looks like extra work. Integrations with the booking system, CRM, or order system, plus a clean handoff, are what make conversational AI useful.

The third is trust. A bot that invents a price, a policy, or an appointment slot once can lose the team's confidence for good. Ground answers in approved content, restrict what it can do on its own, and log every conversation for review. For phone and text channels, check consent and call-recording rules with counsel before going live.

At the end of the timebox, decide: go, extend once with a specific fix, or stop. Agree the criteria before the work starts so the decision rests on evidence rather than sunk cost. A go needs all of these:

• Evaluation scores meet the agreed thresholds, including on the hard-case slice.
• The review rate is low enough for the reviewers to absorb.
• Projected cost per transaction fits the budget at production volume.
• Real data access and security approval are in place, not pending.
• A thin integration has worked end to end with real inputs.
• A named team has agreed to own the system, its monitoring, and its changes.
• Known failure modes have a fallback, such as routing to a person.

Production-ready means the system keeps working when inputs change, models update, and volume grows, and people can see when it does not. The proof of concept shows feasibility. Production needs operating discipline.

The core pieces are the evaluation set running on every prompt or model change, monitoring of quality, cost, and latency with alerts, logs of inputs, outputs, and actions for audit, permissions so the system only sees and does what each user may, and fallbacks that route uncertain or failed cases to a person. Security deserves its own review: the OWASP Top 10 for LLM Applications covers prompt injection, sensitive information disclosure, and excessive agency. NIST's AI Risk Management Framework offers a voluntary structure for governance in larger organizations.

Treat the human exception path as a feature, not an afterthought. AppAdvisor's data pipeline, for example, finds, parses, normalizes, validates, and refreshes data across thousands of universities daily with a human exception workflow built in alongside the automated steps.

Stopping is also a valid outcome. A few weeks spent learning that a use case is not ready is far cheaper than a failed build.

Companies that offer AI proof-of-concept services range from large consultancies and cloud providers' partner networks to independent AI development studios like ours. Whoever you hire, judge the engagement by what you hold at the end, not by the demo. Ask for these in the contract:

• The written success criteria and a go/no-go recommendation measured against them.
• The labeled evaluation set, in a format you own and can rerun.
• Scores for each approach or model tested, including where each one failed.
• A cost-per-transaction estimate at current and production volume.
• Working code for the proof of concept and the thin integration, in your repository.
• A production plan: architecture, integrations, owner, monitoring, and a scoped first version with timeline and cost.
• An honest list of risks, including the reasons to stop.