Most organizations now have an AI policy. Often it is well written, legally sound, and complete. And often it is not read, or read on the day it is adopted and never again after that. That is not a matter of ill will. It is a matter of where it sits in the process.
Employees who work with AI already have a process: the work itself. An AI policy that sits alongside that work, as a separate document you look up, competes with the time someone already doesn't have. Someone who has to write a text, analyze a dataset, or answer a customer question doesn't consult the policy first. They use the tool that works, and only think of the policy when someone asks about it.
The result is predictable. A practice emerges that deviates from the document, without anyone intending harm. No one ignored the policy out of unwillingness; it simply didn't fit into the moment when the choice was made. A policy that wants to be read must therefore not sit alongside the work, but inside it. That means it answers questions that already arise — which tool is allowed here, who is responsible if it goes wrong, what happens to the output — at the moment that question arises, not three chapters further into a pdf.
An AI policy that works in practice contains, at its core, a few recognizable components. First, a classification by risk: not every application of AI requires the same attention, and a document that lumps everything together is not applied seriously by anyone. Second, a clear answer to the question of who decides when a case doesn't fit the classification — that belongs in an oversight decision log that records who is responsible for what, rather than in a footnote no one can find again.
Third, a route for what happens when something goes wrong or is questionable: escalation paths that work describe who you call, not who you should in theory inform. A policy without working escalation is a policy that only gets read after the incident, and by then it is too late to steer anything.
Fourth, a form of follow-up that doesn't stop at adoption. Policy that is written once and never tested again ages faster than the practice it is supposed to cover. Monitoring that yields something is not an added reporting burden, but the mechanism by which the policy keeps pace with what is actually happening.
A common misconception is that AI policy needs a new governance framework. That is usually not the case. Most organizations already have a risk structure — for privacy, for financial risks, for operational continuity. AI risk fits into that structure in most cases, as an extra category or extra question within existing decision-making lines, not as a separate circuit with its own meetings and its own reporting lines. Connecting to the existing risk structure is, for that exact reason, often more effective than setting up a new framework: people already know the process, and don't need to learn where the new document is kept.
That connection is also where things practically get stuck or succeed. A policy that connects well on paper but remains a separate document in practice is ignored all the same. The question is not only what is in the document, but how it is embedded in what people already do — meeting structures, approval flows, reporting moments that already existed before AI became a topic. What that looks like in practice depends on how the organization already works, and that is explored further in what is described about how such a policy becomes embedded in what already exists.
A policy that works can also be summarized in a few sentences for those who don't work with it daily. A board has no need for the full document, but for an answer to the question of whether it is under control and where it isn't. A one-page board report is the test of whether the policy works: if it cannot be summarized on one page, it probably cannot be applied in practice either.
A policy that connects to practice presupposes that you know what that practice is: which tasks are being done, and what part of them is already being carried out with AI or could be. That is a different question from governance, and that question is answered by FTE TO AI's work scan: it calculates, per task, what part of the work can be taken over by AI, so that policy does not rest on assumptions but on a concrete picture of the work itself.
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.