Governance before use cases: the sequencing most firms get backwards

Most AI programmes start in the same place: someone buys a licence, finds an exciting use case, and gets a small team to try it. Governance — the policy, the data rules, the verification step — is treated as something to add once the use case proves itself.

That sequencing is backwards, and it is the most common reason AI adoption stalls. By the time the policy arrives, dozens of small decisions have already been made without one. Each of them sets a precedent nobody chose.

The failure mode

When governance comes last, the same problems appear in almost every firm:

• Staff are using tools nobody vetted, and no one can produce a complete list of them.
• Client or personal data has already passed through tools with unclear data handling.
• AI-assisted output has reached a client or a filing without a named person verifying it.
• Every new project re-litigates the same questions: what are we allowed to use, and what do we have to disclose?

None of these are technology problems. They are sequencing problems, and they are much cheaper to prevent than to unwind.

Why the order matters

Governance is not the brake on adoption; it is what makes adoption repeatable. A written policy does three things at once: it sets the boundary within which people can move quickly, it removes the need to ask permission for the same thing twice, and it gives you evidence that you acted with reasonable care if something goes wrong.

Put differently: you do not get to choose whether a policy exists. You get to choose whether it is written down, or whether it lives in a dozen inconsistent habits.

A sequence that works

The order below is deliberately unglamorous. It front-loads the decisions that are expensive to change later.

1. Inventory and classify. List every AI tool and use case, who owns it, and what data it touches. Distinguish tools you use (deployer) from anything you put on the market (provider), and flag anything close to a high-risk area.
2. Write the policy. One page is enough to start: permitted and prohibited tools, data-handling rules, disclosure expectations, and the requirement for human review before anything client-facing.
3. Handle data and vendors. Decide which data may enter which tool, and ask vendors the questions that matter: where data is processed, what is retained, what is logged, and what happens on an incident.
4. Define verification. Decide what “verified” means for your firm, who is accountable, and what evidence you keep. A checklist is more useful than a principle here.
5. Then scale use cases. With the boundaries in place, a new use case is a decision about value, not a debate about safety.

What good looks like

• A one-page AI policy that staff have actually read.
• A named owner for AI use and a current list of approved tools.
• Clear data zones: what may and may not go into an external model.
• A verification step with a named human and a record.
• An incident path: who is told, what is contained, what is documented.

A 30-day sprint

If you are starting from nothing, this is a realistic first month:

• Week 1: inventory tools and use cases; identify data flows.
• Week 2: adopt a one-page policy; name an owner.
• Week 3: vendor and data-handling review; approve or remove tools.
• Week 4: define the verification workflow; brief the team; run one pilot under the new rules.

That is not a bureaucracy. It is the minimum needed to make the second and third use cases faster than the first.

Where to start

Our guide to AI governance for small business covers policy, data and risk in more depth. The AI policy template gives you a ready-to-adapt starting point, and the human-verification checklist turns the review step into something you can actually run. For data handling specifically, see AI and confidential client data.

If you would like a second pair of eyes on the sequence, book a short call and we will map it to your firm.

This article is general information, not legal advice.