“A person checks everything” is the usual answer when someone asks how an AI document workflow stays safe. It sounds responsible. In practice it often means one tired reviewer reading a finished draft at the end of the day, with no way to see where each sentence came from. That person is checking the writing, not the work.
Review works better when you decide in advance where it happens, what the reviewer looks at and what they’re allowed to change. This article is about placing those checkpoints in work like supplier comparisons, quote summaries, reports and replies drafted from your own documents.
What a reviewer can actually catch
A language model can produce a fluent sentence that no source supports. It can copy the right number into the wrong row, drop the one condition that mattered or fill a gap with a reasonable-sounding guess. None of that is visible in a polished draft. It shows up only when you compare the claim with its source.
So the first design rule is simple. A reviewer can only check what they can trace. If the draft doesn’t show which document each figure or statement came from, the review step can confirm the tone and spelling, and little else.
The second rule is that people who review good-looking output all day start trusting it. The EU AI Act names this directly: for high-risk AI systems, Article 14 requires that the people overseeing them can understand the system’s limits, stay aware of the tendency to over-rely on its output (“automation bias”), and decide not to use, override or stop it. Most document workflows in a small business aren’t high-risk systems under that regulation. But the article is a useful description of what meaningful oversight looks like, and the same human tendency applies to a quote summary as to anything else.
Four places to put a checkpoint
Not every document needs all four. Decide which apply before anything is built.
- Before the sources are used. Someone confirms which documents the workflow may draw on: this quarter’s price list, not last year’s; the signed terms, not a draft. A wrong source makes every later check pointless, because the draft will faithfully match the wrong evidence.
- When the system flags something. Missing information, a claim it couldn’t match to a source, two documents that disagree. The workflow should stop and assign an owner rather than guess. This is the cheapest review there is: a person looks at one flagged item, not the whole document.
- Before anything leaves the business. A reply to a customer, a recommendation sent to a manager, a summary going to a supplier. The reviewer sees the draft next to its sources and can edit, return or approve it.
- Before a decision with consequences. Choosing a supplier, accepting a claim, refusing a request. Here the AI output is input to a person’s decision, and the decision, with its reason, is recorded under that person’s name.
The second checkpoint does most of the practical work. A workflow that is good at saying “I don’t know this” makes every other review shorter.
Match the depth of review to the risk
Ask two questions about each output: does it leave the business, and could a mistake cost money, a relationship or someone’s rights? The answers give you a starting depth.
- Internal and easy to reverse, such as tagging incoming documents or a first internal summary. Spot-check a sample each week, and fix the rules when the same error repeats.
- Internal but used for a decision, such as a supplier comparison or a summary of contract terms. Check every flagged item, and trace the key figures to their source before the decision.
- Sent outside the business, such as a customer reply, a quote summary or a request to a supplier. Read the whole draft against its sources before it goes.
- A decision about a person, such as accepting or refusing a claim, an application or a complaint. A person makes and records the decision; the AI only prepares the material.
The last tier has a legal edge. Under Article 22 of the GDPR, people have the right not to be subject to a decision based solely on automated processing that has legal or similarly significant effects on them, with limited exceptions, and where those exceptions are used they keep at least the right to human intervention, to give their view and to contest the decision. If your workflow touches decisions like that, design the human decision in from the start and check with whoever handles data protection for your business.
Treat these tiers as a starting point, not a rule. A depth can come down once you’ve measured how often reviewers actually change things. It should go up the first time something wrong gets through.
A worked example (fictional)
The following example is invented to show the method. It isn’t a VoxTraffic client or project.
An operations manager needs 2,000 printed mailer boxes and has quotes from three suppliers in three formats. An AI-assisted workflow reads the quotes and drafts a recommendation. Here is where the checkpoints sit:
- Sources. The manager attaches the three quotes and the internal spec. Nothing else is in scope, so the draft can’t borrow a price from an old email.
- Flags. The draft says Supplier B “includes delivery”. The workflow can’t find that in B’s quote and marks the claim as unsupported. Supplier C’s quote has no freight cost and no arrival date. Both are shown as open, not filled in with estimates.
- Resolution. The manager asks Supplier C for freight and a date. When the reply arrives, it’s added as a new source, and the recommendation is updated with a visible note of what changed.
- Decision. The manager reads the current version beside its sources, removes the unsupported delivery claim, and approves the choice. The record shows the version approved, by whom, and when.
The reviewer never had to reread three quotes from scratch. They checked one flagged claim, one gap and one change, then made the decision they were responsible for anyway.
Our supplier recommendation concept is an interactive sample of this kind of flow, with fictional quotes and a simulated supplier reply. It was built as a demonstration, not for a client, and it isn’t connected to any real supplier or AI provider.
Signs that review has become rubber-stamping
Review fails quietly. Watch for these:
- Approval in seconds. If long drafts are approved faster than anyone could read their sources, the step is a click, not a check.
- No edits for weeks. Either the output is now very good, or nobody is looking. Seed a known error occasionally and see whether it’s caught.
- The reviewer can’t see sources. Then they can only judge whether the draft sounds right.
- Nobody can return a draft. If the only buttons are approve and edit, problems get patched by hand and the workflow never learns why.
- Review is someone’s tenth job. Name the reviewer for each output, and give them time for it in the plan.
What to record at each checkpoint
Keep it small, but keep it every time:
- which version of the draft was reviewed, and which sources it used;
- what was flagged and how each flag was resolved;
- who approved, returned or edited it, and when;
- for decisions, the reason in one line.
That record is what lets you lower review depth later with evidence, and answer the question “why did we send this?” six months from now.
Before you build, decide these
- Which documents the workflow may use, and who keeps them current.
- What the system must flag instead of guessing.
- Which outputs leave the business, and who approves each one.
- Which decisions stay with a named person, whatever the AI suggests.
- What the reviewer sees on screen: the draft, its sources and the flags together.
- How you’ll measure whether review is still catching things.
If you’re still deciding which task to automate first, what AI automation can do for a small business has a way to score candidates, and AI agents vs chatbots explains what a system should be allowed to do on its own. For the workflow itself, mapping it step by step is a good first exercise.
Our AI workflows are built around these checkpoints: the system prepares the work from approved information, stops when evidence is missing, and a named person approves anything that matters. If you have a document-heavy task in mind, describe it to us and we’ll tell you where the review steps should go, and whether AI belongs in it at all.