Deal Skipper

Where AI actually fits in finance operations

AI & Business 7 July 2026 4 min read

The interesting question is not what AI can do. It is which parts of a finance process should be probabilistic at all.

Most conversations about AI in finance start in the wrong place. They start with what the technology can do, then look for somewhere to apply it. That order produces demonstrations rather than working systems.

The more useful question is narrower and slightly awkward: which parts of this process are we willing to make probabilistic? Because that is the actual trade. A deterministic automation gives the same answer every time and you can prove why. A model gives a very good answer most of the time and the reasoning is not fully inspectable. In finance, that distinction is not academic.

Where the boundary sits

I find it helpful to sort steps into three groups.

  • Rules that are written down and stable. A tolerance, a threshold, a routing rule. These do not need AI. They need automation, and they need it to be auditable. Using a model here adds cost and removes certainty.
  • Judgement that a person makes quickly using context. Reading a messy remittance description, deciding which of three near-identical records is meant, spotting that something looks unusual. This is where language models genuinely help, because the input is unstructured and the pattern is real but hard to write down.
  • Judgement with consequences that require accountability. Approving, releasing, writing off, signing. A model can prepare the decision. It should not be the one making it.

Most of the value I have seen sits in the second group, and most of the disappointment comes from applying AI to the first and the third.

Before asking whether AI can automate a step, ask whether that step should exist in its current form.

Preparation, not decision

The framing that has worked best for me is that AI prepares work and people decide it. A model that reads an unstructured document and proposes a structured interpretation, flagged with its confidence and shown alongside the source, is genuinely useful. It removes the tedious extraction while leaving the accountable step where it belongs.

That design has a side benefit. When the model is wrong, the reviewer catches it, and the correction becomes a signal about where the process is ambiguous. A fully automated version would have absorbed the error silently.

The unglamorous wins

Some of the most useful applications are not the ones that appear in vendor material. Drafting and structuring documentation. Turning a rambling requirement into a first-pass process description that a stakeholder can correct. Explaining an error message to someone who does not have the background to interpret it. Summarising a long thread so a decision-maker can enter a conversation already informed.

None of it is dramatic. All of it removes friction from work that otherwise gets skipped, and it is available now without a governance programme.

What has to be true first

AI is unusually sensitive to the quality of what it is fed. A process with inconsistent data, unclear ownership and undocumented exceptions will not be rescued by a model — it will produce confident output built on the same shaky ground, and the confidence will make the problem harder to see.

So the sequence stays what it always was. Understand the process. Remove what should not be there. Standardise what remains. Then decide, step by step, which parts benefit from being probabilistic.

Governance is not optional here

Finance carries obligations that do not relax because a model was involved. If a figure ends up in a reported number, someone has to be able to explain how it got there. That argues for a specific design pattern: the model's contribution is visible, the source document is one click away, the human decision is recorded, and the whole path can be reconstructed months later by someone who was not there.

It also argues against quietly inserting AI into an existing control. If a step was a control before, it is still a control, and changing how it is performed is a change that needs to be agreed with the people accountable for it rather than discovered by them.

The other governance question that comes up early is what happens to the data. Which service processes it, where it sits, whether it is retained, and whether it can be used for training. Those answers determine what you are allowed to build long before the technical design does, and it is much cheaper to ask at the start than to unpick a working pilot afterwards.

Staying close to it

I use these tools daily and I keep learning them deliberately — through structured study, and through the wider AI community. In July 2026 I took part in a Guinness World Records event for the most users in an artificial intelligence video lesson, organised by Kanz with the Ministry of Human Resources and Social Development in Saudi Arabia, alongside 14,075 other participants.

What I take from working with them constantly is fairly unromantic. These tools raise the floor on speed. They do not raise the ceiling on judgement. They are most valuable to someone who already knows what a correct answer looks like, because that person can tell when the output is wrong.

If you are deciding where to start: pick a step where the input is unstructured, the output is checked by a person anyway, and being wrong is recoverable. That is where AI earns its place first.

AI for Business Generative AI Finance Automation Microsoft Copilot AI Governance
Deal Skipper, Global Process Automation Expert

Deal Skipper

Global Process Automation Expert

Automation · AI · Data Analytics · Continuous Improvement · Enterprise IT

All insights