In the daily flurry of announcements about new and big AI initiatives, Kirkland & Ellis recently upped the ante by announcing that they were committing an eye-popping $500M of capital toward building their own AI platform. $500M is a dramatic number—I suspect it was deliberately chosen to catch the kind of attention it did. If you’re reading this, you almost certainly can’t build a $500M AI platform (and if you can, please call me!). But to put things in perspective, $500M is less than 5% of K&E’s annual revenue, which crossed $10 billion last year. For most firms, this would be an existential bet. For Kirkland, it’s a rounding error.
But here’s the thing: whether you could write that check or not, the size of the investment isn’t the hard part. The hard part is that K&E has to answer the same questions you do. And the $500M doesn’t buy you out of any of them.
Five questions you can’t buy your way out of
Before any firm deploys AI—whether they’re spending $500M or $50K—there are five conditions that need to be true for the deployment to work. I call them SAFER.
S–Structured data
Most law firms that want to deploy AI have decades of emails, memos, contracts, and briefs—mountains of unstructured text that no AI system can usefully learn from without serious preparation. AI needs structured data that is accurate, consistently formatted, and properly organized.
What does structured legal data look like?
| Data type | Example columns |
|---|---|
| Litigation history | Case type, judge ID, jurisdiction, damages amount, disposition, duration |
| Billing records | UTBMS code, hours billed, hourly rate, matter type, attorney seniority |
| Contract metadata | Contract type, governing law, effective date, indemnification cap, renewal term |
| Docket and scheduling | Matter ID, filing type, court deadline, assigned paralegal, statutory window |
You probably have most of this data already. The problem is that it’s fragmented; it could be a spreadsheet on someone’s Google Drive, a folder on an associate’s laptop, a SharePoint site that three people know about. Getting it into a single, clean AI-ready form means solving six specific problems:
| Structuring requirement | What it means in practice |
|---|---|
| Granular matter categorization | Cases labeled by sub-practice area, jurisdiction, and judge, not just “litigation” |
| Temporal consistency | Filing dates, deadlines, and closing dates follow one standardized format |
| Clean billing codes | Time-entry descriptions actually match LEDES or UTBMS codes |
| Anonymized, compliant text | Confidential client data scrubbed or tokenized without destroying semantic meaning |
| Normalized entity names | “Judge Smith,” “Hon. J. Smith,” and “Smith, J.” all resolve to the same person |
| Complete metadata | Every document carries author, document type, effective date; no blank fields |
None of this is glamorous work. But it’s the foundation everything else sits on, and no amount of money makes it go faster than the painstaking process of actually doing it.
No amount of money makes data structuring go faster than the painstaking process of actually doing it.
A–Auditability
In software development, you can verify AI-generated code by running it. The compiler doesn’t care who—or what—wrote it. Legal work has no equivalent. There’s no compiler for a brief, no test suite for contract analysis, no automated check that tells you a case citation is valid, relevant, and applied correctly. (I’ve written about this structural gap before , and it’s a problem I’ll return to.)
This makes auditability non-negotiable. If your AI system produces an output and you can’t reconstruct exactly how it got there—what sources it drew on, what it ignored, what intermediate steps it took—you have a liability and not a tool.
Auditability means the system is transparent enough to examine, traceable enough to follow, and protected enough that nobody can quietly alter the trail. In practice,
| Auditability requirement | What it means in practice |
|---|---|
| Traceability | Every output links to its original sources, prompts, and intermediate reasoning steps, not just a final answer |
| Data integrity | Records are tamper-resistant and protected from unauthorized changes, so the audit trail itself can be trusted |
| Contextual completeness | The system logs what it didn’t use as well as what it did; a memo that omits a controlling case is wrong even if everything it includes is correct |
| Accessibility | Audit records are usable by the people who actually need them (partners, compliance, malpractice counsel) not buried in system logs only an engineer can read |
The system needs to be both technically and practically auditable. That is, it needs to be auditable by the partners and associates, not just Chad from IT. If a client or disciplinary board asks how your firm reached a conclusion, “our vendor assures us the model is explainable” is not an answer.
F–Feedback loops
AI systems don’t improve by themselves. They improve when they receive structured feedback (corrections, approvals, rejections) that get fed back into the system such that it can learn from them. In software engineering, this loop is practically free. A user hits a bug, files a ticket, the model gets retrained. Automated telemetry captures what works and what doesn’t without anyone lifting a finger.
Legal practice has no natural version of this loop. An associate catches a hallucinated citation, fixes it, and moves on. A partner rewrites an AI-drafted clause and never tells the system why. The correction happens, but it dies in someone’s inbox or in their head. As a result, the AI makes the same mistake the next day for someone else.
A real feedback loop requires three things:
| Feedback requirement | What it means in practice |
|---|---|
| Capture | Every human correction, like edits, rejections, overrides, is logged in structured form, not just made and forgotten |
| Closure | The loop is closed by ensuring that corrections actually reach the system. If an attorney flags a bad output and nothing changes downstream, that’s just a complaint and not feedback |
| Human-in-the-loop design | The system is built so that expert judgment is the feedback mechanism, not an afterthought bolted on for compliance |
The third row is where most legal AI deployments will quietly fail. Vendors love the phrase “human in the loop.” But there’s a difference between a human who is structurally integrated into the system’s learning cycle and a human who is handed an output and asked to click “approve.” The human needs to be part of the system, making it improve over time, and not just a liability shield with a pulse.
The challenge here is that good feedback loops in legal are expensive. Every correction requires someone with enough expertise to know why the output is wrong, not just that it is. And that expertise might bill at partner rates. Firms that don’t budget for this, or don’t incorporate it into the system architecture, will end up with AI that never gets better, which means the efficiency gains they were promised flatline a few months after deployment.
E–Exposure mapping
Here’s a question you might not be asking: when—not if—this system gets something wrong, what exactly is at risk?
This is not a hypothetical meant to scare you out of deploying AI. It’s an engineering question. Every system fails eventually. AI systems, regardless of how sophisticated they are, are still probabilistic systems, meaning they will make mistakes. The firms that deploy well are those that have mapped their failure modes in advance rather than discovering them in a malpractice claim.
Exposure mapping means identifying, for each use case, what goes wrong, who gets hurt, and what it costs. A document summarization tool that misses a key clause in a merger agreement is a different category of exposure than a research tool that surfaces an outdated regulation. Both are errors; one is embarrassing; the other might be a nine-figure liability.
| Exposure dimension | The question you need to answer |
|---|---|
| Error severity | Does a failure cause inconvenience, financial loss, or irreversible harm? A bad first draft of a client memo is recoverable. A missed filing deadline is not. |
| Blast radius | Does the error affect one matter, one client, or every matter that touched the system this quarter? |
| Regulatory exposure | Which rules apply? E.g., attorney competence under Rule 1.1, confidentiality under Rule 1.6, supervisory obligations under Rules 5.1 and 5.3. The answer changes depending on the use case. |
| Privilege risk | Could the deployment itself compromise attorney-client privilege? If client data flows through a third-party model, you may have already answered this question the wrong way. |
| Detectability | How long does it take to discover the error? A hallucinated citation might get caught in review. A subtly wrong contract interpretation might not surface until litigation years later. |
Exposure mapping involves understanding the potential damage of every failure mode, how bad it can get, and how long it will take to discover the error. An AI system that produces errors you catch quickly is manageable. One that produces errors you discover during discovery could be a catastrophe.
The practical step here is unglamorous but necessary: before you deploy AI to any workflow, write down what the worst realistic failure looks like. (Not the worst imaginable failure—that’s a thought exercise for conferences.) Then ask whether your firm can survive it, and whether your malpractice insurer knows you’re taking the risk.
R–Repeatability
I know it might shock you to hear this, but AI is not magic. It’s pattern matching at scale. Which means it’s only as good as the patterns you give it, and only worth deploying where those patterns show up often enough to justify the cost.
Repeatability involves two questions.
The first is pattern density: does the task contain recognizable, recurring structures that a model can learn from? Contract review has high pattern density. NDAs, indemnification clauses, and change-of-control provisions follow predictable shapes across thousands of documents. Litigation strategy has low pattern density. The variables are too numerous, too context-dependent, and too entangled with human judgment to compress into learnable patterns.
There’s a related point worth flagging: the same logic that separates high-density from low-density tasks also suggests that one general-purpose AI platform is probably the wrong tool for most of them. A model trained or fine-tuned for contract analysis and a model built for regulatory screening are solving different problems with different patterns. I’ve written more about this before and will revisit it later. The short version is that starting from the task and working backward to the tool tends to produce better results than starting from the platform and looking for places to use it.
The second aspect of repeatability is task frequency: does it happen often enough? An AI system that saves 20 minutes on a task your firm performs three times a year has saved you one hour. An AI system that saves 2 minutes on a task performed 500 times a day has saved you 16 hours—every day. The math isn’t complicated, but it’s easy to skip it.
| Repeatability factor | High (strong case for AI) | Low (weak case for AI) |
|---|---|---|
| Pattern density | Contract review, document classification, billing code assignment, regulatory screening | Novel litigation strategy, bespoke deal structuring, judicial temperament assessment |
| Task frequency | Due diligence across hundreds of documents, daily intake screening, standard clause extraction | One-off expert opinions, annual regulatory filings, unique cross-border transactions |
The sweet spot is the upper left corner: high pattern density and high frequency, where AI earns its keep. The lower-right corner—low density, low frequency—is where firms burn money building solutions nobody uses twice.
Most legal vendors will not help you make this distinction. Their incentive is to sell you the platform, not to tell you that half your planned use cases don’t have the pattern density to work. That’s your job.
SAFER gives you a framework to evaluate whether your firm is ready to deploy AI. But readiness is only the first question. The harder ones come after: what the system touches, who is accountable when the system fails, what governance structure surrounds it, and whether the economics of verifying AI output deliver the efficiency gains everyone keeps promising. The answer to that last question is less comfortable than most vendors would like you to believe. I’ll get to that next.