A model that you procure and use unchanged is a different situation from a model that you finetune, retrain on your own data, or merge with other systems. The question that comes with that is not whether that is allowed, but what it changes about your role. This page describes what that classification depends on. The current content of the rules is covered elsewhere; here the focus is on the mechanism that determines when something changes and what you do with that internally.
Whether modifying a model changes your role depends on a number of factors that you must establish case by case, not on a fixed threshold that is the same for every model.
These factors work together. None of these points is decisive on its own; the combination determines whether the modification changes your position.
If the modification is substantial enough, it usually changes not only the classification of the model but also what is expected of the organization: different documentation, different internal responsibility, possibly a different party who can be held accountable for the whole. That mechanism, and the distinction between a party that only uses a model and a party that helps shape the model, is worked out on the page describing the distinction between provider and user. Exactly when a modification is substantial enough to tip that role is a question that must be answered separately for each system; the general mechanism behind that is on the page about the moment your role changes.
The consequences of that shift, in turn, depend on the risk level assigned to the modified model. A modified model that falls into a high-risk category carries different obligations than a modified model that stays outside it. What a high risk level means in practice for internal processes and oversight is described on the page about the consequences of a high risk level for your organization. Conversely, it is also possible that a modification keeps a system outside the heaviest category, or that the field of application simply does not fall under the regulation; which applications fall outside scope and why is described on the page about applications that fall outside scope.
Modifications to models often happen close to the work itself: a team finetuning an external model on its own documents, a developer linking two systems together, a department feeding a chatbot with internal knowledge bases. Those are precisely the modifications that do not run through a central procurement process and therefore do not automatically appear on an IT list. Anyone who wants to know whether, and where, this is happening within the organization has to ask — and that only works if the question is not tied to a penalty. A team that has modified a model without asking permission for it will not report that if the answer results in a sanction.
Because the classification of modifications is not fixed but established case by case, it is not enough to determine a model's role once. Modifications that take place after the initial assessment must be run through the same questions again. A policy that supports this must describe in plain language when a modification must be reported and to whom; how such a policy stays readable instead of becoming a text no one consults is described on the page about an AI policy that actually gets read. In addition, it is important that decisions about modifications — who approved them, based on what considerations, with what risk level as the outcome — are recorded in a place where they can be found again. What such a record looks like in practice is described on the page about an oversight decision log.
The classification of a modified model determines which obligations apply, but says nothing about what the model actually does with the work itself in practice. For that question — which part of a task is taken over by AI, which part remains with an employee, and what a modification shifts in that regard — a different lens is needed than a risk assessment. The work scan from FTE TO AI calculates per task which part of the work can be taken over by AI, separate from the question of which governance rules apply to the model.
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.