You hit 'Generate Contract' and get a 12-page document back in 47 seconds. It reads like English. It has clause headings, definitions, term lengths. But when a lawyer reviews it—especially one who regularly handles disputes—they flag problems a human drafter would never write. The gaps aren't typos. They're systemic blindnesses that cost companies tens of thousands when a dispute erupts. Large language models optimize for plausibility and structure. They don't optimize for your liability exposure, your regulatory jurisdiction, or what happens when the contract fails. This post walks through seven gaps lawyers spot first, why LLMs create them, and a lawyer's audit template you can use before a contract ever reaches a signatory. 1. Liability Caps That Leave You Exposed to Unlimited Damages The most common gap: the contract caps liability but doesn't exclude categories. A typical AI-drafted clause reads: "Neither party's total liability shall exceed the fees paid in the preceding 12 months." This sounds protective. It isn't. It caps direct damages but says nothing about indirect damages, consequential damages, lost profits, reputational harm, or regulatory fines. When a breach occurs and your client's system goes down for six hours, their lost revenue claim can balloon to $500K. Your cap is worthless because it never explicitly excluded those categories. A lawyer drafts: "Neither party shall be liable for indirect, incidental, consequential, special, or punitive damages, including loss of profits, revenue, business opportunity, or data, even if advised of the possibility of such damages. Total direct liability shall not exceed fees paid in the preceding 12 months, except for claims arising from gross negligence or willful misconduct." The difference: explicit category exclusion, carve-out for gross negligence (which courts recognize as reasonable), and alignment with industry standard language courts have already interpreted. Why LLMs miss this: They train on language patterns, not legal risk. The cap looks complete to a statistical model. It passes a syntax check. But it omits the linguistic specificity that courts require to enforce an exclusion. 2. Indemnification Duties That Flip Your Risk Upside Down Indemnification is where one party agrees to cover the other's legal costs and damages if a third party sues. It's a deceptively simple concept that LLMs routinely botch because the logic is counterintuitive. A flawed AI clause: "Each party shall indemnify the other against claims arising from its breach of this Agreement." Sounds balanced. But here's the trap: "arising from its breach" is vague. If your vendor's software infringes a patent, does that "arise from" your use of it, or their creation of it? An LLM treats these as equally likely. A lawyer knows the answer depends on negligence, knowledge, and statutory liability—categories the clause never defines. A competent clause specifies: "[Vendor] shall indemnify [Client] against third-party claims that [Vendor]'s deliverables, as provided, infringe intellectual property rights. [Vendor]'s obligation excludes claims arising from Client's modification, combination with third-party products, or use beyond the scope of this Agreement." This defines the scope (IP infringement, not all claims), trigger (deliverables as provided), and exclusions (modifications, misuse). An LLM omits these distinctions because they require domain knowledge of statutory IP law. Why LLMs miss this: Indemnification relies on understanding causation in a legal context. LLMs generate plausible grammar around "indemnify," but not the precision necessary to limit your exposure to the risk you actually agreed to cover. 3. IP Ownership That Defaults to the Vendor, Not You When a contractor or vendor creates custom work—software, designs, documentation—who owns the intellectual property? This question can be worth hundreds of thousands of dollars, and LLMs get it wrong systematically. Default LLM output: "The Vendor retains ownership of all work product, tools, and methodologies developed during the engagement. The Client receives a perpetual, non-exclusive license to use the deliverables." This is vendor-favorable. You pay for custom software but don't own it. The vendor can reuse it, sell it to competitors, or revoke the license if the relationship sours. If you need to modify the code post-engagement, you're locked in—you can't hire another developer to do it because you don't own the source. What a lawyer writes for a client commissioning work: "Client shall own all work product, including code, designs, documentation, and data, created specifically for Client under this Agreement. Vendor retains ownership of pre-existing tools, templates, and methodologies, and grants Client a perpetual, royalty-free license to use them as incorporated in the deliverables. Any custom modifications Vendor makes to pre-existing tools become Client property." Key differences: specificity (code, designs,