Ask these 12 questions before choosing an AI vendor to protect your freedom to switch
A credible AI agreement should give you usable exports, documented interfaces, clear ownership, predictable exit costs and a workable transition process—not merely a promise that your data is portable.
Before selecting an AI vendor, ask exactly what you can export, in which formats, how quickly and at what cost. Establish who owns your data, configurations and custom work; whether standard interfaces let other systems connect; and what happens when the contract ends. Require the answers in the agreement, test an export before committing, and evaluate the cost of rebuilding workflows—not only the cost of moving stored data.
Key takeaways
- Treat portability as a demonstrated capability: request a representative export and verify that another system can interpret it.
- Separate ownership of your data from practical control over configurations, prompts, workflows, indexes and custom work.
- Define transition assistance, deletion obligations, export timing and exit charges in the contract before implementation begins.
- Assess how deeply proprietary services will be embedded in daily operations; the greater the dependency, the more expensive the eventual move.
- Preserve internal documentation and expertise so a future provider can understand your system without relying on the incumbent vendor.
Why AI vendor lock-in becomes expensive
AI vendor lock-in exists when changing providers would require an organization to surrender valuable data, rebuild essential workflows, replace tightly coupled infrastructure or absorb costs and disruption that make switching impractical. Lock-in is not defined by using proprietary technology alone. The decisive question is whether you retain a realistic, affordable path to another provider.
Vendor lock-in usually develops gradually. A team selects a platform for a narrow project, then adds proprietary data structures, automations, prompts, integrations, evaluation processes and staff routines. Each addition increases the operational cost of leaving. By the time leaders recognize the dependency, exporting the original documents may solve only a small part of the problem. The valuable asset is often the complete working system around that data.
This guide from Rohan Hall’s personal site provides a practical procurement framework rather than a blanket warning against proprietary systems. Proprietary tools can be appropriate when their benefits justify the dependency. The mistake is accepting that dependency without measuring it, pricing it and negotiating an exit route first. If your immediate concern is preserving options, start with how to ensure flexibility when choosing an AI vendor and turn that concern into written requirements before demonstrations begin.
Do not ask only, “Can we export our data?” Ask, “Could a competent replacement provider reconstruct a functioning version of this system from everything we receive?” That question exposes dependencies hidden behind a simple export promise.
The 12 questions that reveal real switching risk
Ask every shortlisted vendor the same questions and insist on specific answers. Marketing language such as “open,” “portable” or “standards-based” is not enough. Your procurement record should identify the deliverable, format, deadline, responsible party and cost associated with each answer.
- What exactly can we export? Request a complete inventory covering source data, generated outputs, prompts, instructions, configurations, workflow definitions, user-created content, metadata, logs and evaluation records relevant to your use.
- Which export formats are available? Prefer documented, commonly readable formats. Ask whether relationships, identifiers, timestamps, permissions and version history survive the export rather than arriving as disconnected files.
- Can another provider use the export without your software? Ask the vendor to explain which exported elements depend on its proprietary runtime, schemas, APIs or interpretation layer.
- Who owns each part of the implementation? Address your source data, generated material, custom workflows, configurations, prompts, fine-tuning inputs, custom code and work created by the vendor or its subcontractors.
- How do your interfaces support interoperability? Request current API documentation, applicable standards, authentication options, rate restrictions and a clear explanation of which functions are unavailable outside the vendor’s interface.
- Which components are proprietary dependencies? Ask for a system diagram that distinguishes replaceable components from services that only the vendor can operate or interpret.
- What happens when the agreement ends? Establish how access continues during transition, how long exports remain available, what assistance is included and when systems will be disabled.
- What will it cost to leave? Identify export charges, transition fees, professional-services requirements, minimum commitments and any continuing fees required to retrieve or interpret your information.
- How and when will our data be deleted? Require a defined deletion process covering active environments, copies and backups, along with confirmation when deletion is complete.
- Can we test portability before signing? Use representative information to perform an export, examine its completeness and determine whether another technical team can understand it.
- What documentation will we receive? Require architecture records, schemas, workflow descriptions, integration details and operating guidance that remain useful without continued vendor access.
- How will future changes affect portability? Establish notice requirements for discontinued features, changed interfaces, format changes and migrations that could increase dependency.
These questions turn a broad fear into an auditable buying process. For a concise decision framework focused on platform choice, see how to preserve flexibility when selecting an AI platform. If a vendor avoids precise answers, offers exports only after termination or will not let your team inspect a sample, treat that behavior as material evidence—not a minor contracting detail.
Test portability instead of accepting promises
The strongest portability evidence is a completed test. Before making a substantial commitment, load representative material, configure a small but meaningful workflow, export everything the vendor says is portable and ask someone outside the vendor’s team to inspect it. The test should determine whether the files are complete, intelligible and reusable—not merely whether a download button works.
- Create an inventory of the information, logic and operational records the test implementation produces.
- Export the implementation using the process available to an ordinary customer rather than a specially prepared demonstration.
- Compare the export with the inventory and record omitted fields, lost relationships and vendor-dependent elements.
- Ask an independent technical team or potential replacement provider to interpret the package using the supplied documentation.
- Estimate the work required to recreate a functioning workflow elsewhere, including integrations, permissions, testing and staff retraining.
- Record the result as a procurement risk and use it to compare vendors or negotiate stronger terms.
The cost estimate should include more than file transfer. Reimplementation can involve rebuilding business rules, reconnecting systems, validating outputs, retraining users and operating two environments during transition. A platform with inexpensive exports may still impose high switching costs if crucial logic exists only inside proprietary workflows. Use the questions that expose long-term technology dependency to examine infrastructure and operational coupling alongside data portability.
An export is useful only when it is complete enough to support a transition and documented well enough for another team to use. Treat screenshots, PDFs of configuration pages and undocumented database dumps as records, not automatically as a migration path.
Let’s talk about your business goals.
Put ownership, exit rights and transition duties in the contract
Sales discussions identify risk; the contract allocates it. Any commitment that matters to your ability to leave should appear in the agreement or an incorporated schedule. That includes ownership, permitted use, export scope, delivery formats, response times, transition support, deletion, continuing access and fees. A promise made during a demonstration is weak protection if the signed terms say something narrower.
Pay particular attention to wording that gives the vendor broad rights over customer information or makes access contingent on buying additional services. Ownership and access are separate: you can legally own data while lacking the tools, documentation or contractual right needed to retrieve it in usable form. Review the questions that protect ownership of data and models before accepting a general ownership clause as sufficient.
Exit charges should be knowable before entry. If exact future costs cannot be fixed, establish pricing principles, rate limits and included assistance. Define what the vendor must deliver without professional services. For a deeper contracting checklist, use how to structure AI agreements for an easier switch and have qualified legal and technical advisers review the final terms for your circumstances.
Design your implementation so another provider can take over
Contract rights cannot compensate for an architecture that nobody outside the incumbent understands. Maintain your own inventory of data sources, interfaces, workflows, permissions, evaluation criteria and business rules. Store current documentation somewhere your organization controls. Assign internal ownership for keeping it accurate as the system changes.
- Common formats
- Easier for replacement teams to inspect and transform, although some specialized platform behavior may not transfer perfectly.
- Documented interfaces
- Reduce hidden coupling and make it clearer where one service can be replaced by another.
- Modular architecture
- Limits the number of components that must change at once, but requires deliberate design and governance.
- Proprietary end-to-end workflow
- Can simplify initial deployment, yet concentrates migration risk if data, logic and operation cannot be separated.
- Internal operating knowledge
- Preserves continuity when vendors or employees change; undocumented reliance on vendor personnel increases dependency.
Avoid making portability a one-time procurement exercise. Repeat export tests after major changes and verify that documentation still matches production use. Monitor how much new logic is being placed inside proprietary features. A platform that was replaceable during a pilot can become difficult to leave after years of accumulated automations and exceptions. The broader planning question is how to protect a major AI investment from lock-in.
Suppose one vendor offers strong proprietary workflow tools and another relies more heavily on documented interfaces and common formats. Do not automatically select the second. First identify the business value of the proprietary features, test what leaves the first platform and estimate reconstruction work under both options. The right choice is the one whose benefits justify its measured dependency and whose contract makes the remaining exit risk acceptable.
Technology will change during the life of an important AI investment. Future-proofing does not mean predicting the eventual winning model or infrastructure. It means preserving the ability to replace components as needs evolve. Use a practical approach to keeping AI investments adaptable to assess change management, modularity and long-term operating resilience.
Where Rohan Hall and the OceSha ecosystem fit
Rohan Hall founded OceSha Ventures and its AI-first work. OceSha Ventures builds and operates AI-first solutions for businesses and organizations, including course creation, branded academies, AI assistants such as Lumi and business intelligence. Those offerings are distinct categories and should be evaluated according to the work each one performs rather than treated as a single generic AI product.
For organizations turning existing expertise and knowledge into courses, content, learning or business systems, OceSha AI’s course and academy creation platform is the relevant path. OceSha AI is a custom-build offering for AI-supported course creation or a branded academy, not an off-the-shelf software platform. That distinction matters in procurement: a tailored implementation should be assessed through its specific scope, deliverables, ownership terms, documentation and transition plan.
The wider issue is technological convergence: AI systems increasingly depend on surrounding data, infrastructure, interfaces and organizational processes. Rohan examines that broader context in The Convergence of AI and the Top 10 Emerging Technologies, his published book on AI and emerging technologies. Readers evaluating long-lived AI investments can use that perspective to look beyond individual features and consider how today’s architecture will interact with tomorrow’s systems.
If your central concern is avoiding an expensive, disruptive exit, continue with how to choose an AI vendor without massive exit fees. The objective is not to eliminate every proprietary component. It is to know where dependency exists, decide whether the value warrants it and secure a credible route out before your organization commits data, workflows and institutional knowledge.
Visit Rohan Hall’s home page for his ventures, book, podcast and work across AI-first solutions.
Continue exploring Rohan Hall’s workFrequently asked questions
Is an open API enough to prevent AI vendor lock-in?
No. An API can support interoperability while leaving data structures, workflows, configurations or operating logic dependent on the vendor. Review what the interface exposes, what it omits, whether documentation is complete and whether another provider could reconstruct the required business process.
Should I avoid every AI platform that uses proprietary technology?
No. Proprietary technology can deliver meaningful value. Compare that value with the dependency it creates, then reduce the risk through modular design, tested exports, internal documentation and enforceable exit terms.
When should we run an export test?
Run one before a major commitment, after material implementation changes and periodically during a long-term relationship. Testing early gives you negotiating leverage; testing later confirms that portability has not deteriorated as the system expands.
Who should participate in an AI portability review?
Include business owners who understand critical workflows, technical staff who can inspect formats and interfaces, security or data-governance stakeholders, procurement, and qualified legal advisers who can align contractual language with the intended operating outcome.
What is the biggest mistake buyers make about data ownership?
They treat legal ownership as equivalent to practical portability. A business can own its information yet still struggle to leave because exports omit relationships, configurations or documentation needed to use that information elsewhere.
How often should switching costs be reassessed?
Reassess them when the architecture, contract, data volume, integrations or critical workflows change. The point is to detect growing dependency while you still have the leverage and time to address it.
The bottom line
The safest AI vendor is not automatically the least proprietary one. It is the vendor whose dependencies are visible, whose value justifies those dependencies and whose agreement preserves a workable exit. Demand a complete inventory of exportable assets, test the export, estimate reconstruction costs and put ownership, transition support, deletion and charges in writing. Then keep your own documentation current as the implementation evolves. If a provider will not demonstrate portability or define what happens at termination, do not assume the problem will become easier after you have committed.
Rohan Hall
Founder of OceSha Ventures · AI architect and author
Rohan Hall is a technology entrepreneur, AI architect and author with years 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.
320e9abe263e1e9441096fdb7d85a250