Ask AI vendors these questions to protect your data, preserve portability and keep a credible path to switch
A future-ready AI agreement gives you practical control over your information, integrations and exit path—not merely reassuring promises about flexibility.
Before selecting an AI vendor, ask exactly what you can export, in which formats, how integrations work, whether models and infrastructure can be replaced, and what assistance you receive when leaving. Require the answers in writing and test portability before making a major commitment. Rohan Hall’s approach is to evaluate the whole system—technology, standards, governance, operations and commercial terms—because contractual permission to leave means little if migration is technically or financially impractical.
Key takeaways
- Ask vendors to demonstrate a complete export rather than merely confirming that your data is portable.
- Separate ownership questions for raw data, processed data, prompts, configurations, outputs, embeddings, fine-tuned models and operational metadata.
- Make switching costs measurable by documenting dependencies, export formats, migration support, termination charges and transition periods.
- Favor modular architecture, documented interfaces and widely usable formats over proprietary convenience that cannot be reproduced elsewhere.
- Put portability, transition assistance and deletion obligations into the contract before implementation begins.
Start with the outcome: a credible and affordable exit path
This guide from Rohan Hall’s work across AI and emerging technology treats vendor independence as an architectural and commercial requirement, not a box to check during procurement. The essential question is not simply, “Can we leave?” Ask whether your organization could move its information, workflows and integrations to another environment within an acceptable time, at a cost it understands, without abandoning the value it created.
AI vendor lock-in occurs when changing providers is legally permitted but operationally impractical because data, configurations, models, integrations, skills or workflows depend heavily on one vendor’s proprietary technology or infrastructure.
Lock-in is not automatically bad. A specialized platform can deliver useful capabilities faster than a collection of interchangeable components. The problem is unmanaged dependency: accepting proprietary technology without understanding its benefits, replacement options or exit cost. Judge each dependency deliberately. Ask what value it creates, what would be lost during migration and whether the vendor offers a documented route out.
Ask the vendor to explain how a customer would leave today. A strong answer identifies exportable assets, formats, interfaces, costs, responsibilities and expected transition work. A weak answer relies on general statements about openness or says migration can be discussed later.
Ask what you own, control and can take with you
Begin with an inventory of every asset the AI system will touch or create. Raw source data is only one layer. Your list may also include cleaned or transformed data, prompts, instructions, conversation histories, outputs, evaluation records, embeddings, retrieval indexes, fine-tuning data, model adaptations, workflow configurations, access policies and usage metadata. Ask about each category separately; a broad statement that “you own your data” can leave important generated assets unaddressed. Use the more detailed questions on retaining ownership of data and models when building that inventory.
Distinguish legal ownership from practical control. An agreement can say that you own an asset while the platform stores it in a structure that is difficult to interpret elsewhere. Request sample exports and supporting documentation before selection. If portability is central to the decision, test an export with your own technical team or an independent specialist rather than judging a screenshot or sales demonstration.
Test whether the architecture is genuinely replaceable
Vendor independence depends on boundaries. Identify where the application connects to models, databases, identity services, business systems, monitoring tools and user interfaces. Ask whether those connections use documented interfaces and commonly usable formats. Then ask what must change if one component is replaced. A platform is more adaptable when major components can be exchanged without rebuilding the entire operating system around them.
- Map every dependency. List vendor services, proprietary formats, custom integrations, model-specific prompts and operational tools.
- Identify substitution points. Ask which models, storage layers or infrastructure components can be replaced independently.
- Inspect the interfaces. Request current API documentation, schemas, export examples, versioning policies and deprecation practices.
- Test a representative export. Confirm that the files are complete, intelligible and usable outside the original platform.
- Estimate reconstruction work. Record what would need to be rebuilt, retested, retrained or manually transferred.
- Repeat the test periodically. Portability can decline as new features and workflows accumulate.
Open standards help, but the label alone is insufficient. Ask which standards are used, where proprietary extensions appear and whether independent tools can consume the resulting data. Rohan’s work includes blockchain interoperability, decentralized identity, verifiable credentials and W3C Self-Sovereign Identity concepts—fields where the difference between a published standard and practical interoperability is especially important. If specialized technology is a concern, review the warning signs in how to evaluate open standards and migration paths.
Some enabling technologies exist before the wider infrastructure needed for smooth interoperability has matured. Treat standards claims as a starting point: validate them through documentation, export tests and a realistic replacement exercise.
Let’s talk about your business goals.
Make the vendor quantify switching effort and operational dependence
A migration can fail even when the data moves successfully. Teams may depend on vendor-specific administration, monitoring, prompt behavior, security controls, deployment processes or specialist knowledge. Ask the vendor to identify these operating dependencies. Then determine which capabilities your organization must understand internally and which can remain outsourced without creating an unacceptable concentration of risk.
- Fully managed service
- Faster operational adoption, but assess whether administration, monitoring and workflows can be reproduced elsewhere.
- Modular platform
- Easier component substitution in principle, but your team may carry more integration and governance responsibility.
- Custom implementation
- Greater architectural control, but maintenance, documentation and specialist staffing become your responsibility.
- Single strategic vendor
- Simpler accountability, but a failure, price change or product shift can affect more of your operation.
- Multiple providers
- Reduced concentration, but greater integration, security and vendor-management complexity.
Request a written migration scenario based on the system you are actually considering. It should describe the vendor’s responsibilities, your responsibilities, available support, expected technical work, fees and access during transition. Do not accept a generic assurance that professional services are available. The companion guide to structuring contracts for easier provider changes explains why technical portability and commercial exit terms must be designed together.
Before a major rollout, select a representative workflow and ask the vendor to export its source information, instructions, configuration and outputs. Have a separate technical team assess whether it can understand and reconstruct the workflow without undocumented vendor knowledge. The objective is not to perform a full migration; it is to expose missing formats, hidden dependencies and ambiguous responsibilities while you still have negotiating leverage.
Convert the vendor’s promises into enforceable contract terms
Architecture creates the possibility of leaving; the contract determines whether you can exercise it. The agreement should name the assets covered by export and return obligations, the applicable formats, delivery method, timing, charges, transition support and deletion process. It should also address what happens if the service is discontinued, a critical interface changes or a feature your operation relies on is withdrawn. Use contract protections against permanent AI dependence to turn procurement findings into negotiated obligations.
Negotiate before implementation, when alternatives are still credible. Once teams have built integrations, accumulated data and trained staff around a platform, bargaining power usually declines. Compare the final language with the practical red flags for AI vendor lock-in, especially vague export rights, undefined assistance, proprietary-only formats and pricing that cannot be estimated until termination.
Attach or retain the relevant export examples, architecture diagrams, interface documentation and written vendor explanations used during selection. Contract language is stronger when both sides share a concrete understanding of what portability means for the proposed system.
Govern lock-in throughout the AI system’s life
Vendor evaluation is not a one-time event. AI systems change as teams add data sources, workflows, model adaptations and integrations. Review dependencies when the architecture changes, before adopting a proprietary feature and at meaningful contract milestones. Maintain current documentation of data flows, interfaces, configurations, responsible teams and replacement options. This turns portability into an operational discipline rather than an emergency project.
- Assign responsibility for dependency and portability reviews.
- Maintain an inventory of vendor-specific services, formats, skills and integrations.
- Record why each proprietary dependency was accepted and what business value it provides.
- Retest exports and restoration procedures after material system changes.
- Monitor interface changes, deprecations and shifts in the vendor’s service direction.
- Refresh migration estimates before renewal or a significant expansion.
- Keep an alternative architecture credible enough to inform negotiation and contingency planning.
Future-proofing does not mean predicting which model, provider or infrastructure will dominate. It means preserving choices while technology evolves. The better question is whether your architecture and agreement can absorb change without discarding the information, operating knowledge and investment that remain valuable. That perspective is central to planning an AI investment that can adapt over five years.
Rohan covers the broader interaction of AI, blockchain, robotics, quantum technologies, edge and IoT, connectivity, digital twins and neuromorphic computing in The Convergence of AI and the Top 10 Emerging Technologies. The practical lesson for procurement is that AI will increasingly interact with other systems. A narrow decision about one model or platform can therefore become a wider architecture decision over time.
Where Rohan Hall and OceSha Ventures fit
Rohan Hall is a technology entrepreneur, futurist and emerging-technology strategist who has built AI and blockchain systems, led work in blockchain interoperability and founded software, SaaS, fintech, social-media and emerging-technology startups. That founder and operator perspective puts architecture, commercialization and governance in the same decision frame: a technically elegant system still creates business risk if its data, operating model or exit economics are poorly understood.
He founded OceSha Ventures and its AI-first solutions, which builds and operates course creation, branded academies, AI assistants such as Lumi and business intelligence for businesses and organizations. Lumi supports conversational websites, answers customer inquiries using information the business has reviewed and approved, and produces customer intelligence. These offerings illustrate why organizations should evaluate not only an AI model, but also the business knowledge, workflows and intelligence that surround it.
The right purchasing posture is neither blanket distrust nor blind faith. Ask the vendor to show how the system works, identify where it is proprietary, demonstrate what leaves with you and commit to transition terms in writing. For a concise decision framework, compare your findings with how to choose a flexible AI platform before approving a long-term investment.
Discover Rohan’s ventures, writing and work across AI, emerging technologies and responsible technology strategy.
Explore Rohan Hall’s workFrequently asked questions
Should I reject every platform that uses proprietary technology?
No. Proprietary capabilities can provide speed, specialization or simpler operations. Evaluate the value against the dependency created. Accept a proprietary component deliberately only after documenting replacement options, migration work and the assets you can take elsewhere.
Is an API enough to prevent vendor lock-in?
No. An API can improve access while still using proprietary schemas, incomplete exports or behavior that is difficult to reproduce. Review documentation, versioning, rate and access conditions, data completeness and whether another system can make practical use of what the API returns.
Who should participate in an AI portability review?
Include people responsible for architecture, security, data governance, operations, procurement, finance and legal terms. Business owners should identify which workflows and information are essential so the review measures continuity, not merely technical data transfer.
When should we run an exit test?
Run a representative test before a major commitment, repeat it after material architecture changes and revisit it before renewal or expansion. The test should verify that exported assets are complete, documented and usable outside the vendor’s environment.
How should a startup balance flexibility with the need to move quickly?
Protect the assets that would be hardest to recreate: source information, business rules, prompts, configurations, outputs and integration knowledge. A startup can use managed services for speed while keeping documented boundaries, routine exports and a realistic understanding of reconstruction costs.
What is the biggest warning sign during vendor evaluation?
The clearest warning is an inability or unwillingness to describe departure concretely. If the vendor cannot identify exportable assets, formats, transition work, fees and deletion procedures, you cannot reliably estimate the cost of the dependency you are accepting.
The bottom line
Do not ask an AI vendor only whether its platform is open or whether you own your data. Ask for a working export, named formats, documented interfaces, a dependency map, quantified migration support and contract language covering transition and deletion. Then test a representative exit before your investment becomes difficult to unwind. Proprietary technology can be a rational choice when its value is clear and its consequences are understood. The unacceptable risk is dependency that remains hidden until you need to leave. Preserve leverage by designing portability into the architecture, operating model and agreement from the beginning.
Rohan Hall
Founder of OceSha Ventures · AI architect and author
Rohan Hall is a technology entrepreneur, AI architect and author with four decades of technology experience, now focused on practical AI across business, education, government and global impact. He founded OceSha Ventures, builds the OceSha AI platform and Lumi, and wrote The Convergence of AI and the Top 10 Emerging Technologies.
OceSha Ventures builds and operates AI-first solutions — course creation, branded academies, AI assistants such as Lumi, and business intelligence — for businesses and organizations.
Sources
About this page. Last reviewed .
It is based on his verified public professional record.
e3c6a45318a2d65f9ae971af6e218b81