The AI vendor market is crowded, and every vendor has a compelling demo. This module gives you a decision matrix to choose your path, the five vendor criteria that actually predict long-term switching costs, and the questions that separate durable partnerships from expensive dependencies.
Why the Buy/Build/Partner Question Matters More Now
Two years ago, the AI vendor market had a small number of recognizable players. Today there are hundreds of vendors across every enterprise function, from contract review to supply chain forecasting to HR screening. The proliferation creates a selection problem: how do you evaluate quickly enough to move, but carefully enough to avoid building a costly dependency on a vendor who will not be around in three years, or whose data practices you cannot defend to your board?
The decision between buying a vendor product, building a custom capability, or partnering with a systems integrator or model provider is not primarily a technology question. It is a strategic question about where AI is a commodity input versus where it is a source of competitive differentiation. Getting this wrong costs money in the short term and strategic optionality in the medium term.
The right starting question
Before evaluating any vendor, answer: is this use case core to our competitive differentiation, or is it a commodity capability that every company in our industry needs? The answer determines whether you should buy, build, or partner.
The 3x3 Decision Matrix
The decision framework works across two dimensions: strategic importance (how central is this AI capability to your competitive advantage?) and internal build capability (does your team have the ML engineering depth, data infrastructure, and operational experience to build and maintain this?).
Buy is the right path when strategic importance is low or medium and internal capability is low or medium. Most enterprise AI use cases fall here: document summarization, customer service automation, financial reporting assistance, and code review tools are capabilities where the vendor market is mature, the switching costs are manageable, and internal build would distract engineering talent from higher-value work.
Partner is the right path when strategic importance is high but internal capability is limited, or when the use case requires frontier model capability that no internal team could replicate. A partnership with a model provider or systems integrator gives you access to capability faster than building, with the trade-off that the partnership terms, data handling practices, and roadmap alignment become governance considerations rather than internal decisions.
Build is justified when two conditions are both true: the capability is core to competitive differentiation, and you have the engineering depth to build and maintain it over time. Building AI capability for its own sake, when the use case is commodity and the vendor market is mature, produces higher cost, longer time to deployment, and weaker output than buying would have. FrugalGPT research (Chen, Zaharia, Zou, arXiv:2310.11409) demonstrates that optimized inference cost strategies using a mix of models can reduce costs by orders of magnitude, but only when the team has the engineering capability to implement and maintain that optimization continuously.
Five Vendor Criteria That Predict Switching Costs
Most vendor evaluations focus on feature completeness, accuracy, and price. These matter, but they are not the criteria that predict whether you will be trapped with a vendor in three years when your needs change or their quality degrades. The five criteria that best predict switching costs are:
1. Data format lock-in and proprietary embeddings. If the vendor stores your documents, customer data, or domain knowledge in a proprietary vector database or embedding format that cannot be exported, migration to a different vendor requires re-processing all of that data. This is the most common and most underestimated source of switching cost in enterprise AI procurement.
2. Model transparency and version control. When the vendor updates their underlying model, does your system's behavior change without notice? Vendors who offer model version pinning, change logs, and advance notice of model updates are easier to manage than vendors who treat model updates as invisible infrastructure changes. Behavior changes matter most in regulated industries where you are required to explain AI decisions.
3. Data residency and training practices. Does the vendor process your data in your preferred region? Do they train their models on customer data, and can you contractually prohibit this? For any AI system processing confidential business information, these questions require written contractual answers, not verbal assurances.
4. SLA structure and escalation paths. What is the vendor's uptime commitment for the specific capabilities you depend on, and what is the escalation path when something is wrong? A vendor with a strong SLA for their platform but weak SLA for the specific API you use is a vendor whose SLA does not protect you.
5. Roadmap alignment. Where is the vendor investing in the next 12 months? Vendors who are building deeply into one industry or use case may diverge from your needs faster than you expect. Vendors who are spreading thin across many use cases may fail to maintain depth in the capability you bought them for. Ask for a written roadmap, note what is on it and what is not, and revisit it in six months.
Structuring a Vendor Evaluation That Produces Real Signal
A vendor demo is a best-case demonstration on the vendor's preferred examples. It tells you what the system can do when everything goes well. What you need to know is how the system behaves on your data, your edge cases, and your integrations.
A useful vendor evaluation runs in three stages. The first stage is a structured RFI that requires written answers to the five criteria above, plus your data residency and security requirements. Vendors who cannot or will not answer in writing are telling you something useful.
The second stage is a scoped proof of concept using your actual data. Not a demo environment, not synthetic data: the real documents, real queries, and real integrations that your team will use. Define success criteria before the POC runs, not after you see the results.
The third stage is a reference check with a customer in your industry who has been live with the vendor for at least 12 months. Not a reference the vendor provides: one you find independently through your network. The questions that matter are: what surprised you after go-live, what did you have to build that you thought the vendor would provide, and would you sign the same contract again knowing what you know now?