AI Governance Needs a Paved Road, Not Just a Policy

THE AI GRC DESK

Practical AI for GRC practitioners. Using it, governing it, and building it responsibly.

THE GOVERNED AI PLAYBOOK · ISSUE 02

Hello Hello,

In the first issue of The Governed AI Playbook, I wrote about what changes when AI moves beyond the chat window and becomes part of how work gets done. The comments that followed pointed to the next problem almost immediately.

It is one thing to write that human review is required. It is another to prove that the review happened.

It is one thing to say an AI system should only have appropriate access. It is another to define what it can connect to, what it can do with that connection, what happens when it crosses a boundary, and how you stop it.

That is why I think AI governance needs a paved road, not just a policy.

It gives people a supported route from experimentation to production without expecting every team to reinterpret governance requirements from scratch.

The policy still matters.

But the paved road is where the policy becomes operational.

Take a statement like:

That sounds sensible.

But operationally, I still need to know; What counts as a high-risk action? Where does the workflow stop? Who receives the approval request? Can the AI continue if nobody responds? What happens if the reviewer rejects the action? Is the approval recorded? Can I prove later that the review actually happened?

The same applies to access.

A policy might say that AI should only access information required for its task.

The paved road needs to turn that into something real; which connections are approved, which users or groups can access them, what permissions are granted, what data is in scope, what actions are allowed, what actions are explicitly blocked

That is the difference between policy intent and control execution.

When I talk about a paved road, I am not talking about one product or one technical architecture. I am talking about the operating environment an organisation creates around AI adoption.

At a minimum, I would expect it to define:

The goal is not to centralise every AI decision. The goal is to stop teams having to make the same governance decisions over and over again.

If every team has to rediscover what data is allowed, which connectors are safe, where human review belongs and how evidence should be retained, the organisation does not really have a paved road. It has a collection of individual experiments.

This is where GRC teams need to be careful. If the approved route is too slow, too unclear or too restrictive, people will find another route.

A paved road should therefore be opinionated without being unnecessarily heavy.

A read-only AI assistant summarising approved internal documents should not automatically require the same control depth as an agent that can change production data, initiate a transaction or act across multiple business systems.

The Blueprint Alliance makes this distinction directly in its Governing Agentic Execution whitepaper. It argues that controls should reflect the operational scope and risk of the agent, rather than applying the same control model to every deployment.

That gives us a useful principle:

Claude can be your analyst, editor, and strategist.
But most professionals are using it to fix grammar.

These 200+ Claude prompts take it from grammar tool to your most powerful AI work assistant.

Sign up for Superhuman AI and get:

Claim your free prompts

For me, a paved road for AI adoption comes down to five things an organisation needs to define clearly:

Context + Connections → Capabilities → Cadence

with Controls embedded across all four.

That distinction matters.

Controls should not appear at the end of the process as a final approval step. They should shape how the AI environment is designed from the beginning.

It is about how the organisation decides to roll AI out, scale it and keep it governable.

What rules and expectations shape how AI can be used?

That might include:

The aim is to reduce ambiguity before teams start building.

People should not have to interpret a high-level AI policy differently in every function.

What can AI connect to across the organisation?

This includes:

The important question is not:

It is:

That is where the paved road starts to become enforceable.

What categories of AI capability is the organisation prepared to support?

For example:

Not every capability creates the same exposure. There is a meaningful difference between AI that recommends an action and AI that performs it. The paved road should make that distinction explicit.

How does the AI operate?

Is it:

A user asking AI a question once creates a different operating model from an agent running continuously in the background.

Cadence affects how much autonomy the system has, how often decisions are made and how quickly problems could scale.

Controls should sit across Context, Connections, Capabilities and Cadence. What governance is built around those capabilities? At minimum, I would want to know:

That is why I do not think of controls as the final C in a straight line. They are the governance layer across the entire paved road.

Governance is not the final gate on the paved road. It is built into the road itself.

There is also a useful principle underneath this model:

Risk often comes from the combination of capability, connection, permission and consequence.

An AI system being able to “update a record” does not tell me enough.

I also need to know:

That is where the paved road becomes practical.

This becomes easier to see when you apply the model to a real enterprise rollout.

Imagine an organisation wants to deploy Claude across the business using Claude Chat, Claude Code and Cowork.

Those capabilities create very different operating models. Anthropic separates organisation-level settings for the Claude app, Cowork and Claude Code, alongside controls such as SSO and SCIM, roles and permissions, connectors, data retention and product-specific settings. Anthropic’s enterprise admin guidance is a useful reference point.

So I would think about the rollout as one enterprise AI service with different capability paths.

This is the lightest part of the paved road. For many users, the primary activity is asking, analysing, summarising and drafting.

The organisation would still need to define:

But the execution risk is relatively limited compared with tools that can act on systems directly.

Claude Code changes the control model because the AI can interact with files, repositories, development environments and tools. The paved road therefore needs stronger controls around:

Anthropic supports centrally managed Claude Code policies covering areas such as tool permissions, file access restrictions and MCP server configuration. Anthropic’s Claude Code enterprise guidance is one example of how those controls can move from guidance into configuration.

Instead of saying:

the organisation can define the tools centrally.

Cowork takes the organisation further again because it is designed for multi-step knowledge work across files, tools and connected systems.

Anthropic currently describes enterprise controls including group-based access, custom roles, connector permissions, usage analytics and OpenTelemetry support for Cowork deployments. Its enterprise deployment guidance gives a useful view of that operating model.

The paved road now needs to answer:

This is where AI governance starts looking less like tool approval and more like service governance, and that is the point.

A paved road does not mean giving everyone the same AI access.

It means giving each population a supported route with the right capabilities, connections and controls already built in.

Chat
A broader self-service route for lower-risk assistance.

Code
A more constrained engineering route with repository, file, tool and execution controls.

Cowork
A stronger workflow route with scoped connectors, permissions, monitoring and approval points.

Anthropic’s current enterprise guidance reflects this kind of phased approach: establish the identity, data governance, logging and admin foundations, then scale into more powerful coding and agentic capabilities with visibility intact. See Anthropic’s enterprise readiness guidance.

That is what a paved road should do.

It should allow adoption to expand without governance having to start again every time the capability becomes more powerful.

The Blueprint Alliance frames agent governance around four operational questions:

Those map to discovery and identity, access and entitlements, runtime monitoring and authorization, and active containment.

I like this framing because it moves the conversation beyond:

toward:

That is a much more useful governance question.

Approval is only the beginning.

One of the strongest ideas in the Blueprint Alliance paper is the distinction between technical access and approval authority. An agent might technically have the ability to perform an action, while the workflow still requires an approval when that action crosses an operational or financial threshold.

That matters because access alone should not determine whether an AI system is allowed to complete every possible action. This is where human review has to become a design decision.

If a workflow requires approval, the paved road should define where the workflow pauses, who approves it, what happens if approval is not granted and what evidence is retained.

“Human-in-the-loop” should not just be written into a policy.

It should exist inside the workflow.

Governance does not end once a tool or workflow is approved.

The Blueprint Alliance architecture puts significant emphasis on runtime monitoring, tracing, approval triggers and checking whether an agent continues to operate within its delegated purpose.

It also treats containment as more than one big kill switch.

Response might mean:

And once the issue has been resolved, recovery needs its own controls, including re-attestation, staged restoration and evidence of the decision to return the agent to service.

That gives me another useful way to think about the paved road:

If the governance model only covers entry, it is incomplete.

If your organisation is rolling out AI now, I would ask:

Those questions will tell you very quickly whether you have an AI policy or an AI operating model.

Do not start by trying to design the perfect enterprise AI control plane.

Start with the routes people are already trying to use.

If teams are using chat, define the chat road.

If engineering is adopting coding agents, define the engineering road.

If functions are beginning to use agentic workflows, define the execution road.

Then connect those roads through common governance principles, identity, monitoring, ownership and evidence. The goal is not to slow AI adoption down.

It is to make the supported route clearer, safer and easier to scale than the alternative.

That is when governance stops being something written beside the work and starts becoming part of how the work actually happens.

Next in The Governed AI Playbook: I’ll go deeper into connections and why knowing what AI can reach across the organisation is becoming one of the most important parts of the control model.

Princess David Okoro, CISM
Author, The AI GRC Desk
Find me on LinkedIn: Princess David Okoro
Subscribe to The AI GRC Desk: aigrcdesk.com/subscribe

The practitioner's guide to AI in GRC. Using it, governing it, and building it responsibly.