Switching AI Model Vendors: What Your Company Needs to Keep

A SaaS company that embeds a third-party AI model eventually faces the question of what happens when it wants to leave. The reason may have nothing to do with vendor misconduct — pricing may change, a stronger model may become available elsewhere, or a strategic shift may make a different provider a better fit. The problem is rarely the decision to switch. It’s discovering, after giving notice, that the value the company built on top of the vendor’s model doesn’t move with it.

What Actually Needs to Move

A company’s real AI investment is rarely just an API key. It typically includes the company’s own source and fine-tuning data; curated datasets, labels, taxonomies, and data-preparation rules; prompt libraries and system instructions; evaluation datasets and benchmark results; retrieval configuration — chunking rules, metadata, vector-index design; embedding vectors and the identity and version of the embedding model that produced them; fine-tuning job records, adapter files, and checkpoints; and the deployment, safety, and workflow configuration built around all of it. A contract’s “Customer Data” export clause may have been written before any of these artifacts existed and may not reach each of them. Treating the migration package as a single category can be a mistake; each component should be identified separately.

Ownership of a Fine-Tuned Model Doesn’t Mean It Travels

A company that supplied training data for a fine-tuned model may assume it owns every resulting artifact. That assumption skips a real distinction: a company’s rights in the data, labels, prompts, and evaluation materials it supplied are a different question from technical questions about whether the resulting adapter, checkpoint, or embedding set can actually run anywhere but the outgoing vendor’s model, architecture, and hosting environment. An artifact produced from a company’s own data is not automatically portable merely because the company supplied the data — portability depends on what the vendor agrees to deliver at exit, in what format, and whether the replacement provider can use it at all. The legal treatment of model weights and embeddings remains developing and may turn heavily on the applicable contract, the artifact at issue, and the surrounding facts. This article does not attempt to resolve those questions, and the statutes discussed below do not supply a general answer.

Exportable Is Not the Same as Reproducible

Before a switch, it’s worth testing a company’s own assumptions against a short list:

• Is the export in a documented, machine-readable format?
• Does it include metadata, annotations, and version history, or just raw output?
• Can the retrieval corpus and vector-store configuration actually be rebuilt from what’s exported?
• Is there evaluation data available to test the replacement setup against the old one?
• Are the fine-tuned artifacts compatible with the replacement vendor, or does the company need to re-embed, re-index, or re-train from scratch?
• Is there enough retained documentation to even understand how the existing system currently performs?

A company may be able to export data without having what it needs to recreate a functioning AI workflow with a replacement provider.

Transition Assistance Is a Negotiated Term, Not a Default

Whether an outgoing vendor helps with any of this ordinarily depends on the parties’ agreement and the services the vendor actually agreed to provide — it isn’t a background legal obligation that shows up automatically. Before notice is given, a company may wish to address transition assistance expressly, including a defined post-termination assistance period; secure access and export methods; delivery formats and accompanying documentation; technical support to validate exports; assistance rebuilding retrieval and data pipelines; cooperation with a replacement vendor within defined confidentiality limits; responsibility for correcting export errors; and whether the services are included or separately billed.

What Happens to Company Data Left Behind

A related but separate question is what remains in the outgoing vendor’s systems after the relationship ends:

• Were temporary fine-tuning files, embeddings, evaluation sets, logs, and support materials included in whatever deletion the contract promises?
• What restrictions apply to backup or disaster-recovery copies?
• Is the vendor barred from further using the company’s data for training, service improvement, or benchmarking after termination?
• When — and how — will an authorized representative of the vendor confirm that deletion or isolation is actually complete, and what happens if a residual copy turns up later?

These are questions for the agreement’s exit provisions, not assumptions a company should make about the scope or timing of any vendor’s deletion practices.

Trade Secret Protection During the Switch

Proprietary training data, curation methodology, evaluation materials, prompt design, and retrieval architecture may qualify for trade-secret protection under the federal Defend Trade Secrets Act and the Arizona, California, and Texas Uniform Trade Secrets Acts. The statutes use materially similar core requirements: the information must derive independent economic value from not being generally known or readily ascertainable through proper means, and the owner must take reasonable measures to maintain its secrecy. 18 U.S.C. § 1839(3); A.R.S. § 44-401(4); Cal. Civ. Code § 3426.1(d); Tex. Civ. Prac. & Rem. Code § 134A.002(6). Merely labeling information confidential, without corresponding access, use, and handling controls, may not establish reasonable measures to protect a trade secret. Precautions that actually support a trade-secret claim during a vendor migration include written confidentiality and restricted-use obligations covering the outgoing vendor; a contractual bar on using the company’s materials for another customer, a generalized model, benchmarking, or vendor-side model improvement; role-based, need-to-know access during the transition itself; encrypted, logged transfer procedures; an inventory of exactly what was transferred and to whom; and documented deletion and retention controls once the migration is complete. Arizona, California, and Texas do not materially differ on the underlying definition. A.R.S. § 44-405, Cal. Civ. Code § 3426.5, and Tex. Civ. Prac. & Rem. Code § 134A.006 also address preservation of alleged trade-secret secrecy in judicial proceedings; those provisions do not create a general migration, portability, or deletion right.

No Statute Fills the Gap — Check the Contract Instead

None of the trade-secret statutes or AI-specific statutes discussed in this article creates a general right to export a fine-tuned model, adapter weights, checkpoints, or embeddings; to require a departing vendor to make those artifacts interoperable with a replacement provider; to require transition assistance; or to require deletion on a customer-selected timetable. California’s AI Transparency Act, Cal. Bus. & Prof. Code §§ 22757–22757.6, was effective January 1, 2025, and became operative August 2, 2026. It requires certain covered providers that license a generative-AI system to a third party to preserve, by contract, that system’s required disclosure capability. That is a narrow provenance-disclosure requirement, not a general portability rule. California’s separate Transparency in Frontier Artificial Intelligence Act, Cal. Bus. & Prof. Code §§ 22757.10–22757.16, imposes transparency and reporting obligations on defined frontier-AI developers where applicable and likewise is not a vendor-switching statute. Texas’s Responsible Artificial Intelligence Governance Act, effective January 1, 2026, contains disclosure and use restrictions, including a consumer-interaction disclosure duty in its governmental-agency provisions, but creates no general private-sector duty to announce a model-vendor switch and no model-portability or data-return right. Arizona has no identified in-force general private-sector AI transparency or model-switching statute; its one AI-specific disclosure rule addresses candidate deepfakes in the pre-election period and has nothing to do with vendor migrations. Arizona, California, and Texas do not differ on the central migration point: none of the statutes discussed here establishes a general right to port a fine-tuned model or embedding set, obtain transition assistance, require interoperability, or set a customer-selected deletion timetable. Those subjects should be addressed expressly in the applicable contract.

Before the Next Vendor Decision

Before committing to a new AI model vendor — or giving notice to an existing one — has the company identified the data, configurations, evaluation materials, and model-related outputs it would need to rebuild its AI workflow elsewhere? Asking that question early may be more useful than attempting to negotiate essential exit rights after the notice period has begun.

Authority Table

Frequently Asked Questions

This information is current as of September 2026.

This article is provided for general informational purposes only and does not constitute legal advice. Reading this article or contacting Accord & Shield Legal, PLLC does not create an attorney-client relationship. It does not address securities, tax, or litigation strategy. Some of the ownership and portability questions discussed above are unsettled or fact-dependent, and are identified as such rather than resolved. Laws, contracts, and applicable statutes can change, and their application depends on specific facts and jurisdictions. Do not act or refrain from acting based on this article without obtaining advice from qualified counsel regarding your circumstances. This material may be considered attorney advertising in some jurisdictions. Past results do not guarantee future outcomes.