The Legal AI Supply Chain: The Hidden Risk Behind Legal AI Tools

When law firms evaluate legal AI, the conversation usually starts with features. Can the system review contracts, draft a memorandum, conduct legal research, summarize documents, or perform due diligence? Those are sensible questions because they address the immediate value lawyers expect to receive from the technology. But they concentrate almost entirely on the part of the product that lawyers can see and interact with.

There is another question that may become considerably more important as artificial intelligence moves deeper into legal workflows: What is underneath the legal AI product, and what happens if it changes? Many of the legal AI products lawyers use are not self-contained systems built entirely by a single company. They sit on top of a technology stack that can include third-party foundation models, cloud infrastructure, legal databases, retrieval systems, integrations, vector databases, and other external services. A law firm may therefore have a direct contractual relationship with one LegalTech vendor while relying indirectly on several other technology companies to perform the actual work.

In other words, legal AI has a supply chain. That supply chain is largely invisible to the lawyer sitting in front of the application, but it can influence the product’s availability, performance, cost, security, and even the quality of its outputs. As firms move from experimenting with AI to embedding it into research, drafting, contract review, due diligence, litigation, and knowledge-management workflows, those dependencies become increasingly consequential. Understanding them should therefore become part of legal-technology procurement and risk management.

What Is the Legal AI Supply Chain?

It is tempting to think about a legal AI application as a single piece of software. A lawyer opens the application, uploads a document, asks a question, and receives an answer, creating the impression that everything is happening inside the product supplied by the LegalTech company. In reality, the application may represent only the visible layer of a considerably larger technical system. Multiple external services can participate in processing a single request before the result reaches the lawyer.

Alongside that stack may sit legal research databases, document-management systems, search services, vector databases, Microsoft 365 integrations, identity providers, and other infrastructure. Different vendors will build their systems differently, and not every legal AI product will contain every layer. The important point is that the product a lawyer purchases and the infrastructure actually producing its functionality are not necessarily the same thing. That distinction becomes important when assessing operational resilience.

Most legal AI companies are not developing frontier foundation models from scratch. Training those models requires extraordinary amounts of computing infrastructure, capital, data, and specialist expertise, which means LegalTech companies can instead build applications using models developed by companies such as OpenAI, Anthropic, Google, and Mistral. This arrangement has accelerated legal AI development because specialist companies can concentrate on legal workflows, legal data, user experience, and integrations rather than recreating the underlying model infrastructure. The trade-off is that another layer of technological dependency enters the product.

Harvey provides a useful real-world example of how extensive that ecosystem can become. Its current subprocessor disclosure identifies OpenAI, Anthropic, Google Cloud Platform, and Mistral among its AI-related providers, alongside Microsoft, Amazon Web Services, and other technology suppliers. This does not suggest there is anything unusual or problematic about Harvey’s architecture; modern enterprise software routinely relies upon sophisticated third-party infrastructure. Rather, it illustrates how a product that appears to the customer as a single LegalTech platform can sit on top of a much broader technology ecosystem.

A law firm may therefore believe that it has selected Vendor A, while Vendor A itself depends on Vendors B, C, D, and E. The performance and resilience of Vendor A can consequently depend, at least partly, on decisions and events occurring elsewhere in that chain. That is what I mean by the legal AI supply chain. Once that concept is understood, the questions firms should ask during procurement begin to look quite different.

The Model Underneath Your Legal AI Product Can Change

Software buyers are accustomed to products changing over time. Applications receive security patches, interfaces are redesigned, features are added, and integrations are updated without requiring customers to purchase an entirely new product. Foundation-model changes introduce an additional dimension because the underlying system responsible for generating, analyzing, or reasoning over information can itself change. A familiar interface can therefore conceal significant changes further down the technology stack.

A newer model might be faster, cheaper, more accurate, better at handling long documents, or stronger at complex reasoning. It might also perform differently on a particular legal workflow that the firm has already tested and approved. Two models receiving essentially the same prompt do not necessarily produce identical outputs, follow instructions in precisely the same way, or make the same kinds of errors. Consequently, a model upgrade that represents a substantial technical improvement overall does not automatically guarantee an improvement in every legal use case.

Models also do not necessarily remain available indefinitely. Anthropic, for example, maintains a formal model-deprecation lifecycle and tells developers that once a model reaches retirement, requests to that model will fail. It recommends that developers test replacement models before migration and provides advance notice intended to allow applications to transition. Several Claude models have already moved through this process, demonstrating that model retirement is not merely a theoretical future problem.

That creates an important issue for legal buyers. The product a firm procures today may not be technically identical to the product operating two years from now, even if its name and interface remain the same. The model underneath it may have changed, the way different models are routed may have changed, or the vendor may have redesigned the architecture entirely. The relevant governance question is therefore not whether products should change—they inevitably will—but how those changes are tested, controlled, communicated, and monitored.

Legal AI Is Already Becoming a Multi-Model Market

The development of CoCounsel provides an instructive example of how quickly model strategies can evolve. The original CoCounsel was launched in 2023 using OpenAI’s GPT-4, placing a particular foundation model at the heart of one of the first major professional-grade generative AI products for lawyers. Thomson Reuters subsequently expanded its AI strategy, working with multiple model providers and experimenting with approaches designed for specific professional applications. The architecture behind the product has therefore continued evolving even though the CoCounsel brand remains familiar to legal users.

By 2026, Thomson Reuters was describing CoCounsel Legal as having a model-agnostic architecture, while also announcing an expanded relationship with Anthropic involving the Claude Agent SDK. This is significant because it reflects a broader architectural philosophy rather than simply replacing one model with another. The objective is increasingly to build the legal product above the foundation-model layer so that the application is not permanently defined by a single model provider. That gives the vendor greater flexibility as models improve and the economics of AI change.

The evolution does not suggest instability at Thomson Reuters. It demonstrates something more fundamental about modern AI architecture: the model is increasingly a component of the product rather than necessarily being the product itself. A sophisticated legal AI system can potentially combine models, legal content, retrieval technology, workflow logic, evaluation systems, and user interfaces into a product whose value extends far beyond access to a particular large language model. This distinction will become increasingly important as access to powerful models becomes more widespread.

For LegalTech vendors, that means the ability to change models without degrading the legal product may eventually become a competitive advantage in its own right. A company that has built everything around the assumptions and behavior of a single foundation model may face greater migration costs than a company that deliberately designed for model flexibility. The second company still faces technical challenges when switching providers, but it has at least treated portability as an architectural requirement. Law firms evaluating long-term vendors should begin distinguishing between those approaches.

Model Concentration Risk

Consider a legal AI company that builds most of its core workflows around one foundation-model provider. The arrangement may work extremely well and may even produce a better product because engineers can optimize the application around the strengths of that particular model. However, it also creates concentration risk because a material portion of the vendor’s functionality depends on technology controlled by another company. The LegalTech provider does not ultimately decide how long every model remains available, how the underlying API develops, or what the provider charges for future generations of its technology.

If the model provider experiences a major outage, retires a model, changes access conditions, introduces a materially different replacement, or changes its commercial terms, downstream applications may need to respond. Some changes might be almost invisible to customers, while others could require engineering work, testing, migration, or changes in pricing. The significance of the disruption depends on how tightly the legal application is coupled to that provider. This makes concentration a question of degree rather than a simple yes-or-no risk.

This distinction is particularly important because model branding can become part of LegalTech marketing. A vendor announcing that it has integrated the newest frontier model may genuinely be delivering a significant capability improvement. But access to a strong model and resilience to changes in that model are separate characteristics. Firms planning to rely on AI for important workflows need to understand both.

Model-Change Risk

Successfully switching from one foundation model to another does not necessarily mean a LegalTech product will behave identically afterward. Different models can respond differently to instructions, interpret context differently, vary in their ability to use tools, and produce different output structures. Even successive generations from the same provider can have different strengths and weaknesses. For general consumer applications those differences may be manageable, but in repeatable professional workflows they can be consequential.

Consider a due-diligence system designed to identify specific provisions across thousands of contracts. A new model may perform better on overall reasoning benchmarks while becoming slightly less consistent at extracting a particular clause type or returning information in the structure expected by the surrounding workflow. That difference may seem small at the model level but become meaningful when multiplied across thousands of documents. Legal AI evaluation therefore needs to examine performance at the workflow level, not merely rely on general model benchmarks.

This is why model migration should ideally be accompanied by regression testing and benchmarking against the legal tasks for which the product is actually used. Anthropic itself recommends thoroughly testing applications against replacement models before migration when models approach retirement. Mature LegalTech companies are likely to develop increasingly sophisticated internal evaluation suites designed around the specific legal tasks their products perform. Those evaluation systems may eventually become as strategically important as access to the models themselves.

For lawyers, this produces another procurement question: When a vendor changes an underlying model, does it revalidate the legal workflows that depend upon it? Firms should want to know what testing occurs, what performance thresholds are used, who determines whether a replacement model is acceptable, and what happens if performance deteriorates. They should also consider whether customers are notified when a material workflow begins using a different model. Model governance is consequently becoming part of product governance.

Pricing and Availability Risk

AI economics also differ in important ways from traditional software economics. Conventional SaaS products have infrastructure costs, but generative AI applications can incur meaningful variable inference costs each time models process prompts, documents, images, or generated outputs. The cost can depend on the model selected, the amount of information processed, the length of the response, and the computational intensity of the task. As lawyers move from occasional questions toward large-scale document processing and agentic workflows, those economics become increasingly important.

A LegalTech company that relies heavily on an expensive frontier model may therefore face different economics from a company capable of routing tasks among several models. A relatively simple classification task may not require the same computational power as a complex legal analysis involving hundreds of pages of material. If vendors can intelligently select the appropriate model for each task, they can potentially balance quality, latency, and cost. Model orchestration is therefore an economic strategy as well as a technical one.

Changes in foundation-model pricing can also travel through the supply chain. A model provider reducing prices may give LegalTech companies room to improve margins, expand usage allowances, or lower customer costs, while an increase or a shift toward more computationally expensive models can create pressure in the opposite direction. The effect will depend on the vendor’s contracts, architecture, pricing model, and ability to substitute alternatives. Law firms negotiating significant AI contracts should therefore understand whether upstream cost changes can eventually affect their own pricing.

This issue becomes even more relevant as the LegalTech market experiments with alternatives to traditional per-seat subscriptions. Consumption-based pricing, usage allowances, token-based economics, and hybrid models create a more visible connection between infrastructure usage and what customers ultimately pay. Firms should consequently evaluate not only today’s subscription price but also how the vendor expects AI economics to evolve. A low initial price provides little comfort if the cost structure becomes unpredictable once the product is deeply embedded in legal workflows.

Availability and Business-Continuity Risk

Once AI becomes embedded in substantive legal work, downtime becomes more consequential. An unavailable experimental chatbot is inconvenient, but an unavailable system incorporated into contract review, transaction due diligence, litigation preparation, or a time-sensitive research workflow can become an operational problem. The difference is not the technology itself but the firm’s level of dependence on it. The more essential the workflow, the more important resilience becomes.

A LegalTech vendor may maintain highly reliable infrastructure while still depending on external services that experience disruptions. Cloud providers, model APIs, identity systems, document platforms, and other services can each become potential failure points. The vendor’s architecture determines whether one failure produces a complete outage, limited functionality, automatic failover, or merely reduced performance. Customers rarely see these distinctions during a polished product demonstration.

NIST’s AI Risk Management Framework recognizes risks arising from third-party AI systems and supply chains and emphasizes the importance of processes for managing third-party failures and incidents. That thinking should increasingly influence legal AI procurement, particularly where firms intend to integrate AI into business-critical work. Procurement teams already ask cloud and cybersecurity vendors about redundancy, disaster recovery, service levels, and incident response. AI vendors should not be exempt from comparable scrutiny simply because the technology is newer.

The practical question is straightforward: What happens when something underneath the product stops working? A strong vendor should be able to explain whether workloads can move to another model, whether functionality becomes degraded but remains available, what service-level commitments exist, and how customers are informed during incidents. The answer matters much less when AI is an optional productivity experiment. It matters considerably more when lawyers begin structuring their working processes around it.

Data, Confidentiality and the Invisible Supply Chain

The AI supply-chain question is not limited to uptime and performance. It is also about where information goes and which organizations may process it. A lawyer may contract directly with a LegalTech company, but the technical processing of client documents may involve model providers, cloud providers, search infrastructure, analytics tools, and other subprocessors. The existence of those relationships does not automatically create a confidentiality problem, but firms need to understand them.

This makes subprocessor disclosures increasingly important in legal AI procurement. Firms should understand which third parties can receive or process customer information, where processing occurs, what retention rules apply, and what contractual protections govern those relationships. They should also determine whether customer information can be used to train models and whether particular providers can be excluded where client or regulatory requirements demand it. The answers may vary considerably between products and enterprise arrangements.

For lawyers, these are not merely IT-department questions. The ABA’s Formal Opinion 512 emphasizes that lawyers using generative AI remain subject to existing professional duties, including competence and protection of client information. Similar professional obligations exist across many jurisdictions even where the exact rules and terminology differ. Understanding the technology supply chain can therefore be part of understanding how client information is handled.

This is one reason legal AI procurement cannot be reduced to comparing feature lists. Two products may perform a similar task while using materially different infrastructure, contractual arrangements, data flows, and model providers. A lawyer looking only at the final output may never see those differences. A sophisticated procurement process should.

Multi-Model Architecture May Become a Competitive Advantage

One response to dependency risk is model optionality. Rather than designing an application around one foundation model indefinitely, a vendor can create an orchestration layer capable of selecting among different models according to the task being performed. One model might be particularly effective for document classification, another for long-context analysis, another for complex reasoning, and another for high-volume lower-cost work. The user may never need to know which model handled each individual step.

This approach has several potential advantages. It can allow vendors to take advantage of rapid improvements across the model market rather than waiting for a single provider to catch up in every area. It can also create opportunities to manage cost and latency by reserving the most expensive models for tasks where their additional capabilities are actually necessary. Most importantly for supply-chain resilience, it can reduce the extent to which the entire product is permanently tied to one provider.

Thomson Reuters has explicitly described CoCounsel’s architecture as model-agnostic, while Harvey’s disclosed supplier ecosystem demonstrates relationships with multiple AI providers. These examples suggest that leading legal AI vendors are already thinking beyond the assumption that one foundation model should power every task indefinitely. As frontier models become more interchangeable for some use cases, the ability to evaluate and orchestrate them intelligently may become a meaningful differentiator. Legal AI competition may therefore increasingly occur above the model layer.

That could represent an important shift in the LegalTech market. During the first phase of generative AI, having access to a powerful frontier model could itself be a significant product advantage. As increasingly capable models become available to many companies, access alone becomes less distinctive. The competitive advantage moves toward what a LegalTech company builds around those models: legal data, workflow design, evaluations, orchestration, integrations, security, and user experience.

But “Model-Agnostic” Does Not Mean Risk-Free

There is an important caveat to the growing enthusiasm for multi-model architecture. “Model-agnostic” can easily become a marketing term rather than evidence of genuine portability. Having commercial agreements or API access to several model providers does not mean that a complex production workflow can move seamlessly between them. The practical difficulty lies in everything the LegalTech vendor has built around those models.

Models behave differently, prompts may require adjustment, tool-calling systems can operate differently, retrieval strategies may need recalibration, and output formats can vary. A workflow optimized over months for one model may therefore require substantial testing before another model can replace it. Even when two models are capable of completing the same general task, their error patterns may differ. For legal applications, those differences matter because reliability often depends on predictable behavior across repeated tasks.

This is why firms should be careful about accepting architecture labels without understanding what they mean operationally. A vendor might technically support five models while still depending overwhelmingly on one for its most important legal workflows. Another vendor might support only two but maintain thoroughly tested failover processes between them. The second system could be considerably more resilient despite sounding less impressive in marketing materials.

A better procurement question is therefore not simply “Are you model-agnostic?” It is “What happens when you actually migrate an important workflow from one model to another?” Ask how often the vendor has done it, how long it takes, what testing occurs, what performance differences have been observed, and whether customers experience disruption. That turns an abstract architecture claim into an operational resilience question.

What Law Firms Should Ask Legal AI Vendors

Legal AI procurement questionnaires will need to evolve as these products become more important. Security, confidentiality, pricing, integrations, and functionality remain essential, but firms should also investigate the dependencies beneath the application. The objective is not to demand that every vendor own its entire technology stack, which would be unrealistic and counterproductive. It is to understand whether important external dependencies are being actively managed.

1. Which foundation models currently power the product, and do different workflows use different models?
2. Are you materially dependent on a single model provider?
3. Can workloads be migrated to another provider, and has that capability been tested?
4. How do you evaluate new model versions before deploying them?
5. Do you notify customers when the model powering a material workflow changes?
6. What happens if your primary model provider is unavailable?
7. Which subprocessors can receive or process our data?
8. Can our data be used to train any third-party model?
9. Where is our data processed and stored?
10. Could changes in model-provider costs affect our pricing?
11. Can particular models or providers be excluded for our organization?
12. How do you test output quality after a model migration or major update?

Availability deserves its own line of questioning. Firms should ask what happens if the primary model provider becomes unavailable, whether another model can take over, and whether the product continues operating with reduced functionality or becomes unavailable altogether. They should understand which subprocessors can receive firm or client information, where that information is processed and stored, and whether any provider can use customer data for model training. Firms with particularly sensitive clients should also ask whether particular model providers can be excluded at the organizational or matter level.

Commercial questions belong in the same discussion. Firms should understand whether changes in upstream model pricing could affect their contract price, usage limits, or future renewal terms. They should ask how the vendor chooses between models where several could perform the same task and whether cost optimization ever affects the model selected for substantive legal work. Finally, they should ask how output quality is tested after a major model migration or update. For large firms and corporate legal departments, these questions should increasingly sit alongside traditional cybersecurity and privacy assessments.

The Hidden Concentration Risk Inside the Law Firm

There is another uncomfortable implication of the legal AI supply chain: law firms themselves can accidentally create concentration risk. A firm may purchase several apparently different AI products and believe it has diversified its technology stack. One system handles legal research, another contract analysis, and a third knowledge management, so on the surface the firm appears to have three independent technology suppliers. Underneath those interfaces, however, all three products might rely heavily on the same foundation-model provider or cloud infrastructure.

That means three LegalTech vendors do not necessarily represent three independent AI systems. A significant outage or policy change affecting a shared upstream provider could potentially affect several products simultaneously. This is familiar territory in other areas of technology risk, where organizations discover that apparently diverse suppliers ultimately depend on the same cloud provider, data centre, payment processor, or software component. AI adds another layer of hidden concentration.

For firms increasingly dependent on AI, mapping those relationships may eventually become part of business-continuity planning. Procurement teams could maintain an inventory not only of which AI products the firm uses but also of the major foundation models, cloud platforms, and critical subprocessors underneath them. This does not require documenting every minor technology supplier. The objective is to identify dependencies capable of producing correlated failures across multiple important workflows.

That analysis could also change how firms evaluate new purchases. Adding another AI tool powered by the same underlying infrastructure may increase functionality without materially increasing resilience. In some circumstances that will be perfectly acceptable, but firms should at least understand the trade-off. Apparent vendor diversification and actual infrastructure diversification are not the same thing.

Legal AI Is Starting to Look Like Other Infrastructure Markets

None of these dynamics are unique to the legal industry. Businesses learned similar lessons as cloud computing became foundational infrastructure. Organizations that moved critical systems onto AWS, Microsoft Azure, or Google Cloud eventually had to think seriously about service availability, geographic redundancy, portability, concentration, and what would happen if an essential provider experienced a major outage. Cloud computing did not become less valuable because of those questions; rather, organizations became more sophisticated about managing their dependence on it.

Payment infrastructure offers another useful comparison. Businesses can appear to operate their own seamless payment experience while depending on payment processors, card networks, acquiring banks, identity providers, and other services behind the scenes. Companies that become sufficiently dependent on those systems eventually develop contingency arrangements and monitor upstream risk. Social-media businesses have similarly learned the danger of building entire commercial models around platforms whose APIs, algorithms, access rules, or economics can change. Technology supply chains become most visible precisely when something in them changes.

Legal AI is beginning to encounter the same dynamic, but there is an important distinction. A conventional infrastructure outage can make software inaccessible, while a foundation-model change can potentially alter how the software performs the work even when the application remains available. The interface may look identical while the reasoning engine underneath it has changed. That combination of operational dependency and behavioral variability makes AI supply-chain management unusually interesting.

This should not be interpreted as an argument against legal AI adoption. Cloud computing, payment infrastructure, and other technology supply chains created enormous value despite introducing dependencies. The lesson from those industries is that dependency itself is not necessarily the problem. Unidentified, concentrated, or poorly managed dependency is.

The Legal AI Moat May Be Moving Above the Model

There is a broader business lesson here for LegalTech founders. If access to powerful foundation models becomes increasingly widespread, simply placing a legal interface around a frontier model becomes a weaker long-term competitive moat. Competitors may be able to access the same model, and the identity of the “best” model can change rapidly as providers release new generations. Building a durable LegalTech business therefore requires value that survives changes at the model layer.

That durable value may lie in proprietary or authoritative legal data, workflow integration, domain-specific evaluation systems, institutional knowledge, security, governance, model orchestration, and deeply embedded customer integrations. A vendor that understands exactly how lawyers perform a complicated transaction or research task can potentially preserve that workflow while changing the models used to execute individual steps. In that environment, the foundation model remains enormously important without necessarily defining the entire product. The moat moves upward in the stack.

This also changes how we should evaluate announcements about LegalTech companies adopting new models. Integrating the latest OpenAI, Anthropic, Google, or other model may improve the product, but the more interesting long-term question is how quickly and safely the company can evaluate new models as they appear. A vendor capable of repeatedly incorporating technological advances without forcing customers to redesign their workflows possesses something more durable than privileged access to one model. Its competitive advantage becomes the system for evaluating and deploying intelligence rather than the intelligence provider alone.

There are signs that sophisticated law firms are beginning to think about control over the stack as well. In September 2026, the Financial Times reported that Latham & Watkins had purchased Nvidia servers and was developing in-house AI infrastructure using open-weight models, giving the firm greater control over parts of its AI environment and reducing some dependence on external cloud AI providers. Very few firms have the capital, technical talent, or scale to pursue that strategy, so it should not be treated as a blueprint for the average law firm. What matters is the underlying motivation: control over AI infrastructure is becoming strategically valuable.

From AI Capability to AI Resilience

For the past several years, legal AI procurement has largely revolved around capability. Firms wanted to know what the technology could do, how accurately it could perform legal tasks, whether lawyers would actually use it, and whether the productivity gains justified the investment. Those questions will remain important because infrastructure resilience cannot compensate for a product that does not solve a meaningful problem. But they are no longer sufficient on their own.

The next phase of legal AI procurement will increasingly require firms to ask a second category of questions: What does this tool depend on, and what happens when those dependencies change? That means understanding foundation-model providers, cloud infrastructure, subprocessors, model migration, evaluation systems, failover arrangements, data flows, and upstream pricing exposure. The objective is not to turn every lawyer into an AI infrastructure engineer. It is to ensure that firms making significant technology commitments understand the critical dependencies they are accepting.

Nor does this mean law firms should reject products that rely on third-party foundation models. Doing so would eliminate much of the LegalTech market and misunderstand how modern technology is built. A LegalTech company can rely heavily on external infrastructure while still managing those relationships extremely well through diversification, testing, contractual protections, monitoring, and contingency planning. The important distinction is between dependency and unmanaged dependency.

As AI becomes infrastructure for legal work, the strongest LegalTech companies may therefore not simply be the companies with access to the best models at a particular moment. They may be the companies that can continually evaluate those models, switch between them when necessary, protect customer information across the supply chain, maintain consistent legal workflows, and absorb technological change without transferring unnecessary disruption to their customers. Features will still sell products, but resilience may increasingly determine which products firms are comfortable building their practices around. The real test of a LegalTech company’s AI architecture may not be how well it performs when its preferred model is working perfectly, but what happens when that model changes.