Why Legal Tech Companies Are Turning to Open-Source Foundation Models

1. Background: Why a Legal Tech Company Drew Attention

A U.S. legal technology company recently announced on social media that it had officially released its first proprietary foundation model. The model was not pretrained entirely from scratch but was post-trained on top of an open-source model. The announcement quickly sparked discussion in AI and developer communities.

Founded in 2022, the company has received funding from multiple well-known investment firms, reached a market valuation in the tens of billions of dollars, and serves a large number of top law firm clients globally. Its early product prototype was built on leading closed-source large models, and it had previously collaborated with a model provider to train a custom model for case-law scenarios. It is therefore noteworthy to industry observers that a company so closely tied to the closed-source model ecosystem chose an open-source foundation when building its own foundation model.

The core question this event raises is not which camp a single company has joined, but a broader technical trend: whether and how vertical industry enterprises should build controllable domain models on top of open-source models.

2. Characteristics of Legal AI Scenarios and Model Capability Requirements

To understand why a legal tech company would turn to an open-source foundation, it helps to first clarify the special requirements that legal scenarios place on large model capabilities.

2.1 Highly Structured Legal Text and Long-Range Dependencies

Legal documents, contract clauses, and case opinions typically have rigorous logical structures. The interpretation of one clause may depend on a definition appearing a dozen pages earlier, and the applicability of a case may involve citation relationships among multiple historical cases. This places far higher demands on a model’s long-context understanding, information extraction precision, and cross-paragraph reasoning than general conversation scenarios do.

2.2 Terminology Precision and Citation Reliability

In legal language, similar terms may carry entirely different legal consequences across jurisdictions and contract types. A model must not only understand semantic meaning but also accurately locate statutory provisions, case citations, and contract clause numbers when generating analysis or recommendations. Any citation error can create substantive risk.

2.3 Multi-Turn Task Execution and Workflow Embedding

Typical use of legal tech products is not single-turn Q&A but multi-step tasks embedded in lawyer workflows. For example, extracting all indemnification clauses from a merger agreement, comparing risk levels one by one, and finally generating revision suggestions. This requires stable instruction following, controllable output formats, and the ability to work with enterprise internal toolchains.

3. Decision Logic Behind Proprietary Models: Why Move from Closed-Source to Open-Source Foundations

For a company that has already made deep use of closed-source large models, turning to an open-source foundation for post-training is usually not simply cost-driven but the result of multiple factors acting together.

3.1 Data Controllability and Compliance Boundaries

The legal industry is highly sensitive to data sovereignty and privacy protection. Law firm clients typically do not allow case information, client materials, unpublished contract content, and other sensitive data to enter uncontrolled external service pipelines. Although closed-source model providers offer enterprise-grade security commitments, for legal business with high compliance requirements, fully controlling training data and inference data within one’s own systems still offers significant advantages. An open-source foundation allows organizations to complete end-to-end processing in their own or trusted environments, reducing the risk of data leakage.

3.2 Depth and Flexibility of Domain Adaptation

Closed-source models typically allow domain adaptation only through prompt engineering, retrieval augmentation, or restricted fine-tuning interfaces. Open-source models allow full-parameter fine-tuning of weights, continued pretraining, knowledge distillation, and even architecture-level modifications. For enterprises that need to build differentiated capabilities in specific jurisdictions and specific contract types, this depth of model control is a key consideration.

3.3 Control Over Inference Cost and Deployment Form

A large number of legal service tasks are low-frequency but high-value scenarios, while there are also high-throughput scenarios such as batch contract review. The pay-per-call model of closed-source models offers weak cost controllability at scale. With an open-source foundation, enterprises can choose different inference deployment schemes based on load characteristics—for example, using offline clusters for batch tasks, low-latency services for interactive tasks, and releasing resources during off-peak periods—to optimize overall cost of ownership.

3.4 Avoiding Single-Vendor Lock-In

When a company’s core product capabilities depend heavily on one external model, model version updates, pricing strategy adjustments, and capability changes can all have uncontrollable effects on the product. An important goal of a proprietary model is to internalize core capabilities as the enterprise’s own engineering assets rather than being a passive consumer of external services.

4. Technical Evaluation Dimensions for Foundation Selection

When selecting an open-source foundation, legal tech companies typically evaluate it along the following dimensions.

4.1 Baseline Capabilities

These include general language understanding, reasoning ability, long-text processing capability, and instruction following. Legal scenarios do not require the model to be best on every benchmark, but it must have a sufficiently strong starting point on tasks related to legal text; otherwise, the cost of post-training rises substantially.

4.2 Long-Context Support

Legal documents often run to hundreds of pages. If an open-source foundation performs weakly on long-context tasks, even post-training may not compensate for architectural limitations. Therefore, the foundation model’s long-context processing mechanism, attention implementation, and positional encoding strategy all need close evaluation.

4.3 Multilingual Capability and Localization Potential

Although the company’s core market is primarily the English-language legal system, cross-border business, international contracts, and multilingual legal text processing needs objectively exist. The foundation model’s multilingual capability determines the feasibility of later expansion across multiple jurisdictions.

4.4 Open-Source License and Commercial Usability

For commercial products, the license terms of an open-source model directly determine whether it can legally be used for model training, modification, distribution, and commercial services. Different open-source licenses differ significantly on whether derivative models must remain open source and whether commercial closed-source deployment is permitted. This is especially important in the legal industry, because license ambiguity is itself an unacceptable legal risk.

4.5 Community Ecosystem and Maintainability

Whether an open-source foundation has an active community, complete documentation, and mature toolchain support determines the efficiency of subsequent engineering work. A model lacking ecosystem support may consume substantial resources in adaptation, deployment, and debugging even if its weights are open.

5. From Open-Source Foundation to Domain Model: Key Post-Training Steps

After selecting a foundation, turning it into a usable proprietary model for the legal domain involves multiple technical steps.

5.1 Domain Corpus Preparation and Data Governance

The first step in legal-domain post-training is building a high-quality corpus. This includes public case law, statutes and regulations, contract templates, legal commentary articles, and authorized law firm work documents. The core of data governance is deduplication, cleaning, debiasing, and tiered annotation. Data of different quality levels should be assigned different training weights rather than simply mixed together.

5.2 Continued Pretraining and Knowledge Injection

For proprietary concepts, terminology systems, and reasoning patterns in the legal domain, domain knowledge can be injected into the foundation model through a continued pretraining stage. The goal of this stage is not to make the model “memorize” specific cases but to improve its ability to model legal text structure and its sensitivity to domain terminology. The scale, learning rate schedule, and data mix of continued pretraining all need to be adjusted to the characteristics of the foundation model.

5.3 Supervised Fine-Tuning and Task Generalization

After continued pretraining, supervised fine-tuning with high-quality instruction data is needed. Instruction data in legal scenarios needs to cover multiple task types such as contract review, clause comparison, legal research, and document summarization. The key lies in the diversity and annotation consistency of instruction data, avoiding overfitting on specific tasks that causes the model to lose generalization ability.

5.4 Alignment Optimization and Output Control

Legal scenarios impose higher requirements on the safety, conservatism, and traceability of model outputs. The model should not give definitive legal advice when information is insufficient, nor should it fabricate nonexistent statutes or cases. This needs to be achieved through a combination of preference alignment, reinforcement learning, or rule-based output constraints. For example, a citation verification module can be introduced at the decoding stage to validate statute numbers in generated content in real time.

6. Security and Compliance Architecture: Legal AI-Specific Design

The特殊性 of the legal industry means security and compliance are not add-on features but foundational layers of system architecture.

6.1 Data Isolation and Access Control

During model training and inference, data from different clients must be strictly isolated. For model training, this means establishing a clear data classification system to ensure that only authorized data enters the training set. For inference services, tenant-level data isolation must be implemented to prevent cross-client information leakage.

6.2 Citation Traceability and Output Attribution

Key outputs in legal scenarios should be accompanied by source citations wherever possible. This can be achieved through retrieval augmentation working in concert with the generative model. The system first retrieves relevant statutes, cases, or contract clauses from a controlled knowledge base, then uses the retrieval results as constraints on the generation context and requires the model to indicate citation locations in its output.

6.3 Human Review Loop

In high-risk scenarios, model outputs should enter a human review process. The system design needs to support version comparison between model output and human edits, annotation of edit reasons, and feedback回流. This human feedback can be converted into training data for subsequent model iterations, forming a continuous optimization loop.

7. Engineering Path and Practical Recommendations for Proprietary Models

For enterprises or teams planning to build proprietary vertical domain models, the following engineering path can serve as a starting point.

7.1 Define the Scope of Proprietary Development

Building a proprietary model does not mean pretraining from scratch. For the vast majority of teams, domain post-training on top of a mature open-source foundation is a reasonable balance between cost and effectiveness. What needs to be clarified is: which capabilities rely on the foundation’s existing base, which capabilities need to be acquired through post-training, and which capabilities should be supplemented through external retrieval systems.

7.2 Build the Evaluation System First

Before investing in model training, a domain evaluation benchmark should be established first. This benchmark needs to cover task types in real business scenarios and include both automated metrics and human evaluation metrics. Without a reliable evaluation system, subsequent model iterations lose their direction.

7.3 Small-Scale Iterative Validation

It is recommended to first run rapid experiments with small-scale data on small models or subsets of the foundation model to validate the training pipeline, hyperparameter configuration, and data mix, then gradually expand to full data and the target model scale. This strategy can significantly reduce trial-and-error costs.

7.4 Inference Pipeline and Monitoring

Model training completion is only the first step. Inference pipeline design, performance monitoring, output quality monitoring, and exception fallback mechanisms in production environments are equally important. Real-time sampling review mechanisms for model outputs and model version rollback plans should be established to ensure stable service quality.

8. Conclusion: From “Using Models” to “Building Capabilities”

The shift of legal tech companies from deep use of closed-source models to building proprietary models on open-source foundations reveals a key trend in vertical industry large model applications: when industry needs are deep enough, data barriers are high enough, and compliance requirements are strict enough, enterprises tend to transform model capabilities from external dependencies into internally controllable engineering assets.

For developers and technical decision-makers, what matters is not which specific model foundation to choose, but understanding the evaluation framework and engineering logic behind this decision. Whether in legal, healthcare, finance, or other vertical domains, the path to building proprietary model capabilities follows similar principles: clarify scenario requirements, evaluate foundation capabilities, establish data and evaluation systems, iterate domain adaptation, and build security and compliance architecture.

What is truly valuable is always the data, evaluation standards, and engineering capabilities that enterprises accumulate in vertical domains—not merely the model weights themselves.