What AI Governance Actually Means When You Have Five Employees

A vendor questionnaire arrives from a customer bigger than you. Twelve questions in, there is a section about AI: which tools you use, what data goes into them, whether a human checks the output. The form did not come from the person who wants to hire you. It came from procurement, and procurement is comparing your answers against three other companies' answers.

That is how most small businesses meet AI governance. Not through a regulation, and not through an incident. Through a form, with a deadline, from a customer they want to keep.

Most writing on this topic is aimed at companies with a legal department and a risk committee. It talks about frameworks and oversight boards. If you have five employees, none of that applies to you, so it is easy to read it and conclude the whole subject belongs to someone else.

It doesn't. It is just much smaller than the word makes it sound.

Seven decisions, written down

At this scale, governance is a set of decisions you make once, record somewhere findable, revisit twice a year, and revisit sooner whenever the purpose, the vendor, the data source, or what the automation is allowed to change materially shifts.

Know what tools are in use. Not what you approved. What people are actually using. Ask everyone, including contractors, what AI tools they touch in a normal week. The list is usually longer than the owner expects, because free tiers spread quietly and nobody thinks to mention them.

While you are listing tools, note what each one is for and who it affects. A tool that drafts your newsletter and a tool that ranks job applicants are not the same kind of thing, and treating them the same is how small companies end up with a serious problem in a place they never thought to look.

Decide what data goes into which tool, and on what terms. Start with the categories that need a deliberate decision rather than a default: anything your contracts restrict, passwords and API keys, sensitive personal information, employee records, financials, and confidential client material.

Some of that can be processed safely under the right agreement and the right settings. The point is that it should be a decision you made, with the product, the plan, and the reason written next to it, instead of something that happened because a tool was convenient. Twenty minutes of this heads off a lot of that trouble.

Give every automation a named owner. A person, not a team. The owner knows what the workflow does, what it touches, and how to stop it. When that person leaves, ownership transfers on the way out, the same as a client relationship would.

This is also the decision people skip, and the reason is structural. When a task moves from a person to an automation, the checking that person was doing without being asked does not move with it. Nobody assigns it, because nobody noticed it was a job.

Sort outputs by what they can do, not where they go. The obvious line is internal versus client-facing, and it is the wrong one. Internal résumé screening, complaint categorization, and fraud flagging all stay inside your company and all land on real people.

The line that holds: anything that affects a person, moves money, changes a record, grants access, or creates a commitment gets a human check. Low-stakes drafting and sorting can run without one. Write down which bucket each workflow sits in.

Make the check real while you are at it. A reviewer who approves forty items in ten minutes is not reviewing, and people trust confident-looking output more than they should. Give whoever reviews the time, the criteria, and the standing to send something back.

Know how to turn it off. Every automation needs someone who can stop it quickly, ideally within the hour, with access of their own or a written emergency route to get it. Not a shared password. If the answer involves waiting for a contractor to reply, you do not have an off switch.

Decide what happens after you turn it off. Stopping the thing is step one. Then somebody has to work out what went out while it was wrong, fix the records, tell whoever was affected, and note what changed so it does not repeat. Deciding this on a normal Tuesday takes fifteen minutes. Deciding it during the incident takes a week and you will get parts of it wrong.

Keep a log. What ran, when, and what it produced. Many platforms can retain this depending on how they are configured, and almost nobody looks at it. The value shows up later, when a customer asks why they received something odd in July.

One caution on logging, since it cuts both ways. Execution logs often capture the full content that passed through, which means your monitoring can quietly become the largest pile of client data you hold. Log what you need to diagnose problems, not everything.

That is the foundation. Seven decisions, one page, an afternoon. Higher-consequence uses need more than this, and the rest of the series is about what more looks like.

One boundary worth stating plainly. This is a minimum, and it is not enough on its own if your automation touches hiring, credit, housing, insurance, health, education, biometrics, or anything with a legal effect on someone. Those carry specific obligations that a one-page list does not discharge. If you are in that territory, treat this as the operational layer underneath proper advice, not as a substitute for it.

This echoes the same themes that sit in frameworks like the NIST AI Risk Management Framework and its generative AI profile. The seven decisions themselves come from our own client work, not from those frameworks, scaled to a company that will never staff a risk function. If you want the full version, those are the documents.

The failure is often boring

When people imagine an AI problem, they picture a dramatic one. A chatbot says something offensive. A model invents a number that ends up in a proposal.

A common version is quieter. Someone builds a workflow that works well, then changes roles or leaves. The workflow keeps running. A form field changes upstream, or an email template gets edited, and the automation starts doing something slightly wrong. Because it still runs on schedule and still produces output that looks normal, nobody notices for months.

By the time it surfaces, the person who built it is gone and there is no record of what it was supposed to do. Now you are reverse engineering your own process from log files.

Named ownership and a kill switch are unglamorous, and they are exactly what prevents that. A five-person company has less slack for this kind of failure than a large one, not more. There is nobody sitting nearby whose job is to catch it.

Why this is arriving now

Enterprise customers are adding AI questions to vendor reviews, and those reviews are increasingly handled by procurement, not by the person who wants to hire you.

Regulation is part of the picture, though not in the way most people assume. The obligations generally follow what a system does and who it affects, not how many employees you have. A small company can be a provider or a deployer with real duties, and being small does not automatically exempt you. We covered how that works in What the EU AI Act Means If You're a Small Business Using AI.

The more immediate pressure is indirect. Your customers have obligations, and they meet them partly by asking you questions. Requirements travel down the supply chain whether or not they land on you directly.

None of that requires you to build a compliance function. It requires you to be able to answer plainly when asked.

Where to start

Spend one hour making the tool list. That alone tells you more about your exposure than any framework will, because it usually turns up two tools you did not know were in the building and one place where client data is going somewhere you would not have chosen.

Then make the data decision. Then assign owners to whatever automations already exist.

Three things, one afternoon. The version that takes six months and a consultant is the enterprise version, and most small businesses don't need it.

Part two is about the failure mode described above: how a workflow goes wrong quietly, and what changes before the output does.

Sources

1. Regulatory obligations following what a system does and who it affects, rather than company size: covered in our earlier piece on what the EU AI Act means if you're a small business using AI.
2. The frameworks these decisions echo: the NIST AI Risk Management Framework and its generative AI profile (NIST AI 600-1).
3. The seven decisions are drawn from our own client work rather than from any published framework, and the ordering reflects what tends to fail first at this scale.
4. The trend toward AI-specific questions in vendor risk reviews: ISACA, Six Steps for Third-Party AI Risk Management.

A note on images across this site. Illustrations and workflow diagrams are made with AI, from prompts we write and refine, and we edit most of them afterwards. Screenshots taken in n8n are not, since they show workflows we built in the tool.