White Shoe AI Research
The Integration Inversion: Why Legal AI Is Building for Developers, Not Lawyers
The best technical demo is often the wrong product. Sustainable adoption starts from the document, channel, reviewer, and decision already in the workflow.
- Author
- By Aaron Boersma
- Published
- Published
- Updated
- Updated
- Reading time
- 12 minute read
Abstract
Standalone AI products are easier to demonstrate than workflow-native systems, but they push integration labor onto users. Legal teams should evaluate whether an AI capability can receive appropriate context, preserve permissions, return reviewable work product, and fit the systems of record that govern the matter. New interoperability standards such as MCP can reduce connection friction, but they do not replace authorization, provenance, or human review.
Key findings
- Workflow friction can consume the time a model appears to save.
- The integration boundary must preserve identity, permissions, provenance, and review.
- Interoperability protocols make connection easier; they do not make every tool call safe.
- Adoption should be measured in completed, reviewable work—not prompts sent or features enabled.
The developer-first inversion
It is straightforward to build a clean interface around a model. It is harder to fit that capability into email, Word, Slack, document repositories, approval rules, and matter records without losing context or control. The resulting standalone tool may look powerful while requiring lawyers to move documents, restate context, and manually reassemble the output.
That labor is not merely inconvenient. It introduces versioning mistakes, data fragmentation, duplicated access, and review steps that are easy to miss under deadline pressure.
Four tests for workflow-native AI
A workflow-native product begins from the job and the governing system, not from the model. It should receive only the context required for the task, respect the identity and permissions already in force, produce an artifact that can be reviewed, and preserve enough provenance to understand what happened.
- Context: does the system receive the right playbook, matter, and source material?
- Control: are authentication, authorization, and tool permissions scoped?
- Artifact: does the output return in a format the reviewer can use and revise?
- Evidence: can the team reconstruct sources, changes, and approval decisions?
MCP changes the connection layer, not the duty of care
The Model Context Protocol provides a common way for compatible AI clients to discover and call tools. That can reduce one-off integration work. It does not determine whether a server exposes too much data, whether a client retains content, or whether an answer is legally correct.
For legal deployments, MCP evaluation should include OAuth or equivalent authentication, least-privilege scopes, tool-by-tool authorization, logging appropriate to the risk, clear error behavior, and explicit limits on what leaves the workspace.
Measure completed work
Feature adoption is not the outcome. Measure whether a representative task moved from request to qualified approval with less total effort, equal or better issue coverage, and no unacceptable control failures. A system that produces more drafts but also more corrections may not improve throughput.
Sources and further reading
- Model Context Protocol — Official protocol documentation and current specification links.
- NIST AI Risk Management Framework: Generative AI Profile — Risk-management guidance applicable to connected generative AI systems.
- ABA Formal Opinion 512 — Lawyer duties involving competence, confidentiality, communication, candor, and fees.
These sources support the surrounding framework; the report's conclusions and product perspective are White Shoe's own. References were checked on July 24, 2026.