Choose an AI provider by testing transparency, data portability and your exit path before you sign

Vendor lock-in is not simply the use of proprietary technology. Most useful business systems contain proprietary components. The danger is concentrated dependency: one provider controls the data, application logic, model access, integrations and operational knowledge, while your organization lacks the rights or documentation needed to continue without it. A provider can appear flexible during a demonstration yet become difficult to replace after your knowledge, workflows and customer interactions have accumulated inside its platform.

Your goal is therefore not to eliminate every dependency. It is to make each dependency visible, bounded and replaceable. Ask what happens if the underlying model changes, an integration is discontinued, pricing becomes unsuitable or the provider no longer supports your use case. The answers reveal whether you are buying a manageable service or accepting an open-ended reliance on one company’s technology and staff. For a broader decision framework, consider how to preserve flexibility when choosing an AI vendor.

Create a portability inventory before issuing a request for proposals or evaluating demonstrations. Begin with the information supplied by your organization: documents, structured records, policies, product details, approved responses and other source material. Then identify what the system creates or changes, such as prompts, configurations, generated content, conversation records, evaluations, classifications and workflow logic. Finally, list the technical connections that make the solution useful, including interfaces, identity controls, data pipelines and downstream reporting.

For every item, record who owns it, where it resides, how it can be exported and whether the export is understandable without the original platform. Access to a file is not enough if it arrives in an undocumented structure that no alternative system can interpret. Likewise, an export of source documents does not preserve the prompts, rules and evaluation criteria developed around them. Use this inventory when reviewing the contract clauses that prevent data being held hostage.

Transparency does not require a vendor to disclose every line of proprietary code. It does require enough information for you to understand the system’s material dependencies and make informed decisions. Request a plain-language architecture showing where your information enters, where it is stored, which components process it and which third parties are involved. The provider should also explain how model changes, software updates and service failures affect your application.

Do not rely exclusively on sales answers. Ask technical, legal, security and operational stakeholders to review the same claims from their own perspectives. Inconsistency is informative: if the sales team promises portability but the contract, architecture and export demonstration tell different stories, treat the written and tested evidence as decisive. A structured set of questions that expose long-term technology dependence helps keep the evaluation focused on evidence rather than presentation quality.

Open standards and open-source components can reduce switching friction, but neither automatically prevents lock-in. An open-source model can still sit inside an undocumented application that only one provider understands. Conversely, a proprietary service can be replaceable when it is accessed through a well-defined interface, your data remains portable and the surrounding business logic is documented. Evaluate the complete operating system around the AI, not a single licensing label.

The strongest practical pattern is substitution by design. Keep authoritative business information outside any single model where feasible. Use documented interfaces between major layers. Record prompts, rules and evaluation methods in a form your organization can access. Avoid embedding irreplaceable business logic in a provider-only feature unless its value clearly outweighs the migration cost. When negotiating, focus on protecting against dependence on one model or infrastructure stack and on open standards and workable migration paths.

If source availability is a priority, investigate how to assess providers using open-source AI where appropriate. Ask who maintains each component, how updates are handled and whether a different team could deploy it. Openness is useful only when paired with documentation, skills and operational ownership.

A migration plan should be created before deployment, when you still have negotiating leverage and the system is comparatively simple. Define the events that could trigger an exit: a strategic change, persistent service problems, unacceptable contract revisions or the availability of a better approach. Assign internal responsibility for preserving documentation and keeping the portability inventory current as the system evolves.

Contract terms should match this operating plan. Specify ownership and permitted use, export formats, delivery timing, transition support, deletion obligations and treatment of subcontractors. Define what assistance is included and how additional work is approved. For bespoke systems, compare options for maintaining and upgrading custom AI independently. Before a major investment, also review how to protect the business before committing to one platform.

Rohan Hall’s work on responsible and trustworthy technology emphasizes evidence, transparency, governance, assurance, standards and trust in AI and blockchain adoption. Applied to vendor selection, that perspective leads to a clear position: confidence should come from inspectable architecture, defined responsibilities, tested controls and credible exit arrangements—not from assurances that a particular provider will always remain the right choice.

Rohan founded OceSha Ventures and its AI-first work, which builds and operates solutions spanning course creation, branded academies, AI assistants such as Lumi and business intelligence for businesses and organizations. Lumi supports conversational websites, customer inquiry handling and customer intelligence using information the business has confirmed. That context makes governance and portability practical design concerns: organizations need to know what information drives an assistant, how its answers are controlled and what assets matter to future continuity.

The issue also belongs to a larger technology transition. AI increasingly intersects with blockchain, digital identity, robotics and other emerging systems, making standards and interoperability more consequential over time. Rohan examines these intersections in The Convergence of AI and the Top 10 Emerging Technologies. Readers looking for his ventures, book, podcast and wider work can visit Rohan Hall’s home page.