THE GOVERNED AI PLAYBOOK · ISSUE 01
Hello Hello,
For a while, many AI governance conversations have focused on the chat window: which tools are approved, what information employees can put into them, what they should avoid sharing, and what outputs need to be checked. Those questions still matter.
But AI is increasingly moving beyond a standalone chat experience. It can connect to the systems where work happens, retrieve live information, create outputs, continue work across tasks, and run on a schedule. That changes the governance question.
THE ONE THING TO TAKE AWAY
When AI becomes part of the operating environment, we cannot govern only what someone asks it. We also need to govern what it can access, what it can do with that access, what it can repeat, and who remains accountable for the outcome.
The governance boundary is getting bigger
Think about the difference between these two scenarios. In the first, someone opens an approved AI tool, asks it to help draft a document, reviews the response and closes the window. The governance questions are relatively familiar:
Is the tool approved?
Is the data appropriate to use?
Is the output accurate?
Does a human review it before it is used?
Now imagine the AI is connected to business systems. It can retrieve information from approved sources, operate with permissions attached to those connections, create outputs elsewhere, and potentially run again when an event happens or on a schedule.
At that point, we are no longer governing only a conversation. We are governing a workflow, and the control surface becomes much wider.
The questions I would start asking
Access: What systems, documents and data sources can the workflow retrieve information from, and what is explicitly out of scope?
Permissions: Can it only retrieve information, or can it also create drafts, update records, or trigger actions? The difference between read access and write access matters.
Cadence: Can it run again without another human prompt? A one-off request is different from an event-triggered or scheduled workflow, so the trigger, frequency and boundaries need to be clear.
Human review: Where does review happen? A summary for a practitioner is very different from an action that changes a control record, communicates externally, or influences a material risk decision.
Ownership: Who is accountable for the workflow, reviews whether permissions are still appropriate, responds when the process or data changes, and can stop it if needed?
IN PRACTICE
The ideal framework for designing AI-enabled GRC work is Context + Connections → Capabilities → Cadence. I introduced it in Before the Use Case: How to Build AI Workflows That Actually Work in GRC, where I break down the four things I think need to be defined before an AI use case is ready to build. Each part forces a different governance question:
Context: What does the AI need to understand about how the work should be done?
Connections: Which approved sources does it need access to?
Capabilities: What narrow job is it allowed to perform?
Cadence: When does it run, and who receives or reviews the output?
Governance sits across all four. Approving the AI tool is only one part of the problem. A well-governed model connected to the wrong data, with excessive permissions, unclear ownership or no meaningful review point can still create risk.
QUESTIONS TO TAKE INTO YOUR NEXT MEETING
Do we know which AI workflows have connections to internal systems?
Can we see what permissions each connection has?
Do we distinguish between retrieval, drafting and action-taking capabilities?
Do we know which workflows can run without a new human prompt?
Is there a named owner for each workflow?
Are consequential outputs reviewed before action is taken?
Can we trace what information was used and what the AI produced?
Do we know when the workflow should escalate or stop?
You do not need a sophisticated autonomous agent before these questions become relevant. The moment AI begins interacting with the environment around the chat window, they start to matter.
ONE IMPORTANT POINT BEFORE YOU BUILD
More capability should not automatically mean more access or more autonomy. Start with the minimum context, connections and permissions required for the job, keep the capability narrow, put human review where the consequence requires it, and make ownership explicit before the workflow becomes part of normal operations.
That is the shift I want to explore in The Governed AI Playbook: not AI governance as a document sitting beside the technology, but the practical controls, decisions and operating patterns that help organisations move from AI experimentation to controlled, scalable adoption.
NEXT ON THE AI GRC DESK
Next, I’ll break down what I mean by The Paved Road for AI Adoption, and what it can actually look like in practice.
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.
