Legal AI Concepts: Part 5

A model generates an answer. A Legal AI application must do considerably more: obtain matter information, enforce permissions, choose tools and sources, structure the result, record what happened and send the work to the right reviewer.

The surrounding software is sometimes called a wrapper. The repeatable sequence is a workflow. An agent is one possible way of deciding and executing steps inside that workflow.

1. APIs and gateways

An application programming interface (API) is a defined way for software systems to exchange requests and responses. A Legal AI application may use APIs to call a language model, retrieve a document, perform OCR, search a legal database, create a task or write an audit event.

An AI gateway provides a common interface to one or more model providers. For example, OpenRouter offers access to multiple models and supports provider routing and fallbacks. A gateway can simplify integration, but the application still has to decide which providers are approved, which data controls are required and how a fallback affects confidentiality, cost and consistency.

APIs should use server-side credentials, narrow permissions, secure secret storage and rate and spending limits. A browser-delivered key can be copied by the user or an attacker. Matter data sent through an API should be minimised and logged according to policy.

Case study: A fallback changes the data recipient

A contract-review application normally sends requests to Provider A, which has been approved for confidential matter data. During an outage, the gateway automatically routes the request to Provider B.

The user sees no difference in the interface, but several things may have changed:

• the provider receiving the data;
• the country in which it is processed;
• the retention and training terms;
• the model version and output behaviour; and
• the price and latency of the request.

A fallback should therefore be restricted to approved providers and recorded in the audit trail. Availability should not silently override confidentiality controls.

2. Wrappers and application controls

A wrapper is the application layer around a model. It turns a general capability into a defined legal tool. A contract-review wrapper might provide:

• matter selection and document upload;
• approved contract types and review playbooks;
• parsing, retrieval and source references;
• required output fields and risk categories;
• model and provider configuration;
• role-based permissions and matter isolation;
• lawyer review, revision and approval states; and
• logs of inputs, versions, tool calls and outputs.

A wrapper does not automatically make an unsafe model safe. Its value depends on the controls it actually enforces. A decorative warning beneath a chat box is weaker than preventing unapproved data from being sent or blocking external delivery until review.

Example: General chatbot versus legal wrapper

A lawyer uploads a distribution agreement and asks whether the principal can terminate immediately.

A general chatbot may:

• analyse whichever clauses it notices;
• assume a jurisdiction;
• ignore missing amendments; and
• return a prose answer with no approval state.

A legal wrapper may instead:

1. require the user to select the matter and client position;
2. verify document completeness and permissions;
3. load the approved contract playbook;
4. retrieve every termination clause and cross-reference;
5. return structured findings linked to source text; and
6. prevent external delivery until a lawyer approves the result.

The underlying model may be the same. The surrounding controls determine whether the interaction is reviewable and governable.

3. Model orchestration

Model orchestration is the logic used to choose and coordinate models. Common patterns include:

• Fixed model: one tested model handles a defined task.
• Task routing: different models handle extraction, translation, analysis or drafting.
• Fallback: another approved model is used when the first is unavailable.
• Escalation: a routine model processes most items and sends difficult or high-risk cases to a more capable model or human.
• Ensemble or comparison: several models produce results that are compared or synthesised.

More models do not necessarily mean more accuracy. Models may share the same misconception, and a synthesiser can select the wrong answer. Each routing path creates another configuration to benchmark and another possible data recipient. Use the simplest architecture that meets the tested requirement.

Routing rules should be explicit and observable. Record which model and provider handled each step, the fallback reason, settings, cost, latency and any change in data policy.

Case study: The inexpensive model handles the wrong task

A firm routes routine extraction to a smaller model and complex analysis to a stronger one. The routing rule classifies a 120-page acquisition agreement as a standard contract because the file name contains “template.”

The smaller model extracts the basic fields but misses a bespoke change-of-control clause and a handwritten amendment. The error occurred before generation: the routing logic sent a high-risk matter down the low-risk path.

Routing rules should therefore use more than filenames or document length. They may need contract type, transaction value, unusual drafting indicators, missing schedules and mandatory escalation rules.

Example: Three models agree and are still wrong

Three models are asked whether a clause permits unilateral termination. All three answer yes because each overlooks the same proviso in an amendment.

Agreement among models can increase confidence without increasing correctness. An ensemble is not independent verification when the models rely on the same incomplete context or make the same interpretive mistake.

4. Workflows and agents

A workflow is a repeatable sequence designed in advance. A software agent is given an objective and some discretion to plan steps, choose tools or decide what to do next.

A deterministic workflow might always parse a contract, extract named clauses, compare them with a playbook and produce a fixed report. An agentic workflow might inspect the contract type, decide which checklist applies, run additional searches when cross-references are missing and ask the user for facts.

Agency can help with variable tasks, but discretion increases risk. For high-stakes legal work, combine flexible reasoning with fixed boundaries:

• the workflow controls allowed data, tools and final actions;
• the agent may choose among approved analytical steps;
• important transitions require validation or human approval; and
• the system stops safely when authority, information or confidence is inadequate.

An agent reviewing its own answer is performing self-critique, not independent verification. Verification must compare the result with sources, rules or another genuinely independent control.

Case study: The agent chooses an outdated source

An agent is asked to identify the filing deadline for a regulatory appeal. It may use either the approved legal database or a general web search. To save time, it selects a blog post that accurately described the rule two years earlier.

The rule has since changed. The agent produces a fluent answer with a working link, but the source is outdated and non-authoritative.

The workflow should not leave source hierarchy entirely to agent discretion. For high-consequence research, it should require approved primary sources, current-law checks and escalation when authority cannot be confirmed.

Example: Safe stopping instead of improvisation

An agent preparing a contract notice cannot locate the operative amendment or confirm the recipient's address. A weak agent fills the gaps from previous correspondence and continues drafting.

A controlled workflow stops and requests the missing amendment and verified address. Refusal to proceed can be the correct system behaviour.

5. Tools, permissions and approvals

Tools allow a model or agent to take structured actions: search a repository, retrieve a case, calculate a date, create a document or draft an email. The model normally proposes a tool name and arguments; the application decides whether the call is valid and executes it.

Apply least privilege. A research agent does not need permission to send email. A contract-review agent should not browse every client matter. A tool that may create, alter, disclose or delete information should require narrower permissions and, where appropriate, human approval.

Validate tool arguments outside the model. A filing deadline calculator should use verified dates and deterministic legal rules where possible. An email tool should check recipients and matter classification before sending. Never treat a model-generated function call as inherently authorised.

Case study: Drafting authority becomes sending authority

A legal agent is authorised to draft a demand email. Its email tool also allows immediate sending. The model selects the wrong contact with a similar name and transmits a confidential attachment before a lawyer sees the message.

The agent required drafting permission, not sending permission. A safer design would:

• create a draft only;
• restrict recipients to matter-approved contacts;
• display attachments and classification warnings;
• require human approval; and
• record the final sender and approver.

Example: The model calls a calculator with the wrong date

A deadline calculator may be perfectly deterministic, but its result is only as reliable as its inputs. If the model supplies the date of the internal email instead of the date of service, the calculator will return a precise but legally irrelevant deadline.

Tool validation should therefore confirm both format and legal significance.

6. Guardrails

Guardrails are controls intended to prevent, detect or contain unwanted behaviour. They operate at several layers:

• Input: file restrictions, malware scanning, redaction, data classification and prompt-injection detection.
• Retrieval: matter permissions, jurisdiction and date filters, approved sources and result limits.
• Generation: standing instructions, structured schemas and prohibitions on unsupported conclusions.
• Tools: allow lists, argument validation, spending limits and approval gates.
• Output: source checks, personal-data filters, warning labels and required review status.
• Operations: audit logs, monitoring, incident response, rollback and a kill switch.

Guardrails reduce known risks; they do not make the system infallible. Model-generated confidence scores are not reliable guardrails unless separately calibrated for the task. Similarly, telling a model “do not give legal advice” is weaker than controlling the audience, task and delivery channel.

Case study: A warning label without an enforcement control

A client-facing tool displays:

AI output may be inaccurate. Please consult a lawyer.

The same tool allows the user to generate a personalised limitation analysis and email it directly to a counterparty. No lawyer reviews the result, and no jurisdiction is selected.

The warning identifies a risk but does not control it. Stronger controls could restrict the task to general information, require missing facts, block external sending or route high-risk outputs to a lawyer.

Example: Guardrails working across layers

A merger-review workflow receives a password-protected archive containing executables, contracts and employee records. Effective controls may operate as follows:

1. the input layer rejects executable files and scans the archive;
2. the retrieval layer limits access to the approved transaction matter;
3. the generation layer requires source-linked findings;
4. the tool layer prevents external sharing;
5. the output layer flags personal data; and
6. the operational layer records the event and permits the workflow to be stopped.

7. End-to-end contract review

A controlled first-pass contract review could work as follows:

1. The user selects the client matter and confirms authority to process the document.
2. The system scans the file, preserves the original and parses clauses, tables and page references.
3. It classifies the agreement and loads the approved playbook for that contract type and client position.
4. It extracts defined terms and required clauses, recording absent or unreadable sections.
5. Retrieval finds the relevant contract passage and corresponding playbook rule for each review issue.
6. The model returns structured findings: clause, source text, playbook position, deviation, risk explanation, proposed revision and missing facts.
7. Automated checks validate clause references, quoted text, completeness of mandatory fields and unresolved cross-references.
8. A lawyer reviews each material finding against the contract and commercial instructions.
9. Approved findings generate a redline and client report; rejected or amended findings remain in the audit history.

The model is only one step. Much of the legal value comes from the playbook, document structure, source mapping and review process.

Worked case: From unpaid invoices to a reviewed legal notice

A client uploads a distribution agreement, two amendments, 18 invoices and an email stating, “We will clear the outstanding amount next month.” The client asks the firm to send a legal notice.

A controlled workflow could:

1. identify the parties and confirm the client's legal entity;
2. extract invoice numbers, due dates, amounts paid and balances;
3. identify the governing agreement and operative amendments;
4. locate notice, termination, interest and dispute-resolution clauses;
5. flag the email as a possible acknowledgement without deciding its legal effect;
6. calculate totals using deterministic arithmetic;
7. identify missing documents and disputed amounts;
8. draft the notice using approved language;
9. require a lawyer to verify the legal claims, addresses and deadline; and
10. create a final document only after approval.

The system should not send the notice automatically merely because every earlier step completed.

8. Auditability and operations

For material workflows, log the prompt version, model and provider, settings, source identifiers, retrieval results, tool calls, output, automated checks, human changes and approval. Protect logs because they may themselves contain privileged or personal information.

Operational monitoring should detect provider errors, unusual cost, latency, failed retrieval, incomplete outputs, permission failures and changes in reviewer override rates. A sudden increase in lawyer corrections may indicate a model update, new document type or broken parser.

Design for failure. The workflow should stop rather than improvise when it cannot access the source, resolve a citation, obtain required facts or identify an authorised reviewer.

Case study: A model update changes reviewer behaviour

For three months, lawyers reject about 8% of the system's contract findings. After a provider update, the rejection rate rises to 27% and review time doubles.

The issue may be a model change, a routing change, a broken parser or a new contract type entering the workflow. Because the system records model version, source set, retrieval results and reviewer overrides, the team can investigate rather than relying on anecdotal complaints.

Operational failure checklist

A workflow should stop or escalate when:

• the source file cannot be opened or is incomplete;
• the governing agreement or amendment cannot be identified;
• a mandatory citation does not resolve;
• the model output is truncated or fails the schema;
• the requested action exceeds the user's permission;
• an approved provider is unavailable and no compliant fallback exists; or
• no authorised reviewer is available for the risk level.