AI Governance Policy: Why a Written Policy Falls Short

There's a meaningful difference between three states: having no policy, having a policy in development and having a policy that operates in practice. IBM's data shows organisations aren't simply progressing through these stages at pace. Many are stalling before they reach the third.

A policy in development signals intent. It becomes a governance control only once it's published, communicated and tied to operational processes, and that's the transition where most organisations are currently stuck. For AI governance to mean anything at board level, the policy has to cross from document to operating model.

That stall shows up in IBM's own trend data. The share of organisations developing an AI governance policy rose from 22% to 33% year over year, but IT approval requirements for AI deployments, the most common individual governance control organisations use, fell from 45% to 38% over the same period. More organisations are building policy. Fewer are enforcing the most basic control already inside it.

The consequences show up elsewhere in IBM's data. Security incidents involving shadow AI, unapproved tools operating outside the policy's visibility, more than doubled this year to 43% of incidents, up from 20% last year.

Those incidents also cost more: $5.39 million on average, up from $4.63 million last year, with data loss or compromise in 49% of cases and disrupted operations in 42%. Roughly one in five also resulted in a regulatory fine.

A well-constructed AI usage policy does far more than list acceptable and unacceptable uses of AI tools. Each element it contains needs to be enforceable, backed by the systems that apply it.

What an enforceable AI usage policy actually covers

1. Approved use cases and risk tiers: which AI applications are sanctioned, for which business functions and under what conditions. Without this, approval decisions stay informal and inconsistent.
2. Ownership and decision rights: a named individual holds defined authority to approve, restrict or escalate for every AI system in scope.
3. Data-handling expectations: what data categories AI systems can process, where that data can reside, and what restrictions apply to training, fine-tuning or model outputs. These are enforceable controls on how AI systems handle data.
4. Access and permissions: who can deploy, configure or interact with each AI system. The policy sets the access rules; security teams enforce them technically, from the same source.
5. Evidence requirements: what evidence of compliance is required, how it's captured and how it's retained. Without this, governance is unverifiable.
6. Escalation routes: who's notified, in what timeframe and through what process when an AI system behaves unexpectedly, a new use case arises, or a third-party model is proposed.

Each element does real work on its own, but none of them is useful in isolation. The policy sets the standard. The operating model enforces it, and when the two are disconnected, the standard exists on paper while the risk exists in practice.

IBM's coordination data is stark: only 19% of organisations reported that their AI governance and security teams were working together. That points to a structural blind spot in how AI risk gets managed.

When governance and security operate on separate tracks, the policy defines the intent and the technical environment enforces something else entirely. The rules exist on paper while the technical controls follow a different logic entirely.

What disconnected ownership looks like in practice

Consider what happens when a new AI tool clears a governance approval process, but the access controls, identity verification and data permissions get configured independently by a separate security team working from different documentation. The policy may require role-based access. The deployment may not implement it, and the gap between the two stays invisible until something goes wrong.

IBM's data reinforces the scale of the problem. Among organisations that experienced an AI-related breach, 92% lacked proper AI access controls, including role-based access and multi-factor authentication, according to the IBM Cost of a Data Breach Report 2026. Across all breached organisations, only 40% reported applying access controls to AI models and data.

IBM stops short of claiming a direct causal link between governance-security coordination and these access control gaps. It frames the co-occurrence as a significant governance implication: when policy and technical enforcement sit with separate teams working from separate systems, the conditions for control failure are already in place.

Policy, technical permissions and incident response are meant to move together, but in practice they drift: what security implements can diverge from what policy requires, auditability that governance assumes exists often goes uncaptured, and the incident response both teams expect can fail to trigger silently. Closing that gap takes shared ownership of the same operational picture.

A usable AI governance policy has five operational characteristics. Each one connects the written standard to the people and systems responsible for enforcing it.

1. Clear ownership and decision rights: a named individual holds accountability for each AI system in scope, with documented and known decision rights for approval, restriction and escalation.
2. Approved AI use cases and risk tiers: AI applications are categorised by risk level, with higher-risk use cases requiring additional scrutiny, defined controls and more frequent review. The categorisation changes as use cases and risk profiles evolve.
3. Data, access and identity controls: the policy specifies what data AI systems can process and under what conditions, with access that's role-based, verified and auditable, implemented technically rather than assumed.
4. Monitoring and evidence of compliance: the policy defines how compliance gets demonstrated, what evidence is retained and how monitoring runs on a continuous basis.
5. A shared escalation and review process: governance, security and compliance teams follow the same escalation path when AI systems behave unexpectedly, when new deployments are proposed, or when a policy exception is needed.

The organisational reality is what makes this hard: these five elements are commonly owned by different teams, documented in different places and reviewed on different schedules. Bringing them together takes a shared system of record. For organisations working towards ISO/IEC 42001:2023, the international standard for AI management systems, or building an AI governance operating model, this operational structure is the foundation that makes compliance demonstrable rather than assumed.

For most governance, risk, and compliance (GRC) teams, writing the policy is the easy part. The harder work is operationalising it through the same systems that already manage risk, controls and evidence across the rest of the programme. AI governance sitting in a separate document, managed by a separate working group and reviewed on a separate cycle, creates exactly the coordination failures IBM's data describes. The policy team and the security team are both doing their jobs; they're just working from different pictures of the same problem.

The National Cyber Security Centre reaches a similar conclusion from a different angle: keeping AI systems secure is as much about organisational culture, process and communication as it is about technical measures, with responsibility resting on the organisation rather than on individual users.

SureCloud's approach connects policy, permissions, traceability and human oversight within the same GRC programme, so organisations can manage AI use cases, control evidence and compliance monitoring alongside their existing risk and compliance activity.

Compliance Management supports ISO/IEC 42001:2023 alongside established frameworks including ISO 27001, DORA (the EU's Digital Operational Resilience Act) and the NIST Cybersecurity Framework 2.0, so AI-specific governance requirements sit inside the same system of record as every other compliance obligation.

The principle behind SureCloud's "Secure, Proven and Repeatable. AI You Can Trust." model applies equally to how organisations govern their own AI use: policy, permissions, traceability, model safeguards and human oversight all need to connect within one shared system.

The goal is an operating model where the people defining AI policy, the people approving AI use cases and the people enforcing technical controls all see and prove the same reality.