The question of which applications fall outside scope sounds like a request for a list. It isn't. Whether something falls in or out of scope is a classification that depends on what an application does, in which context, and for whom. The same technology can stay out of view in one application and come under full attention in another. A fixed list of excluded applications therefore does not exist — but a number of factors that determine the classification do.
The first factor is the function of the application: what the system decides or advises, and for whom that has consequences. A tool that rewrites internal text is different from a tool that helps decide on an application, a job application or a claim. The second factor is the risk level attached to that function: as the consequences for people grow larger, an application shifts more readily toward the heavier part of the spectrum. The third factor is the organization's own role: someone who merely uses a system is assessed differently from someone who adapts it, further trains it, or assembles it from components made by others. What that division of roles precisely entails and when it shifts is described on the pages about the distinction between provider and user of an AI system and about the moment at which a user role turns into a different responsibility.
A fourth factor is technical in nature but legally relevant: what an organization itself changes about an existing model sometimes changes that organization's position in the whole. A model that is purchased unchanged fits differently into the picture than a model that is fine-tuned on the organization's own data or embedded in its own process. That boundary — when adapting brings about a change of role — is addressed on the page about what changes when a model is itself adapted, and what that depends on.
Because the classification depends on these factors, scope is not a fixed characteristic of a tool but an outcome that can change. A chatbot that started as an internal writing aid can end up in a different part of the spectrum as soon as it also answers customer questions that lead to a decision. A model that was purchased as a ready-made product can, after adaptation to the organization's own data, bring about a different role for the organization. An application that counts as low-impact today can weigh more heavily tomorrow because the context in which it is deployed has changed — a different team, a different decision, a different group of people affected by the outcome.
This is precisely why a one-off classification does not suffice. A classification recorded at the moment of introduction says nothing about what a tool does a year later. What should come under scope today and what can be scheduled for later is therefore itself a question that depends on the current situation — worked out on the page about the order between what requires attention now and what can follow later.
The classification into and out of scope is made more difficult by a practical problem: the official list of purchased or approved tools is not the same list as the tools that are actually being used. Teams adopt AI functionality without routing that through a request process — not out of unwillingness, but because it is easily accessible and solves a problem. That shadow AI is precisely the part that makes a classification into or out of scope impossible, as long as no one knows the application exists.
Anyone who wants to complete that picture must ask about it — and then in a way that does not feel like a disguised accusation. As soon as an employee suspects that an honest answer will lead to a sanction, the answer stays away and the tool stays under the radar. An inventory built on accountability therefore by definition produces an incomplete picture — and an incomplete picture makes any classification into scope provisional.
Because scope can shift, recording the classification is at least as important as the classification itself. Who decided that an application fell outside scope, based on what information, and at what moment — those kinds of questions become unanswerable as soon as the record is missing. How an organization can make that type of decision structured and traceable is described on the page about a decision log that makes oversight decisions traceable, and how that classification recognizably recurs in the document employees actually consult, on the page about an AI policy that matches what people actually do.
The classification question — what falls within scope and what does not — is about risk and responsibility, not about what an application means for the work itself. That second question, what a task can precisely leave to AI, is a separate calculation. FTE TO AI's work scan calculates per task which part of the work can be taken over, independent of the question of how that application ends up in the governance classification.
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.