A Practical AI Governance Framework For Small Business Workflows

TL;DR

If your AI governance project starts by writing a policy before you know where AI is already being used, it starts in the wrong place. You can't govern what you can't see, and a policy written before you've looked is a set of rules for an imaginary company — the real one is whatever your team is pasting into ChatGPT this week, which the policy author has never seen. The first artifact isn't the policy. It's an inventory: where AI already touches real work, fed with what, owned by whom. The policy still matters — it just needs the inventory to have something real to govern. The actual risk for a small company isn't a dramatic data leak. It's that a real process has quietly come to depend on one person's personal AI habit that nobody decided on, owns, or could rebuild if they left. Find it first. Then the rules are short and obvious.

The pitch you'll hear, and why a policy is the wrong first move

Search "AI governance" and you'll be sold a policy: a template, an acceptable-use document, principles, maybe a committee. Adopt it and you can say you have AI governance. That's the trap. A policy written before you know how AI is actually being used governs a company that doesn't exist. It creates false confidence — "we have an AI policy" reads as the risk being handled, while the AI use that's actually load-bearing stays exactly as invisible as it was. A policy is an answer. The inventory is how you get the question it's supposed to answer.

You can't govern what you can't see

The real risk in a small company isn't the employee being reckless. It's the employee being helpful. Someone found a chat tool drafts the proposal section faster, so now it does — every time, unofficially. No one decided this. No one owns it. It isn't written down anywhere. It is now part of how proposals get made, and you don't know it exists.

This isn't a fringe case; it's the normal one. Microsoft's Work Trend Index found that 78% of people using AI at work bring their own tools rather than wait for the company to provide them — and at small and medium companies it's 80%. More than half won't admit using it for their most important work, because they worry it makes them look replaceable. So the default state of a small company is not "we haven't adopted AI yet." It is: AI is already in your workflows, you didn't put it there, four out of five of your people did, and the ones relying on it most are the least likely to tell you. Governance isn't the act of writing rules. It's the act of making that visible before it breaks.

The leaving test (run it this week)

Skip the framework for a minute. One test tells you whether you have a problem:

Pick the person whose work leans on AI the most. Pretend they quit on Friday. Without asking them, can you list every place AI is now load-bearing in their work, what each use is fed, and who would own it on Monday?

If you can't — and almost nobody can — you don't have a governance gap, you have an invisibility gap. A policy does not close it. Only an inventory does. Notice the test has nothing to do with rules. It's about whether you can even see the thing you claim to govern.

The one part that isn't one of seven

A workable system has seven parts: approved tools, banned data, the inventory, review rules, customer-action rules, an owner of record, exception reporting. Treating them as seven equal parts is the mistake.

Six of them are operations performed on the seventh. You can't sensibly say which tools are approved, which data is banned, what needs review, or who owns it until you know where AI is actually used. The inventory isn't part three of seven. It's the thing the other six act on. Build it first, or the other six are rules about a company you're imagining.

The inventory, filled in

This is the first artifact and the spine of everything else. One row per place AI touches real work:

Sales follow-up drafting — tool: ChatGPT (personal, until now). Fed: CRM notes. Owner: nobody — this is the finding. Tier: Medium. Now assigned: Head of Sales.
Support reply drafting — tool: Claude. Fed: help-center articles. Owner: Support Lead. Tier: Medium. Review: agent approves before send.
Weekly report summary — tool: Copilot. Fed: dashboards. Owner: Ops Manager. Tier: Low.
Pricing or discount wording — tool: none approved. Owner: Finance. Tier: High. Rule: off-limits to AI.

The first time a small company fills this in, the column that does the work is "Owner," because the honest answer for the riskiest rows is usually "nobody, until just now." That blank is the entire point of the exercise.

The approved tool register, filled in

One short table the owner of record keeps. A workable starting version:

ChatGPT (business/Team plan): approved for drafting, summarizing, brainstorming on non-sensitive content. Not for customer financial data, contracts, or identifiers.
Claude (business plan): approved for drafting, analysis, document review on internal non-sensitive content. Same data limits.
Copilot in Microsoft 365: approved for documents and email drafting inside tenant data only.
Personal or free AI accounts: not approved for any company data.
Anything not on this list: not approved until the owner of record reviews it.

Each row records tool, who approved it, approved uses, banned uses. That's the whole register.

Banned data, in specifics

Write it as specifics, not categories, so a non-technical employee can't misread it. Banned from any tool not explicitly approved for it:

Customer financial information: card numbers, bank details, payment records.
Signed contracts, MSAs, NDAs, unredacted legal documents.
Personal identifiers: government IDs, dates of birth, home addresses, health information.
Credentials: passwords, API keys, access tokens.
Unreleased financials, M&A, or board material.
Any third-party data you're contractually required to keep confidential.

Risk tiers, with the rule built in

Low — internal summary, draft, categorization. Rule: owner reviews before the output is used. Example: summarizing internal meeting notes.
Medium — CRM note, customer draft, ticket routing. Rule: named owner plus an exception log. Example: an AI-drafted follow-up a rep edits before sending.
High — pricing, legal, refund, account change, customer commitment. Rule: a person approves before the action. Example: an AI-suggested refund amount Finance must sign off.
Not approved — sensitive data in unapproved tools, or AI making public commitments on its own. Rule: do not use. Example: pasting a signed contract into a personal AI account.

The tier sets the rule. This is what the policy should say — short, specific, and tied to real workflows — instead of abstract principles written before you knew what you had.

The exception log, filled in

When a rule is hit, bent, or unclear, one line gets recorded so patterns show:

Date / who: 2026-05-09, Support Lead.
Workflow: support reply drafting.
What happened: AI drafted a refund promise outside policy; agent caught it before send.
Action taken: reply corrected; stop rule added to the support draft workflow.
Follow-up owner: Support Lead.

A handful of these usually points straight at the one workflow that needs a tighter rule or a cleanup. That's what the log is for.

The first 30 days

Ordered to match the point: you look before you legislate.

Week 1 — see it. Build the inventory. Ask every team where they already use AI for real work. Expect surprises; the surprises are the deliverable.
Week 2 — name it. Give each row an owner and a tier. High-tier rows owned by nobody are your real risk; fix those first.
Week 3 — bound it. Publish the approved tool register and the banned-data specifics, shaped by what you actually found in Week 1.
Week 4 — keep it honest. Stand up the exception log and a standing meeting question: "any new AI use this week?" Governance you don't re-ask goes stale inside a month.

What not to do

Don't start with a policy or a committee. You're answering a question you haven't asked yet.
Don't write tool and data rules before you've seen where AI is actually used.
Don't treat "we adopted an AI policy" as proof the risk is handled. It usually means the opposite.
Don't leave the riskiest workflows owned by "nobody."
Don't run the inventory once. Unseen use grows back.

Related workflow pages

Related field reports

Where to go next

Run the leaving test this week — it takes an hour and tells you whether you have an invisibility problem before you spend a day on rules. The AI readiness assessment helps you build the first inventory, and the AI consulting services and AI implementation services pages cover the workflow-first system that follows. To pressure-test your inventory and tiers against a real outside read, request an implementation review.

FAQ

We already have an AI policy. Aren't we covered?

Probably not in the way you think. The policy isn't wrong, it's just untested against reality. Run the leaving test against your most AI-heavy person; if you can't reconstruct their AI use without asking them, the policy is governing a guess, and you won't know where it's silent until something breaks there.

Isn't this just shadow IT with a new name?

Same shape, faster spread. Shadow IT moved at the speed of budgets and software installs. An AI habit becomes load-bearing in days, through tools that need no procurement and leave no install trail, which is why the old "wait for IT to notice" reflex fails here.

How small is too small to bother?

If more than one person uses AI for work, you already have invisible use. What scales down is the committee and the policy program, not the inventory. The inventory is the part a five-person company needs most, because there's no IT function noticing for them.

Who should be the owner of record?

Someone who can see across teams and is allowed to say no — usually an operations or finance lead. Not whoever is most enthusiastic about AI; enthusiasm is what you're trying to make visible, not what you put in charge of bounding it.

What pushes a use from "personal" to "needs a rule"?

The moment its output reaches a customer, changes a record, moves money, or another person's work now depends on it. Until then it's personal use; after that it's an unowned workflow, and the inventory is where you catch the crossover.