Governance that someone will use.

What governance is actually for

Strip away the framework language and governance answers three questions: what are we using, what could go wrong, and who decides. Everything else is machinery for producing those answers repeatedly. A small organisation can answer all three on a few pages, and a few pages that get read beat a policy document that does not.

Start with an inventory, because you do not have one

Nearly every organisation underestimates its own AI usage, because the estimate counts procured systems and the reality includes everything staff adopted on their own. Before writing any policy, find out what is actually in use.

Four columns is enough: what the tool is, who uses it, what data goes into it, and what happens if the output is wrong. That last column is what turns a list into a risk register, and it is the one people skip.

You cannot govern what you have not found. Governance written before an inventory governs the tools you knew about, which are not the risky ones.

Tier by consequence, not by technology

The instinct is to classify by how advanced the system is. That produces heavy process around impressive-looking tools and none around a spreadsheet macro that decides something important. Classify by what happens when it is wrong.

This mirrors how risk-based AI regulation is structured — obligations scale with the consequence of the decision, with the heaviest requirements reserved for uses that affect people's rights or livelihoods. Tiering by consequence means that if formal obligations do reach you later, you are already sorted into the right buckets rather than starting over.

Four rules people will actually follow

A policy nobody remembers is decoration. Four rules, stated plainly, get followed:

• Say when it was AI. Anything going to a customer or into a decision record is labelled as AI-assisted.
• Don't paste what you wouldn't email. Client data, credentials and personal records do not go into unapproved tools.
• A person signs off anything that leaves. Review before it reaches a customer, a regulator or a public channel — and the reviewer is accountable for it.
• Log the high-tier ones. For anything in the top tier, keep what went in, what came out, and who approved it.

Notice what is absent: no approved-model list to maintain, no committee, no request form. Those are the parts that decay first in an organisation without someone whose job is to maintain them, and their decay is what discredits the rest.

Shadow usage is a supply problem

The reflex response to unapproved tool use is prohibition. It rarely works, because the behaviour has a cause: the sanctioned option is slower, worse, or does not exist. Prohibition without a supplied alternative moves the usage out of sight, which makes it more dangerous rather than less.

Providing a sanctioned path quickly is a data-protection measure, not a productivity perk. The organisations with the least shadow usage are generally the ones that shipped something usable early, not the ones with the strictest policy.

Two reviews, quarterly, an hour each

Governance decays without a rhythm, and the rhythm can be very light. Once a quarter: refresh the inventory — what appeared, what stopped being used — and re-check the tiering of anything whose scope changed, because systems that start as drafting assistants quietly become decision-makers.

One more thing worth doing at the same interval and almost nobody does: re-test your high-tier systems after any model change. Behaviour shifts on upgrade, and a system validated against the previous version has not been validated. That single check catches more real problems than any amount of policy writing.