A board member signs off the income statement and understands every line. They sign an insurance policy and know what it covers. But when they sign off the use of an artificial intelligence system, they often cannot see what it really does without someone from the technical team translating it for them. And a translation that depends on whoever built the system is not supervision: it is trust. The good news is that this can be changed —not with more technical meetings, but with order.

The problem is not technical; it is one of visibility

The usual complaint —"I do not understand what the AI does"— sounds like a knowledge problem, as if it were enough for someone to explain it better. It is not. The problem is that the information about what each system does, what data it uses and what can go wrong lives scattered across code, spreadsheets and the heads of two or three people. There is no single place where leadership can look and see. That is why it depends on the technical director translating each time, and why visibility evaporates the moment that person is on holiday or moves on.

We call this a problem of traceability: the ability to follow, in writing, what a system does and why. When it exists, decision-makers need no interpreter; when it does not, no supervision is possible however many meetings are held. It is the same idea that underpins AI governance for decision-makers: the standards are a dead letter if whoever signs cannot see what they are signing.

Three things a board should be able to see, without an interpreter

There is no need to understand the model from the inside. What is needed is three answers, available in writing and in plain language:

  • What each system does and what for. The starting point is the simplest and the one almost no one has: the list of the AI systems the company uses, with their purpose. Without that inventory, everything else is guesswork.
  • What risks it runs and how they are controlled. The European AI Act requires, for high-risk systems, a living record of what can go wrong and what is done to prevent it, and written procedures for managing the data that feeds the system (Source: Regulation (EU) 2024/1689, art. 17(1), EUR-Lex, 2024). A board should be able to open that record and read it, not have it summarised.
  • When the system decides on a person on its own. If an AI decides by itself about someone —a loan, a hire— with significant effects, that person has the right to human intervention and to contest it (Source: Regulation (EU) 2016/679 (GDPR), art. 22, EUR-Lex, 2016). Knowing in which systems this happens is not a technical detail: it is the responsibility of whoever leads.

To this is added an obligation a board often does not know about: Article 50 of the AI Act requires, in certain cases, disclosing that one is dealing with artificial intelligence —for example, in a chatbot or in generated content (Source: Regulation (EU) 2024/1689, art. 50, EUR-Lex, 2024). It is not the same transparency as the GDPR's (informing a person about their data); confusing the two is one of the errors a well-informed board avoids.

How it changes: the artefact, not the meeting

The solution is not a clearer quarterly presentation. It is that each of those three answers exists as a document leadership can open and point to —the inventory of systems, the risk record, the list of automated decisions. When the documentation is ordered like this, visibility stops depending on a person and becomes a property of the system. The architecture, ordered so that anyone can check what it does, is at once what the board reads and what the regulator asks for: the same work serves both to see and to defend.

That is what it means for a business to be AI-operable: documented so that both a person and a system can read what it does and how it is controlled, without depending on anyone's memory. The same base that lets AI actually operate the business is the one that lets decision-makers see it.

Not theory

We operate an artificial intelligence system in production in a regulated sector, with its management system documented in line with the international standard ISO/IEC 42001 —an AIMS, or AI management system, with an owner, a risk record and review— and with its transparency layer running at runtime, not on paper. The system runs, it passes audit, we built it. That is the proof that the visibility described here is not an aspiration: it is a state a system is brought to by work of order, and we leave it that way by design (technical reference).

What to do with this

The question to take away is not "do I trust my technical team?" —you probably do—, but another one: "if that person were not here tomorrow, could I open a document and see what our AI does?". If the answer is no, you do not have a talent problem: you have a problem of order, and it is fixed by ordering. In our method that inventory is the first thing put in writing, precisely so that seeing what your AI does never depends on someone being available to tell you.