An AI vendor risk assessment asks whether a specific service can support your product on acceptable commercial, data, quality, and exit terms. OpenAI and Anthropic are provider names. Your actual dependency is a combination of model, API feature, hosting platform, account configuration, and contract. That is the unit to evaluate.
For a CTO choosing a provider or reviewing an existing integration, the useful output is a decision supported by evidence: what the service is approved to do, which gaps remain, who owns them, and what changing course would cost. This guide includes a due-diligence checklist, contract questions, a worked migration budget, and a reusable review record.
Buy against your requirements, not the provider’s reputation
A strong model benchmark does not settle data-retention requirements. A large funding announcement does not guarantee your price or capacity. Record evidence for the exact service and make unresolved requirements visible.
Why an S&P 500 Headline Is Not a Vendor Assessment
Stock-index eligibility, a funding round, and a product's operating reliability answer different questions. None tells you whether your chosen API endpoint meets your retention requirement, whether the contract covers a preview feature, or whether your team can migrate the workflow. Those need their own evidence.
Treat financial news as a reason to update the review, not as a substitute for it. Separate verified disclosures from estimates, note their date and scope, and avoid turning an index-inclusion story into an unsupported probability of provider failure. A useful procurement decision connects what is known about the supplier to the exposure your product actually carries.
Four Areas to Assess Before You Commit
Start with the workflow and its consequences. An internal drafting assistant and a customer-facing document-processing feature may use the same model but need different evidence, operating limits, and recovery plans. Assess each important use case across these four areas:
| Assessment area | Questions to resolve | Useful evidence |
|---|---|---|
| Commercial and financial exposure | Who supplies the service, what do we commit to, and what can change? | Applicable agreement, order form, dated supplier information, and usage scenarios |
| Data and permitted use | Which data and features are covered, where is data processed, and how is it retained? | DPA, feature-specific documentation, account settings, and processor inventory |
| Quality and lifecycle | Does it meet our task requirements, and how will model changes be managed? | Held-out evaluations, latency/load tests, model inventory, and retirement notices |
| Dependency and exit cost | What fails with this supplier, and what can we move elsewhere? | Dependency map, export test, replacement evaluation, and migration estimate |
Identify must-have requirements before comparing scores. If a route cannot process the relevant data under the required arrangement, a low token price does not compensate. Mark evidence as confirmed, conditional, or unknown, with a source and owner. An unknown is a review gap, not proof of either safety or impending failure.
Evaluate Financial Exposure Without Guessing Who Will Fail
Financial health matters, especially when the service is difficult to replace or you are making a large prepaid commitment. Ask finance or procurement to assess the supplier information available for the engagement. Keep the contracting entity and reporting period attached to every figure; a valuation, annualized revenue estimate, and audited cash balance are not interchangeable.
- What is disclosed? Request current financial information or supplier-assurance material where available. Distinguish completed financing from announced commitments and public reporting from estimates.
- What money are we putting at risk? Identify prepaid credits, minimum commitments, expiry rules, refund conditions, and the effect of ending the agreement early.
- Who is responsible for delivery? Record whether you contract directly, through a cloud platform, or through a reseller. An investor or infrastructure partnership is not itself a contractual guarantee to your company.
- What uncertainty can the product tolerate? A limited pilot may justify a different commitment from a revenue-critical service with a long migration path. Tie the decision to your exposure and available alternatives.
When disclosure is limited, document that limitation and consider a smaller commitment, shorter review interval, or better-tested exit path. Do not invent a bankruptcy likelihood to make the spreadsheet look complete. Changes in billing terms, support, ownership, or service commitments are reasons to revisit the assessment, even without a prediction about the supplier's finances.
Read the Agreement for the Service You Will Actually Use
The published OpenAI Services Agreement and Anthropic Commercial Terms address matters such as fees, service changes, suspension, customer content, and liability. Your applicable order form, service-specific terms, platform agreement, and negotiated provisions determine the actual arrangement. Keep the document versions used for the decision.
| Contract topic | Question for the review | Why it matters to engineering |
|---|---|---|
| Price and commitments | What rates, minimums, expiry dates, and change notices apply? | Forecasting cost and deciding when migration is economical |
| Model and feature lifecycle | What notice, support, or exceptions cover retirement and preview features? | Scheduling migration and avoiding unsupported dependencies |
| Availability and support | Is there an applicable SLA, what is measured, and what are the remedies? | Setting realistic service targets and escalation paths |
| Data and third-party features | Which processor, retention arrangement, regions, and connected services are covered? | Choosing eligible endpoints and configuring the application |
| Content rights and liability | What rights, obligations, exclusions, and indemnity conditions apply? | Defining permitted use and responsibility for outputs |
| Suspension and exit | When can access end, and what export or deletion options remain? | Preserving task state and completing a controlled exit |
Have engineering, the commercial owner, and the legal or privacy owner review the relevant parts together. A service credit does not complete a customer's interrupted job; an API wrapper does not create a contractual export right. Both contract terms and technical controls affect the exposure.
Separate Training Use, Retention, and Processing Location
"We do not train on your data" and "we do not store your data" are different commitments. OpenAI's enterprise privacy page says business data is not used for model training by default, while describing separate API retention rules and eligibility for zero data retention. Check the endpoint and feature documentation rather than applying one product's controls to the whole provider.
Anthropic's API retention documentation similarly distinguishes arrangements by organization, model, and feature. Stateful capabilities such as file storage or managed sessions have different storage needs from a basic generation request, and third-party integrations are outside the same blanket coverage. The documentation also distinguishes Anthropic-operated services from partner-operated platforms where another company is the processor.
Map a request from collection to deletion: source files, prompts, responses, provider-hosted assets, tool calls, application logs, and backups. Record which party holds each item, the processing location, retention settings, and how deletion is verified. Your own observability system can retain content even when the model endpoint has a stricter retention arrangement.
For each candidate, capture evidence that the required settings or contractual arrangement are enabled on the account you will deploy. Eligibility in a documentation table is not confirmation that your organization has it. Recheck the map when adding a new tool, hosting route, or stateful feature.
Treat Model Retirement as a Planned Maintenance Cost
Model lifecycle changes do not require financial distress at the supplier. Anthropic's deprecation documentation distinguishes deprecated models from retired models and notes that retirement schedules can differ by hosting platform. Record the exact model identifier and platform for each feature, the lifecycle status, and who receives notices.
Budget for evaluating a replacement, adapting prompts and output handling, load-testing, and rollout. Pin versions where supported, but do not mistake a pinned identifier for indefinite availability. Ask what notice and support apply to the model or feature you are buying, then compare that window with the time your team actually needs to migrate.
Measure Task Quality Instead of Assuming Model Equivalence
Evaluate OpenAI, Anthropic, or another candidate on the same representative workload and acceptance criteria. Keep prompt-development examples separate from the held-out comparison set. Include the languages, long inputs, missing information, and failure cases your users produce, and allow candidate-specific prompt tuning under comparable effort and cost constraints.
Measure accepted results, field-level errors, unsupported claims, required human correction, latency under load, and total cost. Valid JSON is evidence of format compliance, not factual correctness. Repeat representative cases because output can vary, and retain model, prompt, retrieval, and tool versions so a regression can be investigated.
Quality changes can come from your own retrieval data or integration as well as from a model update. Compare the complete workflow while keeping those factors visible. Make the approved task and its quality threshold part of the vendor record; passing one extraction task does not qualify the provider for every other feature.
What Would It Cost to Change Providers? A Worked Example
Switching cost is one of the most useful ways to measure lock-in. Estimate the work for one actual feature, including state and data dependencies. The example below assumes an internal engineering cost of $75/hour. These are illustrative planning inputs, not UData rates, a quotation, or a measured client migration.
| Migration work | Assumed hours | Cost at $75/hour |
|---|---|---|
| Inventory dependencies and define the replacement scope | 8 | $600 |
| Adapt provider integration and response handling | 24 | $1,800 |
| Tune prompts and run task-quality evaluations | 20 | $1,500 |
| Export or rebuild provider-dependent data and state | 12 | $900 |
| Stage rollout, monitoring, and rollback checks | 8 | $600 |
| Engineering subtotal | 72 | $5,400 |
Add an assumed $600 for temporary parallel API usage and validation infrastructure: the migration budget becomes $6,000. Include any additional procurement work, minimum commitments, retraining, reindexing, or downtime exposure that your own integration creates. Engineering hours are not elapsed calendar time; account approval and evaluation data can determine the schedule.
Now assume both providers meet the same quality requirements, and the monthly API bill falls from $1,200 to $800 at the same workload. If the new setup adds $100/month of maintenance, the net saving is $300/month. A $6,000 migration takes 20 months to repay on those assumptions. The cheaper token rate alone does not settle the decision.
You may still migrate for data requirements, availability, or a needed capability rather than direct savings. Separate those benefits from the payback calculation. Also stress-test your existing arrangement against longer prompts, more retries, lower cache hit rates, and higher volume: an unchanged price list can still produce a much larger bill. Our AI agent cost-control guide covers enforcement and usage accounting.
Choose the Amount of Provider Independence You Need
A portable integration and an immediately available fallback are different investments. Decide which you need from the feature's business impact and recovery target. There is no requirement to operate several providers for every low-volume internal feature.
| Approach | What it buys | What still needs work |
|---|---|---|
| One provider with a portable interface and owned state | Lower coupling and a clearer migration path | A replacement is not necessarily evaluated or ready to serve traffic |
| A tested alternate provider | A qualified option for approved tasks | Capacity, data eligibility, billing, and ongoing evaluation |
| Active routing across providers | Ongoing evidence about multiple routes and workload allocation | More integrations, prompt variants, monitoring, and account management |
| Self-hosted open-weight alternative | Control over selected model artifacts and serving | Licensing, infrastructure, quality, updates, and operational staffing |
Check shared dependencies: two models behind one gateway or billing account may fail together. Likewise, provider-hosted retrieval or an embedding index can remain a dependency after text generation moves. Test export and reconstruction of the state your feature needs. The AI model access and continuity guide covers fallback qualification and outage recovery in detail.
A Vendor Review Record You Can Reuse
Keep one record per significant workflow and service arrangement. The goal is a traceable decision, not a single unexplained risk score. This outline can become a document in your existing procurement or engineering tracker:
Workflow and business owner:
Provider, contracting entity, model, endpoint, and hosting platform:
Data categories, processing locations, and required controls:
Applicable agreements and document versions:
Measured quality, latency, and capacity; evaluation date:
Current usage cost and growth/stress assumptions:
Prepaid exposure and minimum commitments:
Provider-dependent data/state and export-test result:
Replacement option, migration work, and estimated cost:
Unresolved requirements, evidence needed, owner, and due date:
Decision: approved scope / conditional pilot / deferred
Next review date and events that trigger an earlier review:Attach the evidence behind each answer: relevant clauses, configuration records, evaluation results, usage reports, and an export or replacement test. Keep unknowns explicit rather than allowing an average score to hide a must-have requirement that has not been met.
- Approve a defined scope when the required evidence supports the use case. State the allowed models, features, data categories, and operating assumptions.
- Run a conditional pilot when a narrower scope can be evaluated while gaps are resolved. Give each condition an owner and completion date, and define what would permit expansion.
- Defer the dependency when a must-have requirement is unresolved or the migration and operating costs exceed what the product can support. Record what evidence or change would reopen the decision.
Keep the Assessment Current After Launch
Assign ongoing responsibilities instead of treating supplier approval as permanent. A practical schedule might combine monthly usage and incident review with a quarterly dependency review, adjusted for the importance and change rate of the service. Material changes should trigger review sooner:
- Model, API, or tool changes: engineering reruns the relevant quality and integration evaluations and updates the approved configuration.
- Pricing, volume, or commitment changes: finance and the product owner refresh the cost scenarios and check remaining prepaid exposure.
- New data or processing features: the data/privacy owner checks whether the existing arrangement still covers the workflow and its actual settings.
- Contract, ownership, or policy changes: the commercial and legal owners assess their effect on use rights, obligations, notices, and exit options.
- Incidents or missed service targets: operations records the product impact and recovery result; the workflow owner decides whether the dependency strategy needs to change.
For agentic features, keep provider approval separate from permission to act in your systems. A service may be suitable for generating drafts without being authorized to publish, merge, or modify customer records. Our AI agent governance guide covers that action-level control model.
How UData Can Support the Technical Assessment
UData's software development and automation services can help map AI dependencies, build task-quality evaluations, measure usage costs, and estimate or implement a provider migration. A focused first scope is one workflow with an evidence-backed comparison and a prioritized list of integration changes.
Bring the current model and hosting setup, sample tasks, usage reports, data requirements, and target service levels. Technical findings can feed your procurement, finance, and legal review. For implementation capacity within your own team, see our dedicated developers offering.
Make the Dependency Understandable and the Decision Reviewable
Choose an AI provider on evidence about the service you will use: task quality, commercial commitments, data handling, operating needs, and the cost of changing course. Preserve the evidence, name the owners, and revisit the decision when those conditions change. That is more useful than trying to infer product reliability from a valuation or stock-index headline.
Sources and Assessment Notes
- OpenAI Services Agreement — published commercial terms, customer content, service changes, and contractual responsibilities.
- Anthropic Commercial Terms of Service — commercial use, data, fees, suspension, and termination provisions.
- OpenAI enterprise privacy — business-data training commitments and separate product/API retention considerations.
- Anthropic API and data retention — organization, model, feature, and hosting-platform boundaries.
- Anthropic model deprecations — lifecycle definitions and platform-specific retirement guidance.
Reviewed for the September 25, 2026 revision. The checklist and migration budget are illustrative planning tools, not a financial forecast, client case study, or quotation. Public documentation can change; use the agreements and configuration applicable to your organization when making the decision.
Frequently Asked Questions
Assess the exact model, API feature, hosting route, account configuration, and contract. Cover commercial exposure, data handling and permitted use, measured task quality and model lifecycle, and the cost of exiting the dependency. Record evidence, unresolved requirements, owners, and review triggers.
No. A stock-index story does not establish whether your chosen service meets its quality, data, commercial, or operating requirements. Use verified supplier information as one input and assess the actual dependency rather than inferring a provider's failure probability from the headline.
No. Training use, storage, deletion, and processing location are separate questions. Check the exact endpoint, feature, model, platform, and enabled account arrangement. Provider-hosted files, external tools, application logs, and backups may have different retention rules.
Use the same representative tasks and acceptance criteria, with documented prompt variants for each candidate. Compare accepted results, correction effort, latency, capacity, total cost, data eligibility, contract terms, and migration effort. A strong general benchmark does not qualify every feature you plan to build.
No. A portable interface and application-owned state may be enough for a workflow that can tolerate a pause. A tested fallback or active routing requires additional evaluation, capacity, account management, and operational work. Choose the approach from the feature's impact and recovery needs.
It depends on adapters, prompts, evaluation coverage, data/state dependencies, rollout, and commercial commitments. The illustrative example here totals 72 engineering hours at $75/hour plus $600 for parallel usage and validation: $6,000. It is a planning example, not a standard migration price.