An AI program lead is typically given one mandate: make sure AI is adopted, that teams get faster because of it, that the program shows results. A second mandate is rarely added: make sure that everything that emerges in the meantime is done responsibly. Yet he is held accountable on both fronts as soon as something goes wrong. That is the core of his risk: he is responsible for a program whose edges he doesn't know.
What he gains with adoption — faster processes, satisfied teams, a visible innovation story — stands against what he loses when things go wrong: an incident with a tool that wasn't on his list, an audit that raises questions he has no answer to, a board asking why the program didn't see what was already running. That asymmetry makes his position vulnerable, even when the program itself is running well.
His question is not "which AI tools have we approved". He has that list, and it's often shorter than reality. His question is: what are teams using that isn't on my list, and how do I get visibility into that without people hiding it. A program lead who wants to encourage adoption cannot afford users to hide their tools out of fear of a correction. Whoever asks what is being used and then turns it into a problem will get no answer to the next question. Governance and adoption work against each other here if approached the wrong way.
An answer he does not accept is a single blockade: "AI use is not permitted without approval." That answer satisfies an auditor for a moment, but shifts usage to places nobody sees. It is the opposite of what a program lead wants to achieve: he wants AI use to be visible and guided, not driven underground. A ban without a mechanism for reporting and learning is, for him, a loss, even if it sounds compliant on paper.
He also does not accept an answer that treats everything the same. A tool that summarizes text for internal use is not the same risk as a tool that automatically makes decisions about customers or employees. Without distinguishing by role and risk level, a program cannot prioritize, and a program lead who cannot prioritize cannot execute his mandate.
What does work is an inventory that starts with what exists, not with what has been approved. That means asking teams what they actually use, and doing so in a way that carries no penalty. Only then does shadow AI come into view — the systems introduced without a formal process, often because they eased work and nobody saw a reason to wait for approval.
Classification follows next: which application touches customers, which only touches internal process, which makes decisions without a human in between. That classification determines where oversight needs to be strict and where it can remain light. Without that classification, a program treats everything with equal weight or equally lightly, and both are a problem: the first slows adoption, the second leaves risks unmanaged.
The governance structure that follows must connect to what already exists within the organization — the existing risk committees, the existing reporting lines — not a new circuit alongside them. This is also where a program lead differs from other roles in the organization: an executive wants to know what an executive needs to know about AI risk at the level of ultimate accountability, a CIO approaches it from systems and access as described in what a CIO needs to know about AI risk, and a General Counsel looks at liability and documentation obligations via what a General Counsel needs to know about AI risk. A program lead must be able to serve all three perspectives without losing his own task — adoption.
Which concrete obligations apply to which risk category, and within which timeframes, is not the subject of this page. That text changes, gets tightened, and is explained elsewhere. Here the focus is on the mechanism: how a program gains insight into what is going on, how it translates that into risk levels, and how it demonstrates this to the board and supervisors, regardless of what the exact regulatory text prescribes at any given moment.
Once it is clear what is running and who is responsible for it, a different question arises: what does it yield when that work is properly organized. That is a question that must be answered per task, not per organization. FTE TO AI's work scan calculates at that level which part of the work can be taken over by AI, so that a program lead not only knows what is going on, but also where adding capacity actually makes a difference.
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.