With the pace of new product releases and market buzz, artificial intelligence (AI) has crossed a line in many organizations from an experimental tool to an embedded business function. Companies are increasingly relying on third-party AI offerings to support core processes, streamline operations, automate customer support, and perform other back-office and customer-facing tasks.
For many businesses, the question is no longer whether to adopt AI, but how to implement it in a way that is sustainable. For in-house counsel, a related question is how to contract for such AI tools.
Unlike conventional software or services, AI solutions often depend on a combination of proprietary models, unique training or fine-tuning data, prompt libraries, and frequently changing algorithms. Those elements can be difficult, and sometimes impractical, to replicate elsewhere if the business later wants to switch vendors, migrate to a new platform, or bring the capability in-house.
That creates a common contracting risk: AI agreements that lack clear exit mechanics can leave the customer stranded if costs increase, performance degrades, a provider’s roadmap changes, or regulatory and compliance expectations evolve. As the AI contracting landscape matures, more forward-looking agreements are addressing AI services more like critical outsourced services (and less like “just another software license”), with specific terms designed to preserve continuity and optionality.
This blog has previewed many contracting considerations with respect to AI, including data rights and restrictions and navigating AI in technology transactions. Below are several provisions that can help organizations plan for the end of the relationship during the contracting process, when leverage is typically highest.
Defined Exit Rights and ‘What Happens Next’
AI deployments can quickly become embedded in daily operations. As a result, it is worth treating “exit” as a defined workstream, not a vague concept.
Consider including clearly defined exit rights and any variations based on how the contract ends (e.g., expiration, termination for convenience, termination for cause). Where appropriate, consider:
- A defined transition period (with timelines and responsibilities)
- Termination/transition assistance services as a contractual obligation, not an informal expectation
- Pre-agreed rates for transition support and migration work (or a bundled number of hours included)
- Run-off support for a limited period to maintain business continuity while the replacement solution is implemented
The goal is to reduce the risk that the customer faces a choice between accepting unfavorable renewal terms or absorbing disruption.
Required Cooperation with Replacement Vendors and Internal Teams
Because AI tools are increasingly tied into workflows, data pipelines, and user-facing processes, transition support often requires more than simply “returning the data.”
Where the AI service is business-critical, consider obligations requiring the incumbent provider to reasonably cooperate with the customer and/or replacement vendors during the transition period, including:
- Knowledge transfer (technical and operational)
- Support for data export/migration
- Documentation handover (configurations, prompt libraries, guardrails, and related artifacts)
- Integration support (APIs, connectors, identity and access management, logging)
When these items are not contractual deliverables, customers can discover too late that the operational knowledge needed to migrate sits largely with the provider.
Ownership and Rights in Data, Prompts, Outputs, and Related Artifacts
In addition to general IP terms, AI deals benefit from a more granular allocation of rights that anticipates how the solution is used in practice.
Consider spelling out rights and restrictions for at least four categories:
- Customer data and inputs: Clarity that the customer owns (or retains all rights in) its data, inputs, and business content, and that the provider’s use is limited to performing the services (and any expressly permitted improvement/training rights)
- Customer-developed artifacts: Prompts, prompt libraries, workflows, evaluation datasets, retrieval indexes, embeddings, and guardrails created for the customer’s environment. These elements can be as important to portability as the underlying data
- Outputs: Clarity regarding the customer’s right to use outputs for business purposes (including internal use, customer communications, and downstream workflows) and any restrictions or compliance obligations tied to output use
- Provider restrictions and post-termination obligations: Clear requirements to return customer data and customer-developed artifacts and to delete remaining copies from provider systems (including backups and subcontractors where feasible), with written certification
Even where model ownership remains with the provider (as is often the case), these terms help ensure the customer can migrate what actually drives value in the deployment.
Portability Substitutes When ‘Model Portability’ Is Unrealistic
In many AI relationships, the customer may not be able to take the provider’s proprietary model to a new environment, including a replacement vendor. But the contract can still require practical substitutes that materially support transition and continuity, such as:
- Export of training/fine-tuning datasets (to the extent customer-owned or customer-provided)
- Export of prompt libraries and system instructions
- Export of evaluation datasets and testing results used to measure quality
- Access to logs and telemetry relevant to performance and compliance
- Documentation of workflows, guardrails, and configurations
Framing these as “portability deliverables” can help align expectations and reduce the risk of being locked into a single provider’s tooling and institutional knowledge.
Contract Checklist: AI Exit and Portability Readiness
During the contracting phase, clearly defining what the business will need when the relationship ends can help steer the contract terms. An example of questions to include in a checklist of questions and solutions to think about during the contracting and negotiation process include:
- If we needed to switch providers in 90–180 days, what specific deliverables would we need from the incumbent to make that possible?
- Do we have transition assistance services as a binding obligation, with defined scope and rates?
- Are there run-off services (and for how long) to prevent business disruption?
- Are data export obligations tied to specific formats, timelines, and completeness (including logs where needed)?
- Do we have clear rights to prompts, prompt libraries, workflows, evaluation datasets, retrieval indexes/embeddings, and other customer-created artifacts?
- Are the provider’s rights to use customer data for training/improvement explicitly limited (or expressly permitted only with guardrails and opt-out)?
- Do we have clear post-termination deletion obligations (including subcontractors) and written certification?
- Is cooperation with replacement vendors and internal teams an express obligation (not aspirational language)?
AI contracting is moving quickly from “license terms” toward an operating model that requires that the contract anticipate regulatory change, model updates, and vendor transitions as normal lifecycle events. Planning for exit at the start is one of the most practical ways to protect continuity while still capturing the benefits of rapid innovation.