A team lead at an insurer gets a question from IT: which AI tools does your team use? She answers Copilot, because that is the agreement. The same afternoon she watches a colleague summarise a set of policy conditions in a browser tab she does not recognise, and she has no idea whether anything has been decided about it.
That is the question AI governance is about. Not whether the organisation has an AI policy, because it does. Whether that policy covers the tab that is open.
AI governance is the set of decisions, agreements and evidence an organisation uses to handle AI responsibly. For most organisations that is not about building models. It is about the everyday use of existing AI services by employees: which tools are actually used, what has been decided about them, whether people know that decision at the moment it matters, and whether you can show afterwards that it worked.
#Where does the term come from, and which part do we mean?
Look up "AI governance" and you find four disciplines, each meaning its own part.
Data scientists mean model governance: is the model validated, how does it behave on new data, is it biased, who may release a new version. Risk and compliance people mean a management framework with roles, a risk register and a standard such as ISO/IEC 42001. Security teams mean access, data flows and vendor assessment. Lawyers mean the AI Act and the GDPR.
All four are right, and all four look past something. In most organisations nobody builds a model. What happens instead: a few hundred people use ChatGPT, Copilot, Gemini, a translation tool and a transcription tool, every day, mostly with good intentions and sometimes with customer data. That use is the largest share of the AI the organisation has, and it is the part the four disciplines say least about.
That part is what this article, and the rest of the AI governance topic, is about: the governance of everyday use.
#Which questions belong to the governance of everyday use?
Six, and the order is not accidental.
- Which AI tools are actually used? Not which were requested or licensed, but which get opened.
- Which of those tools are allowed, and which have no decision yet?
- What sensitive information passes through during the work: customer names, citizen service numbers, medical details, contract values?
- How do staff know what the organisation has decided, at the moment they open a tool and not only on the day of the training?
- Is the approved alternative also the alternative people actually use?
- Can you show that the policy is applied in practice, with figures and not with a signature under a document?
The first three are about looking. The second is the actual decision. The fourth and fifth are about help at the moment of work. The sixth is about accountability. Whoever can answer all six has governance; whoever only has a policy usually cannot answer any.
#Why is the order not arbitrary?
Because each step produces the material for the next.
Decide before you have seen what is in use, and you write a policy about last year's tools. It names Copilot and misses the translation tool half the department has since picked up.
Try to help staff before a decision exists, and you produce notices nobody can act on. "Careful, this is an AI tool" without saying what the organisation thinks of it is noise.
Try to show the policy works without a decision per tool, and you have a count, not evidence. Three hundred visits mean nothing while nobody has recorded whether the tool was allowed. Why that distinction makes all the difference to an auditor is in a dashboard is not evidence.
And after showing, the looking starts again, because new tools arrive. That is why governance is not a project with an end date but a rhythm. That is also why an AI policy on paper drifts from practice: written once, while the use kept going.
One thing: the status. May this tool be used, under conditions, not at all, or has the organisation not yet thought about it. That last one is a real status, and the most honest of the four.
Two things stand out in this table. First, the decision belongs to the organisation, not to a vendor or a risk score. A score says how a tool handles data, jurisdiction and incidents; whether that is acceptable is something only your organisation knows. Second, deciding is not only holding back. Naming one environment as the preferred route for text work, and showing that everywhere, is as much a decision as not allowing a tool.
What happens when an organisation skips the decision and reaches straight for a block is in blocking AI doesn't make you safer. The short version: use moves to the phone, and with it out of sight.
#What does this look like in a municipality?
A municipality has allowed Copilot. The policy is clear, the training has been given, and the privacy officer can show the document. Then the organisation looks for the first time at which AI services are opened from the browser.
Alongside Copilot, Perplexity and ChatGPT turn out to be in use, plus three specialised tools: a meeting transcription tool, a translation tool and a service that summarises policy memos. Two of the three appear in no register anywhere. Nobody did anything wrong: the transcription tool saves a policy officer two hours a week, and nobody had told her not to use it, because nobody knew it existed.
This is not an incident. It shows that a one-off inventory falls behind quickly, and that the interesting list is not "allowed" and "not allowed" but "no decision yet". What the municipality does next is the actual work: assess the five tools, pick a status for each, check with the transcription tool whether personal data is discussed in meetings, and where Copilot is the right alternative, say so at the moment someone opens the other tool.
BeeSensible connects a catalog of 865 assessed AI tools to the use observed in the organisation: only the domain, at most once a day per device, with no user id and no page content. An administrator sees which tools have no decision yet and records that decision in the AI Tools module. If the organisation has switched notices on, the decision appears in the browser as soon as someone opens the tool, with the approved alternative as the first button and never as a block.
#Where is the line with monitoring employees?
The six questions above are about tools. None of them needs a name. "This service was opened four hundred times in the organisation this month, and there is no decision about it yet" answers the governance question completely.
Record the same observation per person and three things change at once. It becomes processing of personal data under the GDPR, with a purpose you must be able to name in advance and an assessment of whether less would do. The works council gets a role: in the Netherlands the Works Councils Act gives it a right of consent over facilities aimed at observing the behaviour or performance of employees. And staff start behaving differently: anyone who knows their use is visible per person moves it to a private account, and your figures stop being right.
That last point is not an ethical argument but a measurement argument. Governance needs better figures than oversight can produce. The technical difference, which at its core is one field in a database, is worked out in AI monitoring versus employee monitoring.
There is one kind of question that is about a person: "who did this" after a concrete incident. That is an investigation question with its own procedure and its own legal basis. Mixing governance and incident investigation is the fastest way to stall a conversation with the works council.
#What is it not?
It is not model validation. Whether a language model makes things up, how it performs in your domain, whether it is biased: important questions, but for the provider of the model, not for the organisation using it through a browser.
It is not bias testing and not a conformity assessment. The AI Act places those duties on providers of high-risk systems, and the deployer of such a system has duties of its own. A chatbot for text work usually does not fall into that category, while the GDPR applies to it in full. What does apply to nearly every organisation is the AI literacy duty in Article 4: staff who work with AI must know enough to do so responsibly. How the two frameworks sit side by side is in what the AI Act means for your business, alongside the GDPR.
And it is not autonomous blocking. A system that decides by itself which tool gets shut has taken the organisation out of the decision. What remains is a setting, not governance.
#How do you show the policy is applied?
With the same observations you started with, now tied to the decision. What share of AI use runs through tools that are allowed, and is that share moving the right way? How often was a notice shown on a tool that is not allowed, and how often did someone then choose the alternative? How many tools with real use still have no decision, and is that number shrinking?
Those are figures at organisation level, and they carry only part of what an auditor asks. No measurement knows whether a data processing agreement was signed, and what someone does on their phone falls outside the picture. An honest accountability overview marks those "not substantiated", and is credible precisely because of it.
This week, pick one tool you do not know has been decided on, and decide it. Then you will see why it is such a calm question: not "who uses this", but "what do we think of it, and does everyone know that at the moment it matters".
