Over the past eighteen months, the leading enterprise legal AI platforms have moved from generic models to custom model offerings — bespoke training on a firm's own documents, deployed as part of an enterprise contract. The product is impressive, the engineering is real, and the rollout has been read by many firms as the resolution of an argument that has shaped legal AI procurement since 2023: if the vendor will train the model on our matters, the sovereignty conversation is over.
Read carefully, it is not over. It has gotten sharper. The architectural question that mattered in 2023 still matters in 2026, and the answer determines what the firm actually holds as an asset at the end of a ten-year deployment. This piece works through what custom training does and does not change, and what the analysis produces for a firm thinking about its AI infrastructure as an asset rather than a subscription.
What custom training actually does
The mechanism, fairly summarized: the vendor takes the firm's documents, runs a fine-tuning or retrieval-augmented training process against a foundation model, and produces a model variant that performs better on the firm's specific work product, vocabulary, and matter patterns. The firm pays for the training engagement and gains access to the customized model through the same enterprise platform.
The output is genuinely useful. A model fine-tuned on a firm's brief style produces drafts closer to the firm's voice. A model trained on a firm's transactional precedents retrieves more relevant prior work. Custom workflows configured around the firm's matter lifecycle reduce friction in adoption. None of that is marketing — it is what the engagement produces, and it is why these offerings have traction with sophisticated firms.
The question is not whether the customization works. The question is what the firm holds when the customization is complete.
Where the trained model actually lives
The custom-training feature does not change the deployment model. The trained system runs on the vendor's infrastructure, accessed through the vendor's platform, governed by the vendor's terms. The firm's documents are used as training inputs, but the resulting model file, the weights, and the operational system are the vendor's.
A custom-trained model is a customization layer on the vendor's platform. The firm's documents shaped that layer. The platform, the infrastructure, and the trained system itself are the vendor's.
This matters in three specific ways that show up in any honest scenario analysis.
First, in transit. Every query against the custom-trained model still transits the vendor's infrastructure during processing. The model is fine-tuned on the firm's data, but the firm's data continues to move across third-party compute on every interaction. Under ABA Rule 1.6, the reasonable-efforts analysis covers data in motion as well as data at rest. The custom-training feature improves what the model does. It does not change where the data goes during the doing.
Second, at the end of the relationship. If the firm ends the engagement — for any reason, whether vendor pricing, vendor strategy, vendor acquisition, vendor IPO, or simply a strategic decision to move infrastructure in-house — the firm does not walk away with the trained model. The fine-tuned weights are not portable. The custom workflows live on the vendor's platform. The institutional knowledge the embedded engineers developed about the firm goes back to the vendor's payroll. The firm has paid for and benefited from the customization, but the customization itself does not transfer.
Third, over time. Multi-tenant infrastructure has structural tradeoffs that no contract eliminates. Independent research from Stanford and Berkeley documented measurable behavioral drift in widely-deployed foundation models — not random degradation, but the result of vendor decisions about how to balance cost, latency, safety, and accuracy across millions of users. A custom-trained variant inherits whatever decisions the underlying platform makes. If the vendor optimizes for the aggregate, sophisticated use cases can regress, and the firm has no operational visibility into when or why.
The asset class question
The clearest way to think about what custom training does and does not change is to ask what the firm actually holds, ten years into the deployment, in two different scenarios.
Scenario one: enterprise SaaS with custom training. Year one through ten, the firm pays a recurring fee, ranging from significant to substantial as the engagement grows. The vendor's embedded engineers learn the firm's processes. A custom model is trained, retrained, and refined across thousands of matters. Workflows are built. Institutional knowledge accumulates. The system improves measurably each year, and the firm benefits from those improvements during the contract period. At year ten, the firm holds: ten years of receipts, a corpus of documents that produced the training, and access — for as long as the firm continues paying — to the customized capability. If the firm stops paying, or the vendor changes terms, or the strategic relationship ends for any reason, the customizations remain on the vendor's infrastructure. The firm walks away with documents it already had.
Scenario two: sovereign infrastructure. Year one is a one-time investment in building the system. Year two through ten, the firm operates the system on its own infrastructure, extends it through internal capability, and absorbs the institutional knowledge into its operating model. The system improves measurably each year, and the firm benefits from those improvements during operation. At year ten, the firm holds: the architecture, the model, the workflows, the trained system, and the institutional capability to extend and operate it. The vendor relationship can have ended at year three, year five, year ten, or never — and the system continues running on the firm's terms.
This is not an argument about which scenario produces better AI capability during the engagement period. It is an argument about which scenario produces an asset at the end of it.
Where custom training is the right answer
For firms that want operational AI capability without building internal infrastructure ownership — and many firms do, for entirely legitimate reasons — enterprise SaaS with custom training is a competent choice. The product works, the customization is meaningful, and the platform is operationally mature. A firm that views legal AI as an operating expense, expects to renew its tooling stack regularly, and does not see strategic value in owning the underlying system can make a defensible decision to use these platforms.
What the custom-training feature does not do is resolve the architectural question for firms whose strategic posture treats AI infrastructure as a long-term asset. For those firms, the analysis is different — and it is harder, not easier, to defer to the vendor's roadmap when the vendor's roadmap will not transfer.
The Rule 1.6 analysis is unchanged
From a confidentiality standpoint, the custom-training feature does not change the reasonable-efforts analysis under Rule 1.6 in the way some firms have read it. The analysis the lawyer must perform — understanding how the tool processes client information during operation, where that information moves, how the handling matches the firm's confidentiality obligations, and whether informed client consent is required for specific use cases — applies to the custom-trained variant in the same form it applied to the generic platform. The model has been adapted to the firm. The data handling chain has not been.
State bar guidance has reinforced this. Florida Opinion 24-1 addresses the specific circumstance where the AI tool's data handling is ambiguous and directs the lawyer to seek client consent in that scenario — and the ambiguity is not resolved by the model being custom. The California Practical Guidance instructs lawyers to anonymize inputs where practical and to understand specifically how the tool handles client information. The NYSBA Report treats AI disclosure to clients as a routine communication obligation. None of these standards change because the underlying model has been fine-tuned on the firm's documents.
What separates infrastructure from a subscription
The cleanest test of what a firm has built, versus what a firm is renting, is to ask one operational question: if the vendor relationship ended next quarter, what specifically would the firm continue to operate, and what would the firm need to rebuild?
For a firm running custom-trained enterprise SaaS, the answer is honest and clear: the documents continue to exist, the firm continues to operate using its standard tools, and the customizations need to be rebuilt — because the customizations were never the firm's to keep.
For a firm running sovereign infrastructure, the answer is also honest and clear: the system continues to operate on the firm's terms, and the vendor relationship — to the extent there ever was one — was a deployment engagement that ended cleanly, leaving operational capability behind.
Both answers can be the right answer for the right firm. The error is in believing that the first answer and the second answer are the same answer. They are not, and the difference shows up specifically when the firm needs to know what it owns.
The question worth sitting with
For a Managing Partner or CIO evaluating legal AI procurement in 2026, the productive question is not whether the firm should buy custom-trained AI from a leading enterprise platform. That is a real, defensible choice. The productive question is whether the firm has thought through what it will own at the end of the ten-year deployment, and whether that ownership posture aligns with how the firm treats other forms of strategic infrastructure.
A firm that has answered that question deliberately — in either direction — is operating at a different level of strategic clarity than a firm that has read the custom-training announcements as a signal that the architectural question has been resolved.
It has not been. The product has improved. The asset class question is the same one it was three years ago, and the firms that engage with it directly are the firms whose AI infrastructure will still be doing useful work in 2036.
About the author. Jon Ventoso is the founder of LISA — Legal Intelligence Sovereign Architecture. LISA designs and builds purpose-built AI infrastructure for law firms, deployed inside the firm’s environment and owned permanently. The views above are the author’s own and do not constitute legal advice.