AI governance
AI usage policy, and the enforcement behind it
Writing the policy is the easy half. Your staff are already using these tools, a document has no way of knowing what they actually did, and I build the half that does, inside the Microsoft estate you are already paying for.
What is happening in your firm
Someone summarised a client document in a chatbot, probably in the last fortnight, almost certainly for a sensible reason and with no intent to do anything wrong. That is the ordinary case, not the alarming one, and it is why this is difficult.
The tools arrived faster than any policy cycle could move. Most were adopted by individuals rather than procured, so there is no purchase record, no contract and no list. When a client asks whether you use AI on their data and how it is controlled, the honest answer today is a guess dressed as a policy.
Why a document is not enough
Most firms already have something written, often supplied by a licensee or adapted from a template. It is not a bad document. It is the wrong kind of object for the job, in four specific ways.
No inventory
You cannot govern what nobody has enumerated. Most AI tooling in a small firm arrives through individuals rather than procurement, so there is no purchase record to work from.
No detection
A document has no way of knowing when it is breached. Nothing tells you a client file went into a chatbot, and nothing would have stopped it.
No shelf life
The tools change monthly. A policy written against the landscape of eighteen months ago is describing a world that has moved.
No answer under questioning
The test is not whether you have a policy. It is what happens when a client asks you to demonstrate it held last March.
A policy is a statement of intent, and intent is not a control. The gap between the two is invisible until somebody with standing asks you to close it, and by then the evidence you needed was the evidence you were not collecting.
How we would work
Three stages, in order
The register
First, and quick
What tooling is actually in use, by whom, against what kind of data. Everything downstream depends on it, it is the fastest of the three, and it is routinely the one that surprises people.
The boundary
Written for your firm
Classification of the data that matters and a decision, written down, about which categories may reach which tools. Specific enough that people can actually follow it, rather than a template that says be careful.
The enforcement
Where it becomes real
The same position implemented as policy in Microsoft Purview, so it acts on the data rather than depending on everyone remembering. This is the part that changes your answer when a client asks.
Only the second of those is a writing exercise. A policy in a document holds if everybody remembers it. A policy at the data layer holds whether they do or not, and it produces a record either way. That difference is the whole reason this is worth paying for, and it is the part almost nobody delivers.
What I will not tell you
That I have run this across a portfolio of clients. I have done it once, properly, at a licensed financial services firm, as part of a wider compliance and standards engagement. Guidelines, a usage register, and usage policies implemented in Purview.
What transfers is the sequence and the fact that the enforcement half is achievable inside a Microsoft estate a small firm already has. Being straight about the scope is more useful to you than a broader claim, because it is the version that survives your first hard question.
Where I actually stand on the tooling
I use AI tooling daily and in production, so this is not a position taken from the outside. It is genuinely useful, provided it sits inside documented guidelines and the security exposure is identified rather than assumed away.
Without those, the cost lands in two places. One is literal spend on tokens. The other is exposure, up to and including a breach. Neither shows up anywhere until it is expensive.
The more important point is about capability. People should be able to do their job without these tools and use them to uplift what they already do. I have seen dependency erode capability, and the failure mode is easy to state from inside my own discipline: writing nonspecific business requirements and then depending on a model to write the user story gets you a nonspecific user story.
So I am not selling you a prohibition, and not selling you enthusiasm either. What is worth having is a boundary specific enough to follow and enforced well enough to evidence.
Where this has been done
The policy, the register and the enforcement, and the compliance framework the whole thing has to sit inside without contradicting it.
3
artefacts delivered: guidelines, usage register, enforced policy
AI usage policy, register and enforcement13
policies added across the IT, cyber and privacy layer
Compliance manual and coverage map
Start with the register
It is the quickest piece and it tells you whether the rest is urgent. If a client, an insurer or a licensee has already asked about your AI use, say which and roughly when the answer is due.
This assumes a Microsoft estate, because that is where the enforcement layer is. If your data sits elsewhere the approach still holds but the mechanism will not be Purview, and I will tell you that before you spend anything.