The AI SOC Needs an Entirely New Set of Processes

AI SOC
AI-native MDR
Sovereign Security Operations
Bolt On versus AI Native SOC

The Bolt-On AI Trap

Most “AI SOC” rollouts follow the same pattern: keep the org chart, keep the escalation paths, keep the playbooks, keep severity-based triage, and drop an AI agent into one slot in the pipeline where it can save analyst-hours. Usually that slot is EDR alerts or phishing, because those workflows are contained enough to automate without changing anything around them.

We have watched this movie before. A decade ago, it was SOAR: organizations automated one narrow slice of the workflow and left the rest of the operation largely untouched. The tooling changed, but the process underneath it did not. The result was real but modest: faster handling of the alerts teams were already reviewing, with little improvement in the alerts they were missing.

SwappingSOAR for a large language model does not fix that pattern. It repeats the same mistake with a more capable tool. A 2003 SOC process plus an LLM is still a2003 SOC process: slightly faster and cheaper at the margin, but structurally unable to close gaps that were never caused by speed alone.

A New World Requires a New Operating Model

Traditional SOC processes were designed around two constraints: human analysts cannot memorize every detail and become less consistent under pressure, while machines could execute only the exact instructions they were given.

Modern AI systems change both assumptions. A model can retain broad investigative context, apply it repeatedly, and operate without fatigue across a volume of work no human team could review in depth. That does not make AI a faster version of the same worker. It makes it a different kind of worker. Handing that worker an inherited process is not neutral; it caps the system at the limits of the process it inherited.

So the better question is not,“Where can we insert AI into the existing pipeline?” It is: “If we designed theSOC from scratch for a workforce that includes scalable machine reasoning, what processes would we build?” We believe the answer breaks into five areas:

1.      Specifications

 Playbooks are written for people who forget steps and machines that can't reason. Neither constraint applies to an LLM the way it applies to a junior analyst or a SOAR script. Feeding a capable model a rigid run book doesn't make it more reliable, it caps it at the judgment of whoever wrote the run book. What actually helps is guidance:boundaries, failure modes to watch for, what "good enough" looks like. That's a different artifact, and a different process for producing it.

2.      Alert Architecture

 Full-depth investigation on every alert is too expensive to run at real volume, and pre-filtering by severity just relocates the risk to the tier nobody reviews. Real incidents keep turning up in exactly the alerts that get waved through. The fix isn't picking which one to do. It's running both, at different depths: a cheap pass across everything, and an expensive pass reserved for what that first pass actually surfaces.

3.      Model Selection

 Incident response isn't a category most frontier models are benchmarked or trained against, so "just use the best model" isn't a real strategy. Knowing how to test and choose a model for IR specifically and knowing that different tiers of work may call for different models is its own discipline now, not a footnote.

4.      Design Patterns

How you chain models against each other matters as much as which models you pick. The same logic that says code review shouldn't be done by the author applies to investigation: the agent that generates a hypothesis shouldn't be the one that validates it. That's a process decision, not a model decision.

5.      Division of Labor

Once AI can perform repetitive investigative work consistently and at scale, the SOC should stop assigning work according to the limitations of a human shift. The goal is not to mimic every analyst click. It is to define the desired outcome, the evidence required, and the decisions that still need accountable human judgment.Some examples include:

·      Identity compromise: AI reconstructs the attack timeline; humans authorize high-impact account actions.

·      Suspicious activity: AI investigates and groups related alerts; humans apply business context and choose containment.

·      Incident response: AI recommends actions and blast radius; humans own consequential operational, legal, and customer decisions.

What's Next: The Process Is the Product

Future systems may incorporate world models or other model classes that reason more directly about environments, causality, sequences of actions, and predicted outcomes. A durable SOC architecture should therefore be model-agnostic: designed around capabilities, evidence, controls, and accountability rather than around one specific generation of LLM technology.

The biggest opportunity in the AI SOC is not automating one more analyst task. It is redesigning the operating system of security operations around a workforce that combines scalable machine analysis with accountable human judgment.The familiar building blocks will not all disappear. Alert normalization, enrichment, aggregation, escalation, and governance still matter. What changes is how work is selected, routed, investigated, checked, and handed between models and people.

Organizations that simply bolt an LLM onto a legacy process will gain efficiency.Organizations that rebuild the process itself can gain something more valuable:broader investigative coverage, more consistent reasoning, and a SOC that can finally operate at the scale of the threats it faces.