Many law firms are starting a data lake project as the first step of their AI strategy. It's a reasonable instinct. AI needs data, a lake promises to put all of it in one place, and the CIOs leading these programs are asking the right question: what does AI need from our data? For most firms, I think the answer points somewhere else, and a firm should understand why before it commits two years and a large budget to the lake.
What a data lake is built for
A data lake is very good at a specific job. It stores data in columns, which makes it fast and inexpensive to sum or average one field across billions of rows. It keeps raw data before anyone has decided what it means. It feeds the tools analysts already use, like SQL and Power BI, and the pipelines that train machine learning models. Where data is enormous, raw and mostly structured, such as card transactions, website clickstreams or sensor telemetry, a lake earns its cost.
A law firm's data looks different
A firm's structured data is small by those standards. A firm with a thousand timekeepers creates a few million time entries a year, and its billing, client and matter records are smaller still. Any modern database handles that comfortably.
The knowledge that makes a firm valuable is unstructured. It lives in documents, email, precedent and matter history, and its value depends on context. Which client is this for? Which matter? Who is allowed to see it, and which ethical walls apply? Which version of the agreement controls? Every firm already knows more than any one person in it, and almost none of that knowledge fits in a column.
What agents need from the firm's data
When an agent works on a matter, the questions that decide the quality of its work are all about context. What does this record mean? How does it relate to the client, the matter and the parties? Who is allowed to see it? Is it still current? Where did it come from?
A copy into a lake loses much of that the day it's made. Permissions stay behind in the source systems, including the document security the firm has spent years building in iManage. Relationships flatten into columns. The copy starts drifting from the systems lawyers actually work in. Before an agent can use that copy safely, the firm has to rebuild the context it stripped out, and that rebuild is the longest part of most lake programs. The firm's AI strategy waits for it.
History is no reason to start with a lake
A common argument for the lake is history: the firm needs a record of how its data changed over time. A graph keeps history too, and it keeps it with its context. Reframe records what a fact was, when it changed and how it related to everything else at that moment, and it can restore the graph to any point in time. The firm gets its history without giving up meaning or permissions to get it.
A living ontology is the better starting point
Reframe is the first of its kind living ontology system. The firm defines its ontology with its own lawyers and knowledge teams: its clients, matters, parties, documents, provisions and obligations, and how they relate. Reframe then brings the firm's knowledge to life as a live graph shaped by that ontology, drawn from the systems where the work already happens, such as iManage, Microsoft 365 and SharePoint.
Every fact keeps its source. The document security the firm already maintains in iManage comes with the documents, and ethical walls and access rules are enforced on every read, with no administrator bypass. Data that contradicts the model is refused, with the reason recorded. New knowledge arrives as a proposal a person approves. The graph stays tied to the live systems of record, so it reflects the firm as it is today.
Ready for agentic AI now
Because the graph already carries meaning, relationships, permissions and provenance, agents can go to work on it immediately. They build and run applications on the graph. Every action passes the same approval gate. Ethical walls bind them the same way they bind people. Every finding arrives as a proposal a person approves, and the full trace can be pulled on demand.
That's what lets a firm put agents to work this year. Conflicts announce themselves when a new matter touches a corporate family the firm already represents. A billing entry is checked against the client's outside counsel guidelines before it goes out. A lawyer asks a question about a matter and gets an answer that cites the documents it came from, limited to what that lawyer is allowed to see. A firm can start with one practice group and a defined set of matters and have agents working while a lake program would still be in design.
If the firm already has a lake
Starting with the ontology doesn't waste a lake that's already built. The lake keeps serving finance reporting and analytics, which is the work it does best, and the ontology defines what its data means whenever the firm wants agents to use it. What changes is the order. The ontology comes first, and the lake becomes one tool among several.
The question to ask first
Before a firm commits to a data lake as the first step of its AI strategy, it should ask what its agents will actually need to do their work safely: meaning, relationships, permissions, current information and a source for every fact. For most firms, the answer is a living ontology. Ask your firm anything it has ever known, and get an answer you can trust.