AI Implementation Roadmaps
Why Legal Engineers Starts Onsite: The Week-One AI Deployment Model
By Anthony Villanueva ·
Legal Engineers' deployment model begins with an onsite week — working alongside attorneys in the practice group being served. This article explains the methodology and the evidence behind starting with physical presence.
The Legal Engineers deployment model is built around a week-one onsite presence. Before any system is built, the engineering team spends a week embedded in the practice group — sitting in on matter discussions, shadowing the workflow being addressed, interviewing practitioners about their specific challenges, and observing the informal practices that never appear in a process map. This week is the foundation for everything that follows.
Onsite diagnostics provide necessary context
The value of the onsite diagnostic week is informational, not ceremonial. Every practice group that says "we need AI-assisted contract review" has a specific version of that need that differs from every other practice group's version in ways that matter for system design.
The types of contracts they review, the specific provisions they care about, the risk thresholds that drive their flagging criteria, and the way they currently handle exceptions — all of this context shapes the engineering design in ways that cannot be captured in a requirements document written by someone who has not observed the work directly.
Observation bridges stated and actual work
Change management research on professional AI adoption — including Clio's research on legal technology adoption curves — consistently shows that implementations anchored in observed practice outperform those anchored in stated requirements. Attorneys are good at describing what they think they need; they are less reliable at describing how they actually work. Direct observation bridges the gap.
Onsite engagement builds engineering relationships
The onsite week also establishes the relationship between the engineering team and the practice group that drives the adoption of whatever system is built. Attorneys who watched the engineering team observe their work, who were consulted about their preferences, and who can reach a specific engineer when they encounter a problem are substantially more likely to use the system and to advocate for it with colleagues than those who received a system built remotely and delivered with documentation.
The engineering relationship is a determinant of adoption outcomes, not a nice-to-have.
Frequently asked questions
Why is the information gathered during an onsite diagnostic week critical for system design?
The value of the onsite diagnostic week is informational, not ceremonial. Every practice group that says "we need AI-assisted contract review" has a specific version of that need that differs from every other practice group's version in ways that matter for system design.
The types of contracts they review, the specific provisions they care about, the risk thresholds that drive their flagging criteria, and the way they currently handle exceptions — all of this context shapes the engineering design in ways that cannot be captured in a requirements document written by someone who has not observed the work directly.
What does research show about the difference between stated requirements and observed practice?
Change management research on professional AI adoption — including Clio's research on legal technology adoption curves — consistently shows that implementations anchored in observed practice outperform those anchored in stated requirements. Attorneys are good at describing what they think they need; they are less reliable at describing how they actually work. Direct observation bridges the gap.
How does an onsite week help build the relationship between the engineering team and the practice group?
The onsite week also establishes the relationship between the engineering team and the practice group that drives the adoption of whatever system is built. Attorneys who watched the engineering team observe their work, who were consulted about their preferences, and who can reach a specific engineer when they encounter a problem are substantially more likely to use the system and to advocate for it with colleagues than those who received a system built remotely and delivered with documentation.
The engineering relationship is a determinant of adoption outcomes, not a nice-to-have.