# Human approval is a system design decision, not a concession.

> The pressure to remove people from an AI workflow can obscure the real goal: reliable, accountable work. Sometimes the highest-value automation is one that knows when to stop.

Canonical URL: https://marmation.com/review/human-approval-in-ai-workflows/

By Vikram Roy · 2026-11-12

Removing review can save time and remove the last opportunity to catch a costly mistake. The design question is where a person adds useful judgment, what evidence they need and which checks the application must enforce even after approval.

Consider an AI workflow that handles customer order adjustments. It reads a request, checks account details and proposes a change. The system can save several minutes per transaction if it prepares a recommendation. It can also create a serious problem if it commits the wrong adjustment without the required authorization.

Should the organization give the agent autonomy? That question is too broad. The better question is which actions are safe under which conditions, and who is accountable when the conditions are not met.

## 01. Separate interpretation from execution

Language models are useful where input is messy, a document requires synthesis or a user needs help understanding possible options. Business systems need changes governed by fixed rules, often called deterministic state changes. An approval can be a deliberate boundary between those two functions.

An agent may extract candidate fields, prepare a draft, compare a policy or suggest next steps. A rule engine should validate ordinary constraints, and a user with the right role should approve high-consequence actions. The eventual API call should come from a controlled service, not an unrestricted model tool.

This separation makes it easier to test what the system does and to reason about its failure modes.

## 02. Approval belongs before a consequential transition

Name the stages a task can enter and the rules for moving between them: a workflow state machine. Stages might include Draft, Evidence Ready, Validation Failed, Pending Approval, Approved, Submitted and Reconciled—the point when the receiving system’s result has been checked. Moving between stages should represent a meaningful business event. A prompt that says “ask for confirmation” is not the same as an authorization check in the backend.

The approval record should contain the relevant evidence, what the system proposed, what the human confirmed, the actor's identity, time and the version of the rule that allowed the change. If the downstream API fails, the system needs a recovery state. A user should not be told an order was updated merely because an AI message said it was.

## 03. The adversary may arrive through a document

An agent that reads an external email or attachment may encounter text instructing it to ignore policies or take unrelated actions. That is untrusted content, not a privileged system instruction. Prompt injection is a practical threat, particularly when an application gives a model tools with access to valuable data or write permissions.

OWASP's guidance on LLM applications identifies excessive agency as a risk when an AI system has too much functionality, permission or autonomy. The remedy is not simply to write a stronger prompt. It is to restrict tools, validate actions and preserve human or deterministic control. [\[1\]](<https://owasp.org/www-project-top-10-for-large-language-model-applications/>)

## 04. Repeated actions are a business problem

Suppose the service submits a change but times out before receiving confirmation. It retries. If the receiving service does not recognize and suppress a repeated request, the action may happen twice. That protection is called idempotency. This is a conventional distributed systems problem, now made more likely to be overlooked by systems marketed as agentic. The design needs transaction identifiers, reconciliation and a way to determine what actually happened.

A dependable AI workflow has at least three kinds of test: the model chooses a reasonable interpretation, the policy system permits only approved actions, and the integration updates the authoritative record exactly once or recovers safely.

## 05. Increase autonomy only with evidence

For low-risk routine tasks, human review may be unnecessary after representative testing. For decisions involving money, customer rights, safety or confidential information, additional controls can be appropriate. There is no universal autonomy level. The test is consequence, reversibility, data and demonstrated failure rate.

The most useful metric may not be tasks completed without humans. It may be correct tasks completed, time to resolve exceptions, and how quickly the organization can detect and recover from an error.

## When review can become a bottleneck

Poorly designed human approval can merely move the work to another queue. The review interface should surface what matters: the recommendation, supporting evidence, policy result and the specific change awaiting confirmation. The goal is not to make every employee read the full document again.

**The practical rule:** Use AI to interpret information where it helps. Before a consequential change, enforce fixed business rules and the level of human review its risk requires. Design how people handle exceptions as carefully as ordinary work.

### Sources and limitations

[1] OWASP, *Top 10 for LLM Applications*, 2025.  
[2] NIST, *Generative AI Profile*, 2024, [https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence](<https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence>)  
[3] Thoughtworks Technology Radar Volume 35, November 2026, [https://www.thoughtworks.com/radar](<https://www.thoughtworks.com/radar>)

## Sources

- [Thoughtworks Technology Radar](<https://www.thoughtworks.com/radar>) — Thoughtworks. Original technical editorial research; exemplar of knowledge product. Example of original technical editorial content Limit: The Radar is an editorial reference. Its inclusion does not imply Marmation affiliation or comparable company scale.
- [Generative AI Profile for AI RMF](<https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence>) — NIST. Reference governance and risk design principles for gen AI. Risk management reference for generative AI Limit: This is a risk-management reference, not a certification or evidence that Marmation has been audited or complies with it.
- [Top 10 for LLM Applications](<https://owasp.org/www-project-top-10-for-large-language-model-applications/>) — OWASP. LLM risks such as prompt injection, excessive agency and data disclosures. Threat categories for LLM systems Limit: This is an engineering security reference, not evidence of an independent audit of Marmation or another system.

## Related reading

- [Threat-model the tools, not just the prompts.](https://marmation.com/review/threat-modeling-tool-using-ai-agents/)
- [Your systems may work. The workflow between them may not.](https://marmation.com/solutions/intelligent-business-systems/)
- [The best AI interface is honest about uncertainty.](https://marmation.com/review/designing-ai-ux-for-uncertainty/)