Organizations often think their role is fixed: we are the user, the supplier is the provider, done. That assumption is regularly incorrect, or is correct today and no longer correct tomorrow. The role an organization has in relation to an AI system is not a fixed characteristic of the organization. It is an outcome of what happens with the system: who builds it, who adapts it, who places it on the market, and under what name. If one of those factors changes, the role may also change, and with it the obligations that go with it.
That makes classification not a one-time snapshot. A role that was correctly established at the time of purchase may be incorrect a year later without anyone internally having consciously decided anything.
The classification depends on a limited number of factors, but those factors do not all lie with the party using the system. Relevant considerations include whether a system was developed in-house or purchased, whether the purchased system is deployed unchanged or adapted, and whether the adaptation affects the system's risk profile. Also relevant is under what name a system is presented externally: a system that is resold or further developed under one's own brand may carry a different role than running an external product unchanged. For the precise boundary between those two positions, the page about what changes when an organization adapts a purchased model itself is relevant, and for the basic question of which of the two main roles applies, there is the page that explains what exactly the choice between provider and user depends on.
The classification is therefore not something an organization establishes once and then files away. It is a classification that must be reassessed as soon as the underlying facts change.
If the role changes, what is expected of an organization also changes. A party that is purely a user has different obligations than a party that is (partly) responsible for the creation of a system. That affects more than just paperwork. It also affects where in the organization responsibility for a system should lie, who reports on it, and what level of oversight is appropriate.
That shift carries through to the question of how heavily a system must be weighed internally. A role change can mean that a system previously considered manageable must be reassessed for its risk level — a question addressed separately on the page about what a high risk level means for the organization that uses or provides the system. Conversely, a role change can also mean that a system falls outside the scope of certain obligations, or just falls within it. Which applications exactly fall outside scope and which just don't, is explained on the page about which types of AI applications fall outside the scope of the obligations.
The factors that cause a role change usually play out at a level where the board, legal department, or risk management have no automatic visibility. A team that fine-tunes a purchased model on its own data. A department that passes on an external chatbot product to customers under its own product name. An integration that combines a supplier's model with its own rules and then offers that combination externally. None of these steps automatically passes through a central register, and the IT list of approved tools usually does not register this type of change, because the change is not recognized as a "new purchase" but as an adaptation of something already approved.
That is why role changes often only become visible when something goes wrong, or when external accountability is demanded. The question "what is our role in relation to this system" is then answered retroactively, at a moment when the room to adjust something is smaller than if the question had been asked earlier.
Because the classification can shift, the distinction between what requires attention right now and what needs to be reassessed later is relevant for planning governance work. Not everything a role change brings with it requires immediate action; part of it can be planned. Which part that is, and which part cannot wait, is addressed on the page about what needs to be taken up now and what can be scheduled for a later moment. For a compact summary of the classification question itself, including the most important turning points, there is the page that goes deeper into the precise circumstances under which a role changes.
The question of which role an organization has in relation to an AI system is closely related to another question that rarely receives the same attention: which part of the actual work in the organization is already being done by AI, is planned to be done by AI, or is already being taken over without anyone having recorded it. Where the role question concerns responsibility in relation to a system, the work scan from FTE TO AI concerns the division of tasks itself: for each task it is calculated which part can be taken over by AI, regardless of which role the organization formally holds in relation to it. These two questions touch each other, because a shift in task division is often the trigger for a shift in role.
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.