Ask these 12 questions before choosing an AI vendor to protect ownership and prevent lock-in
A credible vendor should define what you own, what you can export and how you can leave before your data, workflows and institutional knowledge become difficult to move.
Ask who owns every category of data and intellectual property, whether your information trains shared models, which assets you can export, and what happens when the contract ends. Then test portability in practice: request documented formats, interfaces, deletion procedures, transition assistance and a priced exit plan. Rohan Hall’s work through OceSha Ventures spans enterprise AI, architecture and durable operating capability, informing this practical approach to vendor selection.
Key takeaways
- Separate ownership of your inputs, outputs, configurations, workflows, embeddings and custom model work; a general promise that “you own your data” is not enough.
- Require usable exports in documented formats, then test a sample export before committing to a long contract.
- Treat model access and model ownership as different rights; determine what remains available if the vendor relationship ends.
- Put termination, deletion, transition support, fees and deadlines in the contract rather than relying on sales assurances.
- Evaluate operational portability as well as technical portability: your team needs documentation, skills and procedures that can survive a provider change.
Why “we protect your data” is not a sufficient answer
The central risk is not simply whether an AI vendor stores data securely. It is whether your organization retains practical control of its information, model-related assets, workflows and accumulated knowledge. Rohan Hall founded OceSha Ventures and its AI-first work, which includes course creation, branded academies, AI assistants such as Lumi and business intelligence. That enterprise perspective matters here: an AI service should strengthen durable capability inside your organization, not make essential operations inseparable from one supplier.
AI vendor lock-in occurs when changing providers becomes unreasonably expensive, disruptive or technically difficult because critical data, model behavior, integrations, workflows or operational knowledge cannot be transferred or reproduced.
Lock-in often accumulates quietly. A pilot begins with uploaded documents and a few workflows. Over time, the system gains prompts, configurations, conversation histories, evaluations, embeddings, business rules and connections to other systems. Even if the original files remain yours, the operational value may now sit in vendor-specific structures that are difficult to extract or recreate.
Do not ask only, “Do we own our data?” Ask, “If we end the relationship tomorrow, what exactly will you return, in what format, by when, at what cost, and what will still depend on your technology?”
For a broader view of the person and ventures behind this guidance, visit Rohan Hall’s work in AI and emerging technology.
The 12 questions that expose ownership and control
Send these questions in writing and require precise answers. The strongest responses distinguish among different assets instead of treating “data” as one undefined category. If answers remain broad, convert each promise into explicit contract language using the approach in negotiating AI contracts against permanent dependency.
- Who owns our source data, uploaded documents, prompts, instructions, conversation records, feedback and generated outputs?
- Who owns configurations, workflow definitions, evaluation sets, business rules, knowledge structures and other assets created during implementation?
- Will any of our information be used to train, tune, evaluate or improve models or services shared with other customers? If so, can we refuse?
- If work produces a custom model, fine-tuned model, adapter, embedding collection or other model-related asset, what rights do we receive to access, copy, modify and use it elsewhere?
- Which components rely on the vendor’s proprietary models, software, interfaces, data structures or infrastructure?
- Can we export every asset that matters to continued operation, including metadata and relationships between records?
- What export formats are available, and are their schemas and interfaces fully documented?
- Can another provider or our internal team reproduce the workflow without continuing access to the vendor’s platform?
- What integrations, standards or interfaces reduce dependence on vendor-specific technology?
- What transition assistance is included if we move to another provider, and what will additional help cost?
- After termination, how quickly will data be returned and deleted from production systems, backups and subprocessors?
- Which obligations survive termination, including confidentiality, data protection, intellectual-property rights and access to previously created outputs?
These questions support commercial and technical due diligence, but they are not legal advice. Have qualified counsel review ownership, licensing, confidentiality, liability, termination and data-protection terms for your circumstances.
If transparency is difficult to assess during procurement, use a structured process for choosing an AI provider with real data portability rather than accepting a feature demonstration as evidence of control.
Distinguish data ownership from model rights
A contract can say that you own your data while giving you little control over the system that turns that data into useful results. Treat at least four layers separately: your original information, the outputs produced for you, the configured workflow and any model-related work. Each layer can carry different ownership, licensing and portability terms.
- Business data
- Your documents, records, prompts, policies, feedback and other information supplied to or collected through the service.
- Generated material
- Responses, summaries, classifications, reports or other outputs created for your organization.
- Operational assets
- Instructions, workflow logic, configurations, evaluation materials, metadata and knowledge structures developed during use.
- Model-related assets
- Fine-tuning work, adapters, embeddings, weights where applicable, evaluation results and dependencies on underlying models or services.
Ask whether your rights are ownership rights, a continuing license or access that exists only while you subscribe. A right to use an output is not necessarily a right to export the machinery behind it. Similarly, paying for customization does not automatically mean you receive the files, documentation or permissions required to operate that work elsewhere.
Every important asset should have a named owner, defined usage rights, an export method and a clear post-termination treatment. Ambiguity benefits the party controlling the platform.
When proprietary specialization is central to the proposed solution, compare it against ways to preserve flexibility in proprietary AI systems. For projects seeking greater control over the technology stack, also examine how open-source AI affects future options. Open source can reduce some dependencies, but it does not remove the need to assess hosting, maintenance, data formats and internal skills.
Let’s talk about your business goals.
Test portability instead of accepting a portability promise
Portability is useful only when the exported material is complete, documented and operationally reusable. A bulk download of source documents may omit prompts, configurations, metadata, permissions, evaluation history and the relationships that make the system work. Request a data map showing what enters the service, what the service creates, where each category is stored and how each category leaves.
- Select a representative set of documents, records, prompts, outputs and workflow configurations.
- Ask the vendor to export the set using the process available to ordinary customers.
- Review the export for completeness, readable formats, metadata, identifiers and documented schemas.
- Import or reconstruct the material in a neutral environment or with another qualified provider.
- Record missing elements, manual conversion work, external dependencies, time requirements and fees.
- Put remedies for any portability gap into the contract before expanding the deployment.
Suppose a business uses an AI assistant to answer customer questions from information the business has reviewed and approved. The original documents are only one part of the useful system. The business should also identify whether it can retrieve the approved answers, instructions, interaction records, feedback and relevant customer intelligence in usable forms. Lumi supports conversational websites, customer inquiry handling and customer intelligence based on confirmed business information; the general portability principle remains the same: preserve the assets needed to continue serving visitors if the surrounding technology changes.
A provider that supports a real migration exercise gives you better evidence than one that supplies only policy language. Use open standards and migration-path questions for specialized AI to examine whether a proposed architecture can move beyond its original environment.
Negotiate the exit before implementation begins
Your leverage is strongest before the vendor has your data and before employees depend on its workflows. Put exit mechanics into the initial agreement, statement of work and implementation plan. Do not postpone them to renewal, when migration pressure and operational dependence can weaken your negotiating position.
Avoid clauses that leave export formats, transition fees or assistance entirely to the vendor’s future discretion. Also inspect renewal mechanics, minimum commitments and changes to product functionality. A nominal right to terminate offers little protection when the practical cost of leaving is unknown.
The contract should connect legal rights to a workable migration plan. For specific provisions and negotiation priorities, see structuring AI contracts for an easier provider switch. If the system will require ongoing custom engineering, compare maintenance options for custom AI solutions before assigning all future upgrades to one provider.
Build organizational independence, not just contractual protection
A strong contract cannot compensate for an organization that has no record of how its AI system works. Maintain your own inventory of data sources, approved information, prompts, workflows, integrations, evaluation criteria and accountable decision-makers. Keep architecture diagrams, operating procedures and change histories somewhere your organization controls.
Assign employees to understand the workflow rather than allowing all technical and operational knowledge to reside with an outside team. Use documented interfaces where practical, keep original source material in systems you control and periodically verify that exports remain complete. Reassess dependencies whenever the vendor introduces a new model, proprietary feature or data structure.
- Fully managed platform
- Faster to adopt and easier to operate, but portability and transition terms deserve close scrutiny.
- Custom solution
- Greater control over architecture and workflows, with more responsibility for maintenance, skills and upgrades.
- Hybrid approach
- Combines managed services with organization-controlled data, documentation and replaceable components; boundaries must be explicit.
The right choice depends on strategic importance, internal capability and switching tolerance. The goal is not to eliminate every dependency. It is to make dependencies visible, intentional and replaceable at a cost the organization understands. A practical evaluation framework is available in choosing an AI platform without surrendering flexibility.
Hall addresses AI alongside blockchain, neuromorphic technologies, cognitive intelligence and other emerging fields in The Convergence of AI and the Top 10 Emerging Technologies. The broader lesson is relevant to procurement: technology evolves through convergence, so architecture and contracts should preserve room to adopt what comes next.
Discover Rohan Hall’s ventures, writing and work across enterprise AI, architecture and emerging technologies.
Explore Rohan Hall’s workFrequently asked questions
Is owning my input data enough to avoid AI vendor lock-in?
No. Your source data may remain yours while configurations, prompts, embeddings, workflow logic, metadata or model-related assets remain difficult to access. Define ownership, licensing, export rights and post-termination treatment for every asset needed to continue the operation.
Should I insist on owning the vendor’s underlying model?
Not necessarily. Many services depend on models the vendor licenses or operates. The practical question is whether you retain your own assets and can reproduce the required business workflow with another model or provider. Ask which components are replaceable and which are inseparable from the service.
How often should we test data exports?
Test before a major commitment, after material architecture or model changes, and periodically while the service remains operationally important. An export capability that worked during procurement may become incomplete as new features and data structures are added.
Does using open-source AI eliminate lock-in?
No. Open-source software can improve visibility and deployment choices, but dependence can still arise through hosting, proprietary data structures, custom integrations, specialist maintenance or undocumented workflows. Evaluate the complete operating system around the model.
Who should participate in AI vendor due diligence?
Include business owners, technical architecture, security, privacy, procurement and legal counsel. Operational teams should also verify whether exported assets would let them continue essential workflows. Each group sees a different source of dependency.
What is the biggest warning sign during vendor selection?
The clearest warning is an inability or unwillingness to explain exactly what you can export, in which formats, with what documentation and assistance, after termination. Broad ownership claims should never substitute for a demonstrable exit process.
The bottom line
Choose an AI vendor only after it proves that ownership, portability and exit are operational realities rather than reassuring language. Separate your data from generated outputs, workflow assets and model-related work; define rights for each category; test a representative export; and price the transition before signing. Then maintain internal documentation and expertise so the contract is not your only safeguard. Some dependency is unavoidable, but invisible dependency is a choice. The best vendor relationship is one you continue because it creates value—not because leaving would mean abandoning your data, workflows or accumulated investment.
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.
e941c7f0b1f2a01259a6e9273c824605