Human oversight is often recorded as a role: someone who is responsible, a name in a register, a box that has been checked. That is the starting point, not the mechanism itself. Oversight only comes into being when there is a moment at which a human can see the outcome of an AI application, can understand it, and can intervene before that outcome reaches somewhere. Without that moment, the name under the classification is a formality.
Whether oversight works in practice depends on a number of things that do not come together automatically. There must be someone who has the authority to stop an outcome, not merely the task of looking at it. There must be time to look, which means the process is not set up in such a way that the AI outcome has already been processed before the check takes place. And there must be sufficient understanding of what the application does to recognise a deviation. A reviewer who cannot assess the outcome does not exercise oversight, even if the role has been formally assigned.
This connects to what AI literacy means for your employees: oversight without understanding of the underlying application is oversight on paper.
A governance structure can record who is responsible for what, what risk level an application has, and which steps go with that. What the structure does not do is guarantee that the person in question actually assesses the outcome at the moment it matters. That is an organisational fact, not a technical one. A classification can be correct and the oversight can still be empty, because the person who is responsible on paper does not have the time, the access, or the knowledge to review the outcome.
The inventory and the classification expose where this risk is greatest: with applications at a higher risk level, or with applications that have entered outside the regular IT process. The latter group is often the most difficult, because anyone who wants to organise oversight of something that is not in the records must first find it. This touches on the question of what you do with employees who use a tool that no one has approved: oversight of shadow AI begins with recognising that the application exists, not with a sanction on its use.
An application that is under oversight today may have changed by tomorrow. A model gets updated, the input data shifts, or the use within the organisation grows from a simple task into something with more weight. Oversight that was set up for the situation of a year ago no longer matches what is happening now. This is one of the reasons why classification is not a one-off exercise; how often it needs to be repeated depends on the risk level and the extent to which the application changes, as set out in how often you need to reclassify.
This also means that a register only has value if it is maintained. An inventory that was drawn up during the first scan and is not updated afterwards gives an increasingly inaccurate picture of where oversight is needed. The question of how an organisation keeps that register up to date is separate from the question of how the register was built, and deserves attention in its own right: see how you keep an AI register up to date.
A board that is asked to demonstrate that there is oversight of AI use cannot make do with a list of roles. Demonstrability requires a trail: who looked at which outcome, at what moment, with what authority to intervene. That trail is also relevant at the moment something goes wrong. The question of who is responsible when an AI application makes a mistake is not answered by the classification alone, but by the demonstrable oversight that followed it. These two matters are easily confused, while the distinction is relevant; see who is responsible if an AI application makes a mistake.
Oversight also touches on what is entered into an application. An employee who pastes company data into a free chat window places that data outside any oversight the organisation has set up, regardless of how well the oversight of the approved applications is organised. That is a separate area of attention within the broader issue, set out under what you do with company data in a free chat window.
This page describes how oversight works as a mechanism: who looks, when, with what authority, and how that is made demonstrable. The substantive standards that determine when oversight is mandatory, how strict that oversight must be per risk category, and within which timeframes it must be set up, are not covered here. That regulatory content changes and is kept up to date elsewhere.
Organising oversight of a task is only meaningful if it is clear exactly what that task involves and which part of it is done by an AI application. That is a different question from what role or risk level an application has; it concerns the task itself, broken down into the steps an AI application can take over and the steps that are not suitable for that. FTE TO AI's work scan calculates this per task, so that it becomes visible which part of the work can be taken over and which part must remain within the scope of human oversight.
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.