An AI proof of concept for a decision, not a demo.

An AI proof of concept is a bounded technical experiment that tests whether one selected AI approach can solve a specific task under representative conditions. It begins with a current baseline, success threshold, trade-offs, and decision owner. It ends with measured results, failure cases, limitations, operating implications, and a go, narrow, change, or stop recommendation.

It should validate the uncertainty that could change the investment decision. That may be output quality, data readiness, retrieval coverage, prediction performance, action reliability, latency, unit cost, human-review effort, or integration feasibility. The PoC should also expose where the approach fails and what production would still require. It should not attempt to prove every feature at once.

A demo communicates a possible interaction, often with selected examples. A prototype explores how the experience or technical approach might work. A proof of concept measures one uncertain claim. A pilot runs a more complete solution with a controlled real-world group or workload. An MVP is a usable product released to test customer or operating value. Teams can combine artefacts, but the decision each one supports should remain explicit.

Run a PoC when one uncertain assumption could make the larger build unwise. Common examples include unknown quality on your documents, unreliable answers from your knowledge base, uncertain prediction lift, unacceptable reviewer effort, or model cost that may not work at expected volume. Start development when the core evidence is already credible and the remaining work is integration, product behaviour, controls, and operation.

Start with AI consulting when the organisation still needs to choose among several use cases, compare build and buy paths, assess broad readiness, or agree where AI belongs. Start with a PoC when one use case is selected and a testable technical or economic question remains. Consulting chooses the investment; a PoC measures the riskiest assumption inside it.

You need examples that represent the task, difficult cases that could change the decision, permission to use the data, context for the correct outcome, and people who can judge disputed results. The amount varies by task and variation. The first step checks missingness, coverage, leakage, privacy, time drift, relevant groups, and whether a separate holdout can support an honest final evaluation.

There is no universal sample size. A narrow extraction task with a few stable layouts may need fewer examples than a prediction problem with many outcomes or a retrieval system covering thousands of documents. The useful question is whether the set represents the important input families and can estimate the errors that matter. We document the sample, its limits, and which claims it cannot support.

Begin with the current method and the cost of different mistakes. Then define the primary task measure, acceptable false positives and false negatives, review threshold, prohibited outcomes, latency, cost per useful result, and any minimum coverage. Agree which trade-offs are allowed before the final test. A single accuracy percentage can hide the failure that makes the workflow unusable.

Separate examples used for exploration and tuning from a final holdout that remains unseen until the approach is fixed. Record data versions, prompts, models, settings, rules, and changes. Group results by meaningful input types instead of reporting only an overall average. If the holdout is used repeatedly for tuning, it is no longer an honest independent check.

A no-go can be a successful outcome when it prevents a larger investment. The decision record explains whether the gap came from data, task definition, model capability, workflow design, reviewer burden, integration, or economics. It can recommend a narrower task, a human-assisted path, another approach, more evidence, ordinary automation, or stopping. The threshold is not rewritten after the result arrives.

Measure model or inference usage, retries, retrieval, storage, infrastructure, latency, and reviewer time during the experiment. Then model them against plausible volume, peak demand, provider pricing, monitoring, support, and failure recovery. The estimate should be expressed per completed useful result as well as a monthly range. A cheap demonstration can still imply an expensive production service.

Yes. The PoC can use a representative export, approved test environment, sandbox API, or a thin integration when that is enough to test the uncertain claim. If the decision depends on live permissions, latency, write-back, concurrency, or failure behaviour, those boundaries need a more realistic connection. Production migration, complete security hardening, broad user roles, and operational support remain separate unless explicitly included.

A focused AI PoC often takes four to eight weeks after usable data and reviewers are available. Timing moves with data access, labelling, the number of approaches compared, domain-expert availability, evaluation complexity, hardware or live-system dependencies, and formal security or risk review. The schedule, activities, evidence, dependencies, and decision date are agreed before the phase starts.

Every RaftLabs project starts at $9,500. A bounded first phase can cover one proof question, representative data review, an evaluation set, the smallest credible prototype, measurement, failure analysis, and a decision record. Price increases when the test needs extensive labelling, several model families, specialist hardware, complex data access, live integration, or regulated evidence. Scope and price are written down first.

You should receive the proof question, baseline, data and sampling record, evaluation method, thresholds, tested approaches, results by meaningful case group, failure taxonomy, latency and cost evidence, limitations, experiment assets where rights allow, and a production recommendation. The handover should also name what remains unproved, what production would require, and the condition for approving another phase.

The client owns project-specific code, prompts, configurations, evaluation artefacts, and agreed project IP, and controls its data and provider accounts where practical. Third-party models, services, datasets, and open-source components retain their own licence and service terms. Any data or asset that cannot be transferred because of rights or security constraints is identified before the phase starts.