In May, Anthropic reported that legal professionals have become the most engaged Claude Cowork users of any knowledge-work function. That matches what I see inside firms. Associates are building intake tools. Knowledge lawyers are building research workflows. A few partners have built trackers for their own matters. Most of it happened without a ticket to IT.
I don't read that as a governance failure. Lawyers had a problem, the tools let them solve it, and they solved it. The CIO's question now is practical: what exists, what does it touch, and which of it should the firm support? I wrote earlier about how IT and the business can build a law firm's agentic strategy together, including the isolated environment where business-side building should happen. This piece is about what comes after that: the software lawyers have already built, and the software they'll keep building.
Start by finding out what already exists
You can't govern what you can't see, so the first step is an inventory. It works best when nobody is punished for what they declare. Ask practice groups and knowledge teams a short set of questions: what did you build, what does it do, what data does it read, where does it run, and who else uses it?
The answers usually fall into a few groups. Some tools are personal, like a lawyer's own checklist generator that nobody else touches. Some are shared inside a team and have quietly become part of how that team works. A small number are reading client documents in places IT would never have approved. That last group is where to start, and the conversation goes better when the builder hears "we want to keep this working" before anything else.
Give builders a sanctioned place to work
Lawyers will build wherever it's easiest. If the approved path is harder than a personal subscription, they'll use the personal subscription. The sanctioned environment has to be the easy option: firm identities already wired in, approved data sources already connected, and a published list of what an agent in that environment can and can't reach.
That environment also settles the question IT cares about most, which is whose permissions a tool carries. When a lawyer's tool runs under the lawyer's own identity, it sees exactly what that lawyer is allowed to see, ethical walls included. A tool built on a shared service account sees everything the account sees, and that's how a wall gets crossed by accident.
Sort tools into tiers with different gates
If every lawyer-built tool is treated like an enterprise application, the building stops. If none of them are, client data eventually ends up somewhere it shouldn't be. Tiers let the firm apply the right amount of control to each tool.
- Personal. One user, no data beyond what that user can already open, runs only in the sanctioned environment. It gets a light registration and no review.
- Team. Shared inside a practice group. It needs a named owner, a short description of the data it reads, and a basic test the owner runs before a change goes out.
- Firm. Used across groups, or used on client matters in ways that shape advice. It goes through IT's review and evaluation gates, gets monitored, and has a support path.
The tier decides the gate, and a tool moves up when the way people use it changes. Most tools will stay personal forever, and that's fine.
Every shared tool needs an owner and a review date
Software built by a lawyer has a weakness ordinary software doesn't: the builder has a full-time job doing something else. When they change groups or leave the firm, the tool stays behind and nobody understands it. Every team or firm tool should have a named owner, a backup owner and a review date. At each review, the owner renews it, hands it to IT, or retires it.
A plain-language description should live next to the tool and say what it does, what it reads and what it writes. The agents that help lawyers build and maintain these tools rely on those descriptions too. A tool with a clear description is one the next person, or the next agent, can change safely.
Make graduation worth it for the builder
The best lawyer-built tools should become firm tools, and their builders should want that to happen. When IT takes a tool into the firm tier, the builder gets support, monitoring, and access to data sources they couldn't reach on their own. The firm gets a tool it already knows lawyers use, which is a better starting point than most software it buys.
Firms should also think about how this work gets recognized. A tool the firm adopts took real time from a lawyer who could have been billing. Counting it the way the firm counts a strong precedent memo or a practice guide sends the right signal: building inside the governed path is how a lawyer's work gets noticed.
Connect every tool to the firm's knowledge the same way
Most lawyer-built tools need the same raw material, which is the firm's own documents and matters. If every tool builds its own connection to the document management system, the firm ends up with dozens of copies of client data, each with its own idea of who is allowed to see what. One governed source of firm knowledge, which every tool queries under the user's identity, keeps permissions in one place and keeps each tool small.
That source has to get the basics right. Every document is tied to its client and matter. Walls are enforced at the moment a question is asked. Answers cite the document they came from, so a lawyer can check a tool's work before relying on it.
What this asks of IT
IT's role moves from building every application to running the platform lawyers build on: identities, data access, environments, review gates and monitoring. It's a bigger job than the one most IT departments were staffed for, and it's the job that decides whether a firm's AI program scales. The firms that do it well will have more useful software than their IT headcount could produce alone, all of it running inside controls IT designed.
At Reframe, this is the layer we build with firms. We stand up a governed model of the firm's matters, clients and documents in the firm's own cloud, and the tools lawyers build query it under each person's own permissions. Every request passes the same policy checks and ethical walls, every answer cites its source, and anything an agent wants to change arrives as a proposal a person approves.
If you're a CIO, start with the inventory this month. One honest list of what your lawyers have built will tell you more about what they need than any survey.
Drafted with Reframe Editorial Agent, an AI employee at Reframe. 