AI Pilot Cost: What a Pilot Should Cost and What It Should Prove

AI pilots are inexpensive to start and frequently fail to justify anything, which is what makes them expensive. A demonstration that impresses a room and leaves the organisation unable to decide whether to proceed has consumed scarce attention without producing a decision. This guide covers what a pilot should cost and what it must establish, drawing on FISTA Solutions' AI enablement work. It complements ai pilot checklist and ai pilot to production.

What should a pilot prove?

A specific question, stated before it starts. Does this approach reach the accuracy this use case requires, on our data, within the latency and cost the business can accept.

A pilot without that question produces a demonstration that everyone interprets according to what they hoped for. The stakeholder who wanted it to work sees success; the one who did not sees an unconvincing toy. Neither can be argued with, because there was no criterion.

Element	In scope	Why
Stated success criteria	Yes	Otherwise no decision follows
Real data	Yes	Synthetic data proves nothing
Evaluation against labelled cases	Yes	Turns demo into evidence
Production permissions model	Yes	Frequently determines feasibility
Latency and cost measurement	Yes	Determines viability
Full integration	No	Defer, but understand the surface

Why is data access the constraint?

Because getting approved access to real data takes longer than building. Permissions must be granted, owners must agree, privacy review may be needed, and the data must be extracted in a usable form.

Pilots scheduled on engineering estimates slip before any engineering starts. Beginning the access conversation on day one, in parallel with everything else, is the single most effective scheduling decision available.

What makes evaluation essential?

It is what converts a demonstration into evidence. A labelled set of representative cases, stated criteria, and a measured result can be discussed, challenged, and acted on.

Without it, the pilot's output is an impression. Impressions do not survive a sceptical stakeholder, and they certainly do not support a production investment decision. See what is an evaluation rubric.

Why include production constraints?

Because they frequently determine feasibility. A pilot run on a flat copy of data with no permission model proves the approach works in conditions that will never exist. If the production requirement is per-user entitlement filtering, and that turns out to be difficult against the source systems, the pilot proved nothing relevant.

The same applies to latency, residency, and cost. Those should be measured in the pilot rather than assumed manageable afterwards.

What should be deferred?

Full integration, production hardening, scale, and the long tail of edge cases. A pilot demonstrates feasibility on the main path; it does not need to handle everything.

The distinction that matters is between deferring engineering effort, which is fine, and deferring a constraint that might make the approach infeasible, which is not.

What makes a pilot expensive?

Proving nothing. The direct cost of a pilot is usually modest; the expensive part is the time of the people involved and the organisational attention consumed, and both are wasted if no decision follows.

A pilot that concludes clearly that the approach does not work is a good outcome and a cheap one. A pilot that concludes ambiguously is the expensive failure.

How long should one run?

Weeks rather than months. A pilot that runs for a quarter has become a project without the governance of one, and its findings arrive too late to inform the decision they were meant to support.

Time-boxing forces scope discipline, which is the main protection against a pilot that expands until it is indistinguishable from a build.

What should you do first?

Write the question the pilot will answer and the criterion for answering it, in one sentence each, and get the sponsor to agree them. If that cannot be done, the pilot is not ready to start.

Who should be in the room?

The sponsor who will decide, someone from the function whose work is affected, and whoever owns the data. That third person is the one most often omitted and the one most likely to determine the schedule.

Pilots run entirely within a technology team produce results the business does not trust and cannot act on, because nobody who does the work was involved in judging whether the output was any good.

What happens after a successful pilot?

The gap between pilot and production is where most programmes stall. A pilot proves feasibility on the main path; production requires the permission model, the integration, the evaluation in operation, the monitoring, and the support arrangement — and those are the bulk of the work.

Estimating that gap honestly at the point the pilot succeeds, rather than treating production as a small increment, is what prevents the pattern where an organisation accumulates successful pilots and deploys none of them.

How FISTA Solutions helps

FISTA Solutions scopes pilots around a stated question and agreed criteria, starts data access conversations on day one, builds evaluation into the pilot rather than after it, includes production permissions and latency constraints in scope, and time-boxes tightly enough that a decision follows, through AI enablement, AI agents, and forward deployed engineers. The record behind the approach is 150+ projects for 50+ companies with 47% efficiency gains.

To run a pilot that produces a decision, message FISTA on WhatsApp, or read ai pilot checklist.