Why your PMO's AI policy is already out of date

13 June 2026·8 min read

Most PMO AI policies were drafted in 2024, approved in early 2025, and scheduled for annual review. The models they were written about have been replaced two or three times since. The risk landscape has shifted. The tools the policy named are no longer the tools the team is using.

If your PMO has a published AI policy and you haven't touched it in nine months, it isn't governing anything any more. It's archaeology.

The cadence problem

PMO governance runs on quarters or years. AI capability runs on months. The policy you wrote against GPT-4 doesn't anticipate the context windows, vision capabilities, or agentic behaviours that shipped six months later. So in practice one of two things happens:

The policy is ignored. Everyone knows it's out of date. People do what's practical and hope nobody asks. Governance theatre, no real protection.
The policy is enforced literally. The team is banned from using capabilities that are now table stakes elsewhere. The org loses ground; the policy is correct but expensive.

Both are bad outcomes from the same root cause: writing a policy as if AI were a fixed thing.

What dates the fastest

Approved tools lists. The list of "you may use X, Y, Z" is obsolete the moment a major vendor ships a feature update. Lists locked at point-in-time decay within a quarter.
Data classification rules. Most rules were written assuming AI tools would persist or train on inputs. Modern enterprise contracts increasingly forbid this. The default assumption no longer holds.
Output review thresholds. "All AI output requires peer review" sounds prudent but becomes unworkable when AI is drafting every status pack. The threshold needs differentiation by artifact criticality.
Forbidden use cases. "AI may not be used for code review" was reasonable in 2024 and looks quaint now. Forbidding the obvious use cases pushes them underground.

The governance gap

Policies decay roughly twice as fast as PMOs review them. By month nine, the average AI policy permits things nobody does and forbids things everybody does. You're getting the worst of both worlds.

What survives

Some parts of an AI policy age well. They tend to be the parts that describe principles rather than tools or capabilities:

Accountability. A named human is responsible for every AI-produced artifact that leaves the team. This doesn't depend on which model wrote it.
Disclosure norms. If AI materially shaped a deliverable, the consumer should know. The threshold for "materially" is the interesting bit, but the principle survives.
Data handling. Categories of data that may never go into any external model. This is stable; the implementations change.
Failure handling. What happens when AI output is wrong in a way that affects a decision. A defined post-mortem process beats any prescription.

What to do instead of an annual policy

Split the policy into stable and volatile sections. Principles, accountability, data classes go in the stable half, reviewed yearly. Approved tools, model versions, specific use cases go in the volatile half, reviewed monthly.
Name an owner for the volatile half. Not the CIO, not the PMO sponsor — somebody close enough to the work to know what changed last week. They have authority to add tools to the approved list without a committee.
Run quarterly drift reviews. What are people actually doing? What does the policy say? Where do they differ? Update one or the other.
Publish change logs. When the policy changes, everyone needs to know. Quiet updates breed inconsistent enforcement.
Tie policy to incidents, not to calendars. If something went wrong, that's the trigger for review. Not "it's been a year."

The honest reframe

Treating AI policy as a quarterly artifact rather than an annual one feels uncomfortable for governance teams. It looks like the policy isn't "settled." But the underlying capability isn't settled either, and pretending otherwise just transfers the cost from the governance process onto the people delivering work — who are now choosing daily whether to follow a stale rule or do the practical thing.

A living policy is harder to maintain. A dead policy is cheaper to maintain and worse at every actual purpose a policy is supposed to serve. The PMOs that figure this out first will spend the second half of the decade governing something real. The ones that don't will spend it managing the gap between the policy and the practice.