Most AI Requests Aren't AI Problems
Many AI requests are process-ownership and decision-rights problems that arrive as tool requests. A five-question test to run before funding one, and where to route a request that fails it.
A request for AI rarely arrives as a problem. It arrives as a tool: we need an agent for supplier onboarding, we need a copilot for the bid team, we need a model that triages the support queue. The noun is already chosen. The only open question, apparently, is which product.
Ask what the tool is for, and keep asking, and a surprising number of these requests stop being about AI at all. Underneath you find one of three things: nobody owns the process end to end, nobody knows who is allowed to make the decision the process exists to make, or too many people are allowed to make it. None of those is fixed by a model. A model makes each of them faster, more visible, and more expensive.
The useful position is not that AI is overhyped. It is that an AI request is a process request with a technology attached, and the process half decides whether the technology half pays back.
Why this got worse, not better
Two things changed in the last couple of years, and both push in the same direction.
The first is that, for narrow tasks such as summarising, classifying or drafting, a working prototype no longer needs a project. Current tools put one within reach of a single person, working on the happy path, for an audience of themselves. That is useful. It also means the demo can arrive before anyone has mapped the process it automates, and when it does, the demo sets the agenda. The prototype answers can this be done? It says nothing about who carries it when it goes wrong?
The second is noise. Executives are asked to fund AI work against a backdrop of vendor claims, peer anxiety and a tooling market that reshuffles every quarter. Under that pressure the request gets framed around the product, because the product is the thing being argued about in public. “Which assistant should we standardise on” is an easier conversation than “who owns accounts payable exceptions”, and it is almost never the one that decides the outcome.
Three failure modes that look like AI problems
Nobody owns the process
A process that spans four teams usually has four owners of its steps and no owner of its outcome. Work moves between them by email, a shared mailbox, or a spreadsheet someone started in 2019. Exceptions are handled by whoever notices.
Automate one of those steps and you inherit the gap. The model drafts the supplier record perfectly; the record still waits three days because nobody is accountable for the handover after it. Worse, the model’s own exceptions now need somewhere to land, and in a process with no outcome owner they land nowhere. You have added a failure mode without adding anyone responsible for it.
Nobody knows who decides
Most valuable automation sits next to a decision: approve the refund, accept the supplier, escalate the ticket, release the payment. If you cannot name who holds that decision today, and on what criteria, you cannot delegate it to software either. An agent cannot be given authority that nobody in the organisation can say they hold.
This is the same constraint I argued for agents generally in An AI Agent Is Not a Service Account: a named sponsor and a bounded mandate come before the credential. A process with undefined decision rights cannot supply either.
Too many people decide
The opposite failure is a process with six sign-offs. Each approver adds a few minutes of work and a few days of queue. Point AI at the work and you save minutes; the days are untouched, because they were never in the work. They were in the waiting.
This one is easy to miss because the pilot looks good. Measured per step, the model is fast. Measured end to end, cycle time barely moves, and the business case quietly fails at its first quarterly review.
And a fourth, underneath all three: nobody can say what good looks like
You cannot evaluate a model against an outcome nobody has defined. If the team cannot describe a good resolution, a correct triage or an acceptable draft in terms someone else could check, there is nothing to test the system against. You will ship it on vibes and discover the definition later, in an incident.
The test I apply before anything is funded
Five questions. They take about half an hour with the right people in the room, and they are cheaper than the first sprint they replace.
- Who owns the end-to-end outcome? A named person, not a team, not a committee. If the answer takes more than one breath, stop here.
- Who can change the process? Not who runs a step. Who can remove one. AI earns most of its value by changing the shape of work, and that needs someone with the authority to change it.
- What does good look like, measurably? A resolution rate, a cycle time, an error rate, a definition of a correct output that a second reviewer would agree with. This becomes the evaluation set later, so it has to exist now.
- Where does the work actually flow today? Trace one real case from trigger to completion. If it passes through an inbox or a spreadsheet, that is the baseline the AI inherits, and the first job may be getting the work into a single digital flow at all.
- If the AI did its step perfectly, what becomes the bottleneck? If the honest answer is “the approval queue” or “the handover”, that is the real project, and the AI is a later phase of it.
How to read the answers:
| Result | What it means | What to do |
|---|---|---|
| Fails 1 or 2 | A process problem with an AI request attached | Name the owner, and give them the authority to change the process. Revisit in a quarter. |
| Passes 1–2, fails 3 | Owned, but unmeasurable | Define good and build the evaluation set before any build. |
| Passes 1–3, fails 4 or 5 | Owned and measurable, wrong baseline | Digitise or simplify the flow; scope AI as one component of it. |
| Passes all five | A process ready for automation | If the bottleneck is a rule, a lookup or a calculation, automate it conventionally. If it needs judgement over unstructured input, fund a small AI slice against the measure from question 3. |
A “not yet” is not a no
The point of the test is routing, not rejection. A request that fails question one has still surfaced something worth knowing: a process the organisation depends on that nobody owns. That is often worth more than the tool would have been, and it lands with the person who can fix it rather than in an AI backlog where it will wait behind forty other “agent” requests.
It also changes how the eventual AI work is scoped. Once the process has an owner and a measure, AI stops being the project and becomes one component of a wider change, sized to the step where it actually removes cost. That is a smaller, cheaper and far more defensible thing to fund than a platform bet justified by a demo.
The honest qualifier
The test can be abused as a veto, and it shouldn’t be. Some problems are AI problems from the first question: high-volume, well-owned processes where the bottleneck really is reading, classifying, extracting or drafting, and where a clear definition of good already exists. Those should move quickly, and running them through a process review they have already passed is just friction with a checklist.
The test also says nothing about baseline tooling. Giving staff a sanctioned assistant is a hygiene decision, closer to providing email than to funding a project. The condition that decides it is simple: if people are already using these tools on personal accounts, withholding a sanctioned one does not remove that usage — it only removes your view of it. The five questions are for funded work aimed at a process, not for the general-purpose licence.
The bottom line
Before asking which model, ask who owns the outcome and who decides. If nobody can answer, you don’t have an AI problem yet. You have a process with no owner, and adding AI to that only makes it fail faster.
Source: https://bradshaw.cloud/writing/ai-problem-or-process-problem/