Keep Your Logs in Your Cloud: AI Incident Response Without a Data Lake
A read-only AI SRE that keeps logs in your cloud avoids the cost, compliance, and security risk of a vendor data lake. Here's the on-incident-slice model and what to ask vendors.
A read-only AI SRE that keeps your logs in your own cloud avoids three problems that come bundled with the data-lake model: runaway cost, compliance exposure, and a larger security blast radius. Instead of bulk-exporting your telemetry to a vendor’s storage, it reads logs in place and pulls only the narrow slice relevant to the active incident.
Data residency has quietly become one of the most important questions in evaluating AI incident-response tools — and one of the easiest to gloss over in a demo. This guide explains why the data-lake pattern is a liability, what the logs-stay-in-your-cloud model looks like in practice, and the exact questions to put to a vendor.
The hidden cost of the data-lake model
Many incident-response platforms work by ingesting your telemetry — logs, metrics, traces — into their cloud, where their models run against it. It’s the simplest architecture for a vendor to build. It is also the one that quietly pushes cost, compliance, and security risk onto you.
The core issue: to investigate incidents, these tools assume they need a standing copy of your observability data in their environment. That assumption is where the trouble starts.
Cost: you pay to move and store it twice
Log volume is enormous and growing. Continuously shipping it to a vendor means:
- Egress charges from your cloud provider every time telemetry leaves your account.
- Duplicate storage — you’re already paying to retain logs in your observability stack; now they’re stored again on the vendor side, baked into your subscription.
- Cost that scales with the wrong thing. Your bill tracks total log volume, not incident count. You pay to warehouse petabytes to investigate the handful of incidents that actually fire.
Compliance: regulated data crosses a boundary
Production logs are rarely clean. They contain user identifiers, IP addresses, request payloads, and other regulated data. The moment that telemetry lands in a third party’s environment, it’s inside that vendor’s compliance perimeter, not just yours.
- Your data-residency commitments (EU data stays in the EU, for example) now depend on the vendor’s region handling.
- Your GDPR, HIPAA, or PCI scope expands to cover the vendor as a data processor.
- Your data-retention policies have to be enforced in a system you don’t control.
Every regulated boundary your logs cross is a new audit question and a new contract clause.
Security: a bigger blast radius
A vendor holding a standing copy of your production logs is a concentrated, high-value target. If they’re breached, your telemetry is in the blast radius — and production logs are a goldmine of internal hostnames, tokens, schema, and behavioral detail. You’ve taken on risk you can’t directly mitigate, because the data lives somewhere you can’t see.
The read-only, logs-stay-in-your-cloud model
The alternative inverts the assumption. Instead of “ship everything to us so we can investigate,” it’s “grant us read-only access, and we’ll read only what this incident needs, only when it fires.”
Concretely, the on-incident-slice model works like this:
- The AI SRE holds a read-only role scoped to your observability stack and source control — no write access, no standing data export.
- When an alert fires, it pulls only the narrow slice of logs, metrics, and traces tied to that incident.
- It reasons over that slice in place, against your environment.
- When the incident closes, there’s no standing copy of your full telemetry sitting in a vendor data lake.
The contrast with the data-lake model is sharp on all three axes:
| Concern | Vendor data-lake model | Logs-stay-in-your-cloud model |
|---|---|---|
| Cost | Egress + duplicate storage scaling with log volume | Reads in place; pulls only the incident slice |
| Compliance | Regulated data crosses into vendor’s perimeter | Data stays inside your boundary and region |
| Security blast radius | Vendor holds a standing copy of prod logs | No standing copy to breach |
| Access | Often ingest pipelines with broad scope | Read-only, least-privilege |
| What’s retained | Varies; often server-side history | Narrow, incident-scoped, ideally nothing standing |
This is the model HealOps uses: read-only access, your logs stay in your cloud, and only the on-incident slice is touched. It’s also a core part of what separates a trustworthy AI SRE from a telemetry-hungry one.
Be fair: several tools have good residency stories
Honesty matters here, because residency is increasingly table stakes among the serious players — not a HealOps-only feature. If a vendor tells you their residency story is unique, be skeptical.
- Traversal supports read-only access with no vendor data lake, plus on-prem and bring-your-own-cloud deployment. Strong residency, peer-level.
- NeuBird (Hawkeye) is strictly read-only and ephemeral — it purges after a session — with VPC and air-gapped deployment options.
- Robusta / HolmesGPT is open source and can be deployed fully self-hosted or in a VPC, so the data can stay entirely in your environment (though the default SaaS path does ingest to Robusta’s cloud).
- Resolve AI reads in place with no raw-data ingestion and holds SOC 2 Type II, GDPR, and HIPAA attestations — though it retains investigation history server-side, processed in its cloud.
So residency by itself doesn’t decide the bake-off. It’s necessary, not sufficient. The differentiator is what the tool does after it reads.
Pair residency with the fix artifact
This is the part that separates similar-looking residency stories: a read-only model is only half the value. The other half is what comes out of the investigation.
A tool can keep your logs in your cloud and still hand you only a diagnosis — a root-cause summary you then have to turn into a fix yourself. The residency is good; the outcome is incomplete.
The combination worth paying for is read-only access plus a fix that’s ready to merge:
- It reads only the on-incident slice, in your cloud.
- It produces a reviewed pull request with a minimal diff.
- The PR carries a regression test that reproduces the incident — which, notably, almost no competitor advertises.
- A human keeps the merge button; nothing auto-deploys.
That last cluster is where HealOps differentiates against the peers with good residency. Traversal and NeuBird keep your data safe, but Traversal gates on whitelisted ops and NeuBird delegates code changes to external coding agents like Cursor or Claude Code. HealOps natively authors the fix as a PR with a regression test attached. Residency keeps your data safe; the fix-as-PR with a test is what actually closes the incident. We make the full case in why your AI SRE should open a pull request, not deploy to prod.
It’s worth contrasting the other end of the spectrum, too. Platform-locked tools like Datadog’s Bits AI require your telemetry to live in their SaaS — there’s no logs-stay-in-your-cloud option at all. Kubernetes-focused tools like Komodor send cluster metadata out to their cloud. For those, residency isn’t a tunable; it’s a precondition of using the product.
What to ask every vendor
Bring this list to any AI incident-response evaluation. The answers separate the read-only tools from the data-lake ones fast.
- Is access read-only? Or does the tool need write access and ingest pipelines?
- Do my logs leave my cloud? If yes, to which region, and under what controls?
- Standing copy or on-incident slice? Do you hold a continuous copy of my telemetry, or pull only what an active incident needs?
- What’s retained server-side after an incident closes — raw logs, investigation history, embeddings, nothing?
- Do you train models on my data? Shared models or isolated?
- Which compliance attestations (SOC 2 Type II, GDPR, HIPAA, PCI) cover the actual path my data takes — not just the company in general?
- And then what? Does the tool produce a fix as a reviewed PR with a test, or stop at a diagnosis?
Residency is where the evaluation starts, not where it ends. Keep your logs in your cloud — and make sure the tool that reads them hands back a fix you can merge.
For the broader category, see what an AI SRE actually is and the field guide to the best AI SRE tools in 2026.
Frequently asked questions
Why shouldn't an AI SRE export my logs to its own cloud? +
Bulk-exporting telemetry to a vendor data lake creates three problems at once: egress and storage cost that scales with your log volume, compliance exposure because regulated data now lives in a third party's environment, and a larger security blast radius because a breach of the vendor exposes your production logs. A read-only model that reads logs in place and pulls only the narrow incident slice avoids all three.
What is the on-incident-slice model? +
Instead of continuously streaming all your telemetry into a vendor's storage, an on-incident-slice model grants read-only access and pulls only the specific logs, metrics, and traces relevant to a single active incident, only when that incident fires. The vendor never holds a standing copy of your full telemetry, which keeps cost and exposure low.
Do AI SRE tools keep my data, or process it and discard it? +
It varies and you should ask explicitly. Some tools read in place and retain nothing; some read in place but keep server-side investigation history; others ingest your telemetry into their cloud wholesale. Ask where data is processed, what is retained after an incident, and whether your data is used to train shared models.
Which AI SRE tools have good data residency? +
Several do. Traversal supports read-only access with no vendor data lake and on-prem or bring-your-own-cloud deployment. NeuBird is read-only and ephemeral with VPC and air-gapped options. Self-hostable tools like Robusta's HolmesGPT can run fully in your environment. Residency alone is not a unique differentiator, so pair it with what happens after the read — the fix artifact.
What should I ask an AI SRE vendor about data handling? +
Ask: Is access read-only? Do my logs leave my cloud, and if so where do they go? Do you keep a standing copy of my telemetry or only an on-incident slice? What is retained server-side after an incident closes? Do you train models on my data? And which compliance attestations (SOC 2 Type II, GDPR, HIPAA) apply to the path my data actually takes?
Connect a read-only role. Get your first reviewed PR by morning standup.
HealOps investigates the moment an alert fires and opens a pull request with the fix and a regression test attached — your reviewer keeps the merge button.
AIOps correlates and detects; agentic AI runs perceive-reason-act and produces a fix. Here's how the two differ — and where each one stops in an incident.
The best AI SRE tools in 2026, compared. HealOps leads on the fix-shipping motion: a reviewed pull request with a regression test, logs kept in your cloud.