perspective / AI ownership

Your CFO owns the AI budget. Who owns the process?

In September 2026 the IBM Institute for Business Value published a survey of 1,500 CFOs. 62% of respondents say their role has expanded into enterprise technology or AI strategy leadership. Yet only 6% describe their finance function as transformation-ready — with AI consistently embedded into finance workflows and decision-making at scale. Those are the study's numbers and the study's framing.

What follows is my own thesis, not a conclusion of the IBM study: a CFO can be accountable for justifying and controlling the AI investment, but a company still needs an owner for the passage from idea to a measured change in one process. Budget authority and execution ownership are two different jobs. One person has to carry the second one, or the first one buys a lot of experiments.

Three responsibilities, three different jobs

This is how I draw the split in practice. It does not mean every company must hire a CAIO — it means these three jobs must have names attached to them:

• The CFO sets the investment criteria and the acceptable outcome: how much may be spent, what counts as payback, which risks the company will not carry. The CFO should not have to choose between vendors' architectures.
• The process owner is accountable for how the team actually works and where the exceptions live. No automation survives contact with a process nobody on the floor can explain.
• A fractional CAIO — the role I take — assesses feasibility, architecture and vendor claims, and leads execution within the agreed scope. Not a full-time executive; one accountable person, on a defined cadence.

A scenario from machinery trade

Consider a concrete situation, as a scenario — not a documented case study or a client result. An inquiry arrives about a used machining centre: three photos, no nameplate shot, "probably 2015, somewhere in a warehouse in Germany", and the customer wants a price and a delivery date this week.

Before anything is automated, I would measure the process as it runs today: how long one inquiry takes end to end, how many arrive with missing data, how many steps and people it touches, how often the quote turns out wrong, and how quickly the customer gets an answer. If you do not know those numbers, you cannot say afterwards whether the pipeline helped.

Then the automation boundary becomes obvious. Identification from photos, cross-checking comparable offers, pulling missing parameters, drafting the offer document — that is pipeline work. The decisions stay human: the price and its margin, what to say when the year does not match the photos, whether to quote a machine we have not seen running at all. A pipeline that hides those decisions is worse than no pipeline.

After the pilot, "it worked" needs a definition written before the pilot started: fewer handoffs per inquiry, a faster first answer, fewer quotes sent with wrong parameters. If those numbers do not move, the correct decision is to stop — not to extend the pilot.

How I work: select → inspect → value → pilot → measure → scale or stop

The method is deliberately small. Select one process that hurts. Inspect it the way I describe in my reverse engineering method: real inputs, real exceptions, and a hard look at any "AI system" already claimed to run it. Value it — cost, savings and failure modes at an order of magnitude. That step is the paid process valuation, and it ends in a verdict: do it or don't. Pilot one pipeline on real data. Measure against the numbers collected before the pilot. Then scale or stop — both are legitimate outcomes, and "stop" is cheaper than a second year of an unloved pilot.

Start with one process

If you want this applied to your company, the first step is the process valuation — €4,000, 10 business days: one process, a written verdict you can act on, whatever you decide next. And if the question is not one project but who owns AI decisions quarter after quarter, there is the fractional CAIO retainer — one day a week, minimum three months, two client slots.