AI for in-house counsel, from someone who has built for them

Why in-house work needs a different kind of system

The in-house teams I've built systems for face a structurally different problem than the law firms I work with. A firm lawyer's bottleneck is usually the depth of work on a smaller number of matters. An in-house lawyer, especially at a company without a large legal department, is drowning in volume: a constant stream of contracts to review, policy questions from business teams, and requests that range from genuinely important to someone forwarding an email because they don't know who else to ask.

That means the highest-leverage AI system for in-house counsel almost never looks like a drafting tool. It looks like a triage and routing system: something that reads incoming requests and contracts, sorts them by actual risk and urgency, and either handles the low-risk ones directly or surfaces the right context so you can handle the high-risk ones faster. The goal isn't to make you write faster, it's to stop you from spending your attention on the wrong seventy percent of what lands in your inbox.

The contract review triage system I build most often

For an in-house team, this is usually the first and highest-impact build. The idea is simple: every incoming contract, whether it's a vendor agreement, an NDA, or a customer contract, gets run against a defined set of your company's standard positions before it ever reaches your desk in full.

1. 1. Define your standard positions as a checkable reference set

   Your acceptable limitation of liability ranges, your required indemnification language, your non-negotiable data handling terms. This has to be written down explicitly; it's usually living only in your head before this project starts.

2. 2. Build the triage module to flag deviations, not approve contracts

   The system's job is to say 'this clause deviates from your standard position, here's how' with a direct citation to the specific clause and the specific standard it deviates from. It never approves anything outright; it surfaces what needs your judgment.

3. 3. Route by severity

   A contract with only minor, pre-approved deviations can go back to the business team with a short standard note, maybe without your direct review at all if your risk tolerance allows it. A contract with a flagged deviation on liability or indemnification comes straight to you, with the deviation already highlighted.

4. 4. Keep a visible log of what the system routed and how

   This matters both for catching systemic problems (are the same clauses getting flagged over and over, meaning your standard terms need updating) and for being able to show, if ever questioned, exactly how a given contract was handled.

Getting business stakeholders to actually trust the system

This is the part of in-house AI adoption that's genuinely harder than the technical build, and it's mostly a political and trust problem rather than an engineering one. Sales teams, procurement teams, and other business stakeholders have to route contracts through this system willingly, and they will not do that if it feels like a black box that occasionally produces confusing legal jargon back at them.

What worked, in a system I built for an in-house team at a mid-size company, was making the routed feedback plain-language first and legal-precise second: a short, clear explanation of what deviated and why it matters to the business, with the precise legal language available if someone wants to dig in. Business stakeholders trusted a system that talked to them like colleagues far faster than one that talked to them like a legal memo.

The other trust-builder was transparency about the system's limits. I told the business teams explicitly, upfront, what the system does and doesn't catch, and where a human legal review is still required regardless of what the triage says. Overselling the system's capability to non-lawyers is how you end up with a business team relying on it for something it was never built to handle.

Evidence anchoring looks a little different in-house

The anchoring discipline I use everywhere else applies here too, but the source material is different. Instead of case law or outside precedent, an in-house system needs to be anchored against your company's actual internal policies, prior negotiated positions, and board-approved risk tolerances, all of which tend to be scattered across old emails, a policy wiki nobody updates, and institutional memory in the current general counsel's head.

Part of building this system well, for almost every in-house team I've worked with, is a first project that's less glamorous than the AI part: actually consolidating your standard positions into a single, current, checkable reference document. Without that, there's nothing solid for the system to anchor against, no matter how good the underlying model is.

Where to expand once contract triage is working

Once contract triage is running and trusted, the natural next step for most in-house teams is a policy question router: a system that handles the constant stream of 'can we do X' questions from business teams by checking against your actual internal policies and either answering directly for clear-cut cases or routing to you for anything ambiguous, again always with a source citation attached.

The instinct after that is often to reach for something more ambitious, litigation strategy support, complex regulatory analysis, but I'd caution against moving there too fast. The volume-and-triage problems are where in-house counsel gets the most relief the fastest, and the trust you build solving those well is what makes the more ambitious builds land credibly later.