**Causes of PoC Failure and Lessons from Real Cases: Designing AI Adoption with Specification-Driven Development (SDD) and Acceptance Test-Driven Development (ATDD)**

In AI PoCs, even when the demo works flawlessly, no one can definitively say it's "usable" when it comes time to decide on production deployment. The reason for this kind of outcome is that AI-specific characteristics are not addressed at the planning stage. AI output is not always the same even for the same input, performance is determined by the data provided, and "high accuracy" alone cannot determine whether something is ready for production.

This article is aimed at personnel and project managers who plan AI adoption PoCs. After organizing common failure patterns, it explains how to fix the scope of verification in advance using Specification-Driven Development (SDD), and how to convert pass/fail criteria into tests before work begins using Acceptance Test-Driven Development (ATDD). Finally, it presents a checklist and a decision table to confirm before starting work.

In traditional system development PoCs, it was often sufficient to confirm "can it be built," and once the screen worked, most of the verification was complete. What needs to be confirmed in an AI PoC is "at what rate, and in what way, does it make errors." If this difference is not reflected in the planning, decisions end up being made based solely on the impression left by the demo.

The following three sections examine which planning-stage oversights this difference leads to.

Generative AI may return answers that differ in phrasing or content even for the same question. Therefore, the fact that a few cases worked well in the demo does not mean they will work well at the same rate in production. The questions chosen for a demo are usually questions that are easy to answer.

If this characteristic is not addressed at the planning stage, the conclusion of the PoC ends up being swayed by "how the people who watched the demo felt." Full-scale adoption gets decided based on a favorable demo impression, and it is only once difficult-to-answer questions come in during production that the high rate of errors is noticed.

The countermeasure is to state in the planning document that evaluation will be conducted using case counts and rates. What kinds of questions, how many, how many times the same question will be tried, and what pass rate is required to proceed to the next step—these should all be decided before work begins. If this is done, the demo becomes not a substitute for evaluation, but a venue for explaining the evaluation results. Specific methods for building this are covered later in the section on Acceptance Test-Driven Development (ATDD).

AI performance is determined more by what data it was tested with than by the choice of model. What commonly happens in PoCs is that high results come out with the clean, well-organized data on hand, only for performance to drop with the messy data encountered in production.

For inquiry-handling systems, past inquiries collected for the PoC tend to be biased toward "frequently asked questions" selected by staff. In production, questions with many typos, questions mixing multiple requests, and questions asking about confidential information also come in. For systems that search and answer (RAG), the age and duplication of the internal documents being referenced also affect the quality of the answers.

At the planning stage, the following three points should be written regarding verification data: where and how many cases to collect from, how they might differ from actual production inquiries, and to what extent difficult-to-answer cases should be included. If difficult-to-answer cases are not intentionally included, the PoC results will come out higher than the actual production results. The man-hours required for data extraction and personal information redaction should also be included in the budget at this point.

Even if a result of "90% accuracy" is obtained, this does not determine whether the system is ready for production. This is because the impact on operations differs entirely depending on what kind of errors make up the remaining 10%. An answer with slightly unnatural phrasing and an answer that describes a nonexistent refund policy should not be counted as equivalent single errors.

Therefore, at the planning stage, errors should be classified by severity. For example, three levels: "errors usable if corrected by a person," "errors that cause problems if shown to customers," and "errors that warrant considering suspension if they occur even once." For the last level, the criterion should be set by case count rather than by rate.

Besides accuracy, there are other conditions that affect whether something can go into production. Does the cost per case match the unit cost of the business operation? Does the response time fit within the business workflow? Where should human-check steps be inserted? Unless these are also written into the planning document as items to be measured in the PoC, the result will be that accuracy passes but the system still cannot be put into production.

When these three properties are not addressed in the planning stage, PoC failures tend to surface in roughly the following three forms. None of these are cases from a specific company; they are hypothetical examples showing typical patterns of how things unfold.

The losses from such failures are not limited to the cost of the PoC itself. Frontline staff who cooperated in preparing evaluation data and conducting verification start to feel "another PoC?", making it harder to gain cooperation for the next AI project. It's also important to note that a PoC that ends without reaching a conclusion leaves less behind than a PoC that fails outright. Even in the case of a decision to discontinue, if what was confirmed and what could not be confirmed is left on record, it becomes material for the next project.

In all three cases, the cause is not implementation but blanks left at the planning stage. Specification-Driven Development (SDD) and Acceptance Test-Driven Development (ATDD), covered from the next chapter onward, are approaches for filling in these blanks before work begins.

Specification-Driven Development (SDD) is an approach in which specifications are written as documents before implementation, and those specifications are treated as the starting point and the single source of truth for development. It has drawn renewed attention as AI coding assistance has spread, and tools have emerged—such as GitHub's publicly released "Spec Kit" and AWS's development environment "Kiro"—that create specification, design, and task breakdown documents first, before moving on to implementation.

SDD is effective for PoCs because many PoC failures begin with uncertainty over "what exactly are we trying to verify." If the specification document lays out the verification question, inputs, expected outputs, constraints, and out-of-scope items, then whether a request that comes up midway falls within the scope of the specification can be judged against the document.

Another reason is that it is increasingly common to have AI write the PoC implementation itself. When AI is used to build something, a working product can be produced quickly, but without a specification, no one can explain what the resulting product actually satisfies. If the specification document is put in place first, both the instructions given to the AI and the inspection of what it produces can be based on the same document.

A PoC specification document does not need to be as detailed as a specification document for full development. However, the following items must always be filled in before work begins.

The specification document should be read through together by stakeholders, and whenever it is changed, the date and reason for the change should be recorded. Changing the specification partway through a PoC is not a bad thing, but if the change is not recorded, it becomes unclear at the end what was actually verified. The basic approach to conducting a PoC is organized in What is PoC Development? From the Basics of Proof of Concept to Costs, Process, and Choosing a Reliable Outsourcing Partner.

Acceptance Test-Driven Development (ATDD) is an approach in which, before implementation begins, the business side, the development side, and the testing personnel jointly decide on acceptance criteria and write them as executable tests. The criteria are often written in the form of "preconditions, actions, and expected results" (Given/When/Then), and implementation proceeds with the goal of passing those tests.

In an AI PoC, these acceptance tests correspond to a pair consisting of an evaluation dataset and passing conditions. Cases such as "if an inquiry like this comes in, this kind of response should be returned" are collected, and it is decided in advance which conditions must be met to pass. This makes it possible to judge the outcome of the PoC not by a vague sense that "it seemed to go well," but by "how many out of how many cases passed."

What matters is that acceptance tests are not created by the development side alone. It is the business side that knows what constitutes a correct answer. The business side decides the passing conditions, and the development side turns them into a form that can be measured automatically. This division of responsibilities should be written into the project plan.

Building the evaluation dataset by case type reduces the chance of gaps. Using the example of an initial response to an inquiry, this looks as follows.

Cases should be selected by the business side from actual inquiries, with either the correct response or the conditions it must satisfy written down. Since AI responses vary in wording each time, judgment should be based on conditions such as "the procedure is correct" or "no definitive amount is stated," rather than exact matches. Questions that must not be answered and questions with no basis should be prepared before common questions. These are the ones most often overlooked in PoCs and that cause problems in production.

There is no fixed guideline for the number of cases. First, cover all the types, and then add more cases in areas where results fluctuate near the pass/fail line. For models with a fixed output format, such as classification or numerical prediction, the traditional method of measuring accuracy or error against labeled correct-answer data can serve directly as the acceptance test, whereas for generative AI that returns text, judgment based on conditions like those in the table above becomes the main approach.

Once the evaluation dataset is ready, decide on the passing line before starting work. If you draw the line after seeing the results, the line ends up shaped to match the results. Rather than a single line, combine the following four types. The values in the table are hypothetical examples to illustrate the format; actual values should be determined based on the unit cost of the business operation and the errors that can be tolerated.

Since the output changes every time, there is also a method of running the same case multiple times and judging based on how many times it passes. At this point, also decide how many times to run each case and how many passes are needed for that case to be considered passing. The procedure for designing metrics is also covered in AI Adoption PoC Design Guide.

In an AI PoC, the prompt, referenced documents, and model are changed repeatedly. If a person has to check all cases every time a change is made, evaluation cannot keep pace. Set up the acceptance test so that it can be automatically re-run on the same evaluation dataset each time a change is made.

For automated judgment, there are two methods: mechanically checking conditions, and having a separate AI score the results. Conditions such as "does not state a definite amount" or "cites a specific document name" can be checked mechanically. For conditions that are difficult to judge mechanically, such as the clarity of an answer, a separate AI can be used for scoring, but since the scoring AI itself can also make mistakes, a person should score a subset of cases to confirm that the results match.

Record the evaluation results together with the details of the change. If you keep a record of "which change raised the pass rate by how many cases, and which cases newly failed," you can explain at the end of the PoC what was effective and whether the same settings can be used in production. This record also serves as the foundation for regression testing once the project moves into full development.

The table below summarizes everything covered so far into items that can be checked before starting work. If the item listed under "Document to record" on the right is present in either the specification document, the proposal document, or an appendix, that item can be considered confirmed.

There is no item that should remain blank when starting work. If there is an item you cannot fill in, that itself is an issue to be resolved before the PoC.

Even if acceptance criteria are decided, the PoC will stall if no one is designated to make the judgment based on them. Divide roles into at least four: the business-side person in charge of deciding acceptance criteria, the development-side person in charge of running the evaluation, the evaluator who reports the results, and the decision-maker who decides whether to proceed or stop. The decision-maker and the evaluator should be different people. If the person who evaluated the results also makes the decision, the desire to continue can easily creep into the evaluation.

During execution, hold regular reviews at set intervals—such as every two weeks to a month—with the decision-maker also attending. What is reviewed are three points: the latest acceptance test results and the difference from the previous review, the change history of the specification, and whether any out-of-scope work has crept in. If the acceptance test is running automatically, the review can spend its time on deciding the next move rather than explaining the results.

The decision is not a binary of success or failure, but is made in the following three stages. The conditions for each judgment are built from the acceptance criteria.

The reason for limiting "continue with conditions" to changing only one condition is that if multiple conditions are changed at the same time, it becomes impossible to tell from the evaluation results what was actually effective.

Here are the answers to three questions that planning staff often find themselves unsure about when incorporating specification-driven development and acceptance-test-driven development into a PoC.

Even midway, you can rebuild in the following order.

1. Write in one sentence, as a validation question, what you are trying to confirm with what you are currently building, and check it with the decision-maker.
2. List what is out of scope, and stop any ongoing work that falls under out-of-scope items.
3. Work with the business-side person in charge to assemble evaluation data for each type of case. Start with questions that must not be answered and questions with no grounding.
4. Before looking at the results, decide on and record the pass rate and the criteria for critical errors.
5. Run the evaluation data through the current system all the way through, and compare all subsequent changes against this result.

The key point is doing step 4 before step 5. If you decide on criteria after seeing the results, the criteria will end up fitted to the results.

The problem is not the duration itself, but the reason the duration was extended.

If the extension came from accepting requests that fall outside the scope of the specification, you are at the entrance to a PoC that never ends. If the extension is for re-evaluation after changing one condition, based on the results of the acceptance tests, then it is an extension necessary for making a decision. When extending, agree on and record three points with the decision-maker: the reason for the extension, the decision date after the extension, and that the project will be discontinued if it still fails to meet the criteria even after the extension.

The answer changes depending on what you reuse.

The specification document and the evaluation dataset are the items with the highest value in being carried over as-is. The specification document becomes the starting point for the specifications of the full-scale development, and the evaluation dataset and acceptance criteria continue to be used as regression tests in the full-scale development. These two are the deliverables that should most be preserved from the PoC.

Prompts, the way reference documents are organized, and model settings can be reused if they are kept together with records of the acceptance tests. If you don't know which settings produced which results, there is no guarantee that the same results will occur in production.

It is safer to assume the PoC code will need to be rebuilt. This is because a PoC is built prioritizing quick verification, so it often omits elements necessary for production, such as authentication, permissions, handling of failures, and monitoring. If you do reuse it, first identify the gaps by checking it against the specification document for the full-scale development.

The reason AI PoCs end without reaching a conclusion is that AI-specific characteristics—output that is not consistent, performance that is determined by data, and the fact that accuracy alone does not determine production viability—are not addressed at the planning stage. With Specification-Driven Development (SDD), the scope to be verified is fixed in a document, and with Acceptance Test-Driven Development (ATDD), the pass/fail criteria are established before starting, as an evaluation dataset and a passing line. With these two in place, at the end of the PoC you can make a judgment based on "how many out of how many passed."

First, check whether your PoC proposal at hand has these four elements: the validation question, what is out of scope, evaluation data including questions that must not be answered, and criteria for critical errors. If any of these is blank, that is the first line to fill in.