From using AI to directing it: control as a management capability

If your company uses artificial intelligence, you know the scene: the system works, produces results, saves time. And yet there is a question most of those who lead cannot answer with precision: if tomorrow you wanted that AI to do something different — another criterion, another tone, another limit — would you know how to make it happen, and could you verify that it obeyed?

That question separates two very different relationships with the same technology. Using an AI is extracting value from what it does by default. Directing it is what you already do with any team in your charge: setting what you want, verifying that it is met, and correcting when it drifts. The first relationship is the common one. The second is the one that turns AI into a management asset — and it is also, even if it is not the motive, what European regulation ends up asking for.

Using is not directing

Think about how you direct people. You do not explain a good professional's trade to them: you set objectives, review results and correct course when needed. No one would call it management to hire someone capable and never speak to them again. And yet that is, with AI, the situation of many competent companies: they adopted a tool that performs, verified that it performs, and left it operating with its factory behaviour. It is not negligence; it is that almost the entire public conversation treats AI as something to be used, not something to be directed.

There are three signs that a system is being used but not directed:

• The behaviour is not written anywhere you can open. It lives in a supplier's configuration, in the habits of whoever uses it, or in settings no one remembers making.
• When the result is unconvincing, the reaction is to rephrase the request or resign yourself. There is no place to correct the criterion once and for all; the correction has to be repeated every morning.
• If you asked why the system answered what it answered, the answer would depend on someone's memory. There is no record to consult.

None of the three is a technical failure. All three are an absence of direction: the machine acts, but no one has built the place from which to command it.

Directing an AI: four concrete capabilities

Directing artificial intelligence does not require knowing how to program, just as directing a factory does not require knowing how to weld. It requires four capabilities, all of them managerial:

Shaping it. That the instructions governing the system — what it does, by what criterion, what it is forbidden to do — exist in writing, in language you understand, and that changing them is within your reach. A well-built AI obeys documents, not habits: if the commercial criterion changes, the document is changed and the system changes with it. It is the difference between requesting and establishing.

Understanding it. Being able to read what it does and why, without asking for a translation. Not the model's inner workings — no one reads those — but its behaviour: what it decides, on what data, within what limits. How that visibility is achieved without depending on the technical team is what we cover in Your board cannot see what your AI does; here the essential point suffices: you cannot direct what you cannot see.

Correcting it. When the system gets it wrong, or when the business changes, the correction is written down, the system incorporates it, and it is recorded. The difference from repeating the warning each time is the same as the difference between training a team and chasing it.

Delegating within limits. Deciding what the machine may resolve on its own and what requires a person — and having that limit documented, not assumed. It is the same decision you already make when you define each role's signing authority.

If these four capabilities sound like directing people, that is because they are. The novelty is not in the management; it is that the machine, unlike human talent, obeys what is written with total literalness. That is why the quality of the direction depends, more than with any human team, on the quality of what is written.

What the regulator asks for is what a good manager would do

Here comes the part that is usually told backwards. The usual conversation presents AI governance as a burden: documents the regulator demands and the company produces to protect itself. Seen from the direction of the business, the order is the reverse: what the rules ask for is, almost point by point, what a demanding manager would set up anyway.

The EU AI Act requires that high-risk systems be designed so that people can oversee them effectively: understanding their capabilities and limitations, correctly interpreting their output, deciding not to use them, and intervening in their operation or stopping them (Source: Regulation (EU) 2024/1689, art. 14, EUR-Lex, 2024). That is not paperwork: it is the legal definition of being able to direct. The same regulation requires, since February 2025, that those who provide or use AI systems ensure a sufficient level of AI literacy among their staff (Source: Regulation (EU) 2024/1689, art. 4, EUR-Lex, 2024) — put plainly: that whoever works with the machine understands what they are working with. And the international standard ISO/IEC 42001 defines an AI management system — what it calls an AIMS: an owner, processes, review and records — which is, in essence, the structure of direction this article describes, formalised so it can be certified.

The practical consequence is the one that gives this article its title: an AI you can shape, understand and correct already has most of the work done that an auditor would come to check. Compliance is not the motive for directing it; it is the consequence of directing it well. Whoever governs their AI for the auditor produces papers; whoever governs it in order to direct it produces control — and the papers come out of the same work. The three standards, translated into management questions, are on our governance page.

Direction is exercised over artefacts

All of the above has a material condition. Directing requires a place from which to exercise direction: the documents the system obeys, the record of what it decides, the written limits of what it may do on its own. We call that state being operable by AI: the business documented so that both a person and a system can read what is done and how it is controlled (we define it without jargon here). When that foundation exists, directing the AI stops being an aspiration and becomes a concrete act: open a document, change a criterion, see the effect.

This is not theory. We operate an artificial intelligence system in production in a regulated sector, and it is directed exactly like this: its behaviour is written in documents the system obeys, its limits are documented, and every correction is written once and remains. When something must change, the document is changed — no one's memory is relied upon. The system runs, it passes audit, we built it (technical reference).

The question to take away

If you want to know whether your company uses its AI or directs it, you do not need an audit. You need to answer a single question: if tomorrow I wanted the AI to behave differently — a new criterion, a new limit — do I know where to change it, and will I be able to verify that it obeyed?

If the answer is yes, you direct; and the evidence a regulator or a board would ask for already exists, because it is the very instrument of command. If the answer is no, the problem is neither the technology nor your team: it is that no one has yet built the command post. In our method, that command post — the written instructions, the limits, the record — is the central deliverable, precisely because it is what separates having AI from directing it.