Governance Is Not the
Document — It Is the
Name on the Document
Most organisations have an AI policy. Considerably fewer can name the executive accountable for it, produce an inventory of the agents running in their tenant, or evidence a single AI decision to an auditor. This page sets out what that gap costs and how it is closed.
Four Questions That Determine Whether You Have Governance
Not whether a policy exists; any organisation can produce one in an afternoon. These are the questions an auditor, a regulator, or an incident will put to you, and each maps to a concrete artefact that is either in place or is not.
Who Is Accountable?
One named executive, rather than a committee or a function. If the answer requires more than a sentence, the policy is documentation rather than governance.
What Is Running?
A current inventory of AI systems and agents: owner, purpose, identity, data reach, and review date. Most tenants cannot produce this within a week.
What Can It Reach?
The data a given agent or assistant can retrieve, verified against the permission model as configured rather than the intent expressed at build time.
Can You Prove It?
Interaction logging, eDiscovery reach, and retention aligned to the organisation's legal position. Governance that cannot be evidenced is a claim rather than a control.
Four Roles and What Each One Owns
AI governance fails in the seams between security, data, legal, and the business, each assuming another holds it. The remedy is not a larger committee. It is four unambiguous ownerships and a defined decision route between them.
| Role | Owns | Decides | Fails when |
|---|---|---|---|
| Accountable executive Often the fractional AI officer |
The AI policy, the risk appetite, and the escalation route. Reports on the AI estate to the board or risk committee. | Whether a use case proceeds, pauses, or stops. | The role is shared. Shared accountability is, in practice, no accountability. |
| Security & identity | Identity for humans and agents, Conditional Access, privileged access, device compliance, Defender signal. | Whether an agent gets an identity and what it may authenticate to. | Agents are treated as applications rather than as principals with a lifecycle. |
| Data & records | Sensitivity labels, DLP, retention, eDiscovery, oversharing position, and the record of what was remediated. | What data is in scope for grounding, and under which label. | Oversharing is assumed rather than measured, and is subsequently discovered by a user. |
| Business owner Per use case, per agent |
The purpose, the benefit claim, the acceptance of residual risk, and the review date. | Whether the agent still earns its place at each review. | The agent outlives the person who commissioned it and is never retired. |
One rule keeps this workable: nothing is published without a named business owner and a review date. This applies to policy exceptions, pilots, and departmental agents alike. If no one will accept ownership, it does not go live.
Four Documents, and No More
Governance fails on volume. A policy library that goes unread produces the behaviour it was written to prevent, and adds a discovery burden when an incident occurs. The following is the minimum viable stack.
1 · AI Policy
- The named accountable executive and the escalation route
- Approved tools, and the process for approving another
- Prohibited uses, stated concretely rather than in principle
- Risk appetite: what proceeds on self-assessment, what needs review
2 · Acceptable Use
- One page, plain language, with worked examples
- What may and may not be put into a prompt
- The verification duty: output ownership always rests with a named individual
- Acknowledged before a licence is assigned
3 · Agent Standard
- Intake, review, and publish gates, with a light path for read-only agents
- Identity, permission scoping, and connector permission mapping
- Logging, retention, and the mandatory review date
- Retirement criteria, so that the register does not grow indefinitely
4 · AI Register
- Not a document, but a maintained inventory reviewed quarterly
- System or agent, owner, purpose, identity, data reach, risk class
- Framework mapping and the date of last review
- The first artefact provided to an auditor
Choose One Spine and Map the Rest to It
Running three frameworks in parallel produces three backlogs and no completed controls. Select the one your obligations and your board already recognise, adopt it as the spine, and map the others as views onto the same control set.
NIST AI Risk Management Framework
Voluntary, US-origin, and the most practical starting spine for organisations without a binding compliance trigger. Four functions — Govern, Map, Measure, Manage — with a Generative AI Profile that translates them for the systems being deployed.
- Govern — accountability, policy, culture, and risk appetite
- Map — context and intended use of each system, per use case
- Measure — the metrics and testing that render risk observable
- Manage — prioritisation, treatment, monitoring, and retirement
ISO/IEC 42001
An AI management system standard, structured comparably to ISO 27001 and certifiable against external audit. The appropriate spine where certified management systems are already in operation, or where customers and procurement teams require evidence they can file.
- A plan-do-check-act structure already familiar to existing ISMS teams
- Annex controls covering AI-specific concerns and impact assessment
- Certification is the differentiator: an assertion a third party has tested
EU AI Act
Regulation rather than framework: obligations scale with risk class. Unacceptable practices are prohibited, high-risk systems are heavily conditioned, limited-risk systems carry transparency duties, and minimal-risk systems are largely unaffected.
- Applies extraterritorially where output is used in the EU; a US-headquartered footprint is not automatically out of scope
- Obligations phase in on a staged timetable that has itself been subject to amendment proposals
- Classification is per system and per use, not per organisation
Confirm the current timetable with counsel. Phase-in dates have been actively debated since the Act entered into force, and nothing on this page is legal advice.
What most organisations require first is not a framework decision. It is the register described above. Every framework asks, in its own vocabulary, which systems are in operation and who owns them; until that can be answered, the choice of spine is academic.
Where Policy Meets Configuration
In a Microsoft 365 estate, most of what governance requires already exists as a control you own. The work is rarely acquisition. It is enablement, assignment, and the ability to produce evidence afterwards.
| Governance requirement | Microsoft control surface | Evidence it produces |
|---|---|---|
| Only authorised people reach AI capability | Entra ID, Conditional Access, licence assignment by group | Policy state and sign-in logs per cohort |
| Agents have managed, reviewable identities | Agent and workload identities in Entra, permission scoping, connector permission mapping | Identity inventory and permission grants per agent |
| Sensitive content is classified and enforced | Purview sensitivity labels, auto-labelling, encryption | Label coverage reporting over high-value repositories |
| Sensitive content does not leave | Purview DLP across SharePoint, OneDrive, Exchange, Teams | Policy match reporting and incident history |
| Users cannot retrieve content they should not reach | SharePoint Advanced Management: oversharing reports, site access reviews, restricted access control | Before-and-after oversharing reports with a measurable difference |
| AI interactions are auditable | Purview Audit and eDiscovery over Copilot interactions | Searchable prompt and response history within retention |
| Content lifecycle is controlled | Retention policies, records management, ROT clean-up | Disposition records and index quality over time |
| The agent estate remains known | Copilot Studio environment and Power Platform governance, publish gates | The agent register, reviewed quarterly |
| Value and usage are visible | Copilot Dashboard in Viva Insights, usage reporting | Monthly metrics against a pre-rollout baseline |
Capability availability varies by licence and continues to change. The mapping above is verified against your tenant during an engagement rather than assumed from product documentation.
Ninety Days to a Defensible Position
Not to certified, and not to complete. To the point at which the four questions can be answered and evidenced, and a risk committee can be shown a controlled trajectory rather than an intention.
Days 1 – 30 · Establish
- Name the accountable executive and put it in writing
- Inventory every AI system and agent already running in the tenant
- Publish the one-page acceptable-use guidance
- Confirm Copilot interactions are captured in Purview Audit
Days 31 – 60 · Control
- Stand up the agent intake and review gate before the next publish
- Complete the register: owner, purpose, identity, data reach, review date
- Set prompt and response retention to match the legal position
- Close the highest-risk oversharing findings and evidence the delta
Days 61 – 90 · Evidence
- Choose the framework spine and map existing controls to it
- Log the gaps as a tracked backlog with owners and dates
- Complete the first quarterly agent review and retire agents that no longer earn their place
- Report the AI estate to the board or risk committee
None of this ninety-day sequence requires a new product. It requires a name, an inventory, a gate, and a review cadence. Organisations that treat governance as a procurement exercise tend to stall; those that treat it as an ownership exercise progress.
Governance You Can Evidence
The readiness assessment scores the governance pillar alongside identity, data, estate, licensing, and adoption, then identifies which one is blocking the tier above.