Before a risk level, an obligation or a governance measure gains meaning, it must be established which role your organisation plays. Whoever places an AI system on the market has different responsibilities than whoever deploys a system built by someone else. The term used for this is familiar: provider versus user. But the classification itself is not fixed in an organisational chart. It depends on what an organisation does with a specific system, and that can differ per system, per department and per moment.
The core question is not who purchased or installed the system, but who placed it on the market or makes it available under their own name. An organisation that purchases and uses software as delivered is generally a user. An organisation that develops a system, has it developed under its own name, or adapts an existing system in such a way that it becomes functionally something else, can thereby end up in the role of provider. That last point is often where organisations misjudge the situation: fine-tuning a model, building a proprietary layer on top of an external system, or training a chatbot on internal data can shift the role without anyone experiencing it as a deliberate choice. What exactly counts as an adaptation that changes the role is described on what changes when you adapt a model yourself.
Most organisations are not exclusively provider or exclusively user. A bank that deploys an external language model for customer service is a user in that regard, but if that same bank makes an internally developed risk model available to another department or to a customer, a provider role arises for that system. This means that the classification must be made per application, not once for the entire organisation. An inventory that records, per system, who built it, who adapted it and who uses it, is therefore the only way to answer this question structurally rather than incidentally.
The role is not a fixed characteristic of an organisation but a status that is subject to change. A supplier can modify its system in a way that affects the risk profile. An internal developer can further develop an internal tool into something that is offered outside the organisation. A system that once came in as a simple tool can, after an update, perform tasks that place it in a different risk category. The specific moments at which this shift occurs and what that means for who is then responsible is explained on when does your role change. For organisations that want to understand what a shift towards a higher risk level entails in practice, what does a high risk level mean for your organisation offers further elaboration.
Not every application referred to as artificial intelligence falls within the framework for which the role division is relevant. Some systems fall outside the scope for which this classification was made, and it is just as important for an organisation to know what falls outside the scope as to know what falls within it. Otherwise, time is spent classifying something that did not need classification, or something is overlooked because it seemed too small. Which applications fall outside this framework and why is described on which applications fall outside scope.
Establishing the role is a first step, not the outcome of a governance process. After the classification comes the question of what must actually happen for each role and each risk level, and that question falls into two categories: what requires immediate attention and what can be planned for a longer term. These two categories are often confused, with the result that urgent matters are left unaddressed while time goes to something that is not yet acute. An overview of what has priority in this is available on what needs attention now and what can be planned. Anyone who wants to explore the question of the role division even further, with the precise criteria that determine the boundary between provider and user, will find that elaboration on are you a provider or a user: what determines that.
This classification is only meaningful if it is applied to what is actually running within the organisation, not to what appears on an approved list. Systems that were introduced without authorisation count just as much, and the role that belongs to them must be established just as rigorously. That requires an inventory that goes beyond IT administration.
Once it is clear which role an organisation plays per system, attention naturally shifts to another question: what do these systems actually do, and which part of the work do they take over. That question lies outside the governance scan, but connects directly to it. The work scan from FTE TO AI calculates, per task, which part of the work can be taken over by AI, providing a picture of a system's impact alongside the picture of the obligations that come with it.
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.