AI Procurement: Separate Data Storage from Processing

Imagine a small translation business evaluating an AI assistant for unpublished client manuals. The supplier points to a regional storage setting. The owner takes this to mean that every part of the proposed AI operation will happen there. The evidence supplied has answered a narrower question than the owner thinks.

This fictional purchase illustrates a useful distinction: where information is kept and where it is processed need separate answers. Before approving a workflow, identify the specific location claim, the service operation it covers and the configuration that makes it applicable.

Ask two location questions

Google Cloud’s data-residency documentation, updated on 28 October 2026, separates data stored at rest from machine-learning processing. For Gemini Enterprise Agent Platform, it says stored data remains in the selected storage location independently of the endpoint called. Requests to a global endpoint may be processed in Google Cloud locations around the world.

In ordinary purchasing language, ask where saved material remains, then ask where the model’s computation happens. A statement about the first question should remain attached to that question. It cannot supply a missing answer to the second.

Describe the intended boundary precisely. A particular country, a provider-defined geography and a multi-country zone are different descriptions. Ask the supplier to name the applicable boundary and explain how it matches the requirement your business has agreed for this work.

Read the deployment type beside the region

Microsoft’s Foundry data-privacy documentation makes the distinction concrete. For Global inference deployments of models sold by Azure, it permits prompt and response processing across geographies hosting the relevant model. It separately places data saved at rest for Global and DataZone deployments in the customer-designated geography.

The deployment-type guide, updated on 12 August 2026, distinguishes Global, Data Zone and geography-based processing options. It also says that not every model supports every deployment type. The documented choice involves more than the name of the resource’s region.

These are examples of provider-stated arrangements. For a purchase, obtain the exact model, deployment type or endpoint, and feature configuration proposed for your account. Ask the technical owner to show how those details connect with the relevant documentation. Keep provider-defined location terms intact rather than silently translating them into a narrower country promise.

Follow the information when it becomes a prompt

The same Microsoft privacy document describes its “on your data” feature: source data stays in the designated data source, while relevant material is retrieved to augment a prompt. The model then processes that augmented prompt. The source file’s storage address and the processing of its contents are separate parts of that documented journey.

For the fictional translation business, the next enquiry is specific. Would the proposed workflow send the whole manual, selected passages or only text the user pastes? Which service would receive that material, and what location commitment applies to that operation? Leave the answer unresolved until the supplier describes the actual arrangement.

A useful purchasing note follows the information through the proposed task: the original document, the material submitted for processing and the resulting output. Ask what is saved at each stage. Avoid treating the original file’s location as an explanation of everything downstream.

Check the features you intend to enable

Write down the functions included in the purchase. If the proposal includes uploaded files, stored conversation history, retrieval, web search or a separate integration, ask which location statement covers each function. This is a list of enquiries for a proposed system, rather than a claim that every AI product includes those features.

Keep that enquiry bounded. Online inference, model training and fine-tuning are different operations; evidence about one should identify its scope. A supplier’s answer should make clear which operations your team intends to use and which remain outside the proposed setup.

In the translation example, suppose the initial trial uses public sample paragraphs, while a later plan adds a connection to unpublished manuals. Describe the later plan as a changed workflow requiring its own evidence. The fact that both plans use the same supplier does not answer the new location questions.

Keep a short record of the supporting evidence

A small business can organise the enquiry without reproducing an entire technical manual. Keep a short record that connects the claim with the proposed configuration:

• Work and material: the task, the information submitted and any connected source.
• Operation and configuration: the model, deployment type or endpoint, and enabled features.
• Location claim: the boundary stated for storage and the boundary stated for processing.
• Evidence: the exact document, relevant section, update date and supplier clarification.
• Responsibility: who checks the setup and who must review a proposed change.

Preserve unanswered questions as unanswered. If two documents appear to describe different scopes, keep both references and ask the supplier which applies to this configuration. A confident summary should not erase an exception or replace a missing commitment.

For a wider supplier review, MaryChuks’ guide to reading the scope behind a security report explains how to connect assurance evidence with the service being purchased. A location statement and a security report each need to be read for the particular question they address.

Verify the setup and revisit changes

Ask the person configuring the service to compare its actual settings with the purchasing record. Documentation establishes what the provider says about an arrangement; the configuration check establishes which arrangement your team selected. A request returning a useful answer does not, by itself, establish where all processing occurred.

Choose the next step according to the evidence and the requirements already agreed for the material. In the fictional example, the owner could continue with public sample material while seeking clarification about unpublished manuals. That is an illustrative decision, not a universal rule for every business.

Keep a review point for a change in model, endpoint, deployment type, enabled feature or connected supplier. Ask whether the earlier location evidence still applies. Record the answer alongside the changed configuration so a later reviewer can reconstruct the decision.

The purchasing outcome should be an explanation your team can maintain: what information goes where, which statements support that account and what remains unresolved. A region label becomes useful when it sits inside that fuller description of the work.

Sources

Provider documentation checked on 29 October 2026. The translation business and its decisions are fictional; no customer environment or network route was tested. These examples concern the named services and documented configurations.

• Microsoft Learn: Data, privacy, and security for Models sold by Azure in Microsoft Foundry — updated 19 May 2026.
• Microsoft Learn: Deployment types for Microsoft Foundry Models — updated 12 August 2026.
• Google Cloud: Data residency for Gemini Enterprise Agent Platform — updated 28 October 2026.