Let the AI reason. Let the system do the sums.

I spent this morning at Vena’s “How AI is Influencing Finance” event at County Hall, and the second session was from Jed Griffiths, Chief Digital Officer at Microsoft UK. His title was “The Frontier isn’t a destination. It’s a decision.” There was a lot in it, so I’ve picked out the bits I think a CFO can actually do something with.

His opening point was that the conversation has changed. A year or two ago the questions were all about exploring: what can the technology do, where should we try it, do we act now or wait six months? Now the question is how you operationalise it - how AI becomes part of how the business actually runs. And the questions change with it. What is it worth, and what will it cost to run? How do we keep people in the loop? What would we need to see to rely on it? And my favourite: where can AI reason, and where must the answer be exact?

Hold on to that last one - I’ll come back to it.

His view was that most organisations aren’t short of technology. Gartner says 81% of CIOs expect agentic AI to be deployed across the enterprise by mid-2027, while MIT’s NANDA research says around 5% of enterprise AI pilots deliver measurable profit-and-loss impact today. In his words, it’s an operating model problem, not a model problem.

He illustrated it with electricity. When factories first got electric motors, they bolted them onto the old line shafts - the long overhead drive shafts the steam engine used to turn. The productivity came decades later, once someone redesigned the factory floor around the motor. Plenty of organisations are doing the same with AI, sitting it on top of the process they already had. Which ties in with something I wrote in my notes: you need to know your processes, and optimise them, before you start on an AI transformation, if you want the improvement.

Then came the part he called tokenomics, which is where finance should start paying attention. A token is a small unit of AI work. A chat assistant answers once, so its cost is fixed and fairly predictable. An agent loops - plan, act, check, and round again - so its cost scales with the work (his example was reviewing 400 supply contracts against company policy and escalating the exceptions to a lawyer). His advice was to stop measuring AI against the IT budget and start measuring it against the cost of a person doing the same work, and then to allocate tokens like headcount: decide who gets them, how many and for what, and recalibrate often, because today’s price won’t be next year’s. And it won’t all sit in IT - he expects it to turn up across the P&L, in the cost to serve, the cost to sell, and in some cases the cost of what you sell.

If that doesn’t sound like a budgeting problem, I don’t know what does. Somebody in finance is going to own that line.

Now, back to “where must the answer be exact”. He split the architecture into layers. At the top is a probabilistic layer - the AI model. It reads the question, works out what to run, and explains the result. Underneath is a deterministic layer: calculation engines, business rules and classic machine learning models, each one tested and under change control. That’s where the facts come from. And at the bottom, governed data, identity and access, policy and the audit log.

The model calls a function. The function returns the figures, with their source. The model doesn’t do the arithmetic.

That gets you three things. Every figure can be traced back to a tested calculation. It’s far cheaper, because a calculation engine costs a fraction of what a language model does to run. And the model can be swapped for a better one without re-testing all the arithmetic.

For anyone in FP&A this should feel very familiar, whatever you plan in. The numbers you rely on - actuals, budgets, allocations, the forecast everyone has signed off - need to come from somewhere tested and controlled, whether that’s your ledger, a planning tool or a well-built spreadsheet with proper checks in it. The temptation is to paste the data into a chatbot and ask it to work out the forecast. The better approach is to keep the calculation where it’s been tested, and let the AI fetch the figures and explain them. Let the AI reason. Let a tested system do the sums.

On where to spend the effort, he split the work into two lanes. A fast lane, with thousands of everyday uses - back-office efficiency in finance, HR, supply chain and quoting - where his advice was to adopt a platform, because there’s little to gain from building it yourself. And a deep lane, with a handful of uses chosen deliberately: the places where you compete, and where the knowledge is your own. Build only what only you should build. I liked his point that you should judge those against your own definition of good - most teams have never written theirs down.

One last thing I’d underline twice for finance. He talked about managers needing to build judgement in their people, including those early in their careers. A lot of finance judgement has traditionally been learned by doing the groundwork first. If the agents are doing the reconciliations, somebody needs to work out how the next generation learns what a wrong number looks like.

So before anyone builds anything, ask the question: where can the AI reason, and where must the answer be exact? Then make sure every figure that has to be exact comes from a tested calculation, not from the AI!