AI Where It Earns Its Place: Four Questions Before You Fund a Pilot
· Daniel Șotropa
An AI pilot can be technically impressive and still fail to justify a second month of funding.
The problem often begins with the question used to approve it: “Can we build this with AI?” For many ideas, the answer is yes. That says little about whether AI is necessary, whether the result will matter or whether the organisation can operate it responsibly.
A better funding decision starts with the workflow and works towards the technology. Four questions are usually enough to expose whether an idea deserves a bounded pilot or should return to the whiteboard.
1. Does it improve a workflow people already need to complete?
Begin with the work, not the interface. Identify who performs it, what triggers it, what information they use, what decision or action follows and where delay or inconsistency creates a real consequence.
“An assistant for the operations team” is not yet a workflow. “Help a case handler compare an incoming request with the policy record before deciding whether it needs manual investigation” is closer. It names an operator, an input, a decision and a boundary.
This distinction protects the pilot from becoming a demonstration that is technically available but operationally homeless. If users must invent a new habit merely to access the feature, adoption becomes a second untested hypothesis. Sometimes that is justified, but it should be visible in the funding decision.
The workflow question should also reveal frequency and consequence. A rare task with little cost or risk may not deserve a new system. A frequent hand-off that delays customers, or a repeated judgement that creates costly rework, gives the pilot something material to improve.
2. What observable outcome should change?
Choose the evidence before choosing the model.
The outcome might concern elapsed time, rework, error rates, service quality, cost per case or the proportion of work requiring specialist attention. The right measure depends on the workflow; the important point is that the organisation can observe a baseline and compare the pilot against it.
Avoid measures that only describe the AI itself. Response time, benchmark accuracy and token cost can matter, but they do not prove that the operation improved. A system can achieve a good evaluation score while adding review effort or moving errors somewhere harder to detect.
A useful pilot therefore needs two kinds of evidence:
- system evidence: whether the output is sufficiently accurate, reliable and economical under realistic conditions;
- workflow evidence: whether people complete the work with a better result and can understand when not to trust the system.
Set the threshold before the trial. If the team decides what “good” means after seeing the output, an interesting demo can easily be mistaken for a successful pilot.
3. Could a simpler change deliver most of the value?
Test the unglamorous alternatives seriously.
Better source data, a deterministic rule, a database query, a redesigned form or the removal of an unnecessary approval may solve the constraint more cheaply and predictably. If one of those options delivers most of the value, it is not an inferior AI strategy. It is a better operational decision.
AI earns its place when the workflow contains variability that simpler methods cannot handle responsibly: unstructured inputs, language with meaningful ambiguity, a large search space or contextual judgement that cannot be reduced to stable rules at an acceptable cost.
Even then, the final solution may be mixed. Rules can handle known cases, conventional software can enforce the process and AI can address the variable step. Using AI only where uncertainty exists usually makes the system easier to test and operate.
The simplicity question is not designed to reject AI. It prevents the pilot from carrying complexity that the problem did not require.
4. Where must a person approve, override or investigate?
Control is part of the product, not paperwork added before release.
Define what the system may read, what it may change and which actions require approval. Decide how a person will recognise low-confidence or abnormal cases, correct an output, stop the workflow and understand what happened afterwards.
The necessary controls depend on consequence. Drafting an internal summary is not the same as changing a customer record, approving a payment or contacting someone outside the organisation. Autonomy should increase only when the evidence and operating controls justify it.
At minimum, the pilot boundary should make five things explicit:
- permissions and data access;
- human approval points;
- exception and escalation paths;
- logging and evaluation;
- failure, rollback and recovery behaviour.
This is consistent with the NIST AI Risk Management Framework, which treats context, measurement, human oversight and ongoing risk management as connected activities rather than a final compliance check.
A pilot should answer a funding question
The smallest responsible pilot combines the four answers: one real workflow, one observable outcome, the simplest credible mechanism and an explicit control boundary.
Its purpose is not to prove that the technology can produce an output. It is to reduce uncertainty about whether the organisation should make a larger commitment.
That distinction is commercially important. In June 2025, Gartner forecast that more than 40% of agentic AI projects would be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. The precise proportion is less useful than the reasons: each can be investigated before a pilot expands. Gartner’s published forecast also recommends pursuing agentic approaches where they deliver clear value rather than treating autonomy as the objective.
A pilot brief should therefore state:
- the workflow and people in scope;
- the baseline and success threshold;
- the simpler alternatives considered;
- the permissions, approvals and failure boundaries;
- the evidence required to continue, change direction or stop.
Stopping is a valid result. A pilot that demonstrates poor fit before integration, operating cost and organisational dependency accumulate has done useful work.
The concession: not every pilot begins with a financial metric
Some work is genuinely exploratory. A team may need to learn whether an emerging capability is feasible before it can estimate operational value with confidence.
That is a valid activity, but it should be funded and governed as research. Name the learning objective, cap the time and cost, keep it away from consequential production actions and define what evidence would justify a workflow pilot later.
Calling research a business pilot creates false expectations. Calling it research gives the organisation permission to learn without pretending it has already found the use case.
Make the four answers explicit
Before selecting a model, vendor or architecture, ask:
- Does this improve a workflow people already need to complete?
- What observable outcome should change?
- Could a simpler change deliver most of the value?
- Where must a person approve, override or investigate?
If the answers remain vague, the next responsible step is not a larger prototype. It is to clarify the workflow, the evidence and the boundary.
If the workflow is real, the application around it is worth building whether or not the AI component earns its place. That is where Haiori starts: the first useful version of the workflow, with the AI step included only when the four answers hold. If you have one in mind, tell us about the workflow.