Most AI proofs-of-concept end the same way: the results come in ambiguously, and the team argues about what they meant. Prevent that by building a binding investment gate before any testing starts. Write down the business claim the proof of concept must support, then set the thresholds that decide the outcome in advance, so the result triggers a decision instead of a debate.
Without agreed proof of concept success criteria, you have bought a demo. So put the gate up first. Name one person who owns the call. Fix the review date before anyone writes code. Document what the current process costs and how often it goes wrong today, because every claim you test later gets measured against that record.
Then define four outcomes in advance, and write down what triggers each.
Go: every nonnegotiable threshold has passed, and the remaining risks have accountable owners and funding.
Pivot: the technology works, but the chosen task or workflow doesn’t.
Hold: a specific missing input would change the answer, and you can name it and date it.
Stop: the evidence says the claim was wrong. Also agree on what happens when a result lands between a pass number and a fail number. It is not a pass. It triggers Hold if you can name the input that would settle it and the date it will arrive, and it counts as a fail if you can’t.
Gartner predicted in 2024 that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025. In January 2026, it reported the outcome: at least 50% were abandoned, citing poor data quality, inadequate risk controls, escalating costs, or unclear business value. The gate is what turns that abandonment into a cheap, early decision instead of an expensive late one.
A proof of concept can only disprove something specific. "AI will improve customer service" is not testable. "The assistant resolves password reset and refund status requests end to end for 60% of chat volume, with handling time under three minutes against the current eleven" can be checked in two weeks and argued about honestly.
So write the claim as a sentence that could turn out false. Name the task and the environment the system has to work in. Klarna's February 2024 announcement is a useful model of specificity, whatever you think of what followed: the assistant handled 2.3 million conversations in its first month and cut resolution time from eleven minutes to under two.
Your AI business case lives or dies on that last part. If the claim holds only when inputs are clean or when an engineer is watching the output, the case belongs to a laboratory. State up front what evidence would justify spending more money, and state what evidence would end the conversation.
Assemble the test set before you see any results, and freeze it. Realistic volume and the variation your teams actually encounter. Andrew Ng, founder of Landing AI, built an entire Stanford talk around the proof-of-concept to production gap, and his point lands here: performing well on a curated test set is not the same as performing well where the work happens.
Informatica's CDO Insights survey found data quality and readiness tied with technical maturity as the top obstacle to AI success, cited by 43% of respondents. A test set built from the cleanest records in your warehouse hides exactly that problem.
Build the set from four kinds of cases, and keep the proportions honest:
Routine cases at the frequency they actually occur, drawn from a real-time window rather than hand-picked
Messy inputs: bad scans, missing fields, mixed languages, truncated records
Consequential edge cases where an error triggers a refund, a regulatory report, or a safety response
Adversarial cases, including prompt injection attempts and users trying to extract data they shouldn't see
Lock the set. If the team can revise the evaluation after seeing the scores, the AI PoC stops measuring the system and starts measuring the team's optimism.
Tell us about your idea. 24-hour response. NDA-friendly.
Book a Discovery Call →Every decision dimension gets a pass number and a fail number, written down before testing. Some of those numbers are tradeable, and some are not. Safety and compliance sit in the second group, which means a brilliant result on cost cannot buy its way past a privacy failure.
Klarna is the cautionary case. Fourteen months after the launch numbers above, CEO Sebastian Siemiatkowski told Bloomberg that "cost unfortunately seems to have been a too predominant evaluation factor when organizing this; what you end up having is lower quality." The company began rehiring human agents. One dimension had been allowed to outweigh the others, and the correction arrived late and in public.
Your AI PoC success criteria therefore need a structure. Five groups cover most use cases, and each one is examined below.
Set the required improvement against the baseline you documented at the gate. Task completion without human rescue and the expected cost per transaction at production volume. Use numbers.
Be conservative about cost, because proof-of-concept economics mislead. Gartner’s cost optimization research warns that at least 50% of GenAI projects will overrun their budgeted costs through 2028 due to poor architectural choices and a lack of operational know-how, and notes that a production-ready system can be orders of magnitude more expensive than the pilot. An AI business case that only works at pilot token prices isn't an AI business case.
One average accuracy figure is the most comfortable and least useful number in the pack. It hides the failures that cost the most. Define acceptable performance per case type, then set a separate ceiling for critical errors in each type, where critical means a wrong answer that creates liability or harm.
Air Canada found the price of that distinction in court. The British Columbia Civil Resolution Tribunal ordered the airline to pay $812.02 in damages after its chatbot gave a passenger incorrect bereavement fare advice, and tribunal member Christopher Rivers rejected the argument that the bot was a separate legal entity. The American Bar Association's summary of Moffatt v. Air Canada makes the general rule plain: the company owns what its tool says. A chatbot scoring 97% overall still loses that case on the other 3%, which is why AI proof-of-concept success criteria have to be written per case type.
Set a latency ceiling that matches how people work, and confirm the unglamorous things: whether you can get lawful access to the data and whether the integration points exist. The NIST AI Risk Management Framework organizes this work under Map and Measure, and its structure is worth borrowing even if you never claim alignment with it.
Then draw a line down the page. On one side, what the AI proof-of-concept has actually established. On the other, the production engineering still to be built. Monitoring and rollback belong on the second side, and pretending otherwise is how a successful test becomes a stalled deployment.
Tell us about your idea. 24-hour response. NDA-friendly.
Book a Discovery Call →A system that is accurate but slow to check hasn’t saved anyone time. Set a ceiling on reviewer minutes per case, against today’s number from the baseline you documented at the gate, and count the time spent correcting output as well as reading it.
Then set an adoption threshold: the share of target users who actually use the system in their daily workflow during the test, measured from usage rather than from what people say in a survey.
Our own LilyAssist project shows what this looks like when review is designed in. The platform helps school psychologists produce evaluation reports: the AI drafts test descriptions, score tables, section summaries and narratives, while the psychologist remains responsible for reviewing, editing and approving every report. It now has 1,000+ users and has processed 20,000+ assessments. Wherever a professional signs off on every output, as here, the time that sign-off takes belongs in the business case.
Name the findings that stop the project outright. Training or prompting on personal data without a lawful basis. Model output that leaks one customer’s records to another. Those are stop conditions.
Prompt injection and policy bypass need a different kind of threshold, because in practice no LLM system passes every attack. Define a set of attacks before testing, covering instruction overrides, attempts to extract data the user shouldn’t see, and attempts to bypass policy controls, and set a pass rate on that set. A successful attack that exposes one customer’s data to another is still a stop, whatever the overall pass rate.
Then name the findings that allow progress only with a funded mitigation and a named owner, which is a different and weaker category. Regulatory timing belongs here too. The EU AI Act's transparency obligations under Article 50 apply from 2 August 2026 to any system that interacts directly with people or generates synthetic content, and Cooley notes that non-compliance can trigger fines of up to €15 million or 3% of worldwide annual turnover. A disclosure requirement you can meet in a week is cheap. The same requirement discovered after launch is not.
Report each result next to its threshold and its baseline, even the ones that missed. The failures are the most valuable part of the record, because they are the only part that tells the decision owner where the system breaks and what it would cost to fix.
Write down what you did not test. That list is longer than the one you did test, and it's where the next stage's risk lives. Scrapping a proof of concept is common. S&P Global Market Intelligence surveyed more than 1,000 organizations in North America and Europe and found the average company scrapped 46% of its proof-of-concept projects before production, with the share abandoning most of their AI initiatives rising to 42%, up from 17% a year earlier.
A usable evidence record for an AI PoC contains:
Every result against its threshold, with the number of cases behind it
Each critical error, described individually rather than averaged away
Assumptions carried into the test but never checked
Constraints that made the test less representative than production, such as a curated data sample or an engineer intervening mid-run
Say how confident you are and why. Two hundred cases from one business unit over three weeks supports a narrower conclusion than a quarter of live traffic, and the write-up should say so rather than leaving the decision owner to guess.
Now cost the thing you are actually being asked to approve: the additional data work, the staffing to run it, and the production engineering still to be built, priced at production volume rather than pilot volume.
Every residual risk gets a named owner and a date. The owner is a person. An AI business case that assigns risk to a department has assigned it to nobody, and the risk reappears during the first production incident.
The named owner applies the outcome agreed at the gate, on the date fixed at the gate: go, pivot, hold or stop, exactly as defined there. If a result falls between a pass number and a fail number, apply the in-between rule from the gate rather than rounding it up.
Stop is a result, not a failure of the process. In a July 2025 preliminary report, MIT’s NANDA initiative found that only 5% of integrated AI pilots were extracting millions in value, while the vast majority had no measurable P&L impact, so a stop is a realistic outcome to plan for.
Hold the AI PoC success criteria exactly as written. If every other threshold passes and the critical error ceiling doesn’t, the answer is pivot or stop, whatever the demo looked like in the room.
The two failure modes are easy to spot in hindsight and hard to resist in the moment. A flawless happy-path demo gets presented as proof, and thresholds get quietly adjusted once the results arrive. Both convert a decision gate into a formality.
When the evidence misses the gate, change the use case or stop funding it. That discipline is the whole return on the exercise, because the money saved on a failed AI PoC is the money available for the next one.
Planning an AI proof-of-concept? Praetorix Foundry is a senior-led, product-first studio for web, mobile, and AI products. Our AI Pilot takes one AI use case from agreed success criteria to a working prototype, findings, and recommendations in two to four weeks, so you set the gate before testing starts.
Tell us about your idea. 24-hour response. NDA-friendly.
Book a Discovery Call →A missed critical threshold should trigger a pivot or stop, even when other measures pass. The decision owner should record the failure, explain its effect, and identify whether a changed workflow could address it. Do not lower the threshold after testing, because that removes the comparison agreed before the evaluation.
Freeze the test set before reviewing results and build it from a defined period of real work. Preserve the actual mix of routine, messy, high-impact, and adversarial cases. Record excluded cases and data limits, because a clean sample can make performance look better than it will be in production.
A named person should own each remaining risk, with a due date and a funded mitigation when progress is allowed. Assigning risk to a department leaves accountability unclear. You should also receive a record of each owner, deadline, unresolved assumption, and decision condition before funding the next stage.
The report should show every result beside its threshold and baseline, with the number of cases tested. It should describe critical errors individually, list untested assumptions, and explain constraints such as human intervention or curated data. Include a confidence statement that matches the test size and operating conditions.
Estimate the next stage from production requirements rather than pilot usage. Include data preparation, integration, monitoring, rollback, security controls, support staff, and expected transaction volume. This ai proof of concept review should separate costs already measured from assumptions, then attach each unpriced risk to an owner before approval.
Tell us about your idea. 24-hour response. NDA-friendly.
