Your AI Vendor Can Become a Business Risk

Model choice affects contracts, data handling, cost, and your ability to leave.

No vendor or architecture removes vendor risk. The useful question is whether your team knows the dependency, has accepted its terms, and can keep the business operating if the relationship or service changes.

What happens if the model or policy changes?

Ask the agency which parts of the workflow depend on a particular model version, API behavior, provider policy, region, or commercial term. Then ask what your contract says about notice, support, and service changes. A general promise of “model flexibility” is not an operating plan.

• Can the application pin a model version, and what happens when that version is retired?
• Who reviews price, usage-limit, retention, and acceptable-use changes?
• Which model changes require regression tests or a new business approval?
• Does the workflow stop, fall back, or continue with reduced capability when the provider is unavailable?

Put the answers in the scope and handoff. If nobody owns provider notices after the agency leaves, the dependency is undocumented in practice.

Can you move your data and prompts?

“We own our data” does not tell you whether you can export everything needed to run the workflow elsewhere. Inventory the working materials, their formats, and the accounts that control them.

• Can you export prompts, evaluations, files, embeddings, feedback, logs, and configuration in documented formats?
• Which fine-tuning files, indexes, caches, or provider-managed state cannot move directly?
• Are code, deployment settings, and service accounts held in your environment or the agency's?
• Can your team rebuild the workflow from the delivered documentation without private agency access?

Ask for a sample export before launch. A portability clause matters, but a usable export and a tested restore path tell you more about the work required to leave.

Who can retain your inputs?

Follow one real request through every party in the stack: your application, the agency's tooling, the model provider, hosting, monitoring, and support. Record what each party receives, why it receives it, and which agreement governs the copy.

• Are prompts and outputs stored, and are they used for service improvement or model training?
• What appears in application logs, traces, backups, support tickets, and analytics?
• Which people and subprocessors can access retained information?
• How do deletion, legal hold, backup expiry, account closure, and contract termination work?

Have your own legal, privacy, and security reviewers evaluate the answers for the data and jurisdictions involved. An agency's summary of a provider policy is not a substitute for reviewing the applicable terms.

What does switching cost?

A provider swap is not only an API change. It may alter prompts, outputs, latency, evaluation results, safety behavior, support processes, and unit economics. Ask the agency to price and test the exit as a business scenario.

• Which code, prompts, integrations, and evaluations must change for a second provider?
• What data must be exported, transformed, re-indexed, or deleted?
• Which contracts, security reviews, user notices, and internal approvals must be repeated?
• How long can the workflow be unavailable, and what manual process covers the gap?
• Who performs the migration after the original agency engagement ends?

You may reasonably choose a provider-specific feature because it improves the project. Make that trade deliberately: document the benefit, the dependency, and the threshold that would justify switching.

Browse The AI Rolodex as a starting point, then ask each agency how it documents vendor dependencies and hands over the accounts, code, data, and operating instructions. A directory listing does not prove that an agency has built a portable system.