An AI policy that is placed as a separate document alongside existing policy does not, in practice, get read. Not because employees are unwilling, but because a second process alongside an existing process almost always loses. Anyone who already has a risk framework, a code of conduct and an escalation line is not going to consult a parallel system for one specific technology. The AI policy that does work is the policy that visibly uses the same framework the rest of the organisation already knows.
Every organisation of any size already has frameworks for risk, procurement, information security and conduct. An AI policy that stands apart from that introduces a new language, new roles and a new place to look. That is precisely why it gets set aside after launch. Employees follow the path of least resistance, and that path runs through the structure they already know. A policy that asks for a new way of working alongside the old one rarely wins that competition.
The solution is not a better-written document. It is a document that does not claim a new place, but uses the existing one. An AI risk is then treated as a risk, with the same owner, the same escalation line and the same reporting format as any other risk. Anyone who wants to substantiate this will find the reasoning on the page about connecting to the existing risk structure instead of a new framework alongside it.
An AI policy that works does not contain a list of what is and is not allowed per system. That changes too quickly and becomes outdated within a year. Instead, it contains a number of fixed elements that do not depend on which model or which supplier is used:
Together, these four elements do not form a separate AI governance system, but a specification of the risk system that already exists. That is the difference between a policy that gets read and a policy that stays in a folder.
Embedding a policy is of little use if it is not known exactly what needs to be embedded. The IT list of approved systems is insufficient for this: it describes what has been procured, not what is being used. Shadow AI, tools that employees have started using themselves without formal approval, falls outside that scope, while the risk is no smaller for it.
The only way to gain insight into this is to ask. And that only works if asking does not lead to being called to account. Anyone who immediately attaches sanctions to the answer during the initial inventory will stop getting answers. An AI policy that seeks embedding in the existing structure therefore starts with an inventory that is separate from assessment, and only afterwards moves to classification by role and risk level.
The board has no interest in a thick policy document, but in a compact overview of where the risks lie and what is being done about them. That overview should have the same format as other risk reports the board already receives, so that it is not read as a separate AI report but as part of the usual risk picture. What that report looks like is described on the page about a board report of a page that connects to existing risk reports. For those who first want to know what a director should generally know about AI risk before policy is adopted, there is the page about what a director should know about AI risk before policy is adopted.
A policy that connects to the existing structure answers the question of who decides on what and how risk is monitored. It does not answer the question of which part of the actual work can be taken over by AI and which part cannot. That question sits at the task level, and that is what the work scan of FTE TO AI is about: it calculates, per task, which part of the work can be taken over, so that policy and practice are based on the same picture of the organisation.
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.