Keeping SharePoint data in region for AI: where prompts, embeddings and indexes go

23 October 2026

Tags: Warehouses and lakesSearch and vector storesAIDesktopCommand line

The question usually arrives in an email from the data protection officer, a day after someone demonstrated an AI assistant answering questions about a SharePoint list. In the example this post follows (an illustrative organisation, not a customer), a UK housing association keeps its repairs and complaints in a list of about 2,400 open cases, each with a tenant’s name, an address and a free-text description of what went wrong. The operations team wants to ask it things in plain English. The DPO wants one answer first: “If we put AI on this list, does any of it leave the UK?”

Nobody in the room could answer with confidence, and that is the normal position. The honest answer depends on which product does the AI, which deployment type someone picked in the Azure portal, where the index lives and what each service logs. This post maps every hop, with what Microsoft commits to at each one as of 23 October 2026, so the answer to the DPO is a table rather than a guess.

Does AI on SharePoint data send it outside the UK or EU?

It can, and the answer changes from one hop to the next. Microsoft defines data residency as where data is stored or processed, and its Microsoft 365 overview separates the two: data at rest follows your tenant’s default geography, while data in processing is described as a separate concern, with the detailed documentation for it still to be published (Learn, What is Microsoft 365 Data Residency?, updated 8 October 2026).

That split matters more for AI than for anything else in Microsoft 365. A document sitting in SharePoint is data at rest. A prompt that quotes three of its rows, sent to a model for an answer, is data in processing, and most of the commitments people remember are about the first kind.

For a UK organisation there is a second wrinkle. The EU Data Boundary covers the countries of the EU and EFTA, and Learn lists them; the United Kingdom is not among them (What is the EU Data Boundary?, updated 22 July 2026). Any promise phrased as “stays in the EU” says nothing about the UK either way.

The four places SharePoint data can leave region

Every AI setup over SharePoint data, from Copilot to a script a developer wrote last week, moves the data through some of these four hops:

1. The inference endpoint, where a model reads your rows in a prompt and writes an answer.
2. The embedding call, where text is turned into vectors for semantic search, once when it is indexed and again for every query.
3. The vector store or search index, where those vectors and usually a copy of the text are kept.
4. The logs, kept by each service in the chain, which may hold prompts, object names or row identifiers.

Write those four down with a region against each and you have the document the DPO needs. The sections below fill in what Microsoft commits to at each hop.

What do Microsoft’s Copilot data residency commitments cover?

Microsoft 365 Copilot was added as a covered workload in the data residency commitments of the Microsoft Product Terms on 1 March 2024. Prompts, the data they retrieve and the responses are stored in line with the commitments for your other Microsoft 365 content. For processing, Copilot’s calls to the model go to the closest datacentres in the region, but can also call into other regions where capacity is available when demand is high. EU users get an extra safeguard: EU traffic stays within the EU Data Boundary. Customers outside the EU “may have their queries processed in the US, EU, or other regions” (Learn, Data, privacy, and security for Microsoft 365 Copilot, updated 8 October 2026). The same page notes that models provided by Anthropic as a subprocessor are currently excluded from the EU Data Boundary.

Two limits on that commitment are easy to miss. A tenant with Multi-Geo is not in scope for the EU Data Boundary even when its country is in the EU or EFTA (EU Data Boundary page, above). And Copilot Studio is a Power Platform service with its own rules: its generative AI features draw on Azure OpenAI and Bing, and using them from an environment outside the United States moves data across regional boundaries once an administrator turns that movement on (Learn, Configure data movement across geographic locations, updated 7 October 2026).

None of this reaches an agent your developers built themselves. If the agent calls its own model endpoint and reads its own index, Copilot’s commitments do not apply to it, and each of the four hops is whatever your team configured. Our governance resource for custom agents covers the permissions and audit side of that agent; this post covers the geography.

Azure OpenAI deployment types decide where prompts are processed

Most custom agents in a Microsoft 365 organisation call a model in Azure OpenAI, now part of Microsoft Foundry. The resource has a region, and many teams assume that region is where their prompts go. Learn is explicit that the deployment type decides it, not the resource (Learn, Deployment types for Microsoft Foundry Models, updated 12 August 2026):

Data stored at rest stays in the resource’s Azure geography for every type. The EU data zone follows the Azure EU Data Boundary, which covers EU and EFTA countries and not the UK, so Data Zone processing does not meet a UK-only requirement. Learn’s own advice is to start with Global Standard, because new models arrive there first and geography-based types arrive last, “with no guaranteed availability date”. If you need UK-only processing, check the model’s availability for a Standard deployment in your region before you design around it.

The same page applies to the embedding model, which is just another deployment. Learn’s data privacy page for these models adds that abuse monitoring keeps a store of flagged prompts and completions in the geography of your resource, and that for models deployed in the European Economic Area the Microsoft staff who review them are located there too (Learn, Data, privacy, and security for Foundry Models sold by Azure, updated 5 June 2026).

Where does an Azure AI Search index keep its data?

In the geography of the region you picked when you created the service. Azure AI Search stores and processes your data there, and may replicate it to other regions in the same geography for high availability; Brazil South is the exception, where data stays in the region. Data leaves the geography only if you configure features that write to Azure Storage elsewhere, such as an enrichment cache, debug sessions or a knowledge store (Learn, Built-in security for Azure AI Search, updated 2 July 2026).

The query side has its own embedding call. A vectorizer defined on the index calls an embedding model at query time, and Learn recommends deploying that model in the same region as the search service (Learn, Configure a vectorizer, updated 17 September 2026). SPSync fills the vector field from its own embedding call and does not add a vectorizer to the index, so your app embeds each question itself, with the same model, at whatever endpoint it calls. That endpoint belongs on the DPO’s table too.

Logs are the hop people forget

The same security page for Azure AI Search warns that index, field and indexer names “might also be processed outside your selected region”, because they appear in telemetry logs Microsoft uses for support, and advises keeping sensitive data out of object names. An index called complaints-flat-12-oakwood-road would be a small leak of its own.

Your own logs count as well. An agent that writes every prompt and answer to an application log has made a copy of the rows it read, in whatever region that log is kept. SPSync’s run logs are JSON-lines files on the machine that runs it, naming the sites, lists and run events, with credentials redacted before anything is written.

How do you keep SharePoint data in region for an LLM?

Make every hop a place you chose. The pattern that does it is a replica of the list in a database you host, with the model and the embedding call either in a region you control or on your own hardware.

The replica sits where you put it

SPSync’s desktop app and command line run on your own machine or server. They read the list through Microsoft Graph and write the rows into your own database, and SPSync receives none of the list data. The replica’s region is the region of that database: a SQL Server in your own data centre, a Postgres server in UK South, or a DuckDB file on a laptop that never leaves the office. SPSync copies list items and library metadata, not the text of files, so a document’s contents never enter the replica at all.

Pick the embedding endpoint yourself

For the pgvector and Azure AI Search destinations, SPSync can embed chosen text columns on every sync and re-embed only the rows whose text changed. It supports three providers, and the choice is where your text goes:

• azure-openai sends text to the Azure OpenAI endpoint you name in an environment variable, using your deployment name. Processing follows that deployment’s type, so a Standard deployment in your geography keeps the embedding call there.
• openai sends text to OpenAI’s public API. SPSync does not set a region for it, so treat it as outside region unless your agreement with OpenAI says otherwise.
• local runs a fastembed model on the machine doing the sync. There is no endpoint and no API key; the default BAAI/bge-small-en-v1.5 produces vectors of 384 dimensions.

For a UK team using Azure OpenAI, the destination block looks like this, with the endpoint pointing at a Standard deployment in UK South:

destination:
  kind: pgvector
  connection_string_env: REPAIRS_DB_URL
  dataset_name: repairs
  pgvector_embedding_provider: azure-openai
  pgvector_embedding_model: repairs-embed-uksouth   # your deployment name
  pgvector_embedding_dimensions: 1536
  pgvector_embedding_columns: [title, description]
  pgvector_api_key_env: AOAI_API_KEY
  pgvector_azure_endpoint_env: AOAI_ENDPOINT

The Azure AI Search destination takes the same settings under azure_ai_search_embedding_* names. Whichever you use, embed each user’s question with the same model, at the same kind of endpoint, or the similarity scores mean nothing.

Private AI on SharePoint data, with every hop on your own hardware

When the DPO’s answer is “nothing leaves the building”, use a local embedding model with SharePoint data and a local LLM over the replica. Set the provider to local, and the only outbound traffic after the first run is SPSync reading SharePoint itself:

  pgvector_embedding_provider: local
  pgvector_embedding_model: BAAI/bge-small-en-v1.5
  pgvector_embedding_dimensions: 384

The model weights download once on first use and are cached, so plan that download before the server loses its internet access. For the answering model, Ollama runs models locally, and its documentation says it does not see prompts or data when you run locally; it also offers cloud models, which you can switch off with OLLAMA_NO_CLOUD=1 or a setting in ~/.ollama/server.json. Our post on running a local model over a DuckDB replica walks through that setup end to end, including a read-only database tool for the model.

DuckDB and SQLite get the rows and no embeddings from SPSync. On those, the local model answers by writing SQL, which suits counting and filtering questions better than similarity search does anyway.

A residency table for the data protection officer

Here is the table the housing association sent back, with the UK-only choice at each hop:

Two cells are worth arguing about in your own version. The answering model could be local too, at the cost of a smaller model. And if the team later wants Copilot or Copilot Studio over the same data, those rows need their own line, following the commitments described earlier rather than this table.

If the alternative on the table is a flow that sends each changed item to an embedding API, the same deployment-type question applies to the URL in its HTTP action; our comparison with Power Automate covers the other trade-offs.

What the replica does not change

The replica fixes where data sits. It does not decide who may read it. SharePoint item permissions are not carried into the replica, so every row arrives in the table whoever could open it in SharePoint, and views, database roles or row-level security are the control. The governance resource shows how to set those up for an agent’s login.

SPSync is one way. SharePoint stays the system of record, and the replica is read by whatever you point at it; write-back to SharePoint is designed but not shipped. SPSync also ships no agent, so the model, its tools and its region are your choice, which is the reason this approach can answer the DPO’s question at all.

For the semantic search side in more depth, see semantic search over SharePoint lists with embeddings and the post on keeping a SharePoint vector index current.