Before anyone talks about AI, here is the review as it actually runs
A commercial contract lands in the inbox. Maybe it is a vendor MSA, maybe a lease, maybe a counterparty's redline on paper your firm drafted six months ago. Someone, usually a mid-level associate or an in-house counsel with a stack of other matters, opens it and starts reading from page one. They are checking for a limitation of liability clause that matches house position, an indemnity that has crept wider than the last version, a termination clause with a notice period nobody agreed to, an auto-renewal nobody flagged. They mark it up, send it to a senior lawyer for sign off, and the senior lawyer either trusts the markup or rereads the whole document anyway because they have been burned before.
This is the point where firms start asking about an AI contract review workflow. Not because reading contracts is hard. Because reading the fortieth similar contract this quarter, at the same depth as the first one, is where the time goes and where the attention slips. The question worth answering in plain terms is what the system actually does to that document before a lawyer sees it, because that is what determines whether it saves time or creates a new category of risk.
What the system reads and what it does with it
The input is the contract itself, plus two other things that make the system worth building at all: the firm's clause library (the approved and fallback language for the clause types that matter to this practice) and its playbook or position paper (what is acceptable, what needs escalation, what is a dealbreaker). Without those two, the system has a document and no basis for judgment. It can tell you what the contract says. It cannot tell you whether that is a problem, because "a problem" is defined by the firm's own standard, not by the model's general sense of what contracts usually look like.
With that in place, the first thing the system does is extraction, not review. It goes through the document and pulls out the clauses that the firm has told it matter: liability caps, indemnities, termination and renewal terms, assignment and change of control, governing law, data handling, payment terms, whatever the practice area has defined as the checklist. This is AI clause extraction in the literal sense: turning an unstructured document into a structured list of "here is the liability clause, here is where it sits, here is what it says." It is the same task a junior associate does on page one, done consistently across every document that comes through, and it is where firms get their first real measure of whether the system is reading the contract correctly, because extraction errors show up immediately when someone checks the list against the source.
How the system decides what to flag
Once the clauses are extracted, the system compares each one against the applicable playbook position. This is the clause flagging step, and it is worth being specific about what "flag" means, because vague language here is where trust gets lost later. A flag is not a vibe. It is a stated comparison: this clause caps liability at one times fees paid, house position requires two times fees paid or a floor amount, the gap is X. Or: this indemnity covers third party IP claims only, the counterparty's draft extends it to all claims including the firm's own negligence, that is outside the fallback position entirely and needs a partner's eyes before it goes anywhere.
Each flag carries a severity, tied to the playbook rather than invented by the model on the fly: within standard, within fallback but needs a note, or outside fallback and needs escalation. This is AI contract risk flagging doing the job a checklist does today, except it runs on every clause, every time, rather than on whichever clauses the reviewer's attention catches on a Friday afternoon. The output at this stage is a report, not a decision: a list of clauses, what they say, how they compare to position, and why each one was flagged the way it was. A lawyer can read that report in minutes and know exactly where to spend their attention, which is the actual time saving. It is not that the lawyer reads less. It is that they stop reading the parts that match house position and start on the parts that do not.
Where redlining fits and what it does not do
The next step, where a firm wants it, is a suggested redline: proposed replacement language for a flagged clause, pulled from the clause library rather than generated fresh. This matters because generated language that sounds right but has not been through the firm's own drafting and precedent process is a liability, not a convenience. AI redlining review, done properly, means the system proposes the firm's own approved fallback language in the right place, with the original struck through and the substitution visible, so the lawyer is reviewing a choice the firm already made rather than evaluating new prose from scratch.
What the system does not do is decide which fallback applies when a clause sits in genuinely ambiguous territory, or accept a counterparty's position because it looks close enough. Those are judgment calls, and they stay with the lawyer. The system's job ends at presenting the comparison and the options clearly. A related point worth saying plainly: a redline suggestion is only as good as the clause library behind it, and a clause library goes stale the moment a practice group changes its position on a deal point and nobody updates the source document. That is an operational commitment, not a one time setup task.
Where the lawyer sits, and what happens when the system is wrong
This is the part that determines whether the system is safe to run, and it deserves to be stated without hedging. Human in the loop contract review, in a system built this way, means every flagged clause and every suggested redline is a proposal, not an output. Nothing leaves the firm, nothing gets sent to a counterparty, without a named reviewer signing off on the specific clauses the system touched. The sign off is not a blanket approval of the whole document. It is a check against each flag: does this comparison hold, is the severity right, does the suggested language actually fit this deal.
Errors happen in two directions, and both need a path. A false flag, where the system marks something as off position when it is actually fine, costs a reviewer a few minutes of unnecessary checking. That is a tuning problem, fixed by adjusting the playbook mapping, and it is cheap. A missed flag, where the system reads a clause as standard when it is not, is the one that matters, and it is caught by the same mechanism that catches it today: a lawyer who still reads the document, just with the system's output as a guide rather than a replacement for judgment. Firms that skip this step, by trusting the system's severity rating without a second read on anything outside standard, are the ones who end up with a contract in circulation that nobody actually checked. The system existing does not change who is accountable for the document. It changes how that accountable person spends their time getting to a signed view.
There is also a record question worth naming once rather than treating as a footnote: which version of the clause library and playbook produced a given flag, on which contract, reviewed by whom. That record is what lets a managing partner answer, months later, why a particular clause went out the way it did, and it is also what a client or an insurer asks for if a dispute over a contract ever reaches that stage. We have written separately about who approves changes to a contract review system once it is live, which covers the governance side of keeping that record straight as the clause library and playbook evolve.
What has to exist before any of this works
A firm cannot start building a contract review automation system by starting with the model. It starts with the playbook: the firm's actual fallback positions, written down, for the clause types the system needs to check. Many firms discover during this stage that their playbook lives partly in a document and partly in the heads of two senior partners, and that gap has to close before the system has anything reliable to compare against. The same is true of the clause library: approved language has to exist in a form the system can draw from, not scattered across old precedent documents with no clear "current version" marker.
The second requirement is a decision about scope. A system that checks every clause type a firm might ever see is harder to build and harder to trust than one scoped to the contract types and clause categories where volume and risk justify it, say commercial MSAs or NDAs or a specific category of vendor agreement, with everything else still going through manual review. Starting narrow and provable beats starting broad and unverifiable, and it gives the firm a real basis for deciding whether to widen scope later.
Where we come in
Alppoint builds contract review systems like this end to end, or works inside a firm's existing legal technology or AI team to ship the specific workstream, clause extraction, risk flagging, redline suggestion, that is next on the list. Either way the system runs in the firm's own environment, on the firm's own clause library and playbook, and stays the firm's asset once it is live. If contract review is the workflow under pressure right now, we are glad to talk through what a first scoped build would actually look like.
