The default architecture for AIOps products is to ship telemetry to a vendor cloud, run inference there, and send instructions back. It is the easiest thing to build and the hardest thing to defend in a security review. AAQUILIX runs the AI brain inside the customer network, and this article explains the reasoning.
Telemetry is not low-sensitivity data
There is a persistent assumption that infrastructure telemetry is boring — CPU numbers and disk percentages. In practice a full telemetry stream contains hostnames and their roles, network topology and segmentation, installed software with versions and patch levels, service accounts and their scopes, database schema names, batch job schedules, and failure patterns that reveal where the estate is fragile.
Written down, that is a reconnaissance package. An attacker who obtained a year of an enterprise's telemetry would have a better map of the estate than most of that enterprise's own engineers. Treating it as low-sensitivity because it is not customer PII is a category error.
The control-plane dependency problem
A cloud-hosted decision engine means the ability to respond to incidents depends on connectivity to the vendor. Consider the failure modes:
- The internet link degrades — precisely the moment you most need automated response, the automation goes blind.
- The vendor has an outage — your incident response capability is now coupled to a third party's availability.
- A security event triggers network isolation — your isolated segments lose their operations brain at the worst possible moment.
- A DDoS event saturates egress — telemetry queues, decisions arrive late, and late decisions are worse than none.
Every one of these is a scenario where the system is most valuable, and a cloud dependency makes it least available.
Latency and the decision loop
A cloud round trip for a decision costs 150 to 900ms in typical enterprise conditions before inference time. Local inference on a co-located node is single-digit to low-tens of milliseconds. For a single decision this seems academic. For a cascading failure where the response window is short — a connection pool saturating, a replication queue growing past a recovery threshold — the difference between reacting in 40ms and 900ms is the difference between preventing and reporting.
What runs where
The split we use is straightforward:
The cloud plane carries no telemetry, no hostnames, no credentials, and no incident detail. If the cloud plane is entirely unreachable, the local platform continues to operate against its cached licence for the full grace period, with no degradation of diagnostic or execution capability.
The honest trade-offs
Client-local is harder to build and harder to operate, and it is worth being explicit about the costs:
- Models must fit realistic on-premise hardware, which constrains architecture choices.
- Updates are a deployment problem rather than a push, so version skew across customers is real.
- Cross-customer learning is unavailable — one estate's incidents cannot train another's model.
- Debugging requires customer cooperation, because we cannot see into the environment.
We accept all four. The third one is the most commonly raised objection, and our position is that the marginal accuracy gain from cross-customer training does not justify pooling hundreds of enterprise infrastructure maps in one place. Shared learning happens at the level of policy templates and signature libraries, which are reviewed and carry no customer-specific data.
Regulatory alignment
For Indian regulated entities, keeping operational telemetry within the estate materially simplifies RBI and DPDP posture — there is no cross-border transfer to justify, no data-localisation exception to argue, and no third-party processor holding infrastructure data. The same logic applies to GDPR Article 44 considerations for EU estates.
“If your architecture requires the customer to trust you with a map of their entire estate, you have made trust a prerequisite rather than an outcome.”
Priya Ramesh, CTO