Data Residency for AI Agents: Where Memory, Logs and Model Calls Live

Data residency for a company AI layer answers one question: in which country or region do the agent's memory, logs and model calls physically live, and who can reach them? An agent setup keeps company data in at least three places, and each needs a written answer before regulated records go in. This guide walks through each place and gives you the questions to ask any provider first.

Key takeaways

• Residency covers three places: memory stores, logs and traces, and the model calls that carry prompts and retrieved text.
• Each place can be copied to a backup, a cache, a support tool or a subprocessor, so location questions must follow every copy.
• Get written answers on region, retention, training use and access before any regulated record enters the system.
• Decide the residency design in the first engagement, then review it whenever a model, connector or vendor changes.

Why residency is three questions, not one

Most residency conversations start with the model provider and stop there. For a company superintelligence layer, the material that gets stored or transmitted is much wider. An agent that keeps memory, reads your documents, calls tools and writes logs creates copies of company data in several places. Each copy has its own location, its own retention rule and its own list of people who can access it.

Regulators and enterprise buyers ask about the flow of data, not only its final destination. A useful habit is to draw the path one customer question takes through the system: where the request enters, what gets retrieved, what leaves your boundary, and what gets written down. Every arrow on that drawing is a residency question, and every box is a place where a copy may exist.

Where agent memory physically lives

Memory in a business agent is rarely one thing. It usually includes structured records such as client profiles or order history, documents indexed for search, summaries of past conversations, and the settings that define what the agent is allowed to remember. These pieces may sit in different systems, sometimes in different regions.

Retrieval-based designs keep source documents in a store you control and send only relevant excerpts to the model at request time. That narrows what leaves your boundary, but the excerpts still travel with each call, so they need the same residency answer as everything else. Ask where the search index is built and stored, whether embeddings are produced by an external service and where that service runs, and whether deleted records are removed from indexes and backups on a known schedule. Deletion is the question teams most often skip. A record removed from the main database can persist in an index or a snapshot for a long time if nobody owns that cleanup.

Before deciding where memory lives, decide what the agent should keep at all. The guide on AI memory vs chat history: what should your agent remember? helps separate durable facts from transient conversation.

Logs and traces hold regulated data too

Observability is necessary for running agents safely. Traces record each step: the prompt, the retrieved passages, the tool arguments, the responses and the errors. Those records help with debugging and audits, and they are also a complete copy of whatever sensitive content passed through the agent. The OpenTelemetry observability primer describes logs, traces and metrics as distinct signals that each need handling. In an agent system, the trace is often where personal data hides, because it captures everything the model saw.

Ask which logging or monitoring tool receives these events, whether that tool runs in the same region as the rest of the system, how long traces persist, who can read them, and whether personal identifiers can be masked before export. Many exposures begin with a well-meaning person pasting a trace into a shared channel to get help. Set the rule before that moment arrives. For the recording standard itself, see AI Agent Audit Trail Requirements for Regulated Companies.

What happens during a model call

Each model call sends a payload: instructions, conversation context, retrieved text and tool outputs. That payload crosses into the provider's infrastructure, and four facts determine your exposure. First, where the request is processed. Second, whether the provider keeps the payload for a period for safety monitoring or abuse review. Third, whether any caching stores it and for how long. Fourth, whether the content can be used to train or improve models. Each answer should be in writing and tied to the account type and service you actually buy, not inferred from a marketing page. Enterprise terms and standard plans often differ.

Region selection, where a provider offers it, is only one control. A provider in the correct region may still rely on a subprocessor elsewhere for support, monitoring or infrastructure. Follow the chain through the provider's subprocessor list and the processing terms in the contract. The reasoning behind those documents is covered in Data Processing Agreement for AI Vendors: What to Check and AI Vendor Subprocessors: Who Else Handles Your Company Data?.

Questions to ask before storing regulated records

Use this list in the vendor call, and keep the written answers in your AI risk file.

• Which country or region stores our memory index and source documents, and can that location be fixed in the contract?
• Which region processes each model call, and do backups and fallback routes stay in the same region?
• How long are prompts, outputs and traces kept by default, and what changes on our account type?
• Is customer or employee content used to train or improve models, and can that be disabled in writing?
• Which subprocessors touch the payload, logs or support data, and where does each one operate?
• Can we delete one person's records from memory, indexes, traces and backups, and how long does that take?
• Who at the provider can read our content for support or safety review, and what access controls apply?
• What happens to our data when we stop the service, including export format and deletion confirmation?
• Will we receive notice before the model, region or subprocessor list changes?

If a provider cannot answer several of these in writing, treat that as a finding, not a formality.

An illustrative scenario and how managed operations handle it

Illustrative scenario: an accounting office wants an agent to answer client questions from filed tax folders. The first design placed the search index in a vendor's default region, sent full documents into every prompt, and exported traces to a monitoring tool in another region. The review used the questions above. The team moved the index into their own regional cloud account, changed retrieval to send only the relevant paragraphs, masked tax identifiers before traces left the system, and wrote down which subprocessor could see which payload. The residency decisions went into the risk register alongside the permission tiers for each action.

Be Human designs and operates the layer around the model, including memory stores, tool connections, trace settings and permission boundaries. The first engagement defines one useful role and records where each store and log lives and which vendor touches it. Managed operations then include permission review, integration maintenance and incident response, so the residency design is checked again when a connector, model or subprocessor changes. The work is delivered remotely in English and Portuguese.

Decide, document and review residency before launch

Residency works best as a written decision, not as a setting someone remembers. A simple sequence keeps the work manageable:

• Draw the data path for one real task, from the incoming request to every stored copy.
• Classify each copy as memory, log, model payload or backup, and mark which ones hold regulated records.
• Record the region, retention period and subprocessor for each copy, with the source document beside it.
• Mask identifiers in traces and limit who can read them, both inside your team and at the vendor.
• Write a deletion procedure that covers indexes and backups, and test it on one record before launch.
• Review the design whenever a model, connector or vendor changes, and log the review date and the result.

If you are not sure which task should go first, take the free Be Human AI diagnostic to find the first task worth handing to an agent.

Frequently asked questions

Does data residency mean the model runs in my country? Not always. Some providers let you select a processing region for certain models and products, while others process requests in several regions. Ask for the processing location in writing for the exact service you purchase.

Is choosing a region in the provider's console enough? Usually not. Region settings often cover primary storage and processing, but backups, support access, monitoring tools and subprocessors can sit elsewhere. Map the full chain before relying on a single setting.

Should we keep agent memory on our own servers? It depends on the records involved. Keeping the memory index and source documents in an account you control narrows exposure, but it adds operational work. Decide per record type, and revisit the trade-off when volume or risk changes.

When should legal counsel be involved? Involve counsel before regulated records enter the system, especially when you process personal data covered by national rules such as Brazil's LGPD or the EU AI Act. Counsel should review the contract terms alongside the processing map. A technical answer alone does not settle legal obligations.

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