TL;DR
- Two eras of piling more data and tools onto the SOC didn’t make the call any easier, and bolting AI onto that same stack only closes benign alerts faster.
- AI made speed cheap, so the edge now comes from context, like what’s normal in your environment and which server can’t go down.
- Analysts need to learn when to trust or override AI, and an AI tool that can’t explain its calls becomes a liability the first time someone has to defend one.
I’ve watched the SecOps conversation turn into a showdown for two-plus years. AI versus people. Machines versus analysts. Speed versus judgment. Every vendor walks in with certainty that it’s one way, and every security leader walks away still wondering where AI fits.
The question itself admits the answer isn’t all-or-nothing, but still nobody has a real answer.
A better question is what is different about this era of SecOps? What opportunities and new challenges does AI bring to a security program? The answer accounts for every factor impacting the security operations center (SOC) at once: threats, tech, budgets, and people.
I first noticed this when I looked at the first LLMs being applied to security. People were just throwing in all of the context they could find and writing detailed prompts to try to reason about a threat. And it was about as effective (not to mention expensive) as table scanning a SIEM in 2005. But then other use cases emerged: reverse engineering, vulnerability research, rapid prototyping of new tools, processing of large disparate datasets, agentic tooling. That made it clear that security was never going to be the same. But what’s still up for debate is how much security operations will change.
A brief history of (SOC) time
Every SOC does four things: takes in signal, applies judgment, takes action, and delivers an outcome. Each era changed the nature of those four things, and the biggest impact was on the judgment step, more specifically, who makes the call, how fast, and with what information.
The data era
The first era of the SOC was data driven. Security teams wanted to see everything, so their solution was to log it all, store it in a security information and event management (SIEM) product, and have analysts sort it all out on their way to brute-forcing triage, and ultimately answers. On the surface, it made sense (at the time), but in reality, SOCs were now hooking up dozens or hundreds of their tools to their SIEMs and data lakes, sucking up incredible amounts of data and telemetry, and expecting human analysts to find the needles in the haystack.
Yes, those SOCs had all the visibility they’d need, but no real way of being effective at finding threats through all the noise. And on top of that, the maintenance of that data system itself became a body of work requiring a team and a cost center all its own.
The signal era
Data is useful, to a point. There was so much unnecessary telemetry to parse through to find the signal that it was almost impossible. The next shift was to alert-driven security—narrowing the scope of what we’re looking at by enriching telemetry, adding more specific detections, and tuning out the noise. But we ran into the same problem of information overload, now with too many alerts, and we then had to manage severities and triage. So we turned to automated solutions (like SOAR) to try to sift through it all in hopes that the machines can use signals to find what could be threats, then analysts can review those, make the determination, take the proper action, and close the threat.
This was a good step forward, but tough to implement. Maintaining SOARs beyond shallow use cases required significant engineering expertise sitting alongside security operations expertise to provide “what good looks like” to build into the system. The sheer volume strained the process, and in the end didn’t make evaluating alerts that much easier for analysts. Why? These alerts would tell analysts that something happened, but couldn’t actually tell them if it was a real threat. And on top of that, you now had another system to maintain, which itself became a body of work and a cost center, just like the SIEMs from the data era.
Here’s where AI enters the chat. Many vendors attempted to retrofit their solutions with AI. This is where we saw the rise of AI SOC platforms. Problem is, we’re still solving the same alert-closure speed problem with fancier tech. We can’t just bolt AI onto alert-driven and event-driven infrastructure and expect it to be the solution to modern detection and response. Closing benign alerts faster doesn’t address the problem of determining if the remaining alerts actually matter, or if they do, what the proper response is to not cause business disruption. That requires context.
The context era
AI made speed and triage cheap, which makes speed table stakes. Context is what’s scarce: what’s normal in your environment, what you’ve decided before and why, which server can’t go down, who’s traveling this week, what’s going on in environments similar to yours, and so much more.
AI is strong at correlation and evidence gathering, but it is not clear that it’s the system that should own the judgment call. It works in probabilities, and someone still has to answer for the decision. And in SecOps, this decision always has a definitive answer, and sometimes serious consequences.
So every SOC feels the same tension. You need to move at machine speed and defend every call as if a person made it. Speed without judgment is dangerous. Judgment without speed is late.
“Good” now means the quality of the call. It’s the right decision, made fast, with a paper trail behind it.
What changes for people, process, and technology
People first. AI automates log reading and pattern matching, so the skills that matter for analysts shift to validation, communication, and judgment under pressure. They also learn to tune the system they are operating. Most analysts are still learning when to trust AI, when to override it, or when to shut it off. That’s a new competency, and few teams are training for it.
The real talent gap in security has always been a skills shortage, particularly in the deeper parts of the discipline, which take time and significant effort to master. Now AI has the potential to widen that gap especially as the AI-forward part of the talent market pulls away from the rest. As AI absorbs tier-1 triage, entry-level roles shrink, and so does the bench of future senior analysts. Orgs that cut those seats without a plan to grow people will feel it in a few years.
Process is next. Many SOC workflows assume human-paced, sequential investigation. AI can run steps out of order and in parallel, and few orgs have rebuilt their playbooks to match. Many don’t have a written policy for which decisions need human sign-off, and fewer audit against it. But the real process changes come when you have agents operating on behalf of and alongside analysts. Platforms which enable analysts to develop and operate their own bespoke agents bring many new challenges, but also opportunity.
Detection logic drifts faster now. Tuning used to be a cleanup project. It’s a standing discipline now, because rules and models change. AI-generated detections mean greater coverage but also more to maintain. Accuracy decays quickly as attacker behavior changes, especially with AI augmented and operated campaigns using novel exploitation.
Finally, technology. Existing vendors have bolted AI onto existing SIEM and SOAR stacks. Data platforms are buying detection engineering companies. These franken-stacks are accumulations of technology, and instead of rebuilding for the AI future, teams manage more tools and more interfaces.
Every agent you add is one more thing to manage and maintain, and one more source of noise or missed signal for analysts. When an AI tool can’t explain its calls, it becomes a liability the first time an analyst has to defend one. And AI triage is only as good as the telemetry feeding it. Data quality and provenance is the bottleneck, and most tools aren’t built to let you inspect it, so teams aren’t watching it.
Where I land
The first two eras answered the problem with more: more people, then more tech. The Context Era poses a different problem: how do we ensure we meet AI attacker speed while sharpening human judgment?
It’s not a question of if AI can help us solve our speed issues, but the better questions are where to apply it, when it should take the lead, and how we can ensure accuracy. The answer depends on your environment, your risk, and your people.
Speed is table stakes. Context is the edge that gives you real control over the outcome.
