Budget season produces a familiar line item. A number next to the word AI, approved with more confidence than definition.
Nobody in the room disagrees that the company should be spending something on this. Almost nobody has decided what the spending is actually for. That gap is where the money goes quiet.
Short answer: before you approve an AI line item, decide four things. Which workflow the money changes, what number proves it worked, who owns the result, and what happens if it does not work. A budget approved without those four answers is a hope with a dollar figure attached.
Why the line item is usually vague
AI spending gets approved differently than most capital requests. A new piece of equipment comes with a vendor quote, a maintenance schedule, and a clear before-and-after. An AI budget line often arrives as a category rather than a project, because the person requesting it is responding to pressure to have a position on AI rather than to a specific operational problem.
That is not a criticism of the person asking. It is a description of how the request usually gets generated, and it explains why so much AI budget produces so little trace by the following year.
Decision one. Which workflow
Not a department. Not a capability. A single process with a start and an end that the money is meant to change.
If the answer is still a category such as customer service or marketing, the budget has not been scoped yet, and approving it now means scoping it later under worse conditions, usually mid-year, usually after the first vendor conversation has already set expectations.
Decision two. What number proves it worked
Cycle time, cost per transaction, error rate, or a capture rate. Pick one before the money moves, not after.
This single decision is the difference between a project you can defend at the next budget cycle and one you can only describe in adjectives. Boards and lenders respond to numbers. Everyone else in the room responds to the word better, which means nothing on its own.
Decision three. Who owns it
A name, not a department. Someone with hours allocated to watch the thing after it launches, because systems drift and nobody notices drift they were never assigned to look for.
The most reliable predictor of an AI project losing its budget by year end is an enthusiastic sponsor and no operational owner. The sponsor approved the spending. Nobody was accountable for what it did next.
Decision four. What happens if it does not work
Write the stopping condition into the approval, not into a future conversation. A number below which the project gets adjusted or cut, agreed while everyone is thinking clearly rather than defending a sunk cost in October.
Projects without a stopping condition tend to get extended rather than ended, because ending one feels like admitting the January decision was wrong. A stopping condition removes that emotional cost before it exists.
What this looks like in the approval meeting
| Question | Weak answer | Answer worth approving |
|---|---|---|
| What is this for | Improving efficiency with AI | Cutting quote turnaround from six days to one |
| How will we know | The team will feel more productive | Turnaround measured weekly against a captured baseline |
| Who runs it | The operations team | A named operations lead with two hours a week allocated |
| When do we decide | We will revisit next year | A ninety-day gate with a defined pass and fail number |
The right column is not more expensive to produce than the left. It just requires the thinking to happen before the signature rather than after.
What to do if the budget is already approved without this
Go back and answer the four questions now. It costs a week and an uncomfortable meeting. The alternative costs the whole year and a harder conversation at the next budget cycle, when someone asks what the line item bought.
FAQ
Should every AI line item go through this process?
Anything above a trivial subscription cost, yes. A ten-dollar tool does not need a stopping condition. A build or implementation project does.
What if leadership wants a bigger number than one workflow justifies?
Approve the first workflow at its real size and hold the rest in reserve pending the ninety-day result. Funding ambition before evidence is how budgets become subscriptions nobody uses.
Who should be in the approval conversation?
Whoever owns the workflow, whoever will operate the system, and whoever signs the cheque. Leaving out the operational owner is the most common gap.
Does this slow down approval?
It adds a week upfront and removes months of ambiguity later. Most finance leaders take that trade happily once they see it once.
What if we genuinely do not know which workflow to pick?
Then the actual budget item is a readiness assessment, not a build. Fund the diagnosis first and scope the build from what it finds.
Where to go next: Before the next signature, run the four questions with whoever is requesting the line item. It is a short meeting that saves a long year.
