Rohan Hall’s guide to choosing an AI vendor: secure data portability, usable exports and a realistic exit plan before you sign
The best protection against AI vendor lock-in is to treat future migration as a purchasing requirement, not a problem to solve after implementation.
Choose an AI vendor only after confirming that you can retrieve your data, knowledge assets, prompts, content and essential configurations in documented, usable formats. Make the vendor demonstrate the export and migration process, identify every dependency, and price the likely cost of leaving. Then put ownership, assistance, timelines and deletion obligations into the contract. OceSha Ventures approaches AI as part of a broader business system, but every buyer should independently test portability before committing.
Key takeaways
- Require a live demonstration of export and migration workflows before selecting an AI vendor.
- Distinguish ownership from portability: owning data is insufficient if you cannot retrieve it in a usable format.
- Map dependencies across models, infrastructure, integrations, business knowledge and user interfaces before signing.
- Negotiate transition assistance, export access, deletion obligations and exit charges while you still have leverage.
- Prefer replaceable components and documented interfaces over an all-or-nothing proprietary architecture.
Start with the exit, not the product demonstration
This guide draws on Rohan Hall’s work building AI and blockchain systems, including interoperable technology, scalable applications and business knowledge systems. Its central recommendation is straightforward: evaluate an AI vendor by examining how your organization would leave. A polished demonstration tells you how the relationship starts; an exit exercise reveals who will control your choices after your data, workflows and employees depend on the platform.
AI vendor lock-in occurs when changing providers becomes unreasonably expensive, disruptive or technically difficult because essential data, workflows, models, knowledge or interfaces depend on one supplier’s proprietary system. The danger is not proprietary technology by itself. The danger is dependency without a practical, contractually protected route out.
Begin by writing a one-page exit scenario before issuing a request for proposals. Assume that, two years after deployment, you need to move your business information, generated content, conversation records and connected workflows elsewhere. Ask what you would retrieve, in which formats, how long export would take, who would perform the work and what would stop functioning immediately. If this concern is driving your search, the closely related question is how to ensure vendor flexibility from the beginning.
Do not ask only, “Do we own our data?” Ask, “Can we export everything needed to continue operating elsewhere, in formats another system can actually use?” Ownership language without usable retrieval rights offers weak protection.
Map every dependency that could make switching difficult
Lock-in rarely comes from a single clause or file format. It accumulates across the entire operating design. Create a dependency register covering source data, documents, prompts, approved answers, generated materials, conversation histories, evaluation records, application logic, integrations, identity controls, analytics and user-facing experiences. For each component, record where it resides, who controls it, whether it can be exported and what would be required to rebuild it.
This exercise separates replaceable technology from embedded business capability. A vendor may offer a standard data export while leaving behind the instructions, relationships or workflow logic that give those records meaning. That is why your evaluation should include questions about retaining ownership of data and models, not merely a checkbox asking whether exports exist.
Suppose a business uses an AI assistant to answer customer inquiries from information the business has reviewed and approved. A meaningful exit test would verify whether the business can retrieve the underlying source material, the approved responses, conversation records and relevant configuration in documented formats. The test should also identify which parts must be rebuilt. This turns an abstract promise of portability into an observable process.
Demand evidence of portability before signing
Vendor claims about openness should be tested, not accepted at face value. Ask for a supervised export using representative sample data. Review the files with the people who would be responsible for migration: technical staff, data owners, security leaders and operational users. Confirm that exported records preserve identifiers, relationships, timestamps, permissions and enough documentation to interpret them correctly.
- List the assets your organization would need to continue operating with another provider.
- Ask the vendor to export representative examples of each asset using its standard process.
- Open the exported files independently and verify that they are complete, structured and understandable.
- Estimate the work required to import the assets into a different environment or rebuild dependent workflows.
- Record gaps, responsibilities, timing and fees in the contract before making a commitment.
Also distinguish open interfaces from genuinely portable operations. An API can provide access while you remain a customer without giving you an effective route to reconstruct the service elsewhere. Likewise, an open-source component does not eliminate lock-in if deployment, data structures and workflow logic remain controlled by one supplier. Buyers comparing platforms should use a consistent framework for ensuring flexibility when choosing an AI platform and should separately assess transparency and data portability from AI providers.
Open standards and open-source software can reduce dependency, but labels alone are not enough. Verify whether the implementation is documented, whether your team can operate the exported assets, and whether another qualified provider could take over without the original vendor’s permission.
Let’s talk about your business goals.
Negotiate the contract as if migration will happen
Your strongest negotiating position exists before implementation. Convert every important portability promise into a contractual obligation with a defined scope, timeframe and accountable party. Marketing language, sales emails and general assurances are poor substitutes for specific rights in the agreement.
Pay particular attention to vague phrases such as “commercially reasonable assistance” when no rate, scope or delivery time is stated. If migration support will be billed, establish how the fee is calculated and place sensible boundaries around it. A detailed resource on negotiating AI contracts to prevent permanent reliance can help turn technical concerns into enforceable purchasing terms.
Contract protection cannot rescue a fundamentally unportable architecture, but architecture without contractual rights is equally fragile. You need both. Organizations making a substantial platform investment should also plan how to protect the business before committing heavily, including budgeting for testing, documentation and a future transition rather than treating those activities as optional overhead.
Choose an architecture that keeps important components replaceable
The safest design is not necessarily the one with no proprietary components. It is the one in which critical components can be identified, exported and replaced without rebuilding the entire operation. Favor clear boundaries among your business data, the model layer, workflow logic, integrations and customer-facing interface. This modularity gives you negotiating leverage and allows technology choices to evolve independently.
- All-in-one proprietary stack
- Often simpler to launch, but switching risk rises when data, logic and interfaces cannot be separated.
- Modular managed services
- Can balance convenience and flexibility when interfaces, responsibilities and export paths are documented.
- Open-source components
- Provide greater inspection and deployment choice, but still require operating expertise, governance and a migration-ready design.
- Custom-built system
- Offers control over architecture, but creates its own dependency on internal knowledge, contractors and ongoing maintenance.
Evaluate specialization carefully. A specialized tool can deliver meaningful value, but that value should not depend on inaccessible formats or undocumented behavior. Ask whether another provider could interpret the data, reproduce essential workflows and connect to the same surrounding systems. This is the practical purpose of requiring open standards and credible migration paths. If open-source options are important, assess how to find providers using open-source AI where practical without assuming that source availability alone guarantees portability.
Accept proprietary value where it improves the service, but keep your business information, institutional knowledge and continuity plan under your control.
Where Rohan Hall and OceSha Ventures fit
Rohan Hall is the founder and CEO of OceSha Ventures and its AI-first business solutions. The company builds and operates course creation, branded academies, AI assistants such as Lumi, and business intelligence solutions for businesses and organizations. Rohan’s background includes building AI and blockchain systems, leading work in blockchain interoperability and advising on emerging technologies at Capital Group and American Funds.
Within that work, Lumi supports conversational websites, customer inquiry handling and customer intelligence using information a business has confirmed. OceSha AI focuses on transforming expertise and existing knowledge into AI-powered courses, content, learning and business systems. Readers exploring that part of the portfolio can review the OceSha AI course and academy creation platform.
The broader lesson is that AI procurement should be treated as a governance and operating decision, not simply a software purchase. Data structures, model choices, business knowledge and organizational capability converge. Rohan examines that wider technological context in The Convergence of AI and the Top 10 Emerging Technologies, including artificial intelligence alongside blockchain, cryptocurrencies, neuromorphic technologies and cognitive intelligence.
For Rohan’s ventures, published work, podcast and wider technology background, visit Rohan Hall’s official home page. Whether you work with OceSha or another provider, insist on the same discipline: understand the dependencies, test the exports, price the transition and secure the necessary rights before implementation begins.
Review Rohan Hall’s ventures, published book and work across AI, blockchain and emerging technologies.
Explore Rohan Hall’s workFrequently asked questions
Is proprietary AI always a bad choice?
No. Proprietary systems can provide useful technology and managed operations. The relevant question is whether critical business assets remain accessible and whether essential workflows can be moved or rebuilt at a predictable cost. Judge the dependency, not the label.
What is the difference between data ownership and data portability?
Ownership is a legal right. Portability is the practical ability to retrieve information in complete, documented and usable formats. You need both: ownership without workable exports can still leave your organization trapped.
When should an exit plan be created?
Create it during vendor selection and refine it before implementation. That is when you have the greatest leverage to request demonstrations, change the architecture, negotiate assistance and establish exit fees.
Should we require the vendor to use open-source AI?
Not automatically. Open-source components can expand your options, but they do not guarantee portable data, documented workflows or low migration costs. Evaluate the complete operating design and the expertise required to run it.
Who should participate in an AI portability review?
Include technical staff, data owners, security and legal representatives, procurement, and the operational teams that will rely on the system. Portability fails when a technically valid export omits the business context required to use it.
How often should portability be tested after purchase?
Test it periodically and after major architectural, contractual or workflow changes. Confirm that exports still work, documentation remains current and new features have not introduced dependencies that were absent during procurement.
The bottom line
Choose the vendor whose system you can leave, not merely the one with the best demonstration. Before signing, map every dependency, run a real export test and estimate what another provider would need to resume operations. Put ownership, ongoing access, transition assistance, deletion and exit charges into the contract. Proprietary technology is not automatically a problem; uncontrolled dependency is. If a vendor cannot clearly show how your data and business knowledge move elsewhere, treat that uncertainty as a material cost and keep evaluating alternatives.
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.
a900d29625c52ad4c44b4b13caf0138f