Vendor Contracts Are Where AI Lock-In Starts

Most small business owners treat AI vendor selection as a technology decision. It isn't. By the time any technology gets evaluated, the decision that actually matters has already been made — or missed.

The contract is the only moment you have leverage

A systematic review of 721 cloud computing studies found that technical solutions to vendor lock-in have historically addressed infrastructure-level portability and left platform and application-level dependence largely unsolved. Outsourced AI sits at the application layer. That is where your prompts, your training data, your fine-tuned model outputs, and your embeddings live. No amount of post-deployment governance work reaches that layer after the fact.

The Duke University analysis of cloud vendor dependence found that lock-in problems intensify specifically when clients do not demand standardised formats and interoperable APIs at the contracting stage. Not after onboarding. Not after the first model version ships. At signing. Once your data flows into a vendor's proprietary stack, the architecture has already made the migration decision for you.

What certifications actually cover

SOC 2 and ISO 27001 certifications audit a vendor's internal security practices. NIST AI Risk Management Framework alignment signals that a vendor has thought about AI risk systematically. These are worth asking about. They are not substitutes for contractual data rights.

A vendor certified under every relevant framework and still using closed embedding formats returns none of your data in a portable form on exit. Certification tells you how the vendor manages its own processes. It does not determine who owns the fine-tuned model weights, what format your training data gets stored in, or whether you receive anything usable when the contract ends. Those questions live in the contract, not the audit report.

The serverless and cloud portability research is specific about where the tightest constraints appear: provider-specific event triggers at the most abstract service layers. Managed AI platforms sit at exactly those layers. Asking for a vendor's compliance certifications without asking about data portability is like checking a restaurant's health inspection score without asking whether you own the recipe.

Questions to put in writing before you sign

Ask who owns the training data you provide, and ask for the answer in the contract, not a sales call. Ask whether the model outputs and fine-tuned weights trained on your data belong to you or the vendor. Ask what format your embeddings and logs are stored in, and whether those formats are open standards or proprietary ones.

Ask for a documented migration path. Not a verbal assurance. A written procedure specifying what you receive on exit, in what format, and within what timeframe. The research scope on this topic is direct: once prompts, logs, and embeddings flow into a vendor's stack, control over them is limited by whatever the contract and architecture allow.

Ask whether the vendor's APIs follow open standards or vendor-specific event models. The distinction matters because migrating an application built on proprietary API structures is not a business decision — it requires rebuilding the application. Ask about model versioning: if the vendor updates the underlying model, do your outputs change without notice?

The counterargument deserves a fair hearing

A reasonable position holds that specialist AI vendors deliver more reliable systems than a small business without internal technical staff could build independently, and that some dependence is a rational trade-off. The research scope section of the vendor lock-in literature acknowledges this directly. Demanding full portability at signing requires legal expertise most small businesses do not have, creates friction, and addresses a risk that may never materialise.

This argument is strongest when the vendor relationship is stable and the business never needs to migrate. It fails at the structural level the research identifies: certifications and governance frameworks operate at the process layer, not the architectural layer where lock-in actually accumulates. A well-governed relationship with a certified vendor still leaves you unable to migrate if the model weights were never yours to take.

The cost of demanding these terms upfront is real. Legal fees, negotiation time, a vendor who walks away. The Duke analysis frames the alternative plainly: clients who do not demand standardised formats at the contracting stage face intensified lock-in once migration becomes necessary. The contracting moment is the only window where the terms are negotiable. After that, you are not negotiating — you are asking for a favor from someone who no longer needs to give you one.