When everyone can build with AI, who is responsible?

AI has made it significantly faster and cheaper to turn an idea into working code. As a result, employees in the finance function can now build tools themselves that previously required developers, a budget and a waiting period. This creates new opportunities, but also a new leadership challenge for the CFO: When is something a personal aid, and when has it become a solution that the company needs to take responsibility for?

For many years, the cost of development helped determine which ideas were pursued. If the finance function needed a new reconciliation, a specific report or a minor automation, it often required a specialist, a budget and a place in the IT department’s queue. As a result, many ideas were filtered out long before anyone had to decide whether they were actually good.

That mechanism is now disappearing.

With generative AI, a controller or analyst can get help writing a small programme, connecting datasets or testing a calculation model in just a few hours. This does not mean that development has become free, or that everyone is now a software developer. However, the work involved in writing the first version of the code now represents a much smaller part of the overall task than it did previously.

The scarce resource is therefore shifting. The key question is no longer just whether you can afford to build something, but whether you know what should be built, how the solution may be used and when someone needs to take responsibility for it.

This is a leadership responsibility that falls to the CFO, regardless of whether the finance function’s own solutions appear on the official digitalisation plan.

Imagine a controller who spends several days every month comparing two datasets because the company’s systems cannot automatically match the information. With the help of AI, she may be able to write a small programme that solves a large part of the task in a single afternoon.

Or consider an analyst who wants to investigate whether a new model based on business drivers could improve the company’s forecasts. Previously, this might have required a business case and a formal development process before the idea could be tested. Now, a preliminary model can be ready the same day.

This is fundamentally positive. Employees are getting closer to the solution, experimentation is becoming cheaper, and the finance function can test more ideas before deciding what is worth investing in.

The challenge arises when a personal aid gradually becomes part of the company’s operations. This rarely happens through a formal decision. It happens because the tool works.

A colleague asks for access. The tool is run again the following month. The result finds its way into management reporting, and after six months the organisation is dependent on a solution that only its creator understands. No one has necessarily acted irresponsibly, but the significance of the solution has changed without the governance keeping pace.

A calculation intended to be used once in support of an analysis has a relatively straightforward purpose. It needs to process the correct data and produce a result that the employee can verify before using it.

A solution that delivers figures for management reporting or the consolidated financial statements every month needs to do much more. It must be maintainable, its calculations must be explainable, and errors must be detected before they affect decisions or reporting. In addition, someone must be able to take over responsibility if the employee who built the solution takes on a new role or leaves the company.

These are not simply two different levels of quality. They are two different products with different requirements.

AI has primarily reduced the cost of the first step: creating a preliminary solution, testing an idea or automating a defined task. The cost of operating a stable, secure and documented solution has not fallen to the same extent, because it consists only partly of writing code. The rest includes testing, data quality, access management, monitoring, documentation, maintenance and organisational ownership.

The CFO should therefore not ask whether AI-generated code is good or bad. The relevant question is what role the solution is intended to play in the company.

A practical assessment can begin with one question:

Who could be affected if the solution makes a mistake or stops working?

If the consequences are limited to the employee who built the tool, and the employee can verify the result themselves, there should be plenty of room for experimentation. This could be a preliminary analysis, a one-off reconciliation or a prototype intended to show whether an idea is worth pursuing.

If colleagues, management, customers, authorities or financial reporting could be affected, the situation is different. The solution is no longer merely a personal aid, and the company needs to address ownership, controls and operations.

The number of users is a useful warning signal, because user number two often marks the beginning of broader use. However, it cannot stand alone. A solution with one user may be business-critical if, for example, it supplies figures for the annual financial statements, while a simple tool can be shared by several people without becoming critical.

The assessment should therefore be based on the consequences of an error, how the solution is used and the dependency that develops around it.

Once a solution works, it is tempting to keep expanding it. The employee asks the AI for another function, then for a bug fix and later for an adaptation to a new data source.

This may work for a long time. But if no one fully understands how the solution is structured, each change becomes more difficult to assess, and the company builds up a dependency that only becomes visible when something goes wrong.

This is technical debt in a new and more accessible form. The debt does not arise because AI wrote the code, but because a temporary solution was allowed to become permanent without a conscious decision.

Conversely, short-lived solutions do not need to be treated as if they are going to be operated for five years. A small programme that solves a one-off task and is then deleted does not require the same level of documentation and organisational ownership as an automation that forms part of monthly reporting.

The problem is therefore not that employees build quickly. The problem arises when no one decides whether what has been built should be discarded, further developed or taken over as a shared solution.

A general ban on self-built solutions is unlikely to be the answer. Above all, it would move activities out of management’s line of sight, while causing the company to miss out on the innovation that emerges when professionally skilled employees can quickly test their ideas.

Instead, the CFO should ensure two things.

First, employees must have an approved place to experiment. They should be able to test ideas without unrestricted access to production systems, sensitive information or the ability to send data to unauthorised services. The environment does not need to be large or complex, but it must be accessible, and employees must know how they are allowed to use it.

Second, the company needs a clear threshold for when a personal tool should be assessed as a shared solution. This could be when the tool:

• forms part of a recurring process

• provides the basis for other people’s decisions

• processes material or confidential data

• gains multiple users or is shared across teams

• requires ongoing maintenance

• becomes critical to reporting, controls or compliance.

Crossing the threshold does not necessarily need to trigger a lengthy approval process. It should trigger a conversation about who owns the solution, which controls are required and whether it should continue to exist as a local tool.

AI is not only changing how code is written. It is also changing who can turn a professional idea into a working solution.

This represents a significant opportunity for the finance function, because the best ideas are often found among the employees who understand data, processes and business needs in detail. When they can test their ideas more quickly, finance can solve more problems without waiting for a major system project.

However, technology does not remove the need for professional and managerial judgement. On the contrary, judgement becomes more important when more people can build, and when the distance from idea to solution becomes shorter.

The CFO’s task is therefore not to stop development or turn every controller into a programmer. The task is to create an environment in which the finance function can experiment quickly, while ensuring that the company recognises the moment when a useful tool becomes a solution that someone needs to own.

Code has become cheap. Responsibility and knowledge have not.