Your AI Policy Is Not AI Governance. It Is a Permission Slip.

# Your AI Policy Is Not AI Governance. It Is a Permission Slip. **Direct answer:** An AI policy tells people what they should do. AI governance proves who owns the risk, which systems exist, what data they touch, how outputs are checked, and what happens when something fails. A one-page policy is not governance. It is a permission slip with good intentions. The gap is already visible in the data. McKinsey reports that **more than three-quarters of organisations** use AI in at least one business function. Yet only **27% of respondents** at organisations using generative AI said employees review all AI-generated content before use. A similar share said **20% or less** of AI-generated content is checked. **47%** said their organisations had experienced at least one negative consequence from generative AI. IBM reports that, among **600 organisations** studied by the Ponemon Institute, **63% had no AI governance policies** to manage AI or prevent shadow AI. IBM also reports that **97% of organisations with an AI-related security incident lacked proper AI access controls**. High shadow-AI use added **USD 670,000** to the average breach cost in the IBM study. Sources: [McKinsey, The State of AI](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-how-organizations-are-rewiring-to-capture-value), [NIST, AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework), and [IBM, 2025 Cost of a Data Breach Report](https://www.ibm.com/think/x-force/2025-cost-of-a-data-breach-navigating-ai). ## The policy illusion Most founders start with a document: “Do not put confidential data into public AI tools.” “Check AI output before sending it to customers.” “Use approved tools only.” The words sound responsible. But they do not answer the operating questions: - Which AI tools are employees already using? - Who approved them? - Which models can access customer or company data? - Which employees or agents have permission to use them? - What does “check the output” mean in a high-volume workflow? - Where are prompts, outputs, approvals, and incidents logged? - Who can turn a system off? - Which vendor can retain or train on your data? If nobody can answer those questions, the policy is not controlling AI. It is documenting hope. ## Adoption is moving faster than oversight McKinsey’s 2025 global survey shows that AI adoption is broad, but governance is uneven. Only **28%** of respondents at AI-using organisations said the CEO oversees AI governance, while **17%** said the board does. On output review, only 27% said all generative-AI content is checked before use. McKinsey also found that **21%** of respondents said their organisations had fundamentally redesigned at least some workflows around generative AI. Less than one in five said their organisations track KPIs for generative-AI solutions. Less than one-third said their organisations follow most of the 12 adoption and scaling practices McKinsey tested. This matters because AI risk does not sit inside a model alone. It sits inside a workflow. An AI assistant that drafts internal notes is one risk. An AI agent that can issue refunds, change prices, approve suppliers, send customer messages, or access sensitive records is another. A policy that treats both as “using AI” is not a control system. ## Policy-only versus operating governance | Question | Policy-only approach | Operating governance | |---|---|---| | Ownership | Someone wrote the document | A named executive owns the risk | | Inventory | Employees self-report tools | The company maintains a live AI register | | Access | General warning about sensitive data | Role-based access, least privilege, and revocation | | Risk | One rule for every use case | Risk tiers based on impact and autonomy | | Output | “Check before sending” | Defined review thresholds, sampling, and sign-off | | Vendors | Contract language | Vendor due diligence, data-use limits, and exit plan | | Data | “Do not upload confidential data” | Classification, lineage, retention, and deletion rules | | Monitoring | Annual policy reminder | Logs, KPIs, drift checks, incident alerts, and audits | | Failure | Blame the user | Pause, contain, investigate, correct, and learn | | CEO question | Did we publish the policy? | Can we show who used what, with which data, and why? | ## NIST says governance is a lifecycle The U.S. National Institute of Standards and Technology created the AI Risk Management Framework to help organisations incorporate trustworthiness into the design, development, use, and evaluation of AI systems. NIST organises the framework around four functions: **Govern, Map, Measure, and Manage**. That structure exposes the weakness in a policy-only approach. **Govern** means ownership, culture, accountability, and policies that operate across the lifecycle. **Map** means understanding the context, intended use, affected people, data, dependencies, and potential harms. **Measure** means testing performance, security, privacy, bias, reliability, and other risks. **Manage** means prioritising, responding to, documenting, and controlling those risks over time. NIST’s point is practical: an AI system changes. Its data changes. Its users change. Its vendor changes. Its risk changes. A PDF does not change when the system does. ## The access-control problem IBM’s 2025 breach research is a warning for founders who think AI governance is mainly an ethics or compliance topic. It is also an identity and security topic. IBM says **97%** of organisations with an AI-related security incident lacked proper AI access controls. The control question is not simply whether employees are allowed to use AI. It is what the tool can read, write, execute, export, remember, and trigger. An employee using a chatbot to summarise a public article is not the same as an automated agent with access to a CRM, finance system, code repository, customer support inbox, or HR database. Treating both as one policy category is how access grows faster than accountability. ## The minimum governance stack for a growing company **1. Name an owner.** The CEO does not need to run every control, but someone must own the AI risk register, decisions, exceptions, and reporting. **2. Build an AI inventory.** List models, tools, vendors, internal agents, departments, data sources, users, permissions, locations, and business decisions affected. **3. Create risk tiers.** Separate low-risk drafting from high-impact decisions, external communications, sensitive data, autonomous actions, and regulated use cases. **4. Control access.** Use least privilege. Give an AI system only the data and actions it needs. Review permissions and revoke them when roles or vendors change. **5. Classify data.** Define what is public, internal, confidential, personal, regulated, or prohibited. Attach tool-specific rules to each class. **6. Define human review.** “Human in the loop” is not enough. State when review is mandatory, who is qualified, what they must check, and what evidence they record. **7. Log important activity.** Keep records of tool, user, model, prompt category, data class, output, approval, action, and incident where appropriate and lawful. **8. Review vendors.** Ask where data goes, how long it is retained, whether it trains a model, which subprocessors are used, how incidents are reported, and how the company exits. **9. Measure outcomes and failure.** Track adoption, accuracy, override rates, customer complaints, security events, time saved, revenue impact, and cost. A tool that saves hours but creates rework is not a productivity win. **10. Practise the shutdown.** Decide who can pause a system, isolate data, revoke access, notify customers, and investigate. If the answer is “we will figure it out,” the control is missing. ## The founder audit Ask these questions in the next leadership meeting: 1. How many AI tools are in use today, including tools employees bought themselves? 2. Which AI systems can access customer, financial, source-code, HR, or legal data? 3. Which systems can take an action rather than only produce text? 4. Who owns each high-risk use case? 5. What percentage of external AI output receives qualified review? 6. When was each vendor’s retention and training policy last checked? 7. What is the fastest way to revoke an AI system’s access? 8. Which AI KPI proves business value rather than activity? 9. What incident would force us to stop the system today? 10. Can we show the board a current AI inventory and risk map? If the answer to most questions is “we have a policy,” you do not have governance. You have a document standing in for a system.

## Frequently asked questions ### What is the difference between an AI policy and AI governance? An AI policy states principles and acceptable behaviour. AI governance assigns ownership and operates the controls that manage the full lifecycle: inventory, risk mapping, access, testing, monitoring, incidents, vendors, and review. ### Is an AI policy still useful? Yes. A policy is one layer of governance. It communicates expectations and creates a baseline. It becomes dangerous when leaders treat the document as proof that the risk is controlled. ### Does every startup need a formal AI governance team? Not necessarily. A small startup may begin with one accountable owner, a live inventory, risk tiers, access rules, vendor checks, output review, and an incident playbook. The system should grow as AI access, autonomy, data sensitivity, and business impact grow. ### What did IBM find about AI access controls? IBM reported that 97% of organisations with an AI-related security incident lacked proper AI access controls. This is a finding from IBM’s research sample, not a universal rate for every organisation. ### What does NIST recommend? NIST’s AI Risk Management Framework organises risk work around Govern, Map, Measure, and Manage. It is voluntary guidance designed to support trustworthy AI across design, development, use, and evaluation. ### How much AI output should a human review? There is no single percentage for every workflow. Review should rise with customer impact, legal or financial risk, sensitive data, autonomy, and the cost of error. Define review thresholds instead of using the vague phrase “human in the loop.” ### What is shadow AI? Shadow AI is the use of AI tools or features that have not been approved, inventoried, or governed by the organisation. It can create data, security, privacy, vendor, and accountability risks even when employees are acting in good faith. ### What should a CEO measure? Measure business value and control quality: adoption, accuracy, rework, overrides, incidents, customer complaints, data exposure, access reviews, time saved, revenue impact, and cost. Usage alone is not governance or value. ## Final verdict AI will not be governed by a memo. It will be governed by owners, inventories, permissions, risk tiers, review thresholds, logs, vendor controls, measurable outcomes, and the ability to stop a system before it creates a larger problem. **Your AI policy is not governance. It is the first page of governance. If the controls do not operate behind it, it is a permission slip.** ## Sources - [McKinsey — The State of AI: How organizations are rewiring to capture value](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-how-organizations-are-rewiring-to-capture-value) - [NIST — AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) - [IBM — 2025 Cost of a Data Breach Report: Navigating the AI rush without sidelining security](https://www.ibm.com/think/x-force/2025-cost-of-a-data-breach-navigating-ai)