The Liability Cap Nobody Caught in Clause 14

Row 17 of the red-flag report

Row 17 of the spreadsheet reads: "Customer MSA, cl. 14.1 read with cl. 1.1. Liability for Excluded Claims uncapped. Excluded Claims include any breach of cl. 9 (Data Protection). Risk: high."

Nora reads it twice. She is general counsel of a 250-person software company in Hamburg that sells route planning to logistics groups, and this is the red-flag report from the lawyers of the investor leading its next funding round, one row per material contract. Row 17 is a contract she signed off herself, fourteen months ago, in the last week of a quarter.

She opens the signed PDF. Clause 14.1 is exactly as she remembers it: each party's total liability capped at the fees paid in the twelve months before the claim, which is the first line of her own playbook. It begins with four words she read as boilerplate: "Except for Excluded Claims". The definition is on page two, the eleventh of forty defined terms, three lines long. Its second item is any breach of clause 9, the data protection clause. For claims about the drivers' location data the platform processes every day, the cap in clause 14 does not exist.

Nobody has claimed anything. But the investor's lawyers want the row explained, and Nora has to explain a position she would have refused in ten seconds if anyone had put the two sentences side by side.

"Any news on the DPA?"

None of these people exist, and the company is a composite. Clause 14 is the part I would not change: a cap that looks right, switched off by a definition nobody reread.

The legal team is Nora and one legal counsel, Malte. About sixty contracts cross their desks a month, mostly customer DPAs and NDAs, the rest MSAs, order forms and supplier agreements. Enterprise customers insist on their own paper, and every contract is urgent to someone. Henrik on the deal desk sends the same message most afternoons: "Any news on the DPA? They want to sign this week."

The review is repetitive in a particular way. Nora and Malte know their 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. In the last week of a quarter, the second of those is the one that goes.

Nora has already tried the obvious fix. A general chat assistant gave comments that sounded right, but none said which sentence it rested on, so Malte checked each one against the contract from scratch. A review that cannot be traced to the text saves a lawyer no time.

A Word file called Positions

On our first video call I ask Nora for three documents: her playbook, the customer's original Word draft of the row 17 contract, and a DPA Malte reviewed last month. The playbook is a four-page Word file called Positions, last edited two years ago. It says what the team prefers, with no fallback wording, no IDs and nothing about who may approve what.

What surprises me is how much of the team's real practice is not in it. Malte has a standard audit compromise, one on-site audit a year on 30 days' notice at the customer's cost, and it lives in his sent folder.

So the first piece of the build is not a model. It is two afternoons with Nora and Malte turning Positions and the sent folder into rows: one row per position, each with an ID the system cites in every comment. For liability, LIA-1 is the preferred mutual cap at twelve months' fees, LIA-2 the approved fallback of a separate cap of 24 months' fees for data protection claims, and LIA-3 is escalation: unlimited liability, or any cap above 24 months' fees. Governing law gets variants, because a cap that is routine under English law can be unenforceable in German standard business terms. Under a law the playbook does not cover, every finding becomes a question.

Before we go further, I tell Nora what the system will not do. It will not send anything; it has no permission to. It will not write wording of its own: the fallback column is the only text it may propose, and where a position has no fallback it comments and drafts nothing. And it will not decide. Every flag waits for Malte or Nora, and the playbook belongs to Nora.

Clause 14, read with page two

The second piece is also code. A Word file's own XML gives the numbering, headings, defined terms and cross-references exactly. Since a definition is how clause 14 got through, definitions are resolved first, and every clause travels with the definitions it uses.

Then the model does the two things it is good at. It matches clauses to playbook topics by retrieval with a reranker, because the same obligation is drafted a hundred ways. And it judges each tagged clause against the positions, returning a position ID, a verdict and the exact sentence it relied on. Code checks that the sentence appears verbatim in the document; a finding whose quote does not exist is discarded and logged. For DPAs, the processor terms of GDPR Article 28(3) are a checklist in code, so a missing confidentiality commitment for staff is a fact rather than an opinion.

The first real test is the row 17 contract as the customer sent it. On my screen share from Pristina, the copy opens in Word marked up under an author called Playbook review, so nobody mistakes it for a colleague's edits. Beside clause 14.1 is one comment, with both quotes confirmed by code:

LIA-3, escalate to the general counsel. Clause 14.1: "Except for Excluded Claims, each party's total liability under this Agreement shall not exceed the fees paid in the twelve (12) months preceding the claim." Clause 1.1, page 2: "Excluded Claims" includes "any breach of Clause 9 (Data Protection)". Read together, liability for data protection claims is unlimited. No wording drafted: escalation positions get a comment only. Approved fallback on this topic: LIA-2.

Nora scrolls up to page two and back down. "That's the page," she says. "Nobody turns back to page two in the last week of a quarter." The rest of the draft gets one tracked change, to the audit clause from Malte's compromise, now row AUD-2, and the matching clauses are listed with their quotes for a fast skim. The whole route from the other side's draft to tracked changes is in the blueprint for contract review against your own playbook.

Forty-eight contracts with known answers

One good comment on a contract we already know about proves nothing. Malte pulls the first drafts and signed versions of 48 past DPAs, NDAs and MSAs from SharePoint and marks, over a day and a half, where each first draft left the playbook. That is the answer key, and the system reviews the same drafts blind. The gate is recall on escalation positions: every walk-away clause in the key has to be found before go-live. Extra flags are tolerated at first and tuned down later, since a reviewer that flags everything teaches Malte to skim.

The first run misses one, and the miss is mine. One customer's DPA says in clause 12 that the Agreement's limitations of liability do not apply to claims under the DPA, and in clause 1 that the DPA prevails in case of conflict. I had scoped the liability rows to MSAs, because that is where Positions put them, so the tagger never offered a liability position for a DPA clause, and that customer's MSA cap was listed as fine. Two rules come out of it. Topics apply to every contract type, and the type only decides which checklists run. And precedence clauses are read first: when a DPA prevails over its MSA, the two are reviewed as a pair.

The back-test also finds a gap in the playbook itself. It allows a fixed 48-hour breach notice only if the security lead agrees. In the signed DPAs, 48 hours is everywhere, and the security lead saw few of them. Nora corrects the playbook before anyone touches the model: 48 hours becomes a fallback Malte may agree to alone, and anything shorter, or notice of merely suspected incidents, still escalates to her. The answer key stays as the regression set for every change of prompt, model or playbook, as in the LLM evaluation guide.

Malte clicks, Nora signs off

The markup lands where the team already works. Malte goes through Word's review pane as he would with a colleague's edits: accept, edit or reject each tracked change, resolve each comment. A rejection takes a one-click reason, such as "conceded for this deal", which is how the playbook learns where it no longer matches practice.

• Deviations beyond the fallback go to Nora. Risk appetite belongs to the general counsel, so an escalation comment is addressed to her, not to the deal desk.
• The system sends nothing. It saves a new version in SharePoint through Microsoft Graph and leaves the customer's file untouched. Malte sends the markup from his own Outlook when he decides it is ready.
• The record stays with the contract. Findings, decisions and reasons are filed with it, every system action is logged, and a monthly report shows the most-conceded positions: one given up every time is a row that needs rewriting.

The contracts carry commercial terms and personal data, and Nora's security team asks what her customers ask them. The usual setup is an EU-region model endpoint under a data processing agreement, with inputs neither retained nor used for training. If nothing may leave the company's tenancy, the same pipeline runs on an open-weight model behind a private AI gateway that logs every request.

The last week of the next quarter

Henrik still sends his message most afternoons. What changes is the answer. A customer DPA that reaches the intake library in the morning has a marked-up copy waiting when Malte opens it: matching clauses listed with their quotes, fallbacks drafted as tracked changes, and the two or three points that need a decision on top. Malte's time goes into those points, and he can tell Henrik which of them are with Nora instead of saying it is in the queue.

Row 17 stays in the red-flag report. That contract is signed, and fixing it is a conversation with the customer at renewal. But the next draft that defines Excluded Claims wider than it looks reaches Nora before signature, as a comment beside clause 14 with page two quoted under it. The last week of a quarter still brings the most contracts. It no longer brings definitions nobody reread.

Price the products before a build

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 DPAs and your security team accepts the vendor's hosting, a product will be working within weeks.

A build earns its place where a product does not reach: playbook variants per governing law and customer tier, a rule that contracts are processed only in your own tenancy, or review as one step in a longer flow from the deal desk's request to the general counsel's approval. For one or two contract types it usually fits the retrieval-with-evaluation tier of AI integration, plus a day or two of a lawyer's time for the playbook rows and the answer key. The full blueprint has the flow, the failure modes and the back-test, and the same method works for leases, where the answer key is a set of dates rather than positions: see lease abstraction.

Frequently asked questions