What EU AI rules mean for a finance model

Finance teams tend to read EU rules on artificial intelligence in one of two ways: as somebody else’s problem, or as a reason to keep AI away from the numbers altogether. Neither helps. As the rules take shape, the habits that make a finance model trustworthy stay the same: documentation of what the model does and on which data, a log of what went in and what came out, evidence that it is accurate, a person who checks the numbers that feed decisions, and a clear owner. Auditors, boards and regulators increasingly expect exactly that, and a serious finance function should want it in place regardless.

Use matters more than the department

The useful question is not whether a model sits in finance, but what it is used for and whose situation its output affects. A model that forecasts your own company’s cash position, explains a variance against budget or estimates working-capital needs is analysing the business. Its subject is a P&L, and a P&L is not a person.

The trap sits elsewhere. A “CFO agent” that scores employee productivity, ranks people for a restructuring or allocates work based on utilisation has stopped doing controlling, even if the team building it still thinks of it that way. It now makes judgements about people, and that raises very different questions — from employees, from the board and from anyone reviewing how the system is used. The same goes for a model that moves from scoring business customers to scoring private individuals. What applies to a given model depends on how it is used; it is worth checking with someone who knows the rules for your sector.

Habits that apply to every model

Two habits are worth having whatever a model does, and both are easy to overlook.

People who understand the model. Whoever operates an AI system should understand it well enough to interpret its output and recognise when it is wrong. For a finance team this is not a training-video problem; it means the controller using the forecast can say what the model was given and where it tends to fail.

Labels on machine-written content. When text or figures were produced by a model and could be mistaken for human work, say so plainly. A board memo assembled by a model should be identifiable as such: the reader treats it differently, and should.

Why build it in from the start

Put together, what auditors, boards and regulators keep asking for reads like a description of a well-run analytical system: documentation of what the model does and on which data, logging of inputs and outputs, evidence of accuracy, human oversight of the numbers that go into decisions, and clear ownership of each output.

None of this needs a legal reason. Every one of those is something a CFO should already demand before trusting a number in a board pack. If the model revises a forecast, you want to know what changed in the inputs. If it flags a customer, you want the evidence. If it is wrong, you want to find out from your own logs rather than from the auditor. And when someone asks how good the model is, the answer should be a table of errors on months that have already closed, not a line from a sales deck — the method set out in testing an AI forecast on the months you already closed.

There is also a practical argument: uses drift. A system that starts as internal forecasting acquires a supplier-scoring feature, then a customer-scoring feature, and one of those eventually touches a person. Retrofitting logging and documentation into a system that was never designed to produce them is far more expensive than having built it that way.

A minimum bar for a controlling model

If you are evaluating or building one, the checklist is short:

• A clear description. What the model does, what it is not for, which data it reads and what it was tested on — written so that a new controller or an auditor can follow it.
• Input lineage. Every number traceable to a source system, table and timestamp.
• Decision logs. Not just the output, but the inputs and the version of the model that produced it — retained long enough to survive an audit cycle.
• Accuracy evidence. Backtests on closed months against a naive baseline, extended each time another month closes.
• Explained revisions. When a forecast changes, the system names the driver.
• Named human oversight. A person who owns each class of recommendation, reviews the numbers that go into decisions and can override them, with the override recorded.
• Deployment locality. Knowing which jurisdiction the inference happened in, because the moment personal data enters the picture, that question stops being academic.

The teams that will handle the next regulatory turn comfortably are the ones already generating this evidence as a by-product of running the system — not the ones planning a compliance project for the quarter before an audit.