Enterprise AI search — assistants that index your mail, drives, tickets, and wikis and answer questions over them — is the AI deployment most likely to surprise a compliance team, because it quietly builds a derived copy of your most scattered regulated content and logs what everyone asks about it. Under strict data residency constraints, the product category is still deployable, but only through a deliberately chosen architecture with evidence to match. This page maps the data surfaces, compares the three viable architectures, and lists what each must prove.
The Data Surfaces a Search Assistant Creates

Three surfaces: the index it builds over your connected sources (a derived copy of regulated content), the query logs it records (which reveal what staff are looking for), and the AI-generated answers it serves (derived from the index) — plus the connectors' reach, since every connected SaaS source extends the data path.
| Surface | What it holds | The residency weight |
| The index | A derived copy of indexed content across sources | Re-identifiable even when sources are scattered — inherits full classification |
| Query logs | What staff asked, when, from where | Reveals organizational knowledge interests; often contains pasted content |
| AI answers | Generated responses citing retrieved content | Derived from regulated inputs; carries their classification |
| Connector reach | Access paths into mail, drives, tickets, wikis | Each connector extends the data path to a new source |
The index deserves the most attention because it is the surface teams forget: it is a derived copy of everything the connectors touched, compiled in one place that inherits the strictest classification of anything it indexed. Regulated-organization coverage makes the stakes plain — many cannot send queries to public cloud LLMs at all, which means the architecture that handles the index, the logs, and the inference must all respect the boundary. Map your candidate product's actual behavior on all three surfaces plus its connector reach, because products differ in what they log, where indexes live, and how connectors authenticate.
Three Architectures Under Residency Constraints
Three architectures work under strict residency: SaaS with regional commitments (vendor contracts to process and store in-region), VPC-isolated deployment (the product runs in your cloud tenancy), and self-hosted (the stack runs on infrastructure you control) — differing in who operates, what evidence each can produce, and how much the vendor's region commitments carry the compliance weight.
| Architecture | How it runs | Operating burden | Evidence it can produce |
| SaaS with regional commitments | Vendor operates; contract pins processing and storage to your region | Lowest | Contract terms; vendor attestations |
| VPC-isolated | Product deployed into your cloud tenancy; data plane in-region | Shared | Tenancy and network configuration; your own logs |
| Self-hosted | Full stack on infrastructure you control | Highest | Everything — boundary by construction |
Official guidance for strict-compliance organizations recommends regional deployments as the configuration with the highest data control, and the table shows why: each step from SaaS toward self-hosted converts contractual evidence into architectural evidence. The trade is operating burden — self-hosted search means your team runs indexing pipelines, vector stores, and the inference layer. Hybrid patterns exist (SaaS control plane with in-region data plane) and are classified by where the regulated surfaces — index, logs, answers — actually reside.
Evidence per Architecture Before Approval
Collect per architecture: the region commitments in contract (SaaS), the tenancy and network configuration (VPC), or the infrastructure boundary documentation (self-hosted) — plus the shared set: a data-flow diagram across index, logs, and answers, connector inventory with their data paths, access model documentation, and a sampled trace of one query end to end.
| Evidence item | Applies to | What it proves |
| Region commitments in contract | SaaS | Processing and storage pinned to your region |
| Tenancy and network configuration | VPC-isolated | Data plane resides in your controlled environment |
| Infrastructure boundary documentation | Self-hosted | The stack's location by construction |
| Data-flow diagram: index, logs, answers | All | Where each surface's data actually goes |
| Connector inventory with paths | All | Which sources feed the index and how |
| Access model documentation | All | Who can see indexes, logs, and answers |
| End-to-end query trace | All | One real query's full path, sampled and archived |
Residency-control guidance frames the requirement exactly this way — controls governing where systems store, process, and transmit sensitive files — and the end-to-end trace is the artifact that converts configuration claims into demonstrated behavior: one query, followed through indexing, retrieval, inference, logging, and every copy it left. The evidence proves configuration at its date; a quarterly sampled trace keeps it current, and connector additions trigger an out-of-cycle review since each new source extends the path.
FAQ
Do connectors to SaaS sources break data residency?
They can: connectors pull regulated content from mail, drives, and ticketing into the index, so the connector path is part of the residency surface — the control is an inventory of connected sources with their regions and terms, and connector-level approval before each new source is indexed.
Does the model answering queries also need to be in-region?
If queries or retrieved content are regulated, yes in practice: sending the query or retrieved passages to an out-of-region model recreates the cross-border flow the architecture was built to prevent — in-region models (or on-premises inference) are part of the architecture, not an add-on.
What is the right first architecture for a regulated deployment?
Start VPC-isolated in your regulated region: it keeps the index, logs, and inference inside a boundary you control while a vendor operates the product, and it upgrades to self-hosted later only if your evidence requirements outgrow what tenancy isolation can prove.