A compliance officer doesn't lose at the first question about AI. They lose at the second: when it turns out the answer to the first question was incomplete. "Which AI systems does your organization deploy" can be answered with a list from the IT portfolio. The question that follows — "is that the complete list" — is the question on which most compliance files fall apart.
Not: which AI tools has the organization purchased. But: which AI systems are actually being used, by whom, for which decisions, and based on what risk assessment. That is four questions, not one. The first is a procurement list. The other three require people to tell you what they do, including what they never had approved. A compliance officer who only has the procurement list has a false sense of coverage — and that is riskier than no coverage, because it gets reported as complete.
Employees who use a language or analysis tool without procuring it through IT leave no trace of that in an asset register. They do leave a trace of it in what they produce: reports, client communications, advice. The gap between what is registered and what is used is usually not a deliberate violation. It is the result of an organization finding a tool faster than it can complete an approval process. Compliance cannot close that gap with a stricter ban — that only pushes the usage further out of sight. You close the gap by asking, without a penalty attached to the answer. Someone afraid of a note in their file will not tell you what they use; they will tell you what they think you want to hear.
A risk manager wants to know how large the exposure is. A compliance officer wants that, plus something extra: can I demonstrate that we followed the process, even if the outcome later turns out to be questionable. That is a different kind of evidence. It's not just about the classification of a system, but about the trail: who assessed this, at what moment, with what information, and was that assessment repeated when the system changed. AI systems get updated without notice; a classification from six months ago says little about today's system. Compliance therefore must be able to show not just an outcome, but a process that keeps running.
"We have an AI policy" is not an answer to the question of whether that policy covers anything. A policy document that has never been tested against what is actually being used is a statement of intent, not a statement of current status. What a compliance officer needs is an inventory that connects to existing risk categories — the same classification already used for other operational risks — so that AI doesn't end up as a separate, exotic topic alongside the rest of the risk framework, but within it.
The compliance officer rarely works this out alone. The question of which systems qualify as high-risk and what evidence that requires touches on what a General Counsel needs to know about AI risk from a liability and contractual-obligations perspective. The question of whether the organization can technically trace which systems are running belongs to what a CIO needs to know about AI risk. And the question of whether this topic reaches the boardroom before it escalates belongs to what a board member needs to know about AI risk. Compliance is often the party that has to bring these three lines together without itself owning the technology or the contract.
The substance of the regulations — which obligations exactly apply, per risk category, with which deadlines — is covered elsewhere and keeps changing. This page describes the mechanism: how you know what is running, how you classify it, and how you demonstrate that the process was followed. A compliance officer looking for the current legal text will not find it here.
How much shadow AI an organization has depends on the sector, the culture, and how strictly earlier bans were enforced. A stricter ban often correlates with more hidden usage, not less. That pattern is not the same everywhere: in construction the focus is on project costing and planning, while in the installation sector it more often concerns maintenance diagnostics and fault analysis. The inventory therefore has to be done per organization; a national average says little about your own exposure.
The Responsible AI Scan maps out what is actually being used, classifies it by role and risk level, and delivers a governance set that connects to the existing risk structure — without getting ahead of what has already been established elsewhere. This scan is under construction. Anyone with an interest in this can join the waiting list; nothing is being offered that isn't finished yet.
Once you know which AI systems are running, you often run into the follow-up question: what does that mean for staffing levels and division of tasks. That is a different calculation than risk classification, and FTE TO AI makes it with the work scan, which calculates per task which portion of the work can be taken over by AI.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.