"What leaves your environment?" The question that decides AI ops deals

Every enterprise deal for AI in operations reaches the same meeting, and the same question decides it: what leaves our environment? If the honest answer is “your production logs, to our cloud, and some of them to a model provider”, the conversation ends at a bank, a health system, a utility or a government-adjacent buyer before anyone evaluates the product. If the answer is “nothing but the finished report”, the security team becomes your sponsor.

Why is this the question that ends conversations?

Production logs are not neutral telemetry. They contain customer identifiers, account numbers, session tokens, internal hostnames, query text, and occasionally whole payloads that someone logged at debug level in 2019 and never removed. Traces carry the same. Change records name people and systems. A security reviewer looks at an AI investigation tool and sees a pipeline that ships exactly this data, continuously, to a third party, and then possibly onward to a large language model operated by a fourth party.

For a cloud-native scale-up with no regulator, that is a vendor-risk form and a DPA. For a regulated buyer it is a non-starter, for reasons that have nothing to do with how good the tool is:

• Data residency and classification. Logs from systems that touch regulated data inherit that classification. Moving them to a vendor’s multi-tenant environment, often in a different region, is a control failure regardless of the vendor’s certifications.
• Third-party model exposure. Even where a SaaS vendor is acceptable, “and we send excerpts to a model API” introduces a sub-processor that the buyer has never assessed and cannot audit.
• Standing access to production. A tool that continuously reads production telemetry from outside the perimeter is a standing egress path. Security teams have spent a decade closing those.

None of this is hostility to AI. The same InfoSec team will approve an internal model running against the same logs inside the perimeter in an afternoon. The objection is to the direction of data flow, and it is a hard one.

Why does this disqualify SaaS at regulated buyers before the evaluation starts?

Because it is a gate, not a score. Most enterprise procurement processes run a security questionnaire before, or in parallel with, the functional evaluation. A “no” on data residency does not lower a vendor’s ranking; it removes them from the list. This is why the field of chat-first investigation tools, which is almost entirely multi-tenant SaaS, is fighting so hard over cloud-native scale-ups: those are the buyers who can say yes.

It is also why the deployment model is a more important axis of comparison than any feature. Two products with identical investigation quality, one SaaS and one deployable into the customer’s own VPC, are addressing different markets. We keep a comparison of AI operations tools by where they run rather than what they claim, on deploy in your VPC, because it is the first filter a regulated buyer applies and almost no vendor page helps them apply it.

How should a vendor answer “what leaves?” in writing?

Precisely, completely, and before being asked. The reviewer is not looking for “nothing”; they are looking for a vendor who knows exactly what crosses the boundary and can prove it. A good written answer has five parts.

The critical discipline is in the fourth row. If anything egresses at all, even a heartbeat, say so unprompted. A vendor caught understating egress once loses the deal and the reference. A vendor who volunteers “here is the one aggregate metric we receive and here is why” is trusted for everything else they say.

How does a managed service operate inside your VPC?

This is the question a sharp security reviewer asks next, and it is where the story has to be internally consistent. “It runs in your VPC” and “it is a managed service with an SLA and humans signing off” sound like they pull in opposite directions. They do not, provided the operating model is explicit and contractual.

The model we use, and the one we recommend demanding of any vendor making the same claim:

1. Deployment is into your account, under your keys. The software, the models, and the storage for evidence packs live in your VPC. Encryption keys are yours. If the vendor’s own service went dark tomorrow, nothing of yours is held elsewhere.
2. Investigation runs without human access. Agents query your observability, change and topology data in place, and produce the RCA and evidence index inside the tenant. This is the normal path; most incidents never involve a person from the vendor touching your environment.
3. Human sign-off is on the output, not on the data. The vendor’s engineers review the produced report and its linked evidence, and either sign it off, request further investigation, or record an abstention. Reviewing an evidence-linked report is not the same as browsing your logs.
4. Where a person does need tenant access, it is scoped, time-boxed, logged and revocable. Access is granted per session to a defined role, expires automatically, is written to your audit log, and can be cut by you at any moment. The scope, the retention of those logs, and the revocation right are contract terms, not a policy PDF.
5. What crosses the boundary is enumerated in the contract. The list from the table above appears in the agreement, and any change to it requires notice.

Written down like that, the two ideas reinforce each other. You keep data residency because the work happens where the data lives. You get a service, because someone else is accountable for the report arriving on time and being right, and the mechanism by which they are accountable is auditable by you. The evidence pack, with every query, source and timestamp behind the report and a hash over the bundle, is what makes that accountability checkable rather than asserted.

What should you have ready for the security review?

If you are the buyer, ask for these before the first product conversation. If you are the vendor, bring them unprompted. Nothing on the list is exotic; the difference is whether they exist.

• The reference architecture for the in-VPC deployment, including network boundaries.
• The data-flow diagram showing every path in and out of the tenant.
• The model hosting statement: which models, where they run, and confirmation that no production data reaches a third-party model provider.
• The key management and encryption description.
• The access model for the vendor’s engineers, with the audit-log format.
• SOC 2 status and the most recent third-party penetration test summary.
• Incident response and breach-notification terms covering the vendor’s own software.

Buyers who raise “our data cannot leave our environment” unprompted have, in the same sentence, disqualified every SaaS alternative. That is not an obstacle to be talked around. It is the shape of the market, and the reason we built the service to run where the data already lives. Read how it works, or start with your own history and run the replay inside your own account.