Minimum Viable AI Governance: The Complete Series

This page holds the full text of all four published parts of the series.

This series covers the governance work a small business needs once AI moves into daily operations. It skips the version built for a legal team and a risk committee, and stays with the layer underneath: what to decide, what to watch, and what to say when a customer asks.

The four parts build on each other. Part one covers the decisions worth making once, before anything runs. From there it gets into how automations drift quietly with no error to flag it, followed by the monitoring that catches both drift and outright silence. The series ends with turning all of that into answers a customer's procurement team will accept.

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.

Part 4: The AI Questions on Vendor Forms, and How to Answer Them

---

Vendor questionnaires have grown an AI section. If you sell to companies bigger than you, you are increasingly likely to meet one, and it arrives from procurement, not from the person who wants to hire you.

That detail matters. The person who wants to hire you will forgive a rough answer. Procurement or risk may be comparing your answers against other suppliers, and an unexplained blank field creates an easy reason to ask more questions.

The forms themselves vary. Some are three questions bolted onto an existing security review, some run to several pages, and a few are built from published control frameworks. The themes recur even when the wording doesn't, and once you know what a good answer looks like you also know what to ask your own vendors. Many small businesses eventually find themselves on both sides of this, so each question below gets two readings.

A strong answer usually has four parts: the control, who owns it, what proves it is actually happening, and when it was last checked. "We use MFA" is a start. "We use MFA on all workflow admin accounts" is better. "We use MFA on all workflow admin accounts, access is reviewed quarterly, and the owner can produce the current access list" sounds like governance instead of a policy statement. Keep that shape in mind through the questions below.

Not every workflow deserves the same scrutiny, either. The more sensitive the data, the more the automation can reach, the bigger the consequence of a bad output, and the less a person checks it before it acts, the harder these questions should hit. A newsletter-sorting automation and one that moves money are not the same conversation, even if they run on the same platform.

What AI tools do you use, and where does our data go?

What they want to know: whether their information ends up somewhere they have not approved.

Answering it: name the tools and the data each one touches. "We use two AI tools. One drafts internal summaries from meeting notes and does not receive client data. The other categorizes inbound email, which includes sender names and message content."

Do not answer with a category like "we use AI for productivity." That reads as someone who has not looked. This is where the tool inventory from part one pays for itself, because you either have the list or you spend a day building it under deadline.

Asking it: watch for a vendor who names a capability instead of a product. Some architectures legitimately route across several providers, and some details sit behind an NDA. But if they cannot identify the products and providers in the path even confidentially, treat that as a gap in their own knowledge, not as confidentiality.

Where matters too, not just which tools. Ask which country or region actually processes the data, whether a subprocessor accesses it from somewhere else, and whether support staff anywhere in that chain can see it. "Where does our data go" has a literal answer as well as a product-list answer, and buyers increasingly want both.

Data minimization belongs in this question too. Ask whether every field being sent is actually needed, because the safest customer data to hand an AI service is the data the workflow never needed in the first place.

Do humans review AI output before it reaches us?

What they want to know: whether a model can send them something nobody looked at.

Answering it: be specific about which outputs are reviewed. A blanket claim that everything gets checked invites the follow-up question of who checks it, against what, and what record survives, so only make it if you can answer that. A low-volume supplier genuinely can.

Answer on consequence rather than destination. "Anything that affects a person, moves money, changes a record, or commits us to something is reviewed before it goes out. Low-stakes drafting and sorting runs without per-item review." That is a rule someone can picture you following.

Asking it: if the answer is that everything gets reviewed, ask who does it and how long it takes. Universal review is often aspirational, and a reviewer approving forty items in ten minutes is a formality. The gap between the policy and the practice is what you are buying.

Is our data used to train models?

What they want to know: whether their information is being used beyond the service they hired you to provide, including to train or improve models.

Answering it: go read your actual agreements before answering, because this depends on the specific product, the plan you are on, your settings, and sometimes your region. Do not infer it from the vendor's name or from the word "business" appearing on a pricing page. Terms differ between a company's consumer product and its business product, and between plans within each.

One thing worth stating plainly, because buyers increasingly ask it as a separate question: not used for training does not mean not retained, not logged, not reviewed by humans, and not passed to subprocessors. Those are four different commitments and a vendor can make one without making the others.

If a free-tier product has been touching client data, deal with it properly instead of quietly. Check what the terms actually allowed, fix the configuration, and answer honestly about both current and past use if the question asks. Cleaning something up the week before a form arrives and then answering as though it was always that way is the kind of thing that surfaces later, at a worse moment.

Asking it: ask which product and plan, not what the policy page says. People quote the enterprise terms while using the free product.

Who owns the automated processes that touch our account?

What they want to know: whether there is a person, or whether the thing just runs.

When a task moves from a person to an automation, the checking that person was doing informally does not transfer with it. Somebody has to be assigned it, and that assignment is frequently where the gap shows up.

Answering it: internally, put a name on it, not just a role, since a role can sit unfilled for months without anyone noticing. Externally, lead with the accountable role and hand over the named owner when asked, since people change jobs and the role is what should stay durable in a contract. "Each automation has a named owner, reporting into [role], responsible for its output and for stopping it if needed."

Asking it: if the answer is a team, ask for a person. A team name does not tell you who is accountable when something goes wrong.

How do you know when an automated process fails or drifts?

What they want to know: whether you would catch a problem before they did.

Answering it: describe the mechanism, not the intention. "We monitor run volume, failure rates, and whether scheduled jobs produced output at all. Thresholds alert the named owner, and a weekly digest confirms the checks themselves ran. We sample output monthly against a reference set." That describes something that exists. "We monitor our automations closely" does not.

Asking it: ask how they found out about their last automation problem. If the answer is that a customer told them, you have learned what their monitoring is worth.

What will you tell us if something changes?

What they want to know: whether an accurate answer today stays accurate.

A vendor can answer every question above correctly in June and be wrong by September without anyone lying. The model changes. The provider changes. A new subprocessor gets added. The workflow picks up a permission it didn't have. The retention setting changes. None of that needs a new contract to happen.

Answering it: name the specific list rather than promising to "keep them posted," and separate what you control from what you are told. Commit to flagging material changes you make yourself, such as a new permission on the workflow or a different retention setting, and material provider or subprocessor changes you are notified of, such as a new subprocessor or a model update your vendor announces. "We'll tell you before we add a subprocessor or change what this workflow can touch, and we'll pass along any material change our provider tells us about" is a commitment you can keep. "We'll keep you posted" is not.

Asking it: ask what counts as a material change and how fast you would hear about it. If they cannot name the list, they have not thought about this either, and you are counting on them noticing on your own behalf.

Can you turn it off?

What they want to know: whether there is a stop, and who can reach it.

Answering it: state the time and who has the access, whether that is their own or a documented emergency route. A stop that no one can reach in time is not really a stop.

Asking it: ask for a shutdown commitment sized to what the workflow can actually do and how fast the damage piles up, the same cadence-follows-consequence logic from part three. A weekly reporting job does not need weekend coverage. A workflow where harm can compound quickly may need weekend coverage, and a kill switch that only works during office hours is not enough for a process that keeps running outside them.

What happens when something goes wrong?

What they want to know: whether stopping the automation is the end of it, or the start of a response.

Turning something off answers containment. It does not answer what already went out while it was wrong, who fixes the records, or who tells the customer. Too many answers stop at the switch.

Answering it: say what counts as an incident for this workflow, who decides, how fast you would notify, and what information comes with that notice. "A named owner decides within a defined response window whether an incident has occurred, and we notify within the agreed period with what happened, what it touched, and what we've done about it" is a plan. That window should scale with what the workflow can do: a process that moves money or touches customer records needs a shorter one than a newsletter job. "We'll let you know if something happens" is not a plan at all.

Asking it: ask the same four questions of your vendor: what counts as an incident, who decides, how fast you hear, and what you get told. If a vendor has a kill switch but no answer to any of that, you have found the gap.

How is the workflow protected from misuse?

What they want to know: whether someone unauthorized, or something unexpected arriving in the input, could get at their data or make the automation do something it should not.

This is the question the rest of the form implies and rarely asks directly, and it is the one most small suppliers are least ready for. It is also the one that matters most for the automations that are worth building. A workflow that reads email, opens attachments, or pulls from web pages is taking instructions from outside your company all day. Text inside a document or a message can be written to steer a model, a pattern known as indirect prompt injection, and if that model can send, approve, or change something downstream, the content is no longer just data being processed.

Answering it: describe controls that exist, not intentions. Individual logins with multifactor authentication, so access can be traced and removed. Permissions scoped to what each automation needs rather than to whatever was convenient. API keys stored in the platform's credential system and not pasted into a prompt or a workflow node. A defined list of what the automation is allowed to change, with everything else out of reach. And a check on the output before another system acts on it, so a malformed or manipulated result stops there. In practice that means things like schema validation, an allow-list of permitted actions, limits on the parameters a workflow can pass, or a human approval step before anything high-impact goes through.

Say plainly which of these you have. This is a good place to be honest about a gap and name the fix, because it is the section where overclaiming is most likely to be tested.

Asking it: find out what the automation can actually do, not just what it reads. Can it send email, change records, approve anything, move money, delete anything. Then ask what stops it, and where a person has to say yes. The answer to what a workflow can reach tells you more about your exposure than any policy document will.

Who else touches our data?

What they want to know: the chain behind you. Their review does not stop at you if you are passing data to three other services.

Answering it: list everything in the path, including the automation platform itself. An n8n instance, its host, and a model provider are all part of the answer.

Asking it: ask for the list, not a yes or no. This is frequently where people answering the form have not looked past their own product.

How long do you keep it, and what happens when we leave?

What they want to know: whether their data sits in your systems indefinitely.

Answering it: know your retention settings before you answer. Automation platforms retain execution data, and execution data often contains the full content that ran through it. "We delete on request" is not true if your workflow logs hold six months of message bodies.

Worth fixing rather than disclosing: log what you need to diagnose problems, not every field of every record. Monitoring that quietly becomes your largest store of client data creates the exposure the monitoring was supposed to reduce.

Asking it: ask about logs and backups specifically. People answer about their database and forget the pipeline.

Say no clearly when the answer is no

The instinct on these forms is to make everything sound handled. Resist it.

A clear "we do not do this today" is survivable and often fine, particularly for a small supplier where nobody expects a compliance function. An overclaim that gets tested during an incident is not survivable, because now the problem is your answer, not the gap.

If a question exposes something you should fix, say what you do now and what you are changing. Be careful with dates, though. A commitment written on a questionnaire can end up referenced in a contract, so only put one down if you own it and intend to hit it.

The thing that makes this easy

Every question above is straightforward to answer when the record already exists, and surprisingly painful when it does not.

That record is what this series describes. The tool list, the ownership decisions, and the incident plan from part one. The reference pairs and change log from part two. The alerting, the heartbeat, and the quarterly page from part three. None of it was built for a questionnaire, which is exactly why it answers one well.

If you are looking at a form now and cannot answer half of it, start with the inventory and the ownership question. Those two give you the foundation for much of what gets asked.

We build automations for small businesses, and we set this up as part of the build instead of as a separate exercise. If you have workflows running today and cannot say who owns them or how you would know if they stopped, that is the place to start.

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.