AI Data Residency for Business: Where Your Company Data Lives

AI data residency for business means knowing, for every part of your AI setup, where company data is stored, where it is processed and who can reach it from where. The model provider is only one of those places. Prompts, memory, retrieval indexes, logs, caches, backups and vendor support access each have their own location and retention, and each needs its own answer.

Key takeaways

• Residency has three parts: where data is stored, where it is processed, and who can access it from which location. A region setting on one component does not answer the other two.
• The model call is only one stop. Memory, retrieval indexes, logs, caches, backups and support tooling often hold more company data than the model provider does.
• Ask every component the same four questions: where is it, how long does it stay, who can read it, and how is it deleted.
• Write the answers into one data map with a named owner and a review schedule, because vendors, regions and subprocessors change over time.
• Decide by data class, not by tool. Some content can travel freely, some must stay in a region, and some should never reach the agent at all.

What does data residency mean when AI is involved?

In a traditional application, residency is often a single question: which region hosts the database. An AI setup splits that question into many. One request can pass through a messaging app, an agent runtime, a model provider, a document store and a logging service, and each of them may sit in a different country or be run by a different company.

It helps to separate three ideas that are often blurred together.

• Storage: where data rests, including copies nobody planned for, such as caches and backups.
• Processing: where data is read and computed on, for example where the model runs when a prompt is sent.
• Access: who can see the data and from which location, including vendor support staff and their subprocessors.

A provider can store data in one region and still allow processing or support access from another. That is why a sentence like "your data stays in the region" needs follow-up questions before it counts as an answer.

Rules matter here. Depending on where your company and your customers are, laws such as Brazil's LGPD (overseen by the ANPD), the EU's GDPR and the EU AI Act, along with sector rules and customer contracts, may restrict transfers or require specific safeguards. This article is not legal advice. Its purpose is to give you a complete map, so that when your counsel or a customer asks where data goes, you can answer from evidence instead of assumption.

Where can company data rest or travel in an AI setup?

The list below follows a request from the person to the model and back. Each place has the question that matters most for it. Throughout, the four base questions still apply: where, how long, who can read it, and how it is deleted. If you want the wider architecture behind these components, the seven layers of company AI infrastructure gives a plain-language tour.

• Channels and devices: chat apps, email, web forms and phones where people write to the agent. Ask: does the channel keep its own copy of every message, and in which region does that copy live?
• The agent runtime: the system that assembles instructions, runs steps and calls tools. Ask: which cloud region does it run in, and does it write temporary files or queues to disk?
• The model call: the prompt and the documents placed in it, sent to a model provider for processing. Ask: in which region is the request processed, is that region selectable, and is content used for training or retained for abuse monitoring, and for how long?
• Provider-side caching: some providers hold parts of a prompt briefly to speed up repeated requests (prompt caching is one documented example). Ask: what is cached, for how long, and does the cache follow the same region and retention rules as the main call?
• The memory store: facts, preferences and past decisions the agent keeps between conversations. Ask: where is it hosted, who can browse it, and can one entry be corrected or removed on request?
• The retrieval index and embeddings: the searchable copy of your documents. Ask: where does the index live, and does the embedding step send raw document text to a separate provider in another region?
• Connected business tools: the CRM, calendar, ticketing or accounting systems the agent reads from and writes to. Ask: does the agent pull data into its own storage, or read it on demand and discard it?
• Logs, traces and analytics: records of what the agent saw and did. Ask: do they contain full prompts and replies or only metadata, and where is the logging service hosted?
• Backups and exports: scheduled copies, snapshots and downloaded transcripts. Ask: are backups in the same region as the primary, and how long until a deleted item disappears from them?
• Evaluation sets and review tools: saved examples used to test the agent, and screens where people review its work. Ask: were real customer records copied into test sets, and who has access to them?
• Vendor and subprocessor access: support engineers, contractors and the vendors behind your vendors. Ask: which staff can view production data, from which countries, and under what approval?

Which places do teams forget to check?

Most teams ask about the model call first, which is reasonable, and then stop. The less visible places are usually where surprises appear.

Logs are the most common one. Observability tools exist to record what a system did, and conventions for generative AI telemetry (such as the OpenTelemetry work on this topic) allow prompts and responses to be captured as part of a trace. That is useful for debugging and risky for residency. Decide deliberately whether logs record content or only identifiers, timings and outcomes, and put the logging service inside the same region policy as everything else.

Derived data is the second one. An embedding is not a readable sentence, but it is computed from your document and can be tied back to it. A summary stored in memory can contain the most sensitive line of a contract. Treat derived data as the same class as its source. When someone asks for deletion, the source, the index entry, the memory entry and any cached summary all need to go, which is the subject of how to delete AI agent memory.

Backups and exports are the third. A system can honor a deletion request in its live database while a snapshot keeps the record for a further period. Ask for the backup retention period in writing, and do not assume it matches the live one.

The fourth is people. A region-locked database does not help if support staff in another country can open it with a shared credential. Access paths, approvals and audit trails belong in the same conversation as storage. A structured security review of an AI provider is a good place to collect these answers consistently.

How do you map your own setup, step by step?

Start with an example. The following is an illustrative scenario, not a real company.

Illustrative scenario: a freight company with offices in two countries gives an agent the job of drafting replies to customer emails about delayed shipments. A customer writes in and attaches a delivery note. The email sits in the mail provider's region. The agent runtime picks it up and searches the document index for the shipping contract, which lives in a third region. The prompt, containing the email text and contract clauses, goes to a model provider that processes it in a region set by configuration. The agent drafts a reply and stores a note in memory that this customer prefers phone calls. The full exchange is written to a log, and the log is copied nightly to a backup bucket. In that single request, data touched at least six systems. Only one of them was the model.

To build the same picture for your own agent, work through these steps.

• Step one: name the agent's role and list the data classes it will touch, such as public marketing text, customer contact details, contracts, employee records and financial data.
• Step two: draw the path of one real request from the first message to the final log entry, and write down every system on the path.
• Step three: for each system, record region, retention, who can read it and how deletion works, using the four base questions.
• Step four: mark every point where data crosses a border, a company boundary or a subprocessor.
• Step five: compare the map against your legal and contractual obligations, and list the gaps.
• Step six: close each gap by changing the region, removing the data from the path, redacting it before it leaves, or accepting the risk with a named owner.
• Step seven: assign an owner and a review date, and repeat the map whenever a vendor, region or integration changes.

After the map exists, use a simple decision guide by data class.

• Data that is already public: can travel to any component you trust, subject to ordinary quality checks.
• Internal but low-risk data: allowed where the provider's region, retention and training terms are documented and acceptable.
• Personal or regulated data: allowed only in components with a confirmed region, limited retention, restricted access and a deletion path.
• Data that contracts or rules forbid from leaving a region: processed only by components that stay inside it, or kept out of the agent's reach entirely.
• Secrets such as passwords and keys: never placed in prompts, memory or logs. They belong in a dedicated secrets store the agent uses without reading.

The last row is also a permissions matter. An agent that cannot read a data class cannot leak it, which is why scoped access, covered in read, draft and send as separate permissions, is part of residency and not a separate topic.

How does a managed approach handle data location?

Be Human treats data location as part of the design of the role, not as a clause added at the end. In a first engagement, the data classes the role will touch are listed, the systems on the request path are mapped, and region, retention and access are recorded for each one, together with the approval boundaries for what the agent may read or change. Memory, tools and channels are set up under the company's control, and logging is configured to capture what is needed for monitoring without storing more content than necessary. Under managed operations, the map is reviewed as part of recurring work such as permission review, integration maintenance and controlled changes, so that a new vendor region or a new connected tool is checked before it carries company data. What a given setup can offer depends on the model providers and tools chosen, so the answers are documented per component instead of assumed. For the recurring work in more detail, see what managed AI services include.

Frequently asked questions

Is data residency the same as data privacy? No. Privacy concerns how personal data is collected, used and protected, while residency concerns the location where data is stored, processed and accessed. They overlap, because some privacy rules restrict transfers across borders, but a setup can be in the right region and still handle personal data badly, or the reverse.

Does choosing a model provider with a regional option solve the problem? It solves one part. A regional model endpoint addresses where the prompt is processed, but memory, indexes, logs, backups and support access still need their own answers. Also confirm what the regional option covers, since some features, such as certain caches or monitoring, may be handled separately.

Should we avoid sending any company data to an AI model? Usually that is not necessary or practical. A more useful approach is to classify data, decide which classes may reach which components, and remove or redact the classes that should not travel. Public and low-risk content can often be used freely, while regulated or contract-restricted data needs confirmed regions, limited retention and controlled access.

How often should we review the data map? Review it whenever you add a tool, change a model or provider, open a new channel, or hear about a subprocessor change, and on a regular schedule even if nothing seems to have changed. Vendors adjust regions, retention and subprocessors over time, so a map that was correct at launch can drift without anyone noticing.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.