A tool that lives in another tab, needing documents pasted into it, will lose to the tool that is already where the work is — even if it is worse.
Start a conversation with the AI Adoption Concierge, already scoped to integration & workflow fit. Pick a starting point, or describe your situation directly.
The strongest predictor of whether a firm's people use an AI tool is not how good it is. It is how far it sits from where the work already happens. A capable system that requires opening a separate application, locating a document, copying it across and pasting the result back will be used enthusiastically for two weeks and then quietly abandoned, because each of those steps is friction repeated dozens of times a day. Integration also determines whether the firm can see and govern usage at all: a tool inside the document management system leaves a record, and a browser tab does not. Selection decisions that weigh capability heavily and integration lightly are the ones most often regretted.
Several distinct things, frequently conflated in vendor conversations.
Whether it reaches matter files where they live, or requires documents to be moved to it.
Whether it knows about matters, clients and time — the context that makes output useful rather than generic.
Email and the word processor, which is where most legal work is actually produced.
Whether access honours matter-level restrictions, or exposes anything indexed to anyone who asks.
Whether the firm can see what is being used and how, which governance depends on entirely.
Single sign-on and provisioning, so access ends when someone leaves.
How fit is assessed before committing.
Mostly whether the investment produces anything at all.
When the approved tool is awkward and a consumer chatbot is one tab away, people use the chatbot — with client material, outside anything the firm can see. Integration is a confidentiality control, not just a convenience.
More than most selection processes assume, and the asymmetry is worth stating plainly: a moderately capable tool that is already where people work will out-deliver an excellent one that is not, because it gets used. Capability differences narrow as the market matures; friction does not. This does not mean choosing a weak tool for convenience, but it does mean that a large capability advantage should be discounted heavily if it comes with a separate application and manual document movement.
This deserves specific attention and is often discovered late. A tool indexing firm documents to answer questions can surface material across matters unless it honours the firm's access restrictions, and not every product models matter-level permissions properly. The question to put to a vendor is not whether they "support permissions" but how restrictions are enforced at retrieval — and it should be tested rather than accepted on assurance, using a document that a test user should not be able to reach.
It depends on the task, and the benefit is larger than it first appears for anything client-facing. A tool that knows which matter it is working on, who the client is, and what the engagement covers produces output requiring far less correction than one operating on a document in isolation. For firms running an integrated practice system, that context is the difference between a generic assistant and one that behaves as though it works there. For purely internal research tasks it matters much less.
Most firms should buy, and the ones that should build usually already know it. Building requires sustained engineering capacity, not a project — models change, integrations break, and the thing needs an owner indefinitely. The realistic middle path for firms with real technical capability is configuring and connecting bought components rather than building from scratch, which captures workflow fit without taking on a product roadmap the firm has no business maintaining.
Describe your document and practice systems. The Institute will help you assess fit before you commit.