Enterprise AI governance: a practical guide

AI governance is the operating-level control over how AI is accessed, sourced, approved, metered and audited across an organisation. It is not a policy PDF. It is the environment that makes every AI interaction permission-aware, grounded in evidence, and on the record. A policy states an intention; governance is what makes that intention hold in practice.

What AI governance is (and what it isn’t)

Most organisations that say they have AI governance have an AI policy: a document that tells staff what they may and may not do with tools like ChatGPT. It is a necessary first step and, on its own, close to worthless. A document does not check permissions. It does not ground an answer in a source. It does not record who asked what, or stop confidential information leaving the building. It sits on an intranet while the actual behaviour happens somewhere the document cannot reach.

AI governance, properly understood, is the environment in which AI is used, not the rules written about it. It is the set of controls, applied in the systems people actually work in, that determine how AI is reached, what it may draw on, who signs off on its output, and what is kept on the record afterwards. The test is simple: if you removed the policy document tomorrow, would anything about how AI behaves in your organisation change? If the answer is no, you have a policy, not governance.

Two distinctions are worth drawing early. AI governance is narrower than governed work, which applies the same discipline to documents, operations, knowledge and decisions whether or not AI is involved. And it is different in posture from GRC and compliance tooling, which exist to restrict activity and log risk. Governance in the sense meant here lets AI be used, at speed, with the controls built in so the use is defensible.

Why AI policies alone fail

An AI policy fails for the same reason a “no personal devices” memo failed a decade ago: it asks people to act against their own productivity, and gives them no sanctioned alternative. Your most capable staff have found that a general-purpose model saves them hours. Telling them to stop, without offering a governed way to get the same benefit, does not stop the behaviour. It drives it underground, into personal accounts and browser tabs where nothing is visible.

The specific ways a policy-only approach breaks down are worth naming:

• It relies on voluntary compliance for behaviour that is invisible, so non-compliance carries no friction and no signal.
• It cannot see what information left the organisation, so a breach is discovered after the fact, if at all.
• It says nothing about where an answer came from, so output enters documents and decisions with no defensible source.
• It offers no metered, sanctioned path, so the choice staff face is “use the tool against policy” or “work slower than your peers”.

Governance succeeds where policy fails because it changes the environment, not the instructions. When the sanctioned path is also the easy path, and it carries permission-awareness, grounding and a record with it, staff use it because it is better, not because they were told to.

The components of AI governance

A workable AI governance model has six components. Each answers a question a sceptical executive should be asking about every AI interaction in the organisation.

• Access and permissions. Who can use AI, and what can it see on their behalf? Access should inherit from the identity and permission structures you already run, so an AI request draws only on evidence the person is entitled to. AI must never become a way to reach information a user could not otherwise open.
• Approved providers. Which models and services are sanctioned, and on what terms? A governed environment routes requests to vetted providers under commercial terms you control, rather than leaving the choice to whichever consumer app an individual happened to sign up for.
• Evidence and grounding. What is an answer based on? Where AI produces a business artefact, it should be grounded in retrievable evidence and stay connected to it, so any claim can be traced to its source rather than taken on trust.
• Approval. Who signs off before output counts? Anything that leaves the organisation, or drives a decision, should pass through a deliberate human decision rather than flowing straight from a model into the world.
• Audit. What is kept on the record? Who asked what, what it drew on, and who approved the result should be recorded and preserved, so the organisation can answer questions about its AI use after the fact.
• Cost and metering. What is being spent, and by whom? AI usage should be metered and attributable, so cost is visible and controllable rather than arriving as a surprise on a bill.

These are not six separate products to buy. They are six properties that should hold together, in one environment, for every AI interaction. When they do, an interaction is governed. When any one is missing, it is not.

A single governed AI request, step by step

The abstraction becomes concrete when you follow one request through. A project manager asks an internal assistant to summarise the site-safety findings across a body of inspection reports.

1. The request is identified against the person making it, and their permissions are resolved from the organisation’s existing identity structures.
2. The environment gathers only the evidence that person is entitled to see. Reports outside their access are never retrieved, so they cannot surface in the answer.
3. The request is routed to an approved model under terms the organisation controls, not a personal consumer account.
4. The answer is grounded in the retrieved reports, and each claim stays linked to the source it rests on.
5. The interaction is metered and logged: who asked, what it drew on, what it cost.
6. If the summary becomes a document that leaves the organisation, it passes through an approval before it does, and that approval is recorded.

Nothing in that sequence is exotic, and none of it slows the manager down in any way they would notice. The difference from an ungoverned request is entirely in what is checked, sourced and recorded around the answer, which is precisely the difference between plausible and defensible.

An AI governance framework you can act on

The components above describe what good looks like. The checklist below turns them into questions you can take into a room and answer honestly. Treat it as a diagnostic: every “no” marks a place where ungoverned AI use is accumulating.

1. Do you know which AI tools your staff are actually using, including the ones outside any sanctioned list?
2. Is there a sanctioned path to AI that is at least as easy as the unsanctioned one?
3. Does AI access inherit your existing permissions, so a request cannot reach evidence the user could not otherwise open?
4. Are the models and providers in use vetted, and covered by commercial terms you control?
5. When AI produces a business artefact, can you trace its claims back to a source?
6. Does anything AI-produced pass through a human approval before it leaves the organisation or drives a decision?
7. Is AI usage recorded, so you could answer “who asked what, and on what basis” a year from now?
8. Is AI spend metered and attributable, rather than arriving as an unexplained total?
9. Is your governance model independent of any single vendor’s model, so it holds as the models change?

Nine yeses is a governed environment. Most organisations, asked these questions plainly, find they can answer yes to the policy-shaped ones and no to the ones that require the environment to actually enforce something. That gap is the work.

AI governance for Microsoft 365 environments

Most organisations do not need to build a governance environment from nothing, because they already run one that holds their identity, permissions and files. For the majority that means Microsoft 365. Good AI governance builds on that ground rather than working around it: it inherits who a person is and what they are entitled to from the systems already in place, so the permission model behind AI is the same one behind the rest of the organisation’s work.

Microsoft Copilot is the AI layer Microsoft offers over that environment, and it is a capable one: it operates within a tenant’s permissions and can draw on the content a user can already access. It is worth being precise about what a copilot is and is not. It is a capability that helps an individual produce output. It does not, on its own, decide which models and providers your organisation sanctions, ground every business artefact in a traceable source, route work through a defined approval, or give you a single metered record across the tools your staff use. Those are governance questions that sit above any one assistant. We treat this in more depth in the guide to AI governance for Microsoft 365.

Governance enables innovation, it doesn’t block it

The instinct to equate governance with restriction is understandable and, in this case, wrong. The organisations that adopt AI fastest are not the ones with the fewest controls. They are the ones whose staff can reach for AI without hesitating, because they know the sanctioned path is safe, sourced and their own to use. Uncertainty is the real brake. When people are unsure whether a tool is allowed, or where an answer came from, they either avoid it and lose the benefit, or use it quietly and carry the risk.

Governance removes that uncertainty. It says, in effect: here is AI you can trust, over evidence you are entitled to, with a record you can stand behind. That is a licence to move faster, not slower. The point of putting controls around AI is not to stop people using it. It is to let leadership say yes to using it, widely, without lying awake about what leaves the building.

How to get started

You do not begin with a platform decision. You begin by seeing clearly.

• Find out what is actually happening. Before writing another rule, establish which AI tools are in use and for what. Most leaders are surprised. The honest picture is the foundation for everything after it.
• Offer a sanctioned path first. The fastest way to reduce ungoverned use is to give people a governed alternative that is genuinely easier. A ban without an alternative changes where the behaviour hides, not whether it happens.
• Ground the high-stakes work. Start governance where the cost of an ungrounded answer is highest: documents that leave the organisation, and decisions that rely on them. Grounding and approval matter most there.
• Build on the ground you own. Inherit identity and permissions from the environment you already run, rather than standing up a parallel, uncontrolled layer.
• Stay model-agnostic. Keep the governance constant as the models change underneath it, so you are never locked to one vendor’s pace or terms. We make the case in don’t marry a model.

You can see the model applied to real work. A governed place to ask anything puts AI over your own knowledge, permission-aware, so answers stay inside the perimeter. Documents that defend themselves ground every sentence in a source. Both sit inside the same governed environment, which is the point: governance is not a feature bolted onto AI, it is the ground AI stands on. That principle is why we hold that the surface should be calm and explicit rather than restless.

Frequently asked questions

Related reading

• What is Governed Work?
• Shadow AI: the definitive guide
• AI governance for Microsoft 365
• Groundwork: Don’t marry a model
• Groundwork: The case for standing still