Minimum Viable AI Governance: The Complete Series

This page holds the full text of every part published so far. It will be updated with Part 4 on September 15, 2026.

Part 1: 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 starts with a human check unless you have deliberately decided otherwise. 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, 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 is easy to work out on a normal Tuesday. Deciding it during the incident takes longer, when you are least equipped to make the decision well.

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.

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

Part 2: Your Automation Is Wrong and You Won't Notice for Months

---

Checking whether output looks normal will not catch a drifting automation. Looking normal is the problem.

By drift I mean something broader than the statistical kind data scientists usually mean: any change, in the data feeding a workflow, in the tool running it, or in the world around it, that leaves the automation working against assumptions that no longer hold.

Some failures announce themselves: an error fires, a report someone was waiting for does not arrive, a customer complains. Those are unpleasant, but they are diagnosable, because something pointed at the problem.

The harder one is where everything still runs on schedule. The output still looks like it always did: same formatting, same tone, about the same volume. One field is now pulling from the wrong place, or a summary is quietly dropping a category of item it used to include. Anyone skimming sees what they expect, because they are checking whether it is output, not whether it is correct.

Reading output still matters: it is the only way to catch a wrong number, a confident invention, or a recommendation that should never have gone out. But it has to be reading against a standard, on a schedule, not a glance on the way past. Both halves of this article are about making that possible.

Ways things drift

The causes are different and the fixes are different, so it helps to keep them apart.

Something upstream changed. This is the common one. A form field gets renamed. A vendor updates their invoice layout. Someone adds a line to the email signature. A client starts naming files differently. Your CRM gains a required field and the old export shifts by one column.

None of these look like AI problems. They are ordinary business changes. The automation keeps running because nothing errored, it just now has a different thing in its hands.

The tool moved without telling you. The vendor updates the model behind the product you are using, and nobody announces it in a way that reaches you. Outputs get longer, or more cautious, or start formatting differently. Your prompt did not change, but what it produces did.

Sometimes nothing technical changes, and the automation just falls behind. This is the invisible one. Your email classifier learned what your inbound mail looked like in March. You launch a new service, or a competitor's product starts generating a new kind of question, and now a category exists that the workflow was never taught. It handles it anyway, badly, with complete confidence and no error.

None of this shows up as a break in your pipeline or a change in the tool. The job itself just quietly became a different job.

You cannot fully prevent any of the three. What you can control is how well your workflow detects and handles them. Some products let you pin a version or choose when upgrades land, which helps with the second. The third is the one nobody thinks to look for, and it is the reason periodic sampling exists.

Watch the things that move first

Some of the most useful signals sit in the shape of the work around the output, not in the output itself.

Input shape. New file types, new categories, longer messages, a different language, or a rising share of items landing in "other" show trouble before the output does. This is often one of the earliest warnings available, since it shows up before the automation has had a chance to get anything wrong.

Volume. An automation that processed 40 items a week for three months and now processes 12 is telling you something, even if all 12 are perfect. Something upstream stopped reaching it. A jump matters too, and can mean it started catching things it should be ignoring.

How often a human steps in. If your team used to fix one output in twenty and now fixes one in five, something changed before anyone thought to mention it. People absorb small corrections without reporting them. They will not tell you the tool got worse, they will quietly do more cleanup. Track the correction rate and you find out before they say anything.

A falling correction rate is not automatically good news either. People sometimes stop correcting a workflow they have quietly stopped trusting, and start working around it instead, which makes the correction rate look better exactly when the underlying problem is worse.

Run time. A job that took ninety seconds and now takes six minutes changed, even if the result is fine. It may be retrying something, though payload growth, vendor latency, throttling, or an API change can cause the same slowdown.

Absence. A workflow that produces nothing generates no error and no output to inspect. If the Tuesday report simply stops arriving, the gap can run for weeks before anyone asks where it went. Watching for expected output that did not appear catches a whole class of silent failure, and part three is largely about this.

Output shape. Not content, shape. Average length, number of line items, how many fields come back populated. If a summary that ran to four paragraphs now runs to one, look at it.

None of this matters unless a signal moving translates into a decision. Decide in advance what earns what response: a small shift in output length might be worth a note, a correction rate climbing from 5 percent to 15 percent might mean pulling a larger sample, and a serious error touching money, a customer, or a person's record should stop the workflow until someone understands what happened.

Many of these signals can be tracked cheaply and automatically. They will not catch a plausible wrong answer. That is what sampling is for.

Write down what correct looks like

Sampling only works if you have something to compare against. If nobody recorded the standard when the workflow was built, you are comparing today's output to your memory of last spring, and memory drifts faster than the automation does.

So capture it at build time, and capture pairs, not outputs alone. For each example: the input that went in, the output that came back, and a short note on what makes that output correct. An output with no input attached tells you very little six months later.

Record the version details alongside it. The prompt as it was written, the tool and model if the vendor exposes it, and which data sources it was reading. When something changes later, this is what lets you tell whether the workflow changed or the world did.

Include the ugly cases deliberately. Random examples give you the normal path, and the normal path is not where things break. Add the malformed input, the duplicate, the request in the wrong language, the edge case you argued about while building it. Those are the ones worth checking.

When the underlying business rule changes and yesterday's correct answer is no longer today's, do not overwrite the reference set silently. Keep the old version and create a new one. That gives you an audit trail, and it means "correct" always means correct as of a known date.

If you have automations running now with no such record, build one from current output while somebody still remembers what the process was supposed to do. Less clean than capturing it at build time, much better than nothing.

The monthly sample

Ten items on a scheduled day, chosen at random rather than picked. Random matters because picking invites you toward the familiar and the convenient, and neither is representative.

Ten is a habit-building default for low-consequence workflows, not a fixed rule. Sample size and frequency should rise with volume, how often the workflow changes, and what a mistake would actually cost. If a workflow touches money, customer records, or people, sample more, and deliberately include the rare cases instead of waiting for them to show up in a random draw.

Check against your reference pairs. You are looking for the small stuff: a field right in nine and empty in one, a date format that shifted, a category that used to appear and does not.

A single minor oddity may be noise, and the same oddity showing up twice is a pattern worth tracking. A severe error is neither of those: log it as an incident the first time it happens, without waiting for a repeat to confirm it.

Write down what you found even when you found nothing. A note saying "sampled 10, no issues, September" is what lets you narrow the window later when something does turn up.

Change logs, and sometimes more

Most workflows do not need an approval step so much as someone willing to write the date down when something changes.

When a form changes, a template gets updated, a vendor changes their file format, or you edit a prompt, note it in one place with the date. That takes ten seconds and it can turn hours of investigation into minutes, because you can line up when the output went odd against what changed that week.

Most small businesses skip this and pay for it later, in hours, at the worst possible time.

The exception is the workflow that moves money, changes records, affects people, or sends things to customers. There, test the change before it goes live and have someone other than the person making it agree it should. That is a small extra control on the changes where being wrong is expensive.

Where to start

Pick the automation that touches customers or money. That is where drift costs you something real rather than costing you cleanup time.

For that one workflow, start this week: save ten known-good input and output pairs as your reference, write down what its normal weekly volume looks like, and put a note on the calendar for the same day each month to pull a sample.

Part three is about making those signals report themselves, so you are not the one checking.

Part 3: The Automation Stopped and Nothing Told Us

---

A workflow we had built stopped running for five days.

It had error notifications. They worked. They just never fired, because nothing errored. The workflow was not failing, it was not running at all, and a thing that is not running produces no errors to report.

Orders stopped flowing into the tracking database. Nothing else looked wrong. No alert, no failed run, no strange output to notice, because there was no output at all. The client worked it out before we did, which is the part I think about.

We added a heartbeat check afterward. Something that expects the workflow to report in, and raises a flag when it doesn't. It is a small piece of work and it should have been there from the start.

I open with it because it is the exact gap most monitoring has. Error alerting answers "did something go wrong." It does not answer "did anything happen at all," and those are different questions.

Nobody reads the dashboard

The other common approach fails differently. Someone builds a dashboard. It is a good dashboard. It gets opened maybe six times, then never again.

The reason is not laziness. A five-person business has nobody whose job is to look at things that are probably fine. Checking a normal dashboard produces nothing, and work that produces nothing gets dropped the first week things get busy. That is the correct instinct. The monitoring design is what is wrong.

So invert it. Nothing demands your attention while things are normal, and something reaches you the moment they are not.

Exception reporting

No urgent message arrives when things are normal. The owner of a workflow hears from it only when a threshold is crossed. Volume moved outside its usual range. The correction rate doubled. A run took four times as long as it should. Expected output did not appear.

That last one is the lesson from the opening, and it needs to be built deliberately. A scheduled check that asks whether the thing that should have run did run catches a category of failure that error alerts structurally cannot.

Silence is only information if something is listening

"No alerts this week" tells you nothing on its own, because the monitoring can fail the same way the workflow did. A dead alerting path is silent, and a healthy system is silent, and from the outside they look identical.

So the monitor needs its own heartbeat. Something that reports in on a schedule and says the checks ran, whatever the result. A weekly digest saying "all expected checks ran, nothing outside range" is enough. It is the only message you want arriving on a normal week, and its absence is itself a signal.

If a workflow matters enough, put the check somewhere other than the system it is checking. A heartbeat that lives inside the thing it monitors goes down with it.

Set thresholds from real data, tuned to consequence

Set something provisional on day one, based on what you expect the volume to be and what it would cost you to be wrong. Rough numbers are fine. What is not fine is a workflow touching payments or customer records running unwatched for its first month while you gather data on it.

Then tune. After a full business cycle, look at the actual range. If weekly volume sat between 30 and 50, move the alert outside that band with room to spare. You are not trying to catch every fluctuation. You are trying to catch the week it goes to 6.

How fast you need to know is a separate question, and it follows consequence rather than company size. A workflow producing internal summaries can be checked daily. A workflow touching payments, access permissions, customer messages, or bookings needs a shorter loop, because those are hard to walk back and the damage compounds while you are unaware. Ask how long the failure can run before it becomes expensive, then check more often than that.

Revisit the numbers twice a year. Normal moves, and a workflow tuned to a business half your current size starts crying wolf as you grow.

Rare, or it stops working

An alert that fires weekly becomes a filter rule within a month. Then it goes to a folder nobody opens, and now you are worse off than having no alerts, because everyone believes something is watching.

For low-consequence workflows, wider thresholds are usually the better tradeoff. Reserve the interrupt for conditions that actually justify attention, and let the monthly sample catch the smaller deviations. Nothing catches anything through a channel people have stopped reading.

For the workflows that move money or touch customers, tighten the thresholds and accept the higher alert volume that comes with them. Those are worth being interrupted for. But if the volume climbs past what the owner can actually act on, that is itself a sign the thresholds need tuning, not just a cost of doing business.

One name on it

Alerts go to a person, not a shared inbox and not a channel. Shared destinations produce the situation where four people see the message and each assumes one of the others is handling it.

Add one rule: if an alert is not acknowledged within the window you set for that workflow, it goes to a second person. That covers vacation, illness, and the ordinary case of someone seeing it on their phone at 6pm and forgetting by morning.

Acknowledgement only proves someone saw it, not that the problem is fixed. An alert can sit acknowledged and unresolved for days. For higher-consequence workflows, also decide how long an alert can stay unresolved before it escalates again.

If your company is small enough that both names are you, fine. Write it down anyway. The point is that the answer exists before you need it.

Building it once in n8n

Do not build error handling into each workflow separately. Build one workflow that receives failures, formats them, and routes them to the right person.

The mechanics are worth getting right, because this trips people up. n8n has an Error Trigger node for exactly this, but other workflows do not call it. You select the error workflow in each monitored workflow's settings, one by one. Miss that step and the workflow is unmonitored while looking monitored, which is worse than knowing it is unmonitored.

Two things about it that surprise people. The Error Trigger fires on automatic executions, not on manual ones, so testing by clicking execute will show you nothing and you may conclude it is broken. And it only fires on failures, which brings you back to the opening: a workflow that stops running never errors, so this alone would not have caught the five day outage.

That is what the second workflow is for. A scheduled job that checks whether the others actually ran and produced output, compares volume and duration against your stored numbers, and sends anything that looks off down the same path. This is the piece that catches absence.

One practical detail. n8n prunes finished execution data by default after 336 hours, which is 14 days. Anything reading run history to build a picture of the last quarter will find two weeks of it. So write the numbers out as you go, appending run counts and durations to a sheet or table on a schedule, instead of reconstructing them later from history that is no longer there.

Two shared workflows give you the foundation: one routing errors, one checking that things ran. Change how alerts are formatted or where they go and you change it once. Add your twelfth automation and most of the monitoring is a settings entry rather than a build.

They do not cover everything. Each automation still has to emit the signals worth watching, and the ones that move money or touch customers usually need a quality check of their own on top. Shared plumbing, specific checks.

The quarterly page

Alerts catch the sudden stuff. Slow drift needs something periodic, and one page per automation per quarter is enough.

What it ran and how much. What changed, from your change log. How often a human corrected the output. What the monthly samples found. Any alerts or incidents during the quarter, and whether they were closed. Anything still open.

Keep it to a page so it stays easy to maintain. Let it grow past a page and it becomes a document nobody writes.

That page has a second use. When a larger customer asks how you control automated processes, this is the answer: a record showing you have been watching the whole time. That is much stronger evidence than a policy written for the questionnaire, and that is what part four is about.

What you probably don't need, and what you might

You do not need an enterprise evaluation platform, a model observability suite, or anything with a leaderboard. Those exist for teams building models.

You may still need a small test set of your own. If a workflow classifies, summarizes, or recommends, keep a handful of cases where you know the right answer, including the ones that have burned you before, and run them after any change to the prompt, the tool, or the data source. Twenty examples in a spreadsheet counts. It is the difference between hoping a change was safe and having some evidence that it was.

Coverage beats sophistication. Every workflow having a crude threshold and a named owner beats one workflow with beautiful instrumentation while eleven run unwatched.

Where to start

Get every workflow you already have reporting through one path this month, even if the only thing you check at first is whether it ran. Then add the weekly digest so you know the checking itself is alive.

If you build the error workflow and the heartbeat checker as a reusable pair, future automations can plug into the same monitoring path instead of each getting their own. Thresholds and owners still need attention as things change.

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.