Create an AI Vendor Exit and Portability Plan in 2026

Teams often discover lock-in during a price change, outage or policy concern. By then, prompts, embeddings, evaluation data and workflow logic may be scattered across a provider-specific interface.

This guide is designed for product owners, IT teams and procurement leads. It turns the topic into a reviewable sequence rather than asking readers to trust a provider label, a detector score or a fluent model answer.

Before you start

Write down the exact task, accountable owner, approved data, affected people and the result that would be unacceptable. Use safe representative examples during the first pass. Where health, legal, employment, financial, safety or regulatory obligations may apply, involve a qualified professional and follow the rules that govern your organization.

1. Inventory dependent assets

List prompts, assistants, knowledge sources, vectors, files, fine-tunes, logs, user identities, integrations, domains and billing records.

Document the decision made during “Inventory dependent assets”, the evidence consulted and the person responsible for the next action. That short record helps product owners, IT teams and procurement leads distinguish a repeatable control from an informal habit.

2. Separate portable source from derived state

Keep canonical documents and evaluation cases outside the provider. Record how provider-specific indexes or configuration can be rebuilt.

Test “Separate portable source from derived state” with a normal case and a deliberately difficult case. Record what passed, what required correction and which condition should trigger a human review for product owners, IT teams and procurement leads.

3. Document replacement requirements

Define minimum quality, safety, latency, region, access and cost so an alternative can be tested against the same acceptance criteria.

Assign an owner and completion criterion for “Document replacement requirements”. If the evidence is missing or contradictory, pause the workflow instead of allowing speed or model confidence to become the approval rule.

4. Run a small exit drill

Export selected assets, import or rebuild them elsewhere, revoke a test account and verify deletion evidence without disrupting production.

Keep the input, output version and reviewer note associated with “Run a small exit drill” where policy permits. This makes later corrections traceable without retaining unnecessary sensitive data.

5. Set decision triggers

Name the owner and triggers such as material terms, unacceptable incidents, cost thresholds, end-of-life or failure to meet service needs.

Review this step after material changes to the model, provider, prompt, data source or connected system. A control that worked in one configuration should not be assumed to cover the next one.

Common failure modes and controls

The following table is a pre-launch challenge list. Teams should adapt it to the systems, people and permissions in their real deployment.

What to measure

Do not optimize a single headline number. Measure useful outcomes together with correction effort, critical failures and the human work needed to make the result acceptable.

• critical assets with portable copyDefine the numerator, denominator, owner and review period for critical assets with portable copy; compare like-for-like workflow versions.
• time to rebuild a pilotTrack time to rebuild a pilot beside correction effort and serious exceptions so a faster result does not hide weaker quality.
• credentials revoked in drillSample credentials revoked in drill by risk level and user group; investigate material changes instead of relying on one aggregate percentage.
• exit triggers with named ownerSet a baseline for exit triggers with named owner, record the intervention and review whether the change remained useful after human verification.

Final review checklist

• Dependencies are inventoried
• Canonical data is separate
• Acceptance criteria are portable
• Export is tested
• Revocation is tested
• Exit owner is named