# Evaluating a PoC: criteria for go/no-go

[Skip to content](#lm-inhoud)Network/[NL](/en/een-poc-evalueren-criteria-voor-go-no-go)EN[Hubhub.llmnet.nlCompare models on task, language, cost and license.](https://hub.llmnet.nl/en/)[Communitycommunity.llmnet.nlPrompt techniques, patterns and system prompts.](https://community.llmnet.nl/en/)[APIapi.llmnet.nlLLMs in production: rate limits, routing, structured output.](https://api.llmnet.nl/en/)[Consultancyconsultancy.llmnet.nlRolling out AI in an organization, pilot to production.](https://consultancy.llmnet.nl/en/)[Newsnieuws.llmnet.nlAI developments, explained for the Netherlands.](https://nieuws.llmnet.nl/en/)[Benchmarkbenchmark.llmnet.nlMeasure AI quality yourself, on your own tasks.](https://benchmark.llmnet.nl/en/)[Careersvacatures.llmnet.nlAI roles, salaries and career paths in the Netherlands.](https://vacatures.llmnet.nl/en/)[Learnleren.llmnet.nlAI concepts in plain language, beginner to builder.](https://leren.llmnet.nl/en/)[Guidegids.llmnet.nlRun AI privately on your own Mac, PC, NAS or home server.](https://gids.llmnet.nl/en/)[Directorydirectory.llmnet.nlMapping the AI ecosystem: tools, models, companies.](https://directory.llmnet.nl/en/)[Radarradar.llmnet.nlSignals from X, research and communities for indie developers.](https://radar.llmnet.nl/en/)[Appsapps.llmnet.nlReviews of AI apps and open-source repos, with tips for builders.](https://apps.llmnet.nl/en/)[llmnet.nl — main site](https://llmnet.nl/en/)[](https://x.com/intent/post?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Feen-poc-evalueren-criteria-voor-go-no-go&text=Evaluating%20a%20PoC%3A%20criteria%20for%20go%2Fno-go)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Feen-poc-evalueren-criteria-voor-go-no-go)[](https://www.reddit.com/submit?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Feen-poc-evalueren-criteria-voor-go-no-go&title=Evaluating%20a%20PoC%3A%20criteria%20for%20go%2Fno-go)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Feen-poc-evalueren-criteria-voor-go-no-go&text=Evaluating%20a%20PoC%3A%20criteria%20for%20go%2Fno-go)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Feen-poc-evalueren-criteria-voor-go-no-go)[](https://www.reddit.com/submit?url=https%3A%2F%2Fconsultancy.llmnet.nl%2Fen%2Feen-poc-evalueren-criteria-voor-go-no-go&title=Evaluating%20a%20PoC%3A%20criteria%20for%20go%2Fno-go)[](#)

 
# Evaluating a PoC: criteria for go/no-go

 By Ivo Donker — compiled with AI assistance (Claude & Gemini)

 A proof of concept (PoC) within an AI initiative sits at the intersection of technical exploration and business realism. The primary goal of a PoC is not to prove that a large language model (LLM) can formulate a plausible answer to a handful of carefully selected test prompts. The real goal is to test, under controlled conditions, whether the chosen architecture can withstand the variability, integration pressure, governance requirements, and cost structure of an operational production environment.

 In practice, the transition from a working prototype to a stable business solution proves to be one of the biggest stumbling blocks. A PoC that performs impressively in an isolated notebook environment can collapse in a live ERP or CRM environment under unpredictable input, slow latency, or escalating token costs. Anyone who wants to understand why pilots run aground on structural integration flaws can consult the analysis on [the transition from pilot to production](https://consultancy.llmnet.nl/en/pilot-naar-productie) to spot common design flaws early. This article sets out a measurable, objective assessment framework for making a well-founded go/no-go decision.

 
## 1. Defining a successful PoC: scope versus expectation

 A persistent misconception among organizations is that a successful PoC is synonymous with a production-ready system. However, a PoC is designed solely to resolve core uncertainties: is the data sufficient, does the model understand the domain jargon, do response times stay within acceptable limits, and does the potential time savings justify the investment? When this scope is not sharply defined in advance, scope creep sets in, with stakeholders expecting a finished product based on a rudimentary prototype.

 To keep an evaluation objective, the success criteria must be quantified in advance in a test protocol. This protocol sets threshold values across six core areas: functional accuracy, technical performance, operational cost, security and privacy, process integration, and legal compliance. If the PoC falls short on one of these pillars with no prospect of recovery, a no-go decision is one of the most sensible business outcomes. Terminating an unviable use case early prevents capital destruction in long-running software initiatives.

 
## 2. Criterion 1: Functional accuracy and hallucination control

 The functional performance of an LLM application cannot be judged based on anecdotal samples. Testing requires a representative golden dataset (ground truth) of at least one hundred to two hundred anonymized real-world cases, including edge cases, incomplete input, and deliberately misleading prompts (adversarial testing).

 When measuring accuracy, we distinguish between retrieval quality and generation quality:

 
 
- Context precision & recall: Does the RAG (Retrieval-Augmented Generation) system retrieve exactly the right document fragments from the internal data sources, without adding irrelevant noise?
 
- Faithfulness: Does the generated answer contain only facts that are directly traceable to the supplied context, or does the model fill in missing knowledge with fabrications (hallucinations)?
 
- Answer relevance: Does the answer directly address the end user's question, without unnecessary digressions or evasive phrasing?
 
 For non-deterministic answers, classic string-matching methods such as BLEU or ROUGE fall short. A proven methodology is to deploy an LLM-as-a-judge with fixed evaluation rubrics, supplemented with blind validation by domain experts. An acceptable threshold for a PoC depends on the risk profile: for internal summaries, a faithfulness score of 90% may suffice, whereas automated contract analysis or compliance checks require a measurable reliability of at least 98%.

 
## 3. Criterion 2: Technical robustness, latency, and fallback architecture

 A PoC often demonstrates a single ideal path (the so-called happy path). In production, however, the system has to contend with peak load, timeouts from external APIs, changing payload formats, and rate limits from cloud providers. During the evaluation phase, technical robustness must be explicitly tested under simulated stress.

 Latency evaluation must be broken down into Time to First Token (TTFT) and end-to-end latency. For interactive applications such as employee assistants, acceptable TTFT is typically under 1.5 seconds; for asynchronous batch processing, absolute milliseconds play a less dominant role, but throughput is decisive. When an application uses autonomous chains and tool calls, wait time quickly stacks up. Anyone considering building in complex decision-making loops can consult the analysis on [the shift toward autonomous agentic AI systems](https://nieuws.llmnet.nl/en/agentic-ai) to realistically assess the technical complexity and failure risks of such architectures.

 In addition, the PoC must demonstrate that error handling is structurally in place. What happens if the context length is exceeded, if a document is corrupted, or if the model API returns a 503 error? A go decision requires that the system fails gracefully (graceful degradation), with clear error messages to the user and fallback options to alternative models or human intervention.

 
## 4. Criterion 3: Cost structure and scalability of token consumption

 Costs that seem negligible during a PoC (a few tens of euros in API credits for a test group of five employees) can escalate linearly or exponentially once hundreds of active users are uploading documents daily. A thorough evaluation extrapolates token consumption to real production volumes.

 The evaluation team should draw up a Total Cost of Ownership (TCO) calculation that accounts for:

 
 
 
 
 Cost component | 
 PoC observation | 
 Production extrapolation (annual basis) | 
 Point of attention / Risk | 
 

 
 
 
 Inference tokens (input/output) | 
 Direct API costs test group | 
 Volume per active user × frequency | 
 Rising prompt length due to RAG context | 
 

 
 Vector storage & embeddings | 
 Small test database | 
 Full company storage + indexing frequency | 
 Costs for periodic reindexing on updates | 
 

 
 Monitoring & observability tooling | 
 Standard logging in console | 
 Specialized LLM tracing platforms | 
 Data volumes from full payload storage | 
 

 
 Maintenance & prompt engineering | 
 Ad hoc adjustments by the builder | 
 Structural management hours, internal or external | 
 Model updates and deprecation by vendors | 
 

 
 
 
 If the calculation shows that the cost per processed transaction exceeds the value of the time savings achieved, a redesign of the architecture is necessary. This may mean replacing heavy reasoning models with compact, specialized models for routine tasks, or building in caching mechanisms to handle repeated queries cheaply.

 
## 5. Criterion 4: Data security, privacy, and compliance

 A PoC regularly uses synthetic test data or a manually cleaned dataset. For a production rollout, however, the full obligations of the GDPR and sector-specific security standards (such as ISO 27001 or NEN 7510 in healthcare) apply. A positive go/no-go assessment cannot be issued without a watertight security analysis.

 The most important checkpoints in this category are:

 
 
- Data retention and model training: Does the API agreement with the model vendor explicitly guarantee that submitted company data and prompts are not stored for model training or quality improvement by third parties?
 
- Rights management and RAG authorization: Does the search component respect the existing authorization matrix of the source systems? If an employee can use the AI assistant to retrieve confidential HR documents or salary data that they don't have access to in SharePoint, that is a direct blocker for going live.
 
- Prompt injection and data leakage: Has the application been tested against direct and indirect prompt injection, where malicious input or compromised input documents force the model to leak system instructions or confidential context?
 
 Organizations that want to formally embed these frameworks within their operations can consult the article on [drafting an effective AI policy](https://consultancy.llmnet.nl/en/ai-beleid-opstellen) to establish the right operational and legal guidelines.

 
## 6. Criterion 5: User acceptance and integration into work processes

 The technological superiority of a solution offers no guarantee of success if end users ignore the tool, distrust it, or experience it as a disruption to their workflow. User acceptance must be measured quantitatively and qualitatively among the actual target group during the pilot period.

 Important indicators of healthy adoption include:

 
 
- Voluntary repeat use: Do pilot participants voluntarily use the application daily or weekly once the initial curiosity has worn off?
 
- Willingness to correct and adopt: How much time does an employee spend checking and manually correcting the generated output? If correcting it takes more cognitive effort than writing the text themselves, the net return drops to zero.
 
- Qualitative feedback and pain points: Does the interface integrate with existing applications (such as Microsoft Teams, Outlook, or specialized industry software), or does the system force users to constantly copy and paste context between screens?
 
 Resistance on the shop floor often signals a lack of process guidance or a mismatch with actual needs. For organizations struggling with employee reluctance, the overview on [successful change management and AI adoption in teams](https://consultancy.llmnet.nl/en/ai-adoptie-teams) offers concrete tools for gradually building support and digital skills.

 
## 7. The go/no-go decision model: scoring matrix

 To avoid subjective discussions between IT, management, and business units, a weighted scoring matrix brings structure to the final judgment. Each criterion is assigned a predetermined weight and a minimum required threshold score (for example, on a scale of 1 to 5). A failing score on a critical security or compliance component always acts as an absolute veto (knock-out criterion).

 
 
 
 
 Domain | 
 Weight | 
 Minimum standard (threshold) | 
 Measurement method | 
 Status / Outcome | 
 

 
 
 
 Accuracy & Quality | 
 25% | 
 Score ≥ 4.0 / Faithfulness ≥ 95% | 
 Golden test set + expert review | 
 Qualitatively assessed | 
 

 
 Data Security & Privacy | 
 20% | 
 100% compliant (no leaks/veto) | 
 Security audit & authorization test | 
 Knock-out criterion | 
 

 
 Business Case & ROI | 
 20% | 
 Net positive within 12 months | 
 TCO model vs. measured hours saved | 
 Financial projection | 
 

 
 User Adoption | 
 15% | 
 CSAT ≥ 7.5 / Retention ≥ 70% | 
 User measurements and surveys | 
 Pilot group behavioral data | 
 

 
 Latency & Stability | 
 10% | 
 Uptime 99.5% / TTFT < 2.0s | 
 Automated stress tests | 
 System reports & logs | 
 

 
 Maintainability | 
 10% | 
 Established ownership & CI/CD | 
 IT management architecture review | 
 Handover documentation | 
 

 
 
 

 
## 8. What to do in case of a 'no-go' or 'pivot'

 A no-go decision is not a failure of the innovation team, but a victory for sound risk management. It signals that an investment of tens to hundreds of thousands of euros in custom development and production licensing costs has been averted in time. Depending on the reasons behind the insufficient score, there are three rational follow-up routes:

 
 
### Three recovery strategies for disappointing results:

 
 
- Pivoting to a simpler architecture: Does the failure lie in the unpredictability of autonomous decision-making? Scale the complexity back to a static search interface or structured data extraction without free-form generation.
 
- Fixing the data foundation first: Does the RAG solution turn out to be failing due to cluttered SharePoint folders, outdated PDFs, or inconsistent document versions? Pause the AI project and invest first in data quality and document management.
 
- Stopping definitively (kill the project): Is the use case too error-prone for the intended process, or do the operational costs structurally fail to outweigh the benefits? Close the project down cleanly, document the lessons learned, and prevent the same idea from being relaunched six months later.
 
 

 When a pilot gets stuck on organizational resistance or technical debt, the analysis on [lessons from failed AI projects](https://consultancy.llmnet.nl/en/ai-project-mislukt-lessen) offers in-depth insight into how organizations can turn earlier pitfalls into recoverable improvements.

 
## 9. Conclusion and the transition path to production

 A positive go decision does not mark the end of the work, but the starting signal for professional-grade software engineering. Once the criteria have been successfully met, the focus shifts from experimentation to robustness: setting up automated CI/CD evaluation pipelines, establishing continuous monitoring of token consumption and model drift, and formally assigning data and system ownership within the management organization.

 By basing go/no-go decisions strictly on quantitative thresholds, data security, and real user adoption, organizations transform their AI initiatives from noncommittal technology experiments into reliable, scalable business assets that deliver demonstrable value.