Intelai
AI Projects Fail on Decision Rights
The model is rarely why a pilot dies. The reasons are who owns the number, who can say no, and what happens when the output is wrong.
The postmortem for a failed AI project usually blames the data. The data was bad, or the model was not accurate enough, or the users did not adopt it. Those are symptoms. The cause is almost always that nobody wrote down who was allowed to decide.
Decision rights are dull, and they are the difference between a pilot that becomes a capability and a pilot that becomes a slide in next year's strategy deck.
Four questions before a pilot
I have watched projects spend six months on model selection and zero hours on these four questions. Each one has a wrong answer that sounds reasonable.
Who owns the number the model improves? Not the project sponsor. The person whose performance is measured by that number. If the answer is a committee, the project has no owner, and it will be deprioritized the first time it competes with something that does.
Who can turn it off? A system that makes decisions needs a stop. The stop should be a named role with the authority to use it, not a change control board that meets monthly. If turning off the system is harder than living with the error, the system is not controlled.
What does a wrong answer cost? In money, in time, in a legal exposure, in a person's benefits. The answer sets the accuracy bar and the review process. A project that cannot state the cost of an error cannot set a threshold, and will pick one that feels safe and is arbitrary.
What is the fallback? The process that runs when the model is unavailable, wrong, or withdrawn. A system with no fallback is a single point of failure that the organization has agreed to accept without saying so.
Data quality is a symptom
"Bad data" is the most common explanation and the least useful one. Data is bad because a field has no owner, a definition is ambiguous, or an entry step has no validation. Those are organizational facts, and they do not change when a model arrives.
The pattern repeats. A team discovers that two systems disagree about a customer identifier. The project adds a matching model to reconcile them. The model works, the disagreement remains, and now there is a probabilistic layer on top of an unresolved definition.
The better move is to fix the definition, or to name the disagreement and decide which source wins. If neither is possible, the project now knows its real scope: it is a data governance project with an AI component, not the reverse.
A useful diagnostic is to trace one record end to end, by hand, from source to output. Every place the record is transformed is a place where a rule exists. If nobody can name the rule, that is the finding.
Evaluation is a contract
An evaluation is not a report card. It is an agreement about what "good enough" means, made before the results arrive.
Four elements make it an agreement rather than a demo.
A held-out test set with a named owner. The cases should be representative of production, owned by the program, and not shared with the vendor for tuning. If the vendor built the test set, the score measures the vendor's ability to build test sets.
A metric tied to the decision. Accuracy on a balanced test set is a research metric. The production metric is precision or recall at the threshold where the system actually acts, or cost per accepted answer, or time to resolution. Pick the one the owner is measured on.
A failure review. Sample the errors and read them. A model that is wrong in a consistent, recognizable way is manageable. A model that is wrong unpredictably is not, even at a better aggregate score.
A drift plan. What is measured after launch, how often, and who looks. A model is a snapshot of a relationship that changes. Without monitoring, the first sign of drift is a user complaint.
NIST's AI Risk Management Framework (opens in a new tab) is a useful structure for this work, not a compliance ritual. Its functions map onto the four questions: govern the decision rights, map the context, measure the behavior, manage the response.
The organizational pitfall
The technical pitfalls are well known: overfitting, leakage, distribution shift, integration debt. They are real and they are documented.
The organizational pitfall is less discussed and more common. A project is funded by one office, used by another, and evaluated by a third. The sponsor wants a success story. The user wants less work. The evaluator wants a defensible number. Nobody owns the outcome, so the project optimizes for the artifact that each party can point to.
That is how a system with good benchmark scores ends up unused. It solved the sponsor's problem, which was the appearance of progress, and not the user's problem, which was a queue.
Write the four answers down
Before a pilot starts, write four sentences. Who owns the metric. Who can stop the system. What an error costs. What runs if the system is gone.
If the four sentences are specific, the project has a foundation. If any of them is a committee, a process, or a hope, the model is not the risk.
The technology will change. The decision rights will not. That is why they are worth the meeting.