When AI Makes the Vendor Relationship More Complex, Not Less
Menlo Ventures data from late 2025 shows Anthropic holding approximately 40 percent of enterprise LLM API spend while OpenAI dropped to 27 percent, down from roughly 50 percent in 2023. That shift happened in approximately two years. The enterprise AI vendor landscape is moving faster than most vendor management programs were designed to handle, and the contractual, governance, and lock-in implications of AI vendor relationships are materially different from those of the enterprise software relationships that most IT and procurement functions have decades of experience managing.
The Kai Waehner analysis of the enterprise agentic AI landscape makes the compounding lock-in problem precise: the choice of foundation model vendor and the choice of agent framework are not independent decisions. If agents run on a vendor's proprietary orchestration layer, lock-in compounds at every layer of the stack. An enterprise that builds its AI agents on a specific vendor's platform, uses that vendor's orchestration layer to connect those agents to enterprise systems, and fine-tunes models on that vendor's infrastructure has made several individually reasonable decisions that together create a switching cost that is orders of magnitude higher than any individual component would suggest.
Most enterprise vendor management programs were not designed to evaluate this kind of compounding dependency. They were designed to evaluate software licenses, professional services contracts, and support agreements for products with stable feature sets and predictable pricing. AI vendor relationships involve consumption-based pricing that scales with usage in non-linear ways, models that change between contract versions, governance obligations that shift as regulatory frameworks evolve, and data handling practices whose implications are only fully visible with close technical review of terms that change frequently.
What Is Different About AI Vendor Contracts
Pricing in AI vendor contracts is almost universally consumption-based, not seat-based. The enterprise pays for tokens processed, API calls made, compute hours consumed, or conversations handled. The consumption rate is a function of how the AI system is designed, how it is used, and how heavily it is adopted, all of which are difficult to predict accurately before production deployment. An enterprise that negotiates on the basis of projected consumption and then achieves high adoption will pay significantly more than projected without having violated any contract term. The negotiation question for AI pricing is not the unit price but the cost model: what happens to total cost at 2x projected adoption, at 5x, and at the adoption rate the vendor's own success case studies imply?
Model versioning creates a category of contract risk that has no equivalent in traditional software licensing. AI models change between versions in ways that affect their behavior, outputs, and sometimes their compliance posture. An enterprise that deploys a compliant AI system based on a specific model version and then experiences an involuntary model upgrade, common in managed AI service contracts without explicit version pinning provisions, may find that the upgraded model behaves differently in ways that affect its compliance status. The contract needs to address model versioning explicitly: what versions are available, how long they are supported, what notice is provided before automatic upgrades, and whether enterprises can pin to a specific version for compliance-sensitive applications.
Data handling in AI vendor contracts includes provisions that traditional software contracts rarely address: whether the vendor trains on customer data, how long customer data is retained, whether customer data influences model behavior for other customers, and what happens to fine-tuned models if the customer terminates the contract. The key questions for every AI vendor evaluation include whether the vendor uses customer data to train or fine-tune models, what the retention and deletion policy is for data submitted through the API, and whether customer data is isolated or potentially shared across the vendor's model improvement processes.
Exit terms require specific attention to model and workflow portability. A traditional software contract exit involves data export in standard formats. An AI vendor contract exit additionally involves the question of what happens to fine-tuned models, proprietary embeddings, and agent workflows built on the vendor's platform. Models fine-tuned on a vendor's infrastructure using the vendor's tooling may not be portable to another infrastructure without significant re-engineering. Agent workflows built on a vendor's proprietary orchestration layer are typically not portable at all. The exit clause that covers data portability but says nothing about model and workflow portability understates the actual switching cost by the amount required to rebuild those AI-specific assets.
The Lock-In Architecture Problem
AI vendor lock-in compounds across three layers that traditional software does not involve. The model layer: fine-tuned models trained on the vendor's infrastructure cannot typically be exported in a portable format and redeployed on a different vendor's infrastructure without retraining. The agent orchestration layer: agentic workflows built on a vendor's proprietary framework are not portable to other frameworks without rebuilding from scratch. The knowledge layer: vector embeddings generated using a vendor's embedding model are not interchangeable with embeddings from a different model, which means a knowledge base built with one vendor's embedding infrastructure requires complete re-indexing if the vendor changes.
The architectural response is to make explicit design decisions about which layers to build on vendor-specific infrastructure and which to build on vendor-neutral or open-standards infrastructure. The Model Context Protocol post in this series describes the most significant open standard for agent-to-system integration in 2026. Building agent integration on MCP rather than on a vendor's proprietary agent framework preserves optionality at the integration layer regardless of which AI model vendor the organization uses. That optionality has a cost: MCP implementations require more engineering investment than vendor-native integration. The question is whether that investment is justified by the switching cost reduction it provides.
What SLAs Need to Cover for AI Systems
Traditional IT SLAs cover uptime, response time, and incident response. These dimensions matter for AI systems but are insufficient. An AI system that is technically available and responding within SLA thresholds but producing materially degraded outputs has failed in a way that no traditional SLA metric would detect. Model quality degradation, behavioral drift after updates, and accuracy regression for specific use cases are AI-specific failure modes that need to be addressed either through model performance SLAs or through contractual rights to validate model performance before and after updates.
The shift toward outcome-based SLAs applies directly to AI systems. An AI system that deflects 60 percent of support tickets at the accuracy levels that make deflection valuable has a different SLA structure than one measured on API availability. The contract framework that most effectively protects enterprise AI investments measures what the AI is supposed to produce, not just whether it is technically operational when asked to produce it.
The Procurement Process That Fits AI Vendor Relationships
Requirements definition for AI systems needs to include governance requirements alongside functional requirements: data handling standards, model transparency, audit trail requirements, and exit provisions that are contract terms, not features demonstrated in a proof of concept. Enterprises that defer these requirements to contract negotiation, after the vendor has been selected on functional criteria, consistently end up accepting less favorable governance terms than they would have achieved if governance had been part of the evaluation criteria from the start.
A comprehensive RFP process covering security, compliance, data handling, exit terms, and performance guarantees produces a vendor relationship that is better understood before commitment and better governed after it. Making these questions part of the formal evaluation, with written responses that can be incorporated into the contract, is the difference between a relationship that surfaces governance gaps after deployment and one that addresses them before signing.
Talk to Us
ClarityArc helps Canadian organizations develop AI vendor management frameworks that address the governance, contractual, and lock-in dimensions of AI vendor relationships that traditional procurement processes were not designed to handle. If your organization is entering significant AI vendor commitments and wants to ensure the contract protects you appropriately, we are ready to help.
Get in Touch