AI Proof of Concept: Decide What It Must Prove First

An AI proof of concept should prove one thing: whether this AI can do this specific job, on your real inputs, well enough to be worth building properly. It should end in a go or no-go decision, not a demo. A demo that works on hand-picked examples proves the model can do the task. It does not prove that you should build it.

That distinction sounds small. In practice it decides whether the money you spend on a proof of concept buys you an answer or buys you a meeting where everyone agrees it looked impressive and nobody can say what happens next.

What should an AI proof of concept prove?

Most AI proofs of concept are built to impress. The builder picks clean examples, tunes the prompt until the output looks good, and shows it to the people who approved the budget. Everyone nods. Then someone asks whether it is ready to use on the real work, and the room goes quiet, because nobody agreed in advance what "ready" means.

A useful proof of concept answers a question that someone with budget authority actually needs answered. Usually it sounds like one of these:

• Can the model read our documents accurately enough that a person only has to check, not retype?
• Can it handle the messy cases, or only the tidy ones?
• Does it cost a reasonable amount per task at the volume we actually run?

Notice that none of those questions is "does AI work." The model almost certainly can do something useful. The question is whether it can do your thing, on your data, inside your workflow, at a price and error rate the business can live with.

Why do so many AI pilots stall after the demo?

The gap between pilot and production is well documented. Deloitte's State of AI in the Enterprise 2026, released on January 21, 2026 and based on a survey of 3,235 business and IT leaders across 24 countries in August and September 2025, found that only 25% of respondents had moved 40% or more of their AI pilots into production. Another 54% expected to reach that level within three to six months. The same release suggests that communicating a clear strategy can help reduce "pilot fatigue" (fetched 2026-11-02).

Read that carefully. It is not saying a quarter of pilots succeed. It is saying that only a quarter of organizations have gotten even 40% of their pilots across the line. Most companies have more experiments than shipped systems.

In our experience, the stall is usually decided long before the demo, at the scoping stage, when nobody wrote down what success looks like. We cover the wider set of causes in where AI integration projects stall. The fix we focus on here comes first: design the proof of concept so it has to produce a decision.

Which exit criteria should you set before you build?

Exit criteria are the conditions, agreed before any code is written, that tell you whether the proof of concept passed or failed. We write three of them down on one page before we start a build.

The pass mark. What result is good enough to move forward? This has to be agreed with the person who owns the outcome, not the person building the thing. A builder will always find a way to call a result promising. The owner of the workflow knows whether 90% of fields extracted correctly saves the team real time or just moves the retyping somewhere else. The pass mark should name the cases it applies to, because 95% on easy documents and 60% on hard ones is a very different result from 85% across the board.

The kill result. What finding ends the project? This is the one teams skip, and it is the most valuable line on the page. If the model cannot read handwritten forms, and half your forms are handwritten, that is a no. Write it before the work starts, while nobody has an attachment to the prototype, so nobody argues it away later.

The inputs. Which cases will the proof of concept be tested on? The answer should be a sample of real work pulled straight from the workflow, including the ugly ones people complain about: the scanned fax, the email with three attachments, the customer who writes everything in one paragraph. If the sample only includes clean cases, the proof of concept is testing a version of your business that does not exist.

Here is how those three sit next to each other for a typical document-reading proof of concept:

None of this needs a statistician. It needs a page, a conversation and the discipline to write it before the build. This is the "Figure it out" step of how we figure out what is worth building, made concrete.

What should a POC include besides the model?

A proof of concept that tests only the model answers half the question. The parts that sink AI projects in production are usually around the model, not in it. So we build the production-shaped pieces in miniature.

Where a person reviews the output. Almost every useful business AI system has a human checkpoint somewhere. Put it in the proof of concept, even as a rough screen, because how long the review takes is often the real measure of value. In Howdy Dispatch, the AI reads a broker's rate confirmation and pre-fills the load, and the dispatcher reviews it before saving. The interesting question was never whether the model could read a PDF. It was whether reviewing a pre-filled load was meaningfully faster than typing one.

A rough cost per task. You do not need a full cost model, but you need an order of magnitude. Run the real sample, count the tokens or the API calls, and multiply by your monthly volume. A system that works but costs more per task than the person it is helping is not a system you will keep. We go deeper on budgeting in what a custom AI project costs.

The one integration that matters. Most workflows have one system the AI must read from or write to for the result to be useful: the inbox, the CRM, the document store. Connect that one, even crudely. Discovering in month three that the data is locked behind an export nobody can automate is the classic late surprise.

Just as important is what to leave out on purpose: polish, dashboards, user management, every secondary integration. Those belong in the build that follows a "go," not in the experiment that decides whether there is one.

How long should an AI proof of concept take?

Our guidance is to timebox it in weeks, not months, and size it to the one decision it has to support. If the question is narrow, such as "can the model extract these twelve fields from our invoices," the answer should come quickly. If you find yourself extending the timeline because the results are almost there, treat that as information. A proof of concept that cannot answer its question within the window has told you something about how hard the problem is.

Resist the urge to let it drift into a soft launch. The moment real users depend on the output, you are running a pilot, with all the support, monitoring and expectation that come with it. That is a separate step with its own plan.

FAQ: AI proof of concept

What is the difference between a prototype, a proof of concept and a pilot?

A prototype shows what the experience would look like. A proof of concept answers whether the AI works on your data well enough to justify building it. A pilot runs the built system with real users on real work, at a limited scale, before a full rollout.

Who should make the go or no-go call?

The business owner of the outcome, using the builder's evidence. The builder should present results against the pass mark and kill result agreed at the start, not a fresh argument for why it should continue.

Can we run an AI proof of concept ourselves?

Yes, for a narrow task with a clear owner. Plenty of teams can test whether a model reads their documents using off-the-shelf tools. If you want to learn to do that kind of testing yourself, our learn page is the place to start.

What if the answer is no?

Then the proof of concept worked. A cheap, early no is far better than an expensive, late one. If you want to check your footing before spending anything, start with an AI readiness assessment.

Where should a team start?

Pick the one workflow you most want help with. This week, write the pass mark, the kill result and the inputs on one page, and get the person who owns that workflow to sign it. Then build, and hold the result to that page when the timebox ends.

If you are about to fund an AI proof of concept and want the exit criteria set before anyone writes code, tell us what you are working on. It is the first conversation we have on every AI integration for business project.