The Foundation Model Disclosure

Counsel should require a written architecture disclosure when an AI vendor’s product depends on an open-source foundation model. The disclosure should identify the foundation model, its licence, the vendor’s modifications, the deployment path, and the terms that govern customer data and outputs.

Thomson Reuters says it invested $40 million to develop a proprietary, domain-specific model from an open-source foundation. It also says it will release a small open-weight version for academic and non-commercial evaluation, while its first commercial deployment will support document analysis in CoCounsel Legal.

The disclosure starts with the model underneath

“Proprietary” can describe important work: training data selection, domain adaptation, evaluation, retrieval systems, product controls, and the service layer around a model. It does not, by itself, identify the foundation on which the product was built.

That distinction matters to legal, procurement, security, and product teams for different reasons. A vendor’s public product name may describe a complete application, while the legal obligations can depend on a lower layer: the open-source model family, version, weights, code, or licence used in development and deployment.

The first written request should therefore be simple: identify the open-source foundation model and the precise version or release used. Ask whether the commercial product uses that foundation directly, uses a fine-tuned derivative, or uses it only during research and development.

A general statement that a vendor built “on open source” leaves too much room for interpretation. Counsel needs enough detail to connect the product being bought to the model artefacts and licence terms that may affect it.

Licence terms need a practical reading

Open-source and open-weight releases are not interchangeable labels. The relevant question is the actual licence attached to the model, code, and any accompanying materials.

Request the licence text or a stable reference to it, plus the vendor’s written view of the obligations that apply to the customer’s intended use. That view should cover commercial use, redistribution, modification, attribution, notice requirements, usage restrictions, and any terms that flow through to downstream users.

The Thomson Reuters announcement draws a clear line between a small open-weight version released for academic and non-commercial evaluation and a commercial deployment in CoCounsel Legal. That difference is worth treating as a prompt for diligence. A public release for evaluation does not establish the terms governing a commercial product, and a commercial product built from an open-source foundation may involve separate model, service, and customer-contract terms.

Counsel should also ask whether any third-party model components are updated over time. A product can change materially when a vendor changes the underlying model version, replaces a component, or adjusts the system that routes requests.

Fine-tuning does not remove the need for provenance

A vendor may have invested heavily in a domain-specific model, as Thomson Reuters says it did. The investment can be meaningful evidence of adaptation work, but it does not answer every provenance question.

The written record should separate four layers:

• The original foundation model and its licence.
• The vendor’s model changes, including fine-tuning or other adaptation.
• The application layer, such as document-analysis workflows and retrieval components.
• The service terms that govern customer prompts, documents, outputs, retention, and access.

This structure prevents one vague label from doing too much work. It also creates a record that procurement can revisit when the product expands into new workflows or jurisdictions.

For a legal AI deployment, the application layer deserves particular care. Document analysis is a defined use case, yet counsel still needs to know what information enters the system, how it is processed, who can access it, and which contractual commitments apply. Those questions overlap with the concerns raised in Monday, 9:07 AM: Security Rejects the Pilot: a promising pilot can stall when the documentation does not give security and legal teams a usable basis for approval.

Put change notification into the contract

The most useful disclosure is not a one-time answer in a sales process. It is an obligation to keep material information current.

Ask the vendor to define what counts as a material model or architecture change, then require notice before or within a stated period after the change. The contract should say whether customers can review the new terms, suspend affected use, or terminate if the change creates an unacceptable legal, security, or policy issue.

A short appendix can do much of the work: named foundation model and version, applicable licences, known third-party components, data handling terms, update process, and the vendor contact responsible for notices. Keep it specific enough that a later reviewer can compare the disclosure against the product in use.

The objective is a record counsel can rely on when the polished interface changes, the model underneath changes, or someone asks a basic question six months later: what exactly are we using?

Sources

Thomson Reuters, reporting brief supplied for this post.