AI Contract Review Workflow: Flag Clauses, Humans Decide

An AI contract review workflow works best when the agent does the reading and a person does the deciding. The agent compares each clause with your written playbook, flags what departs from it, quotes the exact text and explains why. A named reviewer then accepts, edits or rejects every flag, and nothing is approved, sent or signed by the agent.

Key takeaways

• The agent flags and explains, and a reviewer decides. Build that split into the permissions, not only into a policy document.
• A written playbook is the foundation. Without clear positions, the agent can only guess what your company would accept.
• Every flag should carry the quoted clause, the playbook rule it touches, a short reason and an uncertainty note, so review is fast and checkable.
• Treat the contract as untrusted input. Give the agent permission to read and draft, and no ability to send or sign.
• Judge the workflow by what reviewers change and what the agent missed, not by how many contracts it touched.

What should an AI contract review workflow actually do?

Contract review mixes three kinds of work: reading, comparing and judging. Reading is slow but mechanical. Comparing a clause with your standard position is repetitive and suits an agent well. Judging, which means deciding whether a risk is acceptable for this counterparty, this deal and this moment, depends on context and accountability that belong to people.

So define the agent's role narrowly. It can extract clauses, map them to playbook topics, flag deviations, report clauses that are missing, propose replacement wording drawn only from language your company has already approved, and produce a short review summary. It should not approve a contract, negotiate with the counterparty, send anything outside the company, sign, or edit the original document.

The reviewer depends on your organization. It might be in-house counsel, outside counsel, or an operations lead for low-risk standard agreements, according to your own rules. The workflow organizes the review and does not replace legal advice where you need it. For a wider view of responsibility when something goes wrong, see who is accountable when an AI agent makes a mistake.

Start with a playbook the agent can read

The playbook is the most important input, and most companies have it only in people's heads or in scattered old emails. An agent cannot flag a departure from a position nobody wrote down. Before any automation, write one entry per topic in plain sentences.

A useful entry has five parts: the topic, the preferred position, the acceptable fallback, the trigger that requires escalation, and who must approve an exception. Here is an illustrative entry for limitation of liability:

• Topic: limitation of liability.
• Preferred position: liability is capped at a level tied to the fees under the agreement and applies to both parties equally.
• Acceptable fallback: a higher cap is acceptable if it is mutual and excludes indirect losses.
• Escalation trigger: unlimited liability for our side, or a one-sided cap that favors the counterparty.
• Approver for exceptions: the person your company names for legal risk.

Cover the topics you actually negotiate: liability, indemnity, termination, renewal, payment terms, confidentiality, data protection, intellectual property, governing law, assignment and exclusivity. Give the playbook an owner and a review date, and keep a single current version. The agent should read from that one place, which is the same principle described in how to give an AI agent a reliable source of truth.

When a clause does not fit any playbook topic, the agent must say so instead of improvising a rule. That honest category, outside the playbook, is where the playbook gets better over time.

What does a good flag look like?

A flag is the unit of work the reviewer sees, so its shape decides whether review is fast or tiring. A vague note such as this clause seems risky forces the reviewer to reread everything. A structured flag lets them check one claim at a time.

Each flag should contain:

• The exact clause text, quoted without rewording, with its location in the document.
• The playbook topic and the specific rule it was compared against.
• The result: matches the preferred position, matches the fallback, departs from the playbook, missing, or outside the playbook.
• A reason in one or two plain sentences that separates what the text says from how the agent interprets it.
• An uncertainty note when the wording is ambiguous, refers to another document, or depends on a defined term the agent could not find.
• Optional suggested wording, taken only from approved fallback language and clearly labeled as a suggestion.

Two rules keep flags trustworthy. First, the agent never states that a clause is absent unless it has searched the whole document, including schedules and annexes, and says where it looked. Second, the agent never fills a gap with a guess. Not found and not sure are acceptable answers. A confident wrong answer is the expensive one.

A step-by-step plan to build the workflow

Start small and prove it on one contract type before widening. This follows the same logic as choosing a first workflow small enough to prove, and it keeps the review burden manageable while you learn.

• Pick one contract type that arrives often and has a stable standard position, such as supplier agreements or non-disclosure agreements.
• Write the playbook for that type, with preferred positions, fallbacks, escalation triggers and approvers.
• Define intake: where contracts arrive, in which formats, and how the agent confirms it has the complete file including attachments. A workflow like AI document classification and routing covers this stage well.
• Name the reviewer and a backup, and write down who handles escalations.
• Set permissions: the agent can read the contract and the playbook and can write a draft review. It cannot send email, edit the original or mark anything approved.
• Define the flag format described above and the summary the reviewer sees first, ordered by what needs a decision.
• Test against a small set of past contracts that people have already reviewed. Compare the agent's flags with the human findings and note every miss and every false alarm.
• Run in shadow mode for a period: the reviewer works as usual and compares afterward, so you learn before the agent shapes any real decision.
• Go live with the reviewer deciding every flag, and record each decision with a short reason.
• Review the record regularly, update the playbook where reviewers keep overriding the same rule, and retest after each change.

Where the human decides: a decision guide

The reviewer should not be a rubber stamp at the end. The workflow should make clear which decision each result asks for. Use this guide as a starting point and adapt it to your risk tolerance.

• Matches the preferred position: the reviewer spot-checks the quote and accepts. The agent saves time here, but the human still owns the sign-off.
• Matches the fallback: the reviewer confirms the fallback suits this deal and this counterparty, because a fallback that is fine for one relationship may not be for another.
• Departs from the playbook: the reviewer decides to accept, request a change or escalate. If wording is suggested, the reviewer edits it before anything is shared.
• Missing clause: the reviewer decides whether the absence matters and whether to ask the counterparty to add it.
• Outside the playbook: the reviewer handles it directly or sends it to the approver, then considers adding a playbook entry.
• Agent uncertain: the reviewer reads the source passage in full, since uncertainty usually marks ambiguous drafting.

Illustrative scenario: a consultancy receives a supplier services agreement. The agent quotes the renewal clause, notes that it renews automatically with a notice requirement the playbook does not accept, and proposes the approved fallback wording. It also reports that no data protection clause was found after searching the body and the annexes. The reviewer accepts the renewal flag, adjusts the suggested wording to fit a long supplier relationship, and sends the missing data protection clause to the person designated for that risk. Each decision is logged with a reason, and the agent sends nothing to the supplier.

What can go wrong, and how do you contain it?

The main risks are predictable, and most can be handled by design instead of by hoping the agent behaves.

• Instructions hidden in the document. A contract is text from outside your company, and text can contain instructions aimed at the model. Treat the document strictly as data, never as commands, and read the [OWASP prompt injection prevention guidance](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html). The strongest control is structural: an agent that cannot send, sign or alter files cannot be talked into doing so.
• Excess access. Give the agent only the documents the task needs, and apply least privilege as described in the [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html). The distinctions in read, draft and send as separate permissions apply directly.
• Missed clauses. Fluent summaries can hide omissions. Build a test set of contracts with known findings and rerun it after every change to the playbook, instructions or model, in the spirit of [Anthropic's guidance on evals for agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents).
• Automation bias. Reviewers can start trusting flags too easily. Require the reviewer to see the quoted clause, record a decision for each flag, and periodically check a sample of accepted items against the full text.
• A stale playbook. If positions change and the playbook does not, the agent will faithfully flag against old rules. Give the playbook an owner and a review date.
• Confidential terms. Share only what the task requires, keep access logs, and decide in advance where contract data may be stored and for how long.

A general risk frame such as the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) can help you document who governs the workflow, how it is measured and how problems are handled, without turning the project into a bureaucracy.

How does Be Human run this kind of workflow?

Be Human designs and operates the agent infrastructure around a workflow like this one. A first engagement defines the role (flag clauses against your playbook), the memory and documents it needs, the tools it may use, the approval boundary (a named reviewer decides every flag) and a success criterion you can observe, such as reviewer overrides and missed findings in the test set. Managed operations can then include monitoring, recurring evaluations on your sample contracts, permission review, integration maintenance, incident response and controlled improvements when the playbook changes. Your team keeps control of the playbook, the reviewer roster and every decision.

Frequently asked questions

Can an AI agent approve low-risk contracts on its own? It can, technically, but the design recommended here keeps a person as the decider for every contract, including routine ones. If you later want lighter review for a narrow class of standard documents, make that a deliberate decision by the owner of legal risk, test it against past contracts, and keep sampling the results.

Does this replace a lawyer? No. The workflow helps a reviewer find and compare clauses faster and more consistently, but it does not provide legal advice. Where your rules call for counsel, counsel still reviews, and the agent's flags simply give them a better starting point.

What do we need ready before we start? You need a written playbook for one contract type, a named reviewer and backup, a place where contracts arrive, and a handful of past contracts with known findings for testing. If your documents are scattered or inconsistent, preparing company documents for an AI agent is a sensible first step.

How do we know the workflow is working? Track what reviewers accept, edit and reject, which findings the agent missed in tests and in live use, and how long contracts wait for a decision. A high override rate on one rule usually points to a playbook problem, and a missed clause in testing points to an instruction or retrieval problem. Review those signals regularly and change one thing at a time.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.