AI Policy vs AI Governance

Every spring ISACA, the professional body for IT audit and governance, asks its members how their organizations are handling AI. In 2026 more than 3,400 of them answered. Nine in ten believed employees in their organization were using AI. Policy was catching up: 38 percent said their organization now had a formal, comprehensive AI policy, up from 28 percent a year earlier¹. The machinery behind those policies had not kept pace. Only a third of organizations trained all their employees on AI. Only 12 percent had a documented process for shutting down or overriding an AI system that was also tested regularly, and 56 percent of respondents did not know how long it would take to halt an AI system during a security incident².

Read those numbers as a single sentence and they describe a common condition. An organization writes down what must happen, then leaves open who makes it happen, how anyone would know, and what happens when it does not. The document exists. The system around it does not. That is the difference between AI policy and AI governance.

The core idea

An AI policy is a formal statement of what the organization requires when it uses, builds or buys AI: what is allowed, what is prohibited, which controls are mandatory and which data may be used. It states what must be true.

AI governance is how the organization makes sure it is true, and keeps it true. As What Is AI Governance? established, governance is the system of decision rights, accountability, controls and oversight. The policy is one part of that system, not a synonym for it. Governance decides who wrote the requirement and who may change it, who owns it day to day, how it is enforced, who may grant an exception, what evidence shows it was followed and when it is reviewed.

The distinction matters because the two fail differently and are fixed differently. A weak policy is fixed by better drafting. Weak governance is fixed by assigning decisions, building controls and collecting evidence, and no amount of drafting will do that. AI Governance Principles set out the seven principles this course uses. This chapter shows how one of them becomes a requirement that people actually meet.

Two questions, two kinds of answer

The quickest way to tell policy from governance is to listen to the questions each one answers. A policy answers what: what is required, what is prohibited, what is expected of people. Governance answers who and how: who decides, who owns the rule, who can grant an exception and for how long, how compliance is checked, and how the rule changes when the technology does.

The frameworks that auditors, regulators and prosecutors use draw the same line, and they draw it in strikingly similar terms. ISO/IEC 42001, the international standard for AI management systems, puts the AI policy in a single clause of its leadership section and expects it to be reviewed at planned intervals. Around that clause sit roles and responsibilities, risk assessment, operational controls, monitoring, internal audit, management review and corrective action³. The NIST AI Risk Management Framework opens its Govern function with policies, processes, procedures and practices that are “in place, transparent, and implemented effectively”⁴. Existence is the first of the three conditions, not the only one.

The bluntest version comes from outside AI altogether. When US federal prosecutors weigh a company’s compliance program, the Department of Justice tells them to ask three questions: is it well designed, is it adequately resourced and empowered to function effectively, and does it work in practice? Prosecutors are told to probe whether a program is a “paper program” or one that is implemented, resourced, reviewed and revised. The September 2024 update added questions about how a company assesses the risks of new technologies such as AI⁵.

None of these documents is AI law, and the first two are voluntary. They matter because they are the questions an organization will be asked by a certification auditor, a large customer’s due-diligence team or, in the worst case, a prosecutor. Each of them will look past the policy to the system around it.

From principle to evidence: trace one requirement

Principle, policy, standard, process, control and evidence are often used as if they were interchangeable. They are links in a chain, and following a single requirement along it is the most useful governance test an executive can run.

Take one example and follow it all the way. The principle is privacy and security: protect confidential and personal information. The policy turns that into a requirement: restricted company data and personal data must not be entered into unapproved AI services. The standard sets the specific bar: any AI service that handles restricted data must meet named security, retention and contractual conditions, including a commitment that prompts are not used to train the provider’s models. The process says how work gets done: an employee who needs an AI assistant requests one through a single, published route. The control enforces or checks the requirement: access management, data-loss prevention on uploads to unapproved services, and a maintained list of approved tools. The evidence shows that it happened: access logs, approval records and the result of the last test of the upload block.

Now ask, for each link, who owns it and what you would see if it were missing. A principle with no policy is a value statement. A policy with no standard leaves every team to guess what “approved” means. A standard with no process means people who want to comply cannot find the route. A process with no control depends entirely on memory and good will. A control with no evidence cannot be shown to work, to an auditor or to yourself. The chain is where governance happens, because each link needs a decision and an owner. Which roles hold those links is the subject of AI Roles, Ownership and Accountability. How standards, control types, monitoring and audit are built is the subject of AI Policies, Standards, Monitoring and Audit.

Two ways to fail

Leaders usually see one failure and miss its mirror image. The first is the policy on paper. The document is clear and approved, but people do not know it, understand it or find it workable, and nothing checks whether it is followed. The second is the committee without policy. There is a governance board, a review meeting and an approval route, but no written requirements, so each request is argued from scratch and similar cases get different answers.

Survey data suggest that many workplaces sit in the bottom half of this matrix. In the 2025 global study by the University of Melbourne and KPMG, only two in five employees, 40 percent, said their organization had a policy or guidance on generative AI at work, and that count includes the 6 percent whose policy was a ban. Almost one in five did not know. Among employees who use AI at work, 44 percent said they had used it in ways that contravene policies or guidelines⁶. Some employees had no rule to follow; others had one and worked around it. Both are governance problems, and they call for different fixes.

Even a sound policy sentence leaves governance work undone. “High-risk AI uses require approval” is a reasonable policy. It does not say who decides what counts as high risk, who performs the assessment, who approves, who can say no, or who can grant an exception. Those answers are governance. The risk tiers themselves are taught in AI Inventory and Risk Classification.

Write the policy to last

A practical policy framework has layers, and they should change at different speeds. At the base sits the enterprise AI policy: broad requirements for everyone, covering approved use, data protection, accountability, security, human oversight and AI bought from third parties. It should change rarely. Above it, domain requirements add what a single function needs, for example in hiring, finance or consumer care. Technical standards set the engineering bar for identity, logging, evaluation and access. Procedures and controls change most often of all.

The layering is what keeps a policy from going out of date. A rule that names one model in one version is obsolete within months. A rule that says “use only AI services that meet our approved security, privacy and risk standards” survives every product launch, because the list of services that qualify lives in a standard that can be updated without reopening the policy. The same logic handles new forms of AI. When AI arrives inside business software the organization already buys, or when agents begin to take actions, governance decides whether the existing policy applies, whether a standard needs a new section, or whether a new control is required. Often the answer is a standard, not a new policy. The policy is then reviewed on a fixed cadence, as ISO/IEC 42001 expects³, and also whenever the technology, the business use, a provider, the law or an incident changes materially.

A policy people can follow

Few employees will ever read a thirty-page policy, and they should not have to. They need answers to six questions: what can I do, what can’t I do, what data can I use, which tools are approved, when do I need approval, and whom do I ask? If a policy cannot be turned into those six answers on a single page, it is too long, too vague or both.

Followability is also about whether the approved route does the job. In a 2024 survey of 6,000 knowledge workers in the United States, the United Kingdom and Germany, commissioned by a software company and reported in its press release, about half of AI users relied on tools their employer had not issued. A third of them said it was because IT did not offer the tools they needed, and 46 percent said they would not give up their own tools even if the organization banned them⁷. A requirement that people cannot realistically meet does not produce compliance. It produces bypass, the shadow AI that Privacy and Confidential Data described.

That is why governance reads non-compliance and exceptions as information. One request to depart from a rule is a decision to make, with conditions and an expiry date. A steady stream of requests for the same thing is a message that the policy, the approved tools or the standard no longer fits how people work. The mechanics of a controlled exception, with owner, rationale, compensating controls and expiry, are covered in AI Policies, Standards, Monitoring and Audit. The executive point is simpler: when many people break a rule, ask first whether the rule is workable, then whether it is enforced. Often the answer involves both.

Story: sound guidance, and a regulator’s ban

This is a documented case, taken from a regulator’s investigation report. It is told as a decision, so decide before you read the outcome.

Victoria’s Department of Families, Fairness and Housing, in Australia, employs around 7,000 people. In or around September 2023, one of its child protection workers used ChatGPT while drafting a protection application report, a document submitted to the Children’s Court in the case of a young child, and entered personal and delicate information about the child and the family. The draft contained inaccurate personal information that downplayed the risks to the child. The investigation found that these errors did not, in the end, change the decisions of child protection staff or of the court. The department reported the incident to the Office of the Victorian Information Commissioner (OVIC) in December 2023⁸.

What did the department have in place? At the time of the report it had an acceptable use of technology policy, e-learning on privacy and security, a code of conduct, and three education sessions on AI risks for managers and leaders. On 25 October 2023 it issued specific generative AI guidance with two “critical rules”, one of which told staff not to input anything that could reveal classified, personal or otherwise sensitive information into public AI tools. The regulator later judged that guidance “broadly fit for purpose”⁸.

The usage was not marginal. Between July and December 2023, nearly 900 employees, almost 13 percent of the workforce, visited the ChatGPT website on department devices. The logs showed only who had visited, not what they typed. When the chief information officer emailed those users to ask how they were using it, ten replied. A review of the worker’s own unit found 100 cases with indicators that ChatGPT may have been used to draft child protection documents⁸.

You lead the department. Your guidance says the right thing. Is that enough, or do you build the rest of the chain?

The regulator answered in September 2024. It found that the department had breached two of Victoria’s information privacy principles, which require reasonable steps to keep personal information accurate and to protect it from unauthorized disclosure. Its reasoning followed the chain link by link. There were no specific departmental rules about when and how the tools could or could not be used. There was no evidence of training for staff below management level. There were no technical controls: the department could block websites, but had not applied that to AI tools. And it had almost no visibility of how the tools were used. In the report’s words, in child protection matters “the risks of harm from using GenAI tools are too great to be managed by policy and guidance alone”⁸.

Because the department had not built the controls, the regulator specified them. Its compliance notice required the department to direct child protection staff not to use web-based or external generative AI text tools, to block ChatGPT and fourteen similar services by 5 November 2024 and keep them blocked until 5 November 2026, to scan regularly for new tools of the same kind, to stop those staff from using Microsoft 365 Copilot, and to report on how well the measures worked every six months. The department accepted the breach findings and committed to the actions, while maintaining that the incident was isolated and that use of the tools was not widespread⁸.

Notice what was not missing: the policy sentence. The guidance said the right thing, and the regulator said so. What was missing was everything that makes a requirement true: a standard that said when the tools could be used, training that reached the people doing the work, a control between the employee and the public service, and evidence that anyone could see what was happening. Without them, the requirement was a hope. The block was the regulator’s answer for the highest-risk work in the department, and it came with scanning and efficacy reports, which are governance too. For most work, as the survey on bypass suggests, a block without a usable approved route moves the problem rather than solving it. The executive lesson is simpler: build the chain yourself, or someone else may build its bluntest version for you.

What this means for leaders

The first lesson is that an approved policy is the beginning of governance, not proof of it. When a board asks whether AI is governed, the strong answer traces one important requirement to its evidence and names the gaps, rather than pointing to the policy’s length or its approval date. The second is to keep the policy short and durable and to push fast-moving detail into standards, so that a new model or tool means updating a list rather than reopening the policy. The third is to judge a policy by whether people can follow it: if the approved route does not do the job, enforcement alone will move the bypass somewhere you cannot see. The fourth is to treat patterns of exceptions and non-compliance as data about the policy, reviewed on a schedule by someone with the authority to change it.

Check yourself

1. An organization with an approved AI policy has AI governance.MythFact
2. Frameworks such as ISO/IEC 42001 and the NIST AI RMF treat the AI policy as one element among many.MythFact
3. The more detailed an AI policy is, the better it will hold up as technology changes.MythFact
4. A steady stream of exception requests for the same thing can mean the policy needs redesign.MythFact
5. Strong technical controls make a written policy unnecessary.MythFact
6. Banning unapproved AI tools reliably ends their use.MythFact

What comes next

Every mechanism in this chapter depended on a name: the owner of a requirement, the approver of an exception, the person who reviews the evidence and can change the standard. So far those names have been left blank. The next chapter, AI Roles, Ownership and Accountability, fills them in, and asks who is actually responsible for AI decisions, risks, systems and outcomes.