AI governance · Roles · Decision paths
AI governance rarely fails for want of rules. It fails because nobody is named who is allowed to decide — so the business unit proceeds without a decision.
Most companies start AI governance with a policy. A document is written, filed on the intranet, mentioned at a staff meeting — and changes nothing, because it does not answer the one question that actually comes up day to day: who decides whether this tool may be used?
Governance is not a rulebook. It is a map of responsibilities. It is finished when every recurring decision has a person attached to it and a way to reach them. Everything else — principles, value statements, voluntary commitments — can be added, but not as a substitute.
This article sets out what those decisions concretely are, why the EU AI Act fixes the role per system rather than per company, and how to organise that without a committee.
The role decides the obligations, not the technology
The EU AI Act attaches obligations to the role a company occupies in relation to a system, not to the system itself. The same software can trigger entirely different requirements for two companies — and different ones within the same company, depending on which department runs it.
The third row is the practically most important case and the least often documented. A company is not "a deployer"; it is one or the other per system. Fixing the role once for the whole organisation means fixing it wrongly for half the systems — and the earliest you notice is when somebody asks for the technical documentation that never existed for an in-house extension.
Group structures make this particularly murky. Where a parent buys a system and makes it available to subsidiaries, the allocation is not a formality: if the parent presents it to them under its own name, it can slip into the provider role itself, carrying the full set of obligations while the subsidiaries remain deployers. If the system is merely passed through, each entity stays responsible for its own use. The difference lies not in the technology but in how the system is offered internally — and that is precisely what is rarely written down anywhere.
Four decisions that need an owner
Governance condenses into four recurring decisions. Name those four and you have the core; everything else is elaboration.
May this tool be used?
The most frequent decision and the one that least often has an owner. With no named office, it is effectively made by whoever installs the tool. That is how shadow AI arises — not out of bad faith, but out of an open question of responsibility. The approval does not have to be elaborate; it has to be fast. Three questions usually suffice: what data goes in, what purpose does the system serve, and who at the provider is responsible?
Which risk class does it fall into?
A legal assessment on a technical basis — which is why it sits well neither in IT alone nor in legal alone. What matters less is who makes it than that the classification is recorded with a date, a reason and a name. Without that, it did not happen. It also matters that the classification concerns the use, not the product: the same tool can be uncritical in marketing and high-risk in HR.
Who oversees day-to-day operation?
Human oversight is not an attitude but a named person with competence, time and authority to intervene. Authority is the part missing in practice: someone allowed to doubt an output but unable to halt the process is not overseeing anything. Time is the other part — oversight expected to run alongside a full workload is the first thing to disappear under pressure.
When is something a reportable incident?
This decision is made under time pressure and is therefore made badly if it is first worked out during the incident. It needs a threshold agreed in advance, a person who determines it, and a route by which the provider and the authority are reached. It helps to run two or three examples from your own field through the question beforehand — a wrongly rejected applicant, an incorrect price quotation, a missed diagnosis. That discussion is level-headed in calm conditions and no longer is when it counts.
The quiet change of role
Decisions 1 and 2 are linked, and the most expensive mistake happens between them: a department puts a general-purpose tool to a new use — pre-screening job applications, say. That does not only change the risk class; the company slips into the provider role. With no office that notices changes in use, nobody will see the switch happen, because technically nothing changed at all: same software, same account, a different set of obligations.
Who gets the role — and who should not
The obvious answer is the data protection officer. They are already appointed, know the processes, and are practised at asking business units uncomfortable questions. In many organisations that is also the most pragmatic solution — but it has a limit worth knowing.
In their statutory function the data protection officer is independent and monitors compliance with data protection law. Making them the deciding office for AI approvals at the same time has them take decisions they would later have to audit themselves. For AI systems with no personal data involved — predictive maintenance, quality control on a production line — there is the added problem that these fall outside their remit entirely, while the AI Act obligations still apply.
Workable: a separate, named role
It does not need to be a full-time post or a title on a business card. It needs access to management, the right to stop a rollout, and a reliable deputy. The data protection officer is then consulted rather than deciding.
Risky: the role with IT alone
IT sees which systems are running but not what they are used for in business terms — and the classification hangs on exactly that. A purely technical remit systematically misses a change of purpose.
Unusable: "management decides"
Formally correct, practically a non-assignment. Decisions that require the top of the house for every new tool are either not taken or bypassed. Ultimate responsibility stays up top; the decision belongs further down.
What governance can do without a committee
An AI committee meeting monthly is the wrong answer for most mid-sized companies. It produces meetings, not decisions, and it is slower than the adoption of a new tool. Anyone told to wait four weeks for the next session starts a trial in the meantime — and the trial becomes production.
A named person instead of a committee
One role that makes decisions 1 and 2 and pulls in data protection, IT security and legal as needed. Availability is what counts: anyone waiting three weeks for approval will work around it.
A register instead of a policy
A list of every AI system in use with its role, classification, responsible person and date. It answers questions from authorities, whereas a policy only describes intentions.
Triggers instead of a fixed cycle
New data source, new purpose, major provider update, reorganisation. Events trigger a fresh review — in addition to an annual pass, not instead of it.
Half a page is enough to start: the named person with a deputy, the three approval questions, the list of systems, and the four triggers for a fresh review. That is not mature governance, but it is the difference between a company that knows its AI landscape and one that estimates it.
Practical note: the most honest test of your governance is a single question put to the room: which AI systems are in use here? If the answers from different departments diverge, that is not a communication problem — that is the finding.
The actual point
Governance is usually conceived too large and therefore never started. The four decisions above can be assigned in an afternoon, and they cover most of what the AI Act presupposes in organisational structure. What comes out of it is not a rulebook but a short list with names beside it.
What remains afterwards is maintenance: the list has to stay current, and the named person has to stay reachable. Both are unspectacular — and both are the difference between a company that answers an enquiry within days and one that first spends weeks working out which AI is even in use.
That this difference counts is written into the law: the degree of cooperation with the authority and the organisational measures taken are criteria in setting a fine. Governance is therefore not only the precondition for meeting obligations, but also the factor that decides the amount when it matters.
With SimpleAct
Every system with a role, a classification and a name.
EU AI Act and GDPR in one platform: register AI systems centrally, classify them rule-based, assign responsibilities and export audit-ready evidence at any time. Made in Germany, hosted in Germany.
Start your AI inventory →This article is for general information only and does not constitute legal advice. Last updated: 22 September 2026.
Tags
Ready to put EU AI Act compliance on autopilot?
SimpleAct helps you inventory AI systems, classify risk, and generate the required documentation automatically.
Kamill Jarzebowski | SimpleAct
Author · SimpleAct Team