Kennisbank

What falls outside scope, and when that is no longer the case

A question everyone answers too quickly

Within many organizations there is a fixed list of applications that would supposedly fall "outside scope". A text suggestion in a word processor, a spam filter, a chatbot that only answers based on a fixed FAQ. The assumption is that these applications are too small, too old, or too harmless to fall under governance. That assumption is sometimes correct. It is not always correct, and it rarely remains correct.

Whether something falls outside scope is not a property of the technology. It is a classification that follows from what the system does, for whom, and with what effect if it goes wrong. The same text suggestion that falls outside scope today because it only suggests a word to an employee, may fall within scope tomorrow as soon as it automatically finalizes and sends emails without intervention.

What the classification depends on

Three factors together determine whether an application falls within or outside scope.

The first is function: does the system make a decision, or does it only provide information that a human assesses? A tool that ranks job applicants is closer to scope than a tool that merely makes CVs searchable. Exactly where an application stands on that spectrum, and why, you can read in the analysis of what a high risk level means for your organization.

The second is the role of the organization itself. Whoever buys a system and uses it unchanged is positioned differently than whoever builds, trains, or adapts it themselves. That same application may fall outside scope for one organization and not for another, purely based on who carries which responsibility. This distinction is worked out in the question of whether you are a provider or a user, and changes as soon as someone in the organization adapts or retrains a model, as described in what changes when you adapt a model yourself.

The third factor is time. A system that falls outside scope now may no longer do so a year later, not because the rules changed, but because the use changed. A chatbot that started as an information source can grow into a system that handles complaints. The role of a team or department relative to such a system then shifts along with it, and when that happens is described in when your role changes and what that depends on.

What this means in practice

The consequence of these three factors is that "outside scope" is never a permanent status. It is a snapshot that must be reviewed as soon as the function of a system changes, as soon as the organization acquires a different role relative to that system, or as soon as the use expands into something that was not anticipated at the time of purchase.

This is exactly where shadow AI disrupts the classification. An application noted on the IT list as "outside scope" can in practice be used in a way that no longer fits that label. A team that deploys a language model to draft customer communications may also use it to send final answers without reporting this. The classification on paper and the use in practice then diverge, and no one who only looks at the purchased licenses sees that difference.

The only way to gain insight into this is to ask. Not a system, but the people who use it. That only works if asking questions is not equated with being held accountable: whoever fears consequences adjusts their answer or gives none at all. A classification that relies solely on purchased licenses therefore systematically misses the applications that arose from practical use, and those are often exactly the applications where no one still knows whether they fall outside scope or have long since moved well within it.

Scope is an outcome, not a starting point

The question "does this fall outside scope" cannot therefore be answered separately from the question of what exactly happens, who decides on it, and how long that situation has already existed. An inventory that records these three factors per application produces a classification that matches the actual situation rather than the assumption with which a system was once purchased. What already requires attention now and what can be calmly planned depends on the same factors and is addressed in the distinction between what must happen now and what can be planned.

From classification to insight into the work itself

Once it is clear which applications fall within scope and what role your organization plays in that, a follow-up question arises that is not about governance but about work: what part of a task is actually taken over by such an application, and what part remains human work? The governance scan does not answer that question. That is what the work scan of FTE TO AI is for, which calculates per task what part of the work can be taken over by AI, thereby giving a picture of the deployment underlying the classification.