Choose an AI model provider by workload, not brand

Write the workload before opening a provider comparison

Provider selection often starts with a brand, a benchmark or a procurement preference. Begin instead with the product job: who uses the capability, what input enters, what output is needed, whether it can take action, how errors are handled and what human review remains. A retrieval assistant, document-drafting tool, voice workflow, classification route and agentic integration can have materially different requirements even if each uses a language model.

Define the non-negotiables and the trade-offs. These may include supported regions, data classes, retention or training terms, authentication, tool calling, latency, throughput, evaluation quality, accessibility of the user experience, contract route, support, cost controls, portability and the ability to pause or replace the dependency. Use current official provider documentation for product-specific statements; provider policies and capabilities change.

Assess data handling at the complete workload boundary

A provider's headline privacy statement is not a complete architecture decision. Map the path of prompts, files, embeddings, outputs, telemetry, support records, backups, user identity and downstream integrations. Identify what may contain personal, confidential, commercial or regulated information, which party determines purposes and means where relevant, and which legal/contractual review is needed. The ICO's AI guidance is relevant when personal data is involved, but it does not select a provider for an organisation.

UK data residency should be expressed precisely. It may refer to a chosen regional endpoint, while logs, backups, support access or subcontracted services have their own terms. Do not publish or promise UK-only processing unless the actual workload, provider contract and configuration support it. Record the selected route in the architecture and procurement evidence rather than relying on a marketing label.

Design for dependency, change and exit

A provider decision creates an operating dependency. Document service limits, rate behaviour, error modes, region availability, support route, pricing model and change-notification mechanisms relevant to the selected product. Build an application boundary that can validate input/output and avoid scattering provider-specific assumptions throughout the product. Complete abstraction is not always worth the cost, but hidden coupling makes later change much harder to assess.

An exit plan need not promise instant replacement. It should say what would be needed to change configuration or provider: evaluation assets, prompt/instruction portability, data export or deletion route where applicable, tool contract changes, regression tests and a communication plan for affected users. The presence of a plan is not a claim that every provider can be substituted without cost or risk.

Create a decision record that survives procurement and release

The decision record should name the candidate options considered, the workflow, criteria, evidence, selected configuration, data and region assumptions, limitations, responsible owner and review date. Link it to the security, privacy and release records rather than keeping a provider spreadsheet detached from the implementation. This lets a team answer later questions about why a particular route was chosen and what would trigger reassessment.

Revisit the decision when the workload changes: new data classes, new user groups, tool actions, regions, a provider policy change, a material evaluation regression or an expanded operating commitment. A mature choice is not one that never changes; it is one whose reasons, constraints and review mechanism are visible.

A working check before committing the next stage.

• 01

  Describe the workflow, user, decision and allowed tool actions.

• 02

  Map prompts, files, telemetry, logs, backups and downstream systems.

• 03

  Compare candidates using representative tasks and failure cases.

• 04

  Check current official documentation for regions, terms and support.

• 05

  Record cost, rate, error, change and exit assumptions.

• 06

  Set a named review trigger for a changed workload or provider policy.