Are We Expecting Too Much of Our CLMs?

Having worked with engineers for most of my career, I think they've started to rub off on me — especially now that AI is empowering everyone to become builders. I've always admired how engineers go after a problem statement without inhibition. How they turn seemingly complex processes into clicks and dashboards is nothing short of magic, and while the rest of us are essentially catching up with them, they just build. They build without fear of what might break.

Lawyers are trained from the other end of the spectrum. Risk sits at the forefront of every **solution** we think of. Perhaps that's the reason why most legal tech also focuses on exactly that — risk. Whether it's a tool meant to augment research, e-discovery, or day-to-day contract volume, the focus is squarely on risk mitigation: tools that visualize the organization's risk appetite in neat data stacks so we can make seemingly more informed decisions, dashboards that watch for unhealthy patterns needing attention, reports designed to reassure us that nothing is slipping. And honestly, that's the right focus. Legal tech should focus on legal risk.

But after spending more than a decade with engineers, and more recently at a flourishing tech startup, I wonder if there are simpler tech solutions — or at least a builder's mindset — that could help me manage the risk in my day-to-day operations instead. The risk of a missed deadline. A conversation lost in an email or chat thread. No real visibility into a team's bandwidth — is one person carrying the load while another goes underused? Even with all the swanky tools at our disposal, we're still asked the same questions. Why does sending something to legal feel like a black hole? What's our actual turnaround time on requests? Is the team responsive? Is it actually delivering against the process we said we'd follow? And what about the legacy data — how many times have we reorganized it, and it's still tedious to trace the one document we need when we need it?

As in-house counsel, we're constantly playing catch-up with what the business needs. That's not a flaw in the team — it's structural. The business cannot stop to ask legal's permission before it ships, prices, hires, or partners, nor should it. It's in the natural order of things that legal joins the conversation last. However, to be true business partners, we need to find more advanced ways not just to keep up with business so that we don't become blockers at the 11th hour, but more importantly, to help drive decisions.

Ask a legal tech vendor for a **solution** and the answer is always the same: onboard your team onto our platform, and all your problems will be over. To be fair, the platform delivers what it promises. It tracks the right metrics to answer these questions — how long a request sat in each status, recurring reports on upcoming deadlines like opt-outs and renewals, and increasingly, conversational AI so you can “talk to your contracts” too. But even with all of that, we're still answering the same fundamental questions every single morning. Who's working on what? Is anything at risk of slipping through the cracks? Is something happening in the business right now that I should be interjecting on, before it becomes a legal problem instead of a business decision?

So isn't it time to look at these problems simply as operational issues, and not “legal ops” issues?

That small shift in lingo has helped me get past a wall we tend to build around legal operations — the wall that separates us from the rest of the organization because we're the risk function, and because being the risk function convinces us we need to operate and think differently about our operational issues.

What if the legal function opened itself instead to tech that simply solves for operations? What's coming in, what's the SLA, who was it assigned to, are there recurring questions with repeatable answers that could be automated, are there processes with predictable, repeatable tasks that don't need a human touch every time? Whether you're experimenting with foundation models, building agents, or finding other ways to automate your processes — once you start looking for simple tech solutions (not even AI particularly), we may open ourselves to opportunities we didn't even know existed. Every legal team already has the raw material an engineer would kill for — years of the same requests, the same bottlenecks, the same questions asked every Monday morning. An engineer would call that a training set. We've been calling it a burden. The shift isn't asking legal to become more technical — it's asking us to notice that the problems before us are just the training set we need to build systems the way we'd like them to be.