The AI-first SOC is here — why legacy SIEM is running out of runway

Every SOC I've walked into in the last twelve months has the same posture: they know their SIEM is under strain, they don't know what to do about it, and the vendor account team is quietly recommending "add-on modules" that don't fix the underlying architecture. What's actually happening is bigger than "SIEM needs an upgrade." It's a generational shift in how detection, triage, and response get done — and the platforms that were built for the 2010-2020 era of security operations were built on architectural assumptions that don't hold anymore. This piece is what I'd want a CISO to read before the next Splunk renewal, the next QRadar refresh, the next FortiSIEM upgrade, the next SOC-as-a-Service RFP.

The frameLegacy SIEM was engineered for a world that no longer exists

SIEM as a category was born in the mid-2000s. Splunk 3.0 shipped in 2006. Q1 Labs (which became QRadar under IBM) went GA around the same period. ArcSight was already several years old by then. LogRhythm, McAfee ESM, RSA enVision, all landed in a five-year window. Every one of these platforms was engineered around the same operational assumptions: logs are structured, threats have signatures, correlation rules are the product, analysts sit in tiers, and everything gets faster if you throw more storage and more people at it.

Every one of those assumptions is now either partially or wholly wrong. The consequence is not that SIEM is dead — it's that the SIEM you own was optimised for a problem that the industry no longer has. And the vendor selling it to you is structurally incapable of catching up, because their entire business model, sales motion, and product architecture are locked into the old assumptions.

The four assumptionsWhat's changed at the architectural level

1. Structured logs are no longer the primary telemetry surface

Traditional SIEM's ingestion tier is optimised around parsing. Every log source gets a parser (Splunk "sourcetype," FortiSIEM "parser," QRadar "DSM"), and the parser's job is to extract structured fields that rules can then reference. This works beautifully when your telemetry is 90% firewall syslog, Windows Event Log, and IIS access logs — which is roughly what the world looked like in 2010.

The world in 2026 has fundamentally different telemetry. Cloud audit logs (CloudTrail, Azure Activity, GCP Cloud Audit) are JSON-native but so deeply nested that traditional parsers can extract maybe 30% of the meaningful fields. Container and Kubernetes telemetry is high-volume and low-signal per event — the meaning lives in the sequence, not the individual line. SaaS-application audit trails (M365, Salesforce, Workday, ServiceNow) come in dozens of different formats that mutate every quarter. Endpoint EDR events are already pre-correlated by the EDR product, arriving as behavioural narratives rather than raw events.

The AI-first response is semantic ingestion: use an LLM (or an embedding model fine-tuned for security telemetry) to understand what an event means, without requiring a hand-crafted parser for every source type. This is not theoretical — it's shipping today in Microsoft Sentinel's Auxiliary Logs tier, in Palo Alto Cortex XSIAM's ML-based normalisation, in the newer FortiSIEM release-train's AI-Assist normaliser, and in several open-source projects. But it requires a fundamentally different ingestion architecture than what the legacy SIEM stack is designed around. You cannot "add semantic ingestion" as a feature to a parser-centric platform. The parser tier is the platform.

2. Rules-based correlation was never how experienced analysts actually detect

Ask any experienced Tier-2 SOC analyst how they decide whether a stream of events is worth escalating. You will get an answer that has almost nothing to do with correlation rules. It will be about context: this host normally talks to those five destinations, why is it suddenly hitting a sixth; this user account has never logged in from that country before; this service ran a command it doesn't usually run; the sequence of these three events looks like the middle of a Cobalt Strike playbook.

Legacy SIEM's response to this reality was UEBA — user and entity behaviour analytics — layered on top of the rules engine as a bolt-on. The bolt-on has never worked as well as the marketing suggested, for two structural reasons. First, the UEBA tier and the correlation tier don't share a data model, so alerts from one never enrich alerts from the other in the way an analyst would. Second, UEBA models are trained on your organisation's specific baseline, which means every new deployment starts from a cold-start baseline and takes 60-90 days of noise before it becomes useful.

The AI-first response is reasoning-based triage: give an LLM the same context an analyst would have (recent behaviour of the entity, threat intel, historical incidents, current org context) and let it reason about whether the current event stream is meaningful. This is the operational model behind Microsoft Security Copilot, CrowdStrike Charlotte AI, FortiAI-Assist inside FortiSIEM Cloud, and the internal AI agent Ogma runs at Tier-1/Tier-2 for its own SOC customers. It doesn't replace correlation rules — it wraps around them, catching the incidents the rules missed and dismissing the false positives the rules generate.

3. Tiered analyst structure is the wrong response to the volume problem

Every SOC I've seen in India that scaled beyond 15 analysts hit the same wall around year two. The tiered model — L1 triage, L2 investigation, L3 hunting and IR — was designed to make throughput scale linearly with headcount. It does that. But it also creates a specific set of failure modes: L1 analysts become overwhelmed and start closing alerts to make the queue shorter; L2 analysts spend more time re-doing L1's investigation than doing their own; L3 senior architects become the bottleneck on every Sev-1; and the whole system's efficacy is limited by the median L1 skill, not the peak L3 skill.

The AI-first response is not "get rid of tiers" — it's invert the leverage. AI handles the L1 workload (triage, initial context assembly, rule-out of known-good patterns) with near-infinite scalability. The senior architect layer that was previously a bottleneck now spends its time reviewing AI decisions and handling the Sev-1s. L2 as a distinct role starts to disappear — the "investigation" work that L2 used to do is now either automated (by the AI at L1) or elevated (to the L3 architect who has time to do it because they're not drowning in Sev-1s).

The economic consequence is significant. An AI-first SOC serving 25 mid-market customers doesn't need 8-10 human analysts on payroll. It needs one senior architect, a compliance/audit lead, maybe a customer-success generalist, and a modest fixed AI-agent infrastructure spend. Total operational cost lands roughly 60-70% below the equivalent team-based operating model at the same customer count. That maths is what allows an AI-first SOC to price 30-50% below legacy MSSPs while maintaining healthy margins.

4. Storage and retention are no longer where the innovation is

A striking amount of legacy SIEM product roadmap over the last decade went into storage optimisation: hot/warm/cold tiers, archive-to-S3, index compression, distributed indexers, big-data backends. This was rational engineering at the time. Storage was expensive, retention obligations were growing, and every SIEM vendor was trying to solve the same problem of "how do we let customers keep more logs for less money."

The problem shifted before the vendors fully solved it. Object storage got cheap enough (S3 Glacier, Azure Archive) that raw retention is now a rounding error on a modern SOC's total spend. What matters now is not "how much you can store" but "how usefully you can search and reason over what you've stored." AI-first architectures optimise for the query and reasoning tier, not the storage tier — treating cold data as embedding-searchable rather than SQL-queryable, and using vector similarity to surface historical parallels to current incidents.

Splunk, QRadar, and the on-prem tier of every legacy platform sunk hundreds of engineering-years into a problem the market has largely moved past. Their pricing model — per-GB ingested, sometimes with per-GB-stored — actively fights the shift to AI-first, because the AI-first operating model wants to reason over more data more cheaply, and the vendor's revenue model punishes that.

The visible shiftWhere legacy and AI-first diverge, operationally

The five tiersWhat "AI at every layer of the SOC" actually looks like

When vendors say "AI SOC" they mean many different things — often just a chatbot layered on top of the existing platform. Real AI-first architecture puts AI at each tier of SOC operations. Here's the map:

Why incumbents can't just retrofitThe structural constraints on legacy vendors

The interesting question isn't "why is AI-first better." It's "why can't Splunk, QRadar, LogRhythm, ArcSight just bolt AI onto their existing stack and match the AI-first players?" Some are trying. Splunk shipped Splunk AI Assistant and the Cisco-owned Splunk Attack Analyzer. IBM shipped watsonx integrations into QRadar. LogRhythm and Exabeam merged and are pushing an AI-centric roadmap. Fortinet has FortiAI-Assist across FortiSIEM Cloud, FortiAnalyzer, FortiManager. Palo Alto's Cortex XSIAM was purpose-built as AI-native.

The pattern that emerges when you look at these efforts as a category: the deeper into the architecture AI needs to go, the more structural resistance the vendor's own business creates. Four specific forces:

The vendors most exposed to these constraints simultaneously are the pure-play SIEM vendors from the pre-cloud era: Splunk (still), QRadar under IBM, LogRhythm / Exabeam (post-merger), ArcSight under OpenText, older FortiSIEM tiers before the Cloud variant, McAfee ESM. The vendors least exposed are those without the legacy per-GB revenue model or the accumulated parser IP: Microsoft (Sentinel + Copilot for Security, self-cannibalising), Palo Alto (XSIAM, no SIEM legacy to protect), CrowdStrike (Falcon LogScale + Charlotte, EDR-first therefore not defending a SIEM business), and a small set of AI-native startups (Panther, RunReveal, Tines).

The vendor landscape in three categoriesWhere each vendor sits, honestly

This is my read as of mid-2026. It will change. It's directional, not definitive.

The economic disruptionHow unit costs flip, and what that means for pricing

The most under-appreciated part of the AI-first shift is that it doesn't just change what the SOC does — it changes the shape of the cost curve. This has real consequences for how customers should price-negotiate and how vendors should re-model their offerings.

Legacy SIEM cost is linear in data volume. Every additional GB ingested adds a licence-cost delta, a storage-cost delta, and (indirectly) an analyst-workload delta. This is why every mature SOC eventually starts fighting its own log sources — turning off high-volume, low-signal telemetry to keep the bill manageable. The optimisation is rational and simultaneously wrong: the telemetry you turn off is often where the next incident is going to originate.

AI-first SOC cost is sub-linear in data volume. Storage cost drops to near-zero (S3 Glacier, Azure Archive). LLM reasoning cost per event is genuinely small at commercial API rates for current-generation models, and dropping rapidly. The fixed cost is the AI infrastructure itself: model access, embedding storage, vector-search infrastructure. That's a bounded monthly bill that doesn't grow with your log volume the way a per-GB SIEM licence does.

The consequence for customer pricing: traditional MSSPs pricing per-GB-day or per-EPS are describing a cost model that doesn't hold in an AI-first operating world. When you see a per-GB quote from a vendor whose backend is AI-first, you're being priced against your data volume even though it's not their cost driver. This is arbitrage in the vendor's favour, and it will shrink over time as pricing models catch up.

How Ogma One is priced (disclosure: our own build, pre-launch): per-GB-of-storage-per-month, split into live tier (queryable in real time) and archive tier (queryable with rehydrate latency). Archive tier prices at roughly two-thirds of the live tier — the split matches the actual cost driver on our side. Margins stay clean because our AI-agent infrastructure cost is a bounded fixed spend, regardless of how many customers or how much data. It gives customers a bill that scales with what they actually store, and drops when they retire old data. Simple to explain, simple to defend at audit.

The honest limitsWhere AI-first SOC actually falls short today

Any piece that claims a new paradigm is the answer without naming its limits is a marketing document. Here's where AI-first SOC operations are still shy of the pitch:

1. LLM hallucination in the reasoning loop is a real risk

An AI agent triaging alerts will occasionally produce confident-sounding wrong answers. In a SOC context this could mean dismissing a real incident because the model "reasoned" that it's benign. Mitigation is architectural: (a) constrain the model to reasoning over structured facts drawn from the underlying data, not over its own trained knowledge; (b) require human-in-loop for Sev-1 and above; (c) preserve full reasoning traces so decisions are auditable after the fact; (d) periodic offline evaluation of AI decisions against known-outcome incidents. This works, but it requires operational discipline that a first-year AI-first SOC may not have yet.

2. Regulatory acceptance is uneven

RBI Master Direction, SEBI CSCRF, and the DPDP guidance under Sec 8 don't yet explicitly acknowledge AI-driven SOC operations. In practice, auditors have been pragmatic — an AI-first SOC with human sign-off on Sev-1 and a named senior architect on the monthly compliance report tends to pass audit. But there are BFSI CISOs who read the regulation strictly and want a fully-human SOC on the record. That's their right; it's a real cost to the AI-first model in that segment.

3. The Sev-1 trust gap

Even in mature AI-first SOCs, the human oversight burden at Sev-1 is real. If your AI agent handles 95% of L1/L2 workload but you still need a senior human to authorise anything critical, the workforce economics of your senior tier don't collapse the way marketing sometimes suggests. Well-run AI-first SOCs still have senior architects on call 24×7 with hard rota discipline. The gain is huge — but it's a workload restructuring, not a workload elimination.

4. Custom detection-rule libraries don't port cleanly

If your organisation has spent five years building a custom Splunk detection library optimised for your environment, that library represents real IP and doesn't move to an AI-first platform for free. The good news is that most AI-first platforms have decent SPL/KQL translators (Uncoder.io is the open-source workhorse) and the reasoning layer often makes about a third of your custom rules redundant. The bad news is you still spend 3-6 months of senior-analyst time on the migration, and some of your longer-tail detections stop matching cleanly.

5. Data-residency for LLM reasoning

If the reasoning layer of your AI-first SOC calls out to OpenAI or Anthropic's US-hosted APIs, and your DPDP or sectoral regulator has a data-residency constraint, you have a compliance issue. Solutions exist: Azure OpenAI in Central India for regulated workloads; on-premises open-source models (Llama 4, DeepSeek, Mistral) for the strictest cases. But it adds architectural complexity and constrains model choice. Verify your SOC vendor's reasoning-layer hosting explicitly, not just their data-storage residency.

What to do in the next 12 monthsPractical steps for CISOs, not a marketing sequence

Where Ogma sitsHonest, brief, not the whole point of the article

We're building Ogma One as our own answer to what an AI-first SOC operating model should look like for Indian mid-market and enterprise buyers. It's pre-launch as of this writing — we're engaging design partners now, wide-launch is imminent. The design: priced per-GB-of-storage-per-month, with AI agents at Tier-1 and Tier-2 and a named senior architect at Tier-3 who signs every monthly compliance report. It replaces the traditional bundle of SIEM licence + MSSP retainer + separate VA + separate BAS + separate TI + separate compliance consulting with a single subscription. The pitch is not "we're cheaper" — the pitch is "we've rebuilt the operating model around AI, which is why we can deliver more capability at a lower TCO than the legacy stack even permits." If any of this sounds interesting to design-partner alongside us, get in touch.

You don't need to buy from us to internalise the argument. The shift is real, the architectural constraints on legacy vendors are real, and CISOs who work through the six steps above will end up in the right place regardless of which AI-first vendor they choose. What you should not do is renew a per-GB-priced legacy SIEM without at least paid-piloting one AI-first alternative first. That single discipline will save many organisations from a five-year sunk cost they don't need to pay.

Common questionsFAQ