This article is generated by our in-house contract drafting and review app by converting the insights derived when it vetted risks of a technological contract
How to stop an AI from generating solution to a problem that never existed.
AI can review a contract in seconds.
It can identify unusual wording, compare provisions, suggest alternative language, produce risk scores and even draft a more protective clause.
And yet, some of the most dangerous mistakes in AI-assisted contract review are not sophisticated mistakes.
They are obvious ones.
The problem is not necessarily that the AI does not understand the law. Sometimes it is that the AI does not stop to establish what the contract already does before deciding what is wrong with it.
That distinction matters enormously.
The Obvious Mistake
Consider a technology contract containing a disaster-recovery provision.
The provision requires the service provider to maintain redundant disaster-recovery capabilities, test them annually, and recover from a disaster in accordance with a System Availability SLA.
An AI review system might identify that the clause does not expressly state recovery-time or recovery-point objectives.
It may then recommend adding them.
At first glance, that sounds sensible.
But there is an obvious question:
What does the referenced SLA already provide?
If the SLA already establishes the relevant recovery objectives, the AI has just identified a “risk” that may not actually exist.
Worse, it may produce replacement language that simply says essentially the same thing in different words.
The result is a particularly unhelpful form of AI assistance:
The system has found something it can improve and mistaken that for something that needs fixing.
That is not risk analysis.
It is drafting optimisation masquerading as risk analysis.
Why AI Systems Make This Mistake
AI-assisted contract applications are often designed around a sequence that looks roughly like this:
Identify unusual language → identify possible risk → suggest better language.
That sequence is too short.
A good contract lawyer does something different.
They first ask:
- What does the provision already accomplish?
- What rights and obligations already exist?
- Is another provision incorporated?
- Is there an SLA, schedule, definition or policy that supplies the missing protection?
- What is the actual commercial consequence?
- Is the alleged deficiency material?
- Is this really a risk, or simply a drafting preference?
Only after answering those questions should the lawyer decide whether the clause needs changing.
AI contract systems need the same discipline.
The First Solution: Existing Protection Before Risk
The first control should be simple:
Before identifying a deficiency, identify the protection that already exists.
This means that every potential risk should pass through an Existing-Protection Validation stage.
The system should establish:
Existing rights
Existing obligations
Existing standards
Existing remedies
Incorporated protections
Referenced documents
Existing limitations
Only then should it ask:
What exposure remains?
This sounds obvious.
But making it an explicit architectural rule is important because AI systems are very good at generating improvements. They are not automatically good at knowing when an improvement is unnecessary.
The Second Solution: Dependency Before Deficiency
Contracts are interconnected documents.
A clause may say:
in accordance with the SLA
or:
subject to Schedule 3
or:
as defined in the Agreement
or:
in accordance with applicable law.
An AI system should not conclude that the relevant protection is missing until it has checked the referenced source, where that source is available.
The rule should therefore be:
Dependency before deficiency.
If the referenced material is unavailable, the system should not invent the answer.
It should say:
Requires Verification.
That is a much more legally disciplined conclusion than:
Protection Missing.
The Third Solution: Unknown Is Not Deficient
There are several fundamentally different outcomes in contract review.
A provision can contain:
A genuine material deficiency.
A conditional risk.
A verification point.
An improvement opportunity.
A market deviation.
No material risk.
These are not interchangeable.
One of the most important safeguards for AI-assisted contract review is therefore:
Unknown ≠ Deficiency.
If the available evidence is insufficient to establish that something is wrong, the system should preserve the uncertainty rather than convert it into a risk finding.
That may sound conservative.
It is.
And that is precisely what legal risk analysis often requires.
The Fourth Solution: Prove the Delta
There is another simple test that can prevent bad AI drafting.
Before proposing alternative language, compare:
What the clause currently says
with
What the proposed language would say.
Then ask:
What materially changes?
Does the proposal change:
- legal effect?
- risk allocation?
- protection?
- discretion?
- obligation?
- remedy?
- commercial outcome?
If the answer is “nothing material,” the AI should not rewrite the clause.
This is the Prove-the-Delta Rule.
It forces the system to explain why its proposed drafting is actually necessary.
Risk Analysis and Drafting Must Be Separate Stages
This leads to a broader architectural point.
AI-assisted contract systems should not treat:
Risk identification
and
drafting
as one continuous activity.
They should operate as two controlled stages.
Stage One — Risk Validation
Potential Issue
↓
Existing Protection
↓
Referenced Protection
↓
Actual Exposure
↓
Evidence
↓
Materiality
↓
Risk Classification
↓
Decision
Only a validated material risk should move forward.
Stage Two — Risk-to-Language Conversion
Validated Risk
↓
Risk Objective
↓
Required Change
↓
Preferred Language
↓
Pushback Language
↓
Fallback
↓
Last Resort
That separation is crucial.
Otherwise the AI can create a circular process:
It thinks a clause is risky because it can imagine stronger language, and then uses the stronger language as evidence that the original clause was risky.
The system becomes its own justification.
What Better AI Contract Review Should Produce
The goal should not be the longest possible risk report.
For one or two clauses, the user may need only:
Risk
What is the actual problem?
Existing Protection
What does the contract already provide?
Remaining Exposure
What genuinely remains?
Risk Rating
How material is it?
Suggested Position
What should change?
Pushback Language
What should we say if the counterparty resists?
Residual Risk
What remains if the change is not accepted?
This is much closer to how an experienced commercial lawyer actually works.
The Same Principle Applies to Negotiation
A good redline is not necessarily the most protective redline.
It is the redline that addresses the validated risk without unnecessarily disturbing the commercial architecture of the agreement.
That means the AI should be capable of saying:
No change required.
Or:
Please verify the referenced SLA first.
Or:
This is a drafting improvement, not a material risk.
Or:
The risk is genuine; here is the preferred position.
Or:
The counterparty rejected the preferred position; here is the commercially acceptable fallback.
Those are very different outputs.
An AI contract application that can produce all of them is much more useful than one that simply produces more redlines.
The Bigger Lesson for AI Contract Applications
The next generation of AI contract tools should not compete only on:
- how many risks they identify;
- how many clauses they review;
- how quickly they produce redlines;
- how many alternative clauses they can generate.
They should compete on something more difficult:
How accurately can they distinguish a real risk from a possible improvement?
That requires a different philosophy.
The system must be designed to pause before drafting.
It must reconnect to the contract architecture.
It must identify existing protections.
It must check dependencies.
It must consider jurisdiction and authoritative sources where necessary.
It must distinguish law from market practice and best practice.
It must assess materiality.
And only after a risk has been validated should it start drafting.
A Simple Rule for AI-Assisted Contract Review
The entire philosophy can be reduced to one question:
What does the contract already protect, what risk genuinely remains, what evidence establishes that risk, and why is intervention justified?
Only after answering that should the next question be:
What should we say?
That sequence may add a few seconds to an AI workflow.
But in contract drafting and negotiation, those few seconds can prevent something much more expensive:
an AI-generated solution to a problem that never existed.
And perhaps that is one of the most important lessons in building AI for legal work:
The intelligence is not only in knowing what to add. It is in knowing when not to add anything at all.