Use caseDocument AIKnowledge and search
Contract review against your own playbook, with every flag tied to the clause that caused it
AI contract review that checks NDAs, DPAs and MSAs against your playbook, quotes the clause behind every flag and drafts tracked changes for a lawyer to decide.
A blueprint, not a client story. The business described is illustrative; the architecture, integrations and trade-offs are real, and this is how I would build it. By Ergini, .
The short version
A first-pass contract reviewer for in-house legal teams and law firms. It reads NDAs, DPAs, MSAs and supplier contracts from Word, SharePoint or the DMS, splits them into clauses and compares each with your playbook of preferred, fallback and unacceptable positions. It checks required terms such as the GDPR Article 28 list, quotes the clause behind every flag and drafts tracked changes only from approved wording. A lawyer decides every point before anything goes back to the other side.
- Best for
- Legal teams reviewing the same few contract types against positions they already know by heart, usually on the other side's paper and under a sales deadline.
- Connects to
- Microsoft Word and SharePoint, iManage or NetDocuments, Clio, Ironclad or Juro, where a CLM exists, The playbook and clause library
- The AI does
- Matches clauses to playbook topics, judges each against your positions with the quoted text as evidence, and drafts redlines from your approved fallback wording.
- People do
- Decide every flag, negotiate, approve any deviation from the playbook and send the markup. The system has no permission to send anything.
- Built as
- AI Integration, usually $15K - $35K
Sixty contracts a month, most of them on someone else's paper
Consider a 300-person SaaS company in Berlin with a legal team of two: a general counsel and one legal counsel. About 60 contracts cross their desks each month. Most are customer DPAs and NDAs, the rest MSAs, order forms and supplier agreements. Enterprise customers insist on their own templates, so the team reviews the customer's paper far more often than its own.
The review is repetitive in a particular way. The team knows its positions by heart. What takes the time is finding where a 14-page DPA hides each topic, noticing that a definition on page two widens a clause on page nine, and typing the same fallback wording for the fortieth time.
Sales asks every afternoon when the DPA will be back. The general counsel tried a chat assistant; its comments sounded right, but nobody could tell which sentence each one rested on, so every comment had to be checked from scratch. A review that cannot be traced to the text saves a lawyer no time.
A playbook written so software can apply it
Most legal teams have a playbook in someone's head or in a Word file of preferences. The first job is turning it into data: one row per position, each with an ID the system cites in every comment.
| Topic | Preferred | Acceptable fallback | Escalate to the general counsel |
|---|---|---|---|
| Liability cap (MSA) | Mutual cap at 12 months' fees | A separate cap of 24 months' fees for data protection claims | Unlimited liability, or any cap above 24 months' fees |
| Breach notification (DPA) | Without undue delay after becoming aware, as GDPR Article 33 puts it | A fixed 48 hours, if the security lead agrees | Less than 48 hours, or notice of incidents that are only suspected |
| Sub-processors (DPA) | General authorization, public list, 30 days' notice of changes with a right to object | The customer may end the affected service if an objection cannot be resolved | Prior written approval of every new sub-processor |
| Audits (DPA) | Third-party reports first: SOC 2 Type II, ISO 27001 | One on-site audit a year, on 30 days' notice, at the customer's cost | Unannounced audits, or audits carried out by a competitor |
| Confidentiality term (NDA) | Three years from disclosure; trade secrets for as long as they stay secret | Five years | Perpetual protection for everything, or a residuals clause favoring the other side |
| Governing law | German law, courts of Berlin | Another EU member state, or England and Wales | Any other law, or arbitration seated outside Europe |
One inbound DPA, from upload to markup
A prospect's procurement team sends its own 14-page DPA as a Word file. These are the calls behind the markup the legal counsel opens a few minutes later.
Deal desk request, Wednesday 10:12
- segment(file: "prospect_dpa_v3.docx")38 clauses, 2 annexes, 11 defined terms / cross-reference in 9.4 points to 'Annex 4', which does not exist
- governing_law()Dutch law, courts of Amsterdam / covered by the playbook's EU variant
- check_article_28(contract_type: "dpa")subject matter, duration, data and data subjects: Annex 1 / 7 of 8 processor terms found / missing: 28(3)(b), confidentiality commitment of staff
- review_clause(id: "7.2", topic: "breach_notification")"within 24 hours of any suspected incident" / BN-3: escalate / quote verified in 7.2
- review_clause(id: "8.3", topic: "audits")"on-site audit on 5 business days' notice" / AUD-2: fallback available / quote verified in 8.3
- review_clause(id: "11.1", topic: "liability")"liability for breaches of this DPA shall be unlimited" / LIA-3: escalate, no wording drafted
- mark_up(changes: ["8.3", "28(3)(b)"], source: "fallback_library")2 tracked changes and 5 comments, author 'Playbook review' / saved as a new version in SharePoint / the prospect's file untouched
- The legal counsel accepts the audit change and the added confidentiality clause, sends 7.2 and 11.1 to the general counsel with their comments, and fixes the broken annex reference by hand. Nothing has gone to the prospect yet.
The route from the other side's draft to tracked changes
The model reads and judges. Code does everything that has to be exact: the structure, the checklists, the quotes and the edits to the Word file.
01 Trigger · Microsoft Graph, CLM webhook
A contract arrives for review
From the deal desk, a legal inbox in Outlook, a SharePoint intake library or the CLM, with the counterparty, contract type and deal value, which decide who may approve a deviation.
02 Plain code · Open XML
Read the structure
The Word file's XML gives numbering, headings, defined terms and cross-references exactly. Scanned PDFs go through OCR and are treated as read-only. If the draft started as your own template, a plain diff shows what the other side changed, and for many NDAs that is most of the review.
04 AI model
Judge each clause against the positions
With the definitions it uses attached, each tagged clause is compared with the playbook. The model returns a position ID, a verdict and the exact sentence it relied on, in a fixed schema.
05 Plain code
Verify quotes, run the checklists
A finding whose quote does not appear verbatim in the document is discarded and logged. Required-term checklists, such as the eight processor terms in GDPR Article 28(3), are evaluated in code from the tags.
06 Decision
What each finding becomes
Decided by the playbook row, not by the model.
- The clause matches the preferred position then listed as fine, with its quote, for a fast skim
- A deviation with an approved fallback, or a missing required term then a tracked change from the approved wording, with a comment citing the position
- A walk-away position, or a governing law the playbook does not cover then a comment only, flagged for the general counsel
07 System · SharePoint or iManage API
Write the markup into Word
Tracked changes and comments go into a copy of the file under the author name 'Playbook review', so nobody mistakes them for a colleague's edits, and the copy is saved as a new version.
08 Person
The lawyer decides every point
In Word's normal review pane, the lawyer accepts, edits or rejects each change and resolves each comment. A rejection takes a one-click reason, which is how the playbook finds out where it is out of date.
09 Result
A record of the review
Findings, decisions and reasons are filed with the matter in Clio or on the CLM record, with every system action logged against it. A monthly report shows which positions are conceded most often.
Where clause-by-clause review goes wrong
A contract is not a list of independent paragraphs. These are the ways a naive reviewer misreads one, and what the build does instead.
A definition quietly changes a clause
A limitation of liability looks standard until you notice that 'Losses' is defined on page two to include lost profits, or that 'Confidential Information' covers everything disclosed, marked or not. The system resolves every defined term, sends its definition along with each clause, and cites both when a definition causes a flag.
Cross-references and precedence
'Subject to clause 14.3' and 'in case of conflict, this DPA prevails over the Agreement' change what a clause means. Cross-references are followed in code and the referred text is included; precedence clauses are read before anything else. Broken references are flagged, since customer templates are often stitched together from older ones.
Scanned and signed PDFs
A scan has no numbering structure and cannot take tracked changes, so the system reads it with OCR and produces an issues list with page references instead of a redline. For signed copies it compares the text with the last agreed Word version, which catches edits made after the negotiation was supposed to be over.
Governing law changes the answer
A liability cap that is routine under English law can be unenforceable in German standard business terms (AGB). The system reads the governing law clause first and applies the playbook variant for that law. If the law is one the playbook does not cover, every finding goes to the lawyer as a question rather than a verdict.
The lawyer's part and the software's part
The split follows one rule from the human-in-the-loop guide: software prepares, a person commits.
The AI model
Match clauses to playbook topics
The same obligation is drafted a hundred ways, so keyword rules miss most of them.
Judge each clause against the positions, with a quote
Reading legal language in context is the model's strength, and the quote makes its reasoning checkable.
Plain code
Split the contract into clauses, resolve definitions and cross-references
Word's own XML is exact; a model's guess at numbering is not.
Confirm the quote exists and run the required-term checklists
Whether a term is present is a fact, checked the same way every time.
Insert tracked changes and comments
Edits to the file are deterministic, and the wording comes only from the approved fallback library.
A person
Accept, edit or reject every flag
Legal judgment and negotiation strategy stay with the lawyer.
Approve a deviation beyond the fallback
Risk appetite belongs to the general counsel, not to software.
Send anything to the counterparty
The system has no permission to send at all.
Testing it on contracts you already signed
Before anyone relies on the flags, the system reviews contracts where the right answer is already known.
- Pull the first drafts and executed versions of 40 to 60 past DPAs and NDAs from SharePoint or the DMS.
- A lawyer marks where each first draft deviated from the playbook. That takes a day or two and becomes the answer key.
- The system reviews the same first drafts blind, and every miss is logged against the position it should have triggered.
- The gate is recall on escalation positions, because the expensive error is a walk-away clause marked acceptable. The system has to find every one of them in the back-test before it touches a live contract; extra flags are tolerated at first and tuned down later.
- Where the back-test shows that the written playbook differs from what the team actually signs, the playbook is corrected first.
- The answer key stays as the regression set that every change of prompt, model or playbook is run against.
Expect the back-test to find gaps in the written playbook as well as in the model. The same approach works for leases, where the answer key is a set of dates rather than positions: see lease abstraction.
Privilege, confidentiality and where the model runs
Contracts carry commercial terms, personal data and, at a firm, privileged material. The usual setup is an EU-region endpoint from a major model provider under a data processing agreement, with inputs neither retained nor used for training. Teams that want nothing to leave their own tenancy run the same pipeline against an open-weight model on EU infrastructure, behind a private AI gateway that logs every request.
The system reads documents through a service account limited to the legal workspace, and in iManage or NetDocuments it inherits matter security, so an ethical wall stays a wall. At a firm, the clause library it drafts from holds only the firm's own templates and positions, never another client's negotiated wording. German law firms must also bind any IT provider to confidentiality under § 43e BRAO.
For a cautious partner, the persuasive thing is rarely a vendor certificate. It is a per-matter log of every action the system took: what it read, what it flagged and proposed, and who accepted it. That log is built in from the first day.
Harvey, Spellbook or LegalOn, or a build around your own playbook?
For many legal teams the honest answer is to buy. LegalOn and Spellbook review contracts inside Word against playbooks you can customize, Harvey and Luminance also work in Word, and Ironclad and Juro have added AI review to their CLMs. If your contracts are mostly standard NDAs and customer DPAs, you already use one of those CLMs, and your security team accepts the vendor's hosting, a product will be working within weeks. I would tell you that on the call.
A build earns its place when the value sits where a product does not reach: a playbook with variants per governing law and customer tier, documents in iManage or NetDocuments behind ethical walls, a review record that must land in the Clio matter or the CLM, or a rule that contracts are processed only in your own tenancy. It also fits when review is one step in a longer flow, from the deal desk's request to the general counsel's approval.
The hybrid is common. Lawyers keep the drafting assistant they like, while the intake, the template diff, the playbook check and the audit trail are built around your systems and write their output as ordinary tracked changes, so the choice of Word add-in stops mattering.
How you would know it is working
A blueprint has no results to report, so here is what I would measure from the first week instead, on your own data.
- Recall on escalation positions
- Share of known walk-away clauses the system flags, measured on the back-test set and on a monthly sample of live contracts.
- Flag acceptance rate
- Share of flags the lawyer acts on. A low rate means noise the team will learn to ignore, so thresholds are tuned per topic.
- Time to first markup
- Hours from a contract arriving to the first markup going back to the counterparty, tracked by contract type.
- Most-conceded positions
- Which fallbacks and escalations are given up most often. A position conceded every time is a playbook row that needs rewriting.
What a build like this costs
This is built as AI Integration, which runs $3.5K - $45K overall. A build like this one usually lands in the retrieval over your documents, with evaluation tier: $15K - $35K, 3-6 weeks. The first working version runs on your real data well before the end of that window.
What it costs to run
Model costs are typically well under a few dollars per contract, even for a long MSA read clause by clause with its definitions attached. A private deployment swaps per-token fees for a fixed server cost, which suits firm scale or a policy against external providers.
What moves the price
- How many contract types there are and how detailed the playbook is: DPAs and NDAs are a smaller job than MSAs across three jurisdictions
- Where documents live: SharePoint through Microsoft Graph is simpler than iManage or NetDocuments with matter security
- Whether findings are written back as tracked changes in Word or delivered as an issues list
- Deployment: an EU-region API under a data processing agreement, or a private model on your own infrastructure
- The size of the back-test, which also costs lawyer time to annotate
Who this is for
- In-house legal teams of one to five lawyers at SaaS and tech companies, where customer DPAs and NDAs queue behind sales deadlines
- Law firms with written playbooks per client or practice area that want first-pass review inside iManage or NetDocuments
- Privacy and procurement teams checking supplier DPAs for the GDPR Article 28 terms before signature
- Legal teams that tried a general chatbot on contracts and could not trace its comments back to the text
Questions people ask about this
Can AI review contracts against our own playbook?
Yes, as a first pass. The system compares each clause with your preferred, fallback and unacceptable positions, quotes the text behind every flag, drafts tracked changes only from your approved wording and checks for missing clauses. It decides nothing: a lawyer accepts or rejects every point. How well it works on your contracts is measured by a back-test on contracts you have already signed.
Can AI check a DPA against GDPR Article 28?
Yes, and it is the most mechanical part of the review. Article 28(3) requires the subject matter, duration, nature and purpose of the processing, the types of data and categories of data subjects, and eight processor obligations, points (a) to (h). The model tags where each appears, code checks that all are present, and missing terms are inserted from your standard wording for a lawyer to confirm.
How do we get past confidentiality concerns about AI contract review?
By choosing the deployment for it and proving it with a log. Contracts go to an EU-region endpoint under a data processing agreement with no retention or training, or to a private model inside your own infrastructure. Access runs through your DMS permissions, ethical walls included, and every action the system takes is logged against the matter, so a partner can see exactly what it read and proposed.
Does it work in Microsoft Word with tracked changes?
Yes. Proposed wording is inserted as tracked changes under a distinct author name, with a comment on each citing the playbook position, so the lawyer works in Word's normal review pane. Scanned or signed PDFs cannot take tracked changes, so for those the system produces an issues list with page references instead.
How long does it take to set up AI contract review?
For one or two contract types, such as DPAs and NDAs, a few weeks of build, plus a day or two of a lawyer's time to write the playbook as data and annotate the back-test. Each further contract type adds its own playbook rows and test contracts. Most of the effort goes into the playbook and the back-test, not the model.
Sources