Summary
What an unreviewed AI process actually looks like
An unreviewed AI process is one where the output of an AI agent flows directly to an end state, a customer, or a downstream system without a human decision point between generation and delivery. The agent runs, produces output, and the output is acted on. No one checks it first.
This is more common than it should be, and it usually happens for one of three reasons. First, the team building the workflow is optimising for speed and treats human review as friction to be eliminated rather than a control to be placed deliberately. Second, the process was reviewed manually at the start, the AI output looked good, and the review step was quietly removed when it felt redundant. Third, the workflow was built by someone who understood the process well and assumed the AI would behave consistently, because it did during testing.
All three paths lead to the same place: a process that runs without accountability until the moment it produces an output that should not have been produced. At that point, the question is not whether the error was expensive. The question is how many times it ran before anyone noticed.
The cost of an unreviewed AI process is not the cost of a single bad output. It is the cost of every bad output the process produced between the last time someone checked and the moment the problem surfaced. In a high-volume workflow, that interval can be days or weeks. In a low-visibility workflow, it can be longer.
The four failure modes of unreviewed AI output
Unreviewed AI processes fail in predictable ways. Understanding the failure modes before you build is the argument for designing review in from the start rather than adding it after the first incident.
1. Confident errors. AI agents do not flag uncertainty the way a careful human reviewer does. A human who is not sure whether a contract clause is standard will say so. An AI agent will produce a confident, well-structured response that happens to be wrong. Without a review step, that confident error reaches its destination looking exactly like a correct output. The recipient has no reason to question it. Confident errors are the most dangerous failure mode because they are the hardest to detect downstream.
2. Drift from the original intent. An AI agent's output is shaped by its system prompt, the model it uses, and the context it receives. All three of these can change over time: system prompts are updated, model versions are rotated, and the context passed to the agent evolves as the workflow matures. Without a review step, drift in any of these inputs produces drift in the output, and that drift accumulates invisibly. A workflow that produced good output six months ago may be producing subtly different output today, and no one will know until the difference becomes large enough to cause a visible problem.
3. Policy and compliance violations. AI agents do not have inherent awareness of your organisation's current policies, regulatory obligations, or legal constraints. A response that was compliant last quarter may not be compliant this quarter if a policy changed. A contract clause that was acceptable in one jurisdiction may not be acceptable in another. Without a review step, policy violations reach their destination at the speed of the workflow, which is faster than any manual audit process can catch them.
4. Cascading errors in multi-agent workflows. When multiple agents run in sequence, the output of each agent becomes the input of the next. An error in the first agent's output is not just a single bad result: it is the foundation on which every subsequent agent builds. A misclassification in a triage agent produces a misdirected response from the drafting agent, which produces a confused approval from the review agent, which delivers a wrong answer to the customer. The error compounds at each step. In a workflow with no human review node, there is no point at which a human can interrupt the cascade before it reaches the end state.
What human review actually costs, and what it prevents
The objection to human review in AI workflows is almost always framed as a cost argument: review slows the process down, requires headcount, and defeats the purpose of automation. This framing is wrong in two ways.
First, it misidentifies what review replaces. Human review in an AI workflow does not replace the same human effort that existed before automation. Before automation, a human did the work from scratch: reading the source material, making the decision, producing the output. In an automated workflow with a review step, the human reads the AI's draft and decides whether to approve, reject, or request changes. That is a fundamentally different task, and it is faster. A lawyer who reviews an AI-drafted contract summary spends a fraction of the time they would spend drafting the summary themselves. The review step is not the cost of automation: it is the residual human cost after automation has done the heavy lifting.
Second, the cost comparison is wrong. The relevant comparison is not the cost of review versus the cost of no review. It is the cost of review versus the cost of the errors that no review produces. A single confident error that reaches a customer, a regulator, or a counterparty in a contract negotiation can cost more than months of review labor. The cost of review is predictable and bounded. The cost of unreviewed errors is unpredictable and unbounded.
In DAVE, a Human Review task appears in the assignee's Task Inbox when the workflow instance reaches a Human Review node. The assignee reads the payload, which contains the AI-generated content and any context the workflow has accumulated, and makes one of three decisions: Approve, Reject, or Request Changes. Each decision is recorded with the acting user, the timestamp, and an optional comment explaining the reasoning. The entire interaction is logged for compliance and accountability, supporting SOC 2 and GDPR audit requirements when those modes are active.
The time cost of that interaction is the time it takes a qualified person to read the payload and click a button. In a well-designed workflow, that is measured in minutes, not hours. The accountability it creates, and the errors it catches, are not measurable in minutes.
Designing review into the right places, not every place
The answer to the risk of unreviewed AI processes is not to add a human review step after every node. That approach recreates the cost of the manual process without the speed benefit of automation, and it produces reviewer fatigue: when every output requires review, reviewers stop reading carefully and start approving reflexively. A rubber-stamp review is not a review.
The right design places human review at the points where the cost of an error is highest and the AI's confidence is least reliable. In practice, that means three categories of checkpoint.
Before high-stakes outputs reach their destination. If the workflow produces a contract, a customer-facing response, a financial report, or a compliance document, a Human Review node before the End node is non-negotiable. The cost of a bad output in these categories is high enough that the review step pays for itself on the first error it catches.
After classification decisions that determine the path of the workflow. In a multi-agent workflow, the first agent often makes a classification decision that determines what every subsequent agent does. If that classification is wrong, the entire downstream path is wrong. A Human Review node after the classification step, or an Agent Review node that checks the classification before the workflow branches, catches errors at the point where they are cheapest to correct: before they have propagated to every subsequent step.
When the context or policy environment has changed. If your organisation's policies, regulatory obligations, or standard contract positions have changed recently, add a temporary Human Review node to the relevant workflows until you are confident the AI's output reflects the change. Remove it once you have validated a sufficient sample of outputs. This is a deliberate, time-bounded use of review as a quality gate during a period of change, not a permanent fixture.
In DAVE, the Task Inbox shows every pending task across the tenant, filterable by status. A reviewer can see at a glance how many tasks are waiting, which ones have due dates approaching, and which instances they belong to. Pending tasks that are not acted on block workflow progress: the instance waits at the review node until the assignee submits a decision. This is the mechanism that makes review enforceable rather than advisory.
The audit trail argument: why logged review is worth more than informal review
Many teams that skip formal review steps in their AI workflows do have some form of review: a manager who spot-checks outputs, a team member who glances at the queue before it goes out, a weekly meeting where someone mentions that the AI has been producing odd results. This informal review catches some errors. It catches none of the compliance risk.
When a regulator, an auditor, or a legal counterparty asks who reviewed a specific output and when, "someone on the team usually looks at these" is not an answer. The question requires a specific person, a specific time, and a specific decision. Informal review produces none of these. Formal review, structured as a task in a workflow system, produces all of them automatically.
In DAVE, every task decision is recorded in the audit log: the acting user, the decision (Approve, Reject, or Request Changes), the timestamp, and any comment the reviewer attached. Task completion supports SOC 2 CC6.1 (logical access controls) and GDPR Article 30 (records of processing activities) when those compliance modes are active. This means the audit trail is not something you build separately from the workflow: it is a byproduct of the review process itself.
The value of this audit trail compounds over time. In the first month, it tells you who approved what. In the first year, it tells you whether your review process is consistent: whether the same types of outputs are being approved and rejected at similar rates, whether specific reviewers are outliers, and whether the AI's output quality is improving or degrading. These are signals that informal review cannot produce because informal review leaves no record.
For organisations that operate under SOC 2, GDPR, or similar frameworks, the audit trail is not a nice-to-have. It is a requirement. Building it into the workflow from the start costs nothing extra. Reconstructing it after an audit request, from email threads and meeting notes and memory, costs a great deal.
The real cost calculation: review versus no review
The business case for human review in AI workflows is straightforward once you frame it correctly. The question is not whether review adds cost. It does. The question is whether the cost of review is less than the expected cost of the errors it prevents.
To calculate this, you need three numbers: the frequency of errors in your AI process without review, the average cost of each error when it reaches its destination undetected, and the time cost of a review step per output. For most well-scoped AI workflows, the math is not close. A single undetected error in a contract, a compliance document, or a customer-facing communication costs more than weeks of review labor at the volume most teams operate.
The frequency of errors is the number that teams most often underestimate, because they calibrate it against their testing experience. AI agents perform well on the inputs they were tested with. They perform less well on the full distribution of inputs they encounter in production, which includes edge cases, unusual phrasings, ambiguous context, and inputs that were not represented in the test set. The error rate in production is almost always higher than the error rate in testing. If you do not have a review step, you will not know by how much.
The Pending Tasks card on DAVE's Reports page (visible to Admin and Reporting roles) gives you a real-time view of how many review tasks are waiting across your tenant. If that number is consistently high, the review step is a bottleneck and you should add reviewers or redesign the workflow to reduce the volume reaching review. If that number is consistently low, the review step is not a meaningful burden on your team. Either way, the number is visible and actionable. The cost of errors in an unreviewed process is neither.
Design review in from the start. Place it at the points that matter. Log every decision. The cost is predictable. The alternative is not.