---
Title: "Where does the prompt go? AI agent data residency and retention"
Url: "https://devrev.ai/blog/where-prompt-go-data-residency-retention"
Published: "2026-10-15"
Last Updated: "2026-10-16"
Author: "DevRev Editorial"
Category: "Blog, AI Quality & Trust"
Excerpt: "A residency label covers one surface. This decision memo traces each place a prompt can go for one named configuration, and why production stayed on hold."
Reading Time: 9
---

# Where does the prompt go? AI agent data residency and retention

_A decision memo on one named configuration, with the evidence file behind every row._

**Decision: pilot only; production held.** Vendor Q’s “EU data residency” label covers stored conversation history. It doesn’t yet answer inference on route B, the prompt cache, safety and support logs, feedback reuse, or a US overflow subprocessor.

This is an illustrative memo, written for Fernhill Mutual, an invented insurer, and its procurement lead, Sasha Anand. Vendor Q, Model Provider M, and the evidence rows are made up for teaching. No real vendor, customer data, or test result appears, and nothing here describes a DevRev product.

Sasha’s team had closed a vendor review on that label alone. Three weeks later, privacy counsel asked where the safety logs live and which subprocessor handles overflow inference. Nobody could answer.

The residency claim had only ever described stored data. A prompt doesn’t sit in one place. It gets stored, processed, logged, cached, and sometimes passed to another company, and each step can follow a different rule.

## What a residency label actually covers

One label usually describes one surface. A full answer on AI agent data residency covers six dimensions, each with its own geography and retention rule:

- **Storage and caches:** history, files, retrieval indexes, and backups. Caches can be temporary, in memory, or persisted, so identify each one.
- **Inference:** where the model processes the prompt, which can differ from where the result is stored.
- **Safety and operational logs:** abuse monitoring, telemetry, and support records that may hold prompt content.
- **Training use:** whether content or feedback is reused to improve models.
- **Subprocessors:** other companies that handle the data, and where they operate.
- **Contractual commitment and transfer:** not a place the prompt goes, but the terms that commit each answer and govern cross-border movement.

Two terms need extra care. **Zero data retention (ZDR)** is a provider term, not a universal definition. Its scope depends on the provider, endpoint, feature, and eligibility, and published exceptions can leave caches or application state outside it. It never means the prompt wasn’t processed.

A “no training” promise is a separate claim about reuse. It says nothing about retention or deletion. A vendor can delete history after a set period and still keep logs longer.

If this review sits inside a wider regulatory program, the [EU AI Act compliance](https://devrev.ai/blog/eu-ai-act-compliance) guide covers that context.

## The configuration under review

Answers change with configuration, so Fernhill named one for the initial review. Vendor Q’s Enterprise plan, EU workspace, model route B, web search off, and feedback on. Change the plan, region setting, model route, or an optional feature, and the path can change with it.

The test input was a synthetic support ticket simulating personal-data fields, like a customer name and policy number. The retrieval corpus was a synthetic knowledge base, and test accounts used invented identities.

Fernhill’s requirement was plain. Customer content must be stored and processed in the EU and kept out of logs outside the EU. It must never be used for training, and deletion at contract end needs stated coverage.

Sasha’s team graded every row on the same scale.

**Claimed** means a sales, marketing, or verbal statement. A written representation, like a sales email, is a record to confirm against applicable terms. **Documented** means published product terms or official docs for this exact configuration. **Contractually committed** means a term in the executed agreement or documents it incorporates, as counsel confirms.

That scale covers only the data surface. The [AI agent security](https://devrev.ai/blog/ai-agent-security) framework applies the same discipline across data, actions, and outputs.

## The evidence file, row by row

Eight artifacts, eight answers. Only one is committed.

| Artifact | Owner | Evidence found | State | Remediation and result |
| --- | --- | --- | --- | --- |
| Conversation history | Vendor Q | DPA hosting annex names EU hosting for customer content | Committed | None needed; clause text reviewed |
| Retrieval index of Fernhill’s knowledge base | Vendor Q stores it; Fernhill owns the source | Product terms say indexes follow the workspace region | Documented | Amended DPA annex naming the index received in draft; not yet incorporated into the agreement |
| Inference on route B | Vendor Q and fictional Model Provider M | Trust page says “EU processing available” | Claimed | Order-form clause naming route B’s region drafted by Vendor Q; unsigned |
| Prompt cache | Vendor Q | Docs silent; vendor email says “in-region, short lifetime” | UNKNOWN (written representation only) | Email recorded; no term found, and in-memory vs persisted is unstated |
| Safety and abuse logs | Model Provider M | Vendor Q says M offers “zero retention” on its API | UNKNOWN | M’s log terms for route B requested; not received by review date |
| Support and telemetry logs | Vendor Q | DPA says “service data may be processed globally” | UNKNOWN (vague clause) | Vendor Q hasn’t confirmed whether service data can include content |
| Training and feedback | Vendor Q | Terms exclude customer content from training; silent on feedback | UNKNOWN for feedback | Feedback turned off in admin settings; no term states what the setting excludes |
| Subprocessors and backups | Vendor Q | List shows Model Provider M in the US for “overflow”; deletion terms say “per backup cycle” | Documented gap | Counsel review opened; transfer basis and backup deletion coverage unconfirmed |

### Where the answers came from

Storage rows were the easiest, because a data processing agreement (DPA) hosting annex names regions. History is committed there. The index is only documented, since its amendment arrived as a draft and isn’t yet part of the agreement.

Inference is harder. A trust page saying “EU processing available” is a claim, and an EU endpoint isn’t proof of EU inference. The only document that could commit route B is the order form, and Vendor Q’s draft clause is unsigned.

### What the vendor said versus what the terms say

Two rows rest on words outside the contract. The cache answer is a sales email, a written representation that still needs a term behind it. It also doesn’t say whether the cache is in memory or persisted.

The safety-log row rests on Vendor Q’s account of Model Provider M’s “zero retention.” That’s one endpoint’s claim, scoped by terms that haven’t arrived. Even when they do, ZDR wouldn’t mean the prompt wasn’t processed.

### What stayed vague

Support and telemetry logs sit under a clause allowing service data to be processed globally. Nobody has confirmed whether service data can include prompt content, so the row stays UNKNOWN, with those exact words recorded.

Feedback is a toggle without a term. Feedback was on in the reviewed configuration, and Fernhill switched it off in admin settings for the pilot. That makes the pilot a different configuration, and the setting’s effect stays UNKNOWN, because a setting’s name doesn’t prove what it excludes.

Subprocessors exposed the sharpest gap. The current list shows Model Provider M in the US for “overflow,” which no storage label could reveal. “Per backup cycle” deletion doesn’t say whether backups or subprocessor copies are in scope.

### What the operating evidence showed

Fernhill also captured pilot traffic at its own egress proxy. The fictional record shows a connection to Vendor Q’s EU hostname, and nothing more. That trace covers Fernhill’s side only, not where Vendor Q forwards the request.

The tempting inference is that storage residency settles the rest. It doesn’t prove inference, logs, training, or subprocessor location. An empty log export, encrypted data, a toggle labeled “off,” or one endpoint’s zero-retention claim each stays partial evidence about a single artifact.

## Why the pilot could proceed

Fernhill’s security and privacy leads approved a limited pilot under their own sign-off. It covers the synthetic ticket, synthetic knowledge base, and invented test identities on route B, with feedback off, for a fixed test period. No production data, real attachments, or real customer accounts enter it.

That approval isn’t a privacy pass. Operational metadata, such as tester logins, IP addresses, and support tickets the team files, can still be real. Fernhill logs that metadata as a separate UNKNOWN for its privacy team.

## Why production couldn’t

Production stays on hold until every unmet row closes, and each has an owner. Vendor Q’s account team owns the signed route B clause and Model Provider M’s safety-log terms. It also owes the cache answer as a term, support-log content, the feedback setting’s written effect, and the incorporated index amendment.

Fernhill’s privacy counsel owns the US overflow transfer and backup deletion coverage. Safety logs and the overflow route come first, because each could place prompt content outside the EU. Closing them won’t clear the other rows, and a row-by-row review is booked for two weeks out.

Deletion needs its own check. If production data later flows through route B, a deletion request to Vendor Q wouldn’t prove deletion at Model Provider M. Fernhill would need that confirmed separately, with backups in scope. Deletion covers stored copies; it can’t undo an earlier disclosure.

Even a fully signed file has limits. Each evidence state supports a different conclusion:

| Evidence state | What it supports | What it doesn’t support |
| --- | --- | --- |
| Claimed or written representation | A question to confirm | Any decision |
| Documented | A provisional answer for your exact configuration | A commitment that survives a terms change |
| Contractually committed | A documentary commitment counsel confirms applies | Enforceability, or proof that operations match the term |
| Operating evidence | What a trace, report, or test actually observed | Coverage beyond what it observed |

A signed clause records what was agreed. It isn’t runtime proof, and it doesn’t enforce itself. Control reports answer a different question too: a [SOC compliance](https://devrev.ai/blog/soc-compliance) report can show controls exist and operate, not where a given prompt was processed.

The memo organizes evidence; it doesn’t prove residency or replace legal advice. Fernhill’s counsel decides what a clause means for its obligations. Legal review belongs wherever a row involves a cross-border transfer, a vague retention clause, or deletion coverage.

## Reusing the memo on your next vendor

Sasha’s file reduces to a worksheet. It’s a proposed buyer method, not an industry standard, and it starts with naming one plan, region setting, and model route.

| Dimension | Question to answer for this configuration | Evidence to request | Common trap |
| --- | --- | --- | --- |
| Storage and caches | Where do history, files, indexes, and backups persist? Which caches are persisted? | DPA hosting annex, product terms | Assuming backups follow the primary region |
| Inference | Where does the model run for this route? | Order form or product terms naming the route | Treating an EU endpoint as proof of EU inference |
| Logs | Which logs hold content, where, and for how long? | Log-retention terms, support policy | Reading an empty log export as “no logs” |
| Training | Is content or feedback reused, and is that the default? | Product terms, admin setting documentation | Taking a toggle name as proof of its effect |
| Subprocessors | Who touches the data, for what, and where? | Current subprocessor list with locations | Missing model providers listed as “overflow” |
| Transfer | Which clause commits each answer above? | DPA, transfer terms, order form | A strong trust page with no matching clause |

![Proposed buyer worksheet asks for separate claims, documents, and executed contract terms for storage, inference, logs, training, subprocessors, and transfer; blank cells remain unknown.](https://cdn.sanity.io/images/umrbtih2/production/deead724393c83d4e5d25b5f245215e299128ea8-5334x2667.png)

_Illustrative buyer worksheet – Ask for a claim, supporting documentation, and an incorporated term for each data surface; blank cells remain unknown._

Then match each row to the document that could close it. Each one proves something different:

| Document | Surfaces it can evidence | What to check |
| --- | --- | --- |
| Data processing agreement (DPA) | Storage, transfer, deletion | Named regions, transfer mechanism, deletion coverage including backups |
| Subprocessor list | Subprocessors, inference | Each entity’s purpose and location, plus change-notice terms |
| Product terms for your edition | Storage, inference, training | Whether terms match your plan, region, and model route |
| Log-retention and support terms | Logs | Which logs hold content, retention period, and location |
| Order form | Inference, any configuration-specific promise | Clauses that name your exact route or region setting |

Ask the vendor to point each row to a clause in the DPA, product terms, or order form. Where there’s no clause, the row is claimed or documented, not committed. Deletion terms should say what they cover, including backups and subprocessor copies.

When a clause is missing or vague, write down the exact words and mark the row UNKNOWN. Then ask one specific question in writing, including how subprocessor changes are notified. Your [AI governance](https://devrev.ai/blog/ai-governance) program should name who reviews each open row and when it’s rechecked.

Data handling is one input among several. The [enterprise AI agent buying criteria](https://devrev.ai/blog/enterprise-ai-agent-buying-criteria) cover the wider evaluation, and the [CFO guide to AI agents](https://devrev.ai/blog/cfo-guide-ai-agents) picks up cost and value. If you evaluate [Computer, by DevRev](https://devrev.ai/meet-computer), ask DevRev for the same per-surface documentation for your configuration. Grade each answer as you would for any vendor.

## The row Fernhill can’t close yet

Every open row still holds production, but the first one waits on a single document: Model Provider M’s safety-log terms for route B. Until they arrive, nobody can say whether prompt content sits in a log outside the EU, or for how long. When they arrive, counsel still has to decide whether they’re incorporated into Vendor Q’s agreement. And the egress trace still won’t show what M keeps.

Scoped terms would tell Fernhill what M says it logs on route B, where, and for how long. They still wouldn’t show what M’s systems actually keep. So the open question becomes what operating evidence, if any, M can offer beyond its terms.

If your own file has a row like that, a [data-handling evaluation with DevRev](https://devrev.ai/request-a-demo) can work through it alongside your contract set.