Choosing an AI provider around your data requirements

A model is only a viable choice if the complete service fits the task and its data requirements. Quality, latency and price matter, but so do the information sent, where it is processed, what is retained and who can access it.

Define those requirements before comparing providers. They may lead to a managed API, a controlled cloud deployment or a local model. None is automatically the most secure option; each places different responsibilities on the organisation operating it.

The useful comparison is between complete configurations that the organisation is permitted and able to use.

Map what actually leaves the application

Begin with a specific feature. Identify who starts it, what records it reads, what context the application adds and whether the result is a draft or an action.

Trace the information through retrieval, model requests, tools and output storage. Include caches, analytics, error reporting and evaluation. A production request can be handled carefully while a debugging service receives an unnecessary copy.

Derived data needs attention too. A summary or embedding may reveal information about its source. Do not assume a transformation removes the source's sensitivity or retention requirements.

Ask whether the feature needs every field being sent. Reducing context can improve privacy, cost and latency, but it can also remove evidence the task needs. Evaluate the reduced input rather than assuming it is either sufficient or useless.

This map provides the basis for selection. A provider name alone says little about the configuration and data path an application will use.

Turn requirements into specific questions

Replace broad terms such as “private” or “enterprise-grade” with conditions that evidence can address. Record where each requirement comes from and who can interpret or approve it.

Important questions often include:

• Which data classes may the feature process, including in development and support?
• What content can persist, for what purpose and for how long?
• Where may processing, storage, backups and support access occur?
• Who can administer the service, inspect content or change its settings?
• Which contractual commitments and assurance material are required?

Separate mandatory conditions from preferences. A preferred region may be negotiable; a contractual restriction may not be. Technical selection should not silently reinterpret either.

Training use is only one retention question. A provider may exclude submitted data from training while retaining it for another purpose. Examine the terms and settings for the actual service and account, including any exceptions that apply.

For legal or contractual requirements, involve the responsible specialist. An engineer can map the data path and test observable controls without claiming to settle the legal meaning of an agreement.

Separate three kinds of capability

Model capability concerns the task: input types, output quality, context, tool use and behaviour when evidence is missing. Evaluate it on representative work.

Provider controls concern delivery of the service: accounts, regions, retention, administration, service commitments and applicable terms. Check their scope and whether the proposed account can use them.

Application controls concern your software: user identity, record access, context selection, validation, approval, logging and recovery. These remain necessary even when the provider has strong controls.

A model's instruction to respect permissions does not replace an application access check. A contract cannot show that the application selected the right endpoint. A provider audit does not prove that your tools reject an invalid state change.

This separation helps assign work. It also prevents a strong result in one category from hiding a gap in another.

Match each claim to evidence

Published documentation describes the provider's stated behaviour. Terms establish obligations within their scope. Configuration shows how an account is set. Tests verify behaviour visible through an interface. Independent assurance has its own scope and assessment period.

Use the combination appropriate to each requirement. As a constructed example, a content-retention requirement might need applicable terms, service documentation and an account setting. Application review would also check what the product's own logs retain.

A test request cannot establish an internal deletion process that you cannot observe. Record that dependence on provider evidence rather than presenting it as directly verified.

Keep a compact record of the requirement, evidence, scope, date, owner and remaining gap. If evidence is missing, decide whether to reduce the data, change the design, seek clarification or reject the option. Acceptance of residual risk belongs with the person authorised to make that decision.

The NIST AI Risk Management Framework and Generative AI Profile provide broader risk-management guidance. They do not approve an individual provider or replace evidence about a particular configuration.

Compare deployment and operating costs

A managed API reduces infrastructure work but places service operation outside your environment. A controlled cloud deployment changes some network and identity responsibilities; check which support and control-plane paths remain external.

Self-hosting gives more direct control over processing and transfers responsibility for capacity, patching, model files, inference software and monitoring. A local model can support disconnected work, but device limits and update management become part of the design.

Compare these options against the same task. Measure latency from the user's action to a useful result, including retrieval, retries and review. Model price alone does not represent the cost of a completed task.

Plan failure behaviour. A fallback provider must satisfy the same data restrictions. A manual or reduced-function path may be safer than automatically sending a failed request elsewhere. Evaluating an AI feature before release describes how to assess the remaining candidates.

Record what would reopen the choice

Record the chosen service, model, account, region and important settings, together with the task and data classes covered. State which application controls remain to be implemented and who owns operation.

Identify review triggers: a model replacement, changed terms, new data, a different region, new tools or a material shift in cost and latency. Keep configuration and credentials separate from application logic, and maintain evaluations that can compare a replacement.

A shared API wrapper can reduce integration work. It cannot make models equivalent: their behaviour and supported features may differ. Changing provider still needs evaluation and may require product changes.

Choose within the requirements, test the complete task, and preserve enough evidence to explain the decision later. That produces a selection the team can maintain as both the product and its providers change.