AI Model, API and Provider Dependencies

A practical procurement guide to understanding and controlling AI model, API and provider dependencies.

Most AI products are not self-contained. They may depend on foundation models, cloud platforms, vector databases, moderation services, speech APIs, search providers, external data sources and other subprocessors. Procurement should make those dependencies visible before award.

Map the dependency chain

Record the supplier, named product, model providers, model families, hosting, retrieval/vector services, external APIs, data sources and critical subprocessors. Identify which component performs which function.

Understand data exposure

For every material dependency, ask what customer data can reach it, where processing occurs, how long data is retained, whether it is used for training or improvement and what contractual terms apply.

Identify change authority

A supplier may be able to swap a model, API or subprocessor without a conventional software release. Buyers should know which changes require notice, approval, regression testing or reassessment.

Assess concentration and continuity risk

Consider what happens if a provider becomes unavailable, changes terms, deprecates a model, raises prices, alters geography or experiences a security incident. Critical services may need contingency or exit arrangements.

Check scope of third-party assurance

A cloud or model provider's certifications can be useful evidence, but they do not automatically prove that the supplier's complete product architecture is secure or appropriate. Verify how third-party controls combine with the supplier's own controls.

Preserve the evaluated baseline

At award and go-live, record the material model/provider configuration. Monitoring should detect later changes that could alter security, privacy, performance, legal exposure or human-oversight requirements.

Contract controls

Depending on risk, contracts may address:

  • material model/provider changes;
  • subprocessor notification;
  • data-use restrictions;
  • geographic processing changes;
  • regression evidence;
  • continuity and exit;
  • reassessment triggers.

How AI TrustMark fits

AI TrustMark can independently verify declared dependencies and evidence relevant to the named product and assessed configuration. It does not treat a third-party provider's certification as proof of the complete service.

Organisation-specific architecture mapping, dependency-risk analysis, contractual controls and evidence verification remain professional services.

Return to the AI Procurement Knowledge Base or continue to Contract for AI Services.