Not every AI application within an organization requires the same speed. Some matters demand immediate attention, others can be incorporated into a normal planning cycle. The problem is that this classification is rarely made explicit. Without classification, everything gets the same urgency, or — more often — no urgency at all.
The question of whether something must happen now or can wait is not a matter of preference. It depends on a number of factors that together determine how heavily an application weighs.
The risk level of the application is the first factor. A system that makes decisions about people — hiring, credit provision, access to services — weighs differently than a tool that summarizes text for internal use. What a high risk level precisely means for an organization's obligations, and why that is not the same for every application, is described at what a high risk level means for your organization.
The organization's role is the second factor. An organization that develops or adapts an AI system itself carries different responsibilities than an organization that acquires and uses a ready-made system. That role can also change without a deliberate choice underlying it: whoever fine-tunes a model, adapts it, or deploys it differently than intended can shift from user to provider as a result. Where that boundary lies is explained at what changes when you adapt a model yourself and at are you a provider or a user, what does that depend on.
The third factor is whether the application falls within scope. Not every system called AI falls under the same obligations; some applications are excluded or fall under a lighter regime. Which applications fall outside scope and why is described at which applications fall outside scope.
These three factors — risk level, role, scope — together determine where an application falls on the timeline. A high-risk application in which the organization acts as a provider requires a different speed than a low-risk application that may soon fall outside scope.
The classification is not permanent. An application that is considered manageable today may no longer be so tomorrow — not because the rules change, but because the application itself changes. A model that gets adapted, a system that receives a new task, a tool that moves from internal pilot to production: each of these steps can cause the role or risk level to shift.
Organizational changes also play a role. A merger, a new supplier, an expansion of use to another department — all these events can move an application that previously qualified as 'can be planned' to 'must happen now'. When a role changes and where exactly that shift lies is worked out at when does your role change, what does that depend on.
This means that a one-time classification is not sufficient. What is on the agenda today as a planned item can take on a different weight due to a change elsewhere in the organization. A fixed, periodic reassessment is therefore part of any classification that needs to hold up — not as an extra step, but as a condition for keeping the classification current.
A clear classification prevents two opposite mistakes. The first is that everything is treated as urgent, causing priorities to blur and attention to become scattered across applications that carry little risk. The second is that nothing is seen as urgent, causing applications with real risk to remain under the radar for years — often because no one has ever classified them.
The classification itself is not a one-time document but a structure that moves along with the organization. It produces an overview of what requires attention in the short term, what can be incorporated into a regular process, and — crucially — what must be reassessed as soon as the situation changes. Precisely that distinction, and the question of what it depends on, is further worked out at what needs to happen now and what can be planned, what does that depend on.
This classification assumes that it is known which applications exist. In practice, that is far from always the case. Alongside the systems approved through IT or procurement, virtually every organization has tools running that no one requested and no one registered — a spreadsheet assistant here, a text generator there, deployed by people who wanted to solve a problem and did not want to go through a procedure. This shadow AI does not appear on the IT list, and whoever asks about it without anything being at stake for the user is more likely to get an honest answer than whoever immediately threatens with a sanction. Without that inventory, any classification by urgency is a classification of part of reality, not of the whole.
This page is about classification: what weighs heavily, what weighs lightly, what requires attention now and what can wait. Another, complementary question is what an AI application actually delivers within a task. The work scan from FTE TO AI calculates, per task, what portion of the work can be taken over by AI, providing a concrete picture alongside the governance classification: not only whether an application carries risk, but also what it contributes to the work itself.
The Responsible AI Scan is in development. Those who want to use the inventory, classification and governance set as soon as it becomes available can sign up for the waiting list.
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.