Ask where your organization's AI data lives, and someone will answer for the database. Almost nobody answers for the logs — yet AI systems generate prompt logs, output logs, audit trails, telemetry, and evaluation records continuously, several of them carrying regulated content verbatim, and nearly all of them flowing to wherever the observability stack's defaults send them. Log residency is the gap between your data-residency policy and your logging configuration, and closing it takes four controls. This page provides the inventory, the default-path analysis, and the control set.
The Log Inventory: What Your AI System Records
An AI deployment generates at least five log types — prompt logs, output logs, audit trails, application telemetry, and evaluation records — and several carry regulated content verbatim: prompt logs frequently contain the same PHI or personal data as the interaction itself, which means log storage inherits the interaction's data classification and its residency obligations.
| Log type | What it typically carries | Inherits regulated classification? |
| Prompt logs | User inputs, often verbatim | Usually yes — this is the interaction's content |
| Output logs | Model responses as delivered | Often yes — derived from regulated inputs |
| Audit trails | Who did what, when — with event context | Partially — required by security rules, handled per policy |
| Application telemetry | Latencies, token counts, error rates | Usually no — unless payloads are sampled in |
| Evaluation records | Test prompts, graded outputs | Yes when eval sets derive from real interactions |
The inheritance principle is the whole analysis: a log is data, and its classification follows its content. A prompt log containing a patient's question is PHI in a log store; a telemetry line containing a token count is not. Compliance guidance for healthcare states the baseline clearly — HIPAA requires safeguards for ePHI wherever it resides, which makes the location of content-bearing logs a safeguards question, while other regimes add actual geography. Inventory your actual capture rather than assuming this generic list, because configurations drift and new log sources appear without anyone re-running the classification.
How Logs Cross Borders by Default
Logs cross borders through defaults, not decisions: observability platforms ship to their SaaS regions by configuration, AI vendors log per their terms to their infrastructure, cloud trails aggregate cross-region, and backup or analytics pipelines replicate quietly — each default is a cross-border flow your data classification never approved.
| Default path | Where it sends logs | Who approved it (usually) |
| Observability SaaS | The vendor's ingestion region | Nobody — it is the integration default |
| AI vendor logging | The AI provider's infrastructure, per their terms | The vendor's terms of service |
| Cloud trail aggregation | A central region spanning your whole estate | whoever set up the landing zone |
| Backup and analytics pipelines | Replica and warehouse regions | Nobody recently |

Each path is individually defensible engineering; together they mean a prompt typed in Frankfurt can rest in three jurisdictions before the user's session ends. The deeper wrinkle is the residency-versus-sovereignty distinction that compliance coverage draws: even in-country storage can fall under foreign jurisdiction claims through the vendor's administrative reach, which is why the control set below contracts for reach as well as configuring for location. Trace one log type end to end — from the AI gateway to every store that eventually holds a copy — and every border crossing you find is a flow your classification never reviewed.
The Control Set for In-Region Logging
Four controls close the gap: capture-time minimization (log metadata, redact content), in-region log stores with region-pinned routing, vendor region commitments in contract for any logging service, and periodic verification that sampling the log path finds no cross-border copies — with the evidence being the configuration export plus a trace of one real interaction end to end.
- Minimize at capture: log metadata and redacted content instead of verbatim prompts wherever the log's purpose allows — every verbatim log you eliminate removes its entire downstream residency question.
- Pin the region: in-region log stores and region-pinned routing for log types that must carry regulated content, so the store's location is configuration rather than accident.
- Contract the vendors: region commitments and administrative-reach terms in every logging and observability agreement — the storage-versus-sovereignty distinction means location without reach control is half the answer.
- Verify periodically: sample one real interaction and trace every copy it leaves, quarterly, with the trace archived as the evidence artifact.
The evidence standard is the trace, not the configuration: configuration exports show intent, the end-to-end trace shows what actually happened to one interaction — and audits believe traces. Which log types require in-region handling is a jurisdiction determination informed by your flow inventory; these controls implement whatever that determination requires.
Residual Risk and Ongoing Verification
Record the residuals: new log sources added without review, vendor region changes, debugging sessions that export live logs, and third-party tools attached to the log store — mitigated by an intake check for new log sources, contract change-notification clauses, and a quarterly path-verification cadence with a named owner.
| Residual risk | Mitigation | Owner |
| New log sources added without classification review | Intake check: every new log source classified before it ships | Platform engineering |
| Vendor changes its ingestion region | Change-notification clauses; vendor-region review at renewal | Procurement/compliance |
| Debugging exports live logs to a laptop or ticket | Debug runbook using synthetic or masked data; export approval step | Engineering leads |
| Third-party tools attached to the log store | Access review of the log store's integrations | Security |
The cadence question resolves practically: quarterly verification catches the drift patterns above without becoming noise, and the named owner matters more than the interval — an unowned control is a control that exists only in the policy document. For teams whose flow inventory concludes that log stores belong inside their operating boundary entirely, dedicated environments such as OneSource Cloud's private AI infrastructure keep logs in-region by construction rather than by configuration, which is the strongest form of the third control above.
FAQ
Does HIPAA require AI logs to stay in the US?
No: HIPAA requires safeguards for ePHI wherever it resides, not geography — but logs carrying PHI still inherit your safeguard duties in every region they land, and other regimes, contracts, or organizational policy can independently require US residency, so the answer is a determination, not a default.
Does product telemetry count as regulated data?
When telemetry can carry regulated content — prompt lengths are fine, but sampled payloads, error messages with user content, and identifiers are not — it inherits the classification. The control is capture-time minimization so telemetry stays telemetry.
What is the single fastest control to implement?
Capture-time minimization: stop logging full prompts and outputs where you do not need them, and the entire downstream residency question shrinks to the logs that remain — it is one configuration change that reduces the compliance surface more than any routing change.