Defining success for an AI proof of concept

A proof of concept (PoC) is supposed to reduce uncertainty. Too often it does the opposite: a few weeks of work end with an impressive demo, a room full of people who liked it, and no agreement on whether to invest further.

The demo isn’t the problem. The problem is that nobody decided in advance what the PoC had to prove. This guide covers how to set that up so the end of a PoC is a decision, not a debate.

Write down the one question

Every useful PoC answers a single question. For example:

• Can a model extract the ten fields we need from our supplier invoices accurately enough to replace manual entry?
• Can an assistant answer staff questions from our policy documents, with correct citations, for most everyday questions?
• Can we classify incoming support requests well enough to route them without a person triaging every one?

Notice what these have in common: a specific task, a specific source of data, and an implied standard of “good enough.” If your question is “can AI help our operations team?”, it is not ready for a PoC yet. It needs an opportunity assessment first.

Separate the three kinds of risk

A PoC can test different things, and it helps to be explicit about which ones you’re testing:

1. Technical risk: can the approach produce good enough results on your real data?
2. Integration risk: can it connect to the systems where inputs come from and results need to go?
3. Adoption risk: will the people who own the process actually use it and trust it?

Most PoCs focus on the first and assume the other two. That’s fine, as long as everyone agrees that a technical pass is not the same as a green light for production.

Build an honest test set

Your results are only as meaningful as the examples you test on. A good test set:

• Comes from real work. Use actual documents, messages, or records, with sensitive details handled according to your policies.
• Includes the awkward cases. Ask the people who do the work today for the examples they find hardest: poor scans, unusual formats, ambiguous requests. A PoC that only sees clean examples will overstate how well it works.
• Has known right answers. For each example, record what the correct output is, agreed by the process owner. This is your answer key.
• Is set aside before building starts. Keep the test set separate from anything used to design prompts or tune the system, so you aren’t grading on examples the system has already “seen.”

A few dozen carefully chosen examples are far more useful than thousands of unlabeled ones.

Choose measures that match the decision

Pick measures that mean something to the business, not just to engineers:

• Accuracy on the task, defined the way the process owner would judge it (for extraction: share of fields correct; for answers: share that are correct and properly cited)
• Coverage: share of cases the system can handle at all, versus those it should hand to a person
• Time per item compared with the current process
• Quality of failure: when it’s wrong, is it obviously wrong and easy to catch, or confidently wrong?

That last one matters more than it looks. A system that says “I’m not sure, please review” on hard cases is often more valuable than one with slightly higher accuracy that never admits doubt.

Agree on the pass mark in advance

Before the build starts, agree with the sponsor and the process owner on three thresholds:

• Go: results good enough to plan a production version (for example, a target accuracy with human review of flagged cases)
• Adjust: promising, but a specific gap needs closing (better source data, a narrower scope, a different approach)
• Stop: the approach doesn’t work well enough for this task right now

Writing these down protects everyone. It stops the goalposts from moving once results arrive, and it makes “stop” a legitimate, useful outcome rather than a failure. Learning that a task isn’t ready, for the cost of a few weeks, is a good result.

Keep the scope and timeline tight

A PoC should be short. A few weeks is typical. To keep it there:

• Limit it to one task, one data source, and one team
• Use the simplest integration that proves the point, such as a file export or a sandbox connection, rather than a full production integration
• Set a fixed end date and hold the review on that date, whatever the state of the work

If the PoC keeps growing, that’s usually a sign the question wasn’t specific enough.

Plan the decision meeting

The end of a PoC should be a short, structured review:

1. Restate the original question and the agreed thresholds
2. Show results on the test set, including the failures and why they happened
3. Show what a person would need to review in a real workflow
4. Estimate what a production version would need: integration, security review, monitoring, and support
5. Make the call: go, adjust, or stop

Bring the people who do the work today into this meeting. Their view on whether they’d trust the output is as important as the numbers.

A quick checklist

• One clearly written question
• A test set from real work, including hard cases, with agreed right answers
• Measures that match how the business will judge the result
• Go, adjust, and stop thresholds agreed before building
• A fixed end date and a decision meeting in the calendar

Where to go from here

If you have a use case in mind and want to test it properly, our AI Proof of Concept engagement follows this structure, from defining the question to a clear recommendation. If you’re not sure which use case to test first, start with choosing the right first AI automation opportunity.