Incident-investigation AI tools compared by deployment model (2026).
Deployment model, SaaS, vendor-managed BYOC, customer VPC or air-gapped, decides whether an incident AI tool clears security review at all. This page compares the four on where telemetry lives, who holds keys, where inference runs, what egresses and who is accountable. Onepane is a managed root-cause service, not a tool in this category, but often evaluated alongside them.
What changes between SaaS, BYOC, customer VPC and air-gapped?
Every other comparison of self-hosted or on-prem incident AI ranks features and pricing. None of that matters if the tool cannot be deployed where your data is allowed to be. Start here.
| Dimension | SaaS multi-tenant | BYOC, vendor-managed | Customer VPC (self-hosted in your account) | Air-gapped / on-prem |
|---|---|---|---|---|
| Where telemetry lives during investigation | Copied or streamed to the vendor's cloud; retained per vendor policy. | Data plane in your cloud account, but provisioned and operated by the vendor; control plane in vendor cloud. | Stays in your account. Read-only queries against the observability you already own; nothing shipped out. | Stays inside the isolated network. No outbound connectivity at all. |
| Who holds the encryption keys | The vendor (sometimes with customer-managed keys as an option). | Usually you, for the data plane; the vendor for the control plane and metadata. | You. Your KMS, your IAM, your network controls. | You, entirely. |
| Where model inference runs | Vendor cloud, often via a third-party model API. Production logs are visible to that API unless redacted. | Varies: some run inference in your account, many still call an external model API from it. Ask specifically. | Inside your VPC boundary. No third-party model API sees production data. | Inside the isolated network on your hardware; model must be shipped in. |
| What egresses your environment | Logs, metrics, traces, change data, the investigation inputs. | Control-plane metadata, usage, often prompts and retrieved snippets. Read the data-flow diagram carefully. | Ideally only service heartbeats and aggregate metadata about the service itself, and it should be disclosed in writing. | Nothing. |
| Typical security-review outcome at a bank or health system | Disqualified in week one on data residency, before product evaluation. | Case-by-case; long review; depends on what the control plane sees. | Reviewable. InfoSec becomes an ally once the data-flow diagram holds up. | Reviewable, but operating burden falls on you and updates are slow. |
| Who is accountable when the answer is wrong | You. The subscription buys software, not an outcome. | You. Same subscription model, different hosting. | Depends on the commercial model: a tool is still a tool; a managed service with an SLA is accountable. | You, plus whoever maintains the deployment. |
| Deliverable | A chat answer, a summary in Slack, or a suggested hypothesis for an engineer. | Same as SaaS: an answer for an engineer. | For a tool: an answer. For Onepane: the finished, evidence-linked RCA document set inside an SLA. | Whatever the deployed software produces; usually an answer, not a document. |
Categories are described generically. Individual vendors differ inside each column; the questions further down are how you find out where.
Which incident AI tools are SaaS, and which run in your VPC?
Stated as of each vendor's public documentation at the time of writing. Deployment options change; verify with the vendor before a security review. Nothing here is a judgement of product quality.
| Vendor | Deployment model | Category |
|---|---|---|
| Resolve AI | SaaS-delivered | Chat-first incident investigation |
| Cleric | SaaS-delivered | Chat-first incident investigation |
| Traversal | SaaS-delivered (has published on BYOC direction) | Chat-first incident investigation |
| NeuBird | SaaS-delivered | Chat-first incident investigation |
| Deductive AI | SaaS-delivered | Chat-first incident investigation |
| Datadog Bits AI | SaaS (Datadog cloud) | Observability-vendor AI, on Datadog data |
| Dynatrace Davis | SaaS (Dynatrace cloud); Managed variant historically | Observability-vendor AI, on Dynatrace data |
| Onepane | Customer VPC, Terraform/Helm into your AWS, Azure or GCP account | Managed root-cause service: document deliverable + SLA (not a tool in this category) |
Sources: vendor websites and public documentation, August 2026. Sherlocks, Anyshift and other chat-first tools in the same category are also SaaS-delivered as far as we can tell from public material.
Why does sending logs to a third-party AI vendor end the conversation?
The inputs to an incident investigation are the most sensitive operational data an enterprise has: production logs with customer identifiers in them, traces that map the architecture, change records that describe the controls. A SaaS tool has to move that data to work. Its security questionnaire is then a list of exceptions someone in InfoSec has to sign, and in a regulated account they will not.
That is why the number one blocker on enterprise AI-operations deals in North America is one sentence: "we are not sending production logs to your cloud, and certainly not to a model provider." It ends most evaluations in week one, before the product is seen. Deployment model is not a feature; it is the difference between being evaluated and being disqualified.
Onepane's answer: we don't ask you to send us anything. We deploy into your VPC. Your data stays in your account, under your keys, inside your controls, and the RCA is generated where the data lives. Reference architecture and egress disclosure.
What should you ask any incident AI vendor about deployment?
Six questions. Ask them of us too. Anything a vendor will not answer in writing, assume the unfavourable answer.
- 01 Does any production telemetry, logs, traces, metrics, change data, leave our account? Which fields, to where, retained how long?
- 02 Where does model inference run, and does any third-party model API see our data or derived snippets of it?
- 03 Who holds the keys for data at rest and in transit, and can we revoke access?
- 04 What is the complete list of things that egress, including heartbeats, usage metering and support telemetry? Can we have it in writing?
- 05 How does your staff access our environment, scoped, time-boxed, logged, revocable?
- 06 If the answer is wrong, who is accountable and what does the contract say?
Not a tool in this category, but in the same first meeting.
Three real differences. First, deployment: the tools above are SaaS; Onepane runs in your VPC. Second, deliverable: they hand an engineer a faster answer in Slack, which is useful; we hand you the Root Cause Report, Evidence Pack and Customer-Facing RCA your auditor, customer and problem-review board will accept. Third, commercial model: they sell a subscription to a tool; we sell an outcome with an SLA and credits attached.
We do not run accuracy bake-offs against their demos. The comparison that matters is against the RCA your own team wrote, which is what the 90-day replay measures. See also how we compare with legacy AIOps correlation and observability-vendor AI.
Deployment model, the questions.
Can AI root cause analysis run inside our VPC without data leaving?
Yes, if the vendor's architecture is genuinely single-tenant in your account: read-only connectors to your existing observability, model inference inside the boundary, no third-party model API in the path, and only service heartbeats or aggregate metadata egressing, disclosed in writing. Onepane is deployed this way via a Terraform or Helm reference deployment into your AWS, Azure or GCP account.
Why do security teams block SaaS incident AI?
Because the investigation inputs are production logs, traces and change data, and a SaaS tool has to copy or stream them to the vendor's cloud, often onward to a third-party model API. In a bank, an insurer, a health system or a utility that is a data-residency and third-party-risk exception nobody wants to own, so the evaluation ends before the product is seen.
What is the difference between BYOC and customer-VPC deployment?
BYOC typically means the vendor provisions and operates a data plane inside your cloud account while running the control plane in their own cloud; what the control plane sees varies by vendor. Customer-VPC (self-hosted in your account) means the whole service runs in your account under your keys and controls. The practical test is the data-flow diagram: ask what crosses the boundary in each direction.
Is Onepane an AI SRE tool?
No. Onepane is a managed root-cause service, not a tool in this category, but it is often evaluated alongside them. Chat-first investigation tools deliver an answer to an engineer under a software subscription; Onepane deploys in your VPC, investigates every Sev1 across the estate, has engineers sign off, and delivers the finished evidence-linked RCA inside an SLA.
Are the AI SRE vendors listed here really all SaaS?
As of their public documentation at the time of writing, Resolve AI, Cleric, Traversal, NeuBird and Deductive AI are SaaS-delivered, and Datadog Bits AI and Dynatrace Davis run in their respective vendor clouds. Some have discussed BYOC or private deployment options. Verify current deployment options directly with each vendor before a security review.
Does air-gapped deployment beat customer-VPC?
For data isolation, yes; for practicality, rarely. Air-gapped means shipping models and updates in by hand and carrying the operating burden yourself. Customer-VPC gives most of the isolation, your keys, your controls, no telemetry egress, while a managed service can still operate and update it under a scoped, logged access model.
See it run inside your own VPC.On your own incidents.
Send us your last 90 days of Sev1 tickets. The replay runs where your data lives, and we hand you the data-flow diagram before it starts. Two weeks, no cost.