“Just Tune Your Detections” Misses What’s Actually Changing

AI in the SOC isn’t a faster way to clear the alert queue. It’s a different architecture for doing detection and investigation.

There’s a line of argument making the rounds lately that goes roughly like this: the AI SOC category is overhyped (well, this is still true, but in a different context), if your analysts are drowning in alerts the fix isn’t to increase the investigation throughput, it’s to fix the source of excessive alerts. Tune your detections. Write better content. Stop generating the noise in the first place.

I have real sympathy for the first half of that. Reducing alert volume through better detection engineering and tuning is good practice, and it should be done everywhere. Nobody serious is arguing you should generate garbage and then automate your way through it.

But the conclusion doesn’t follow from the premise. “You just need to be better at tuning” treats AI in the SOC as a throughput hack (a way to investigate more of the same alerts faster) when the more interesting thing it does is blurring the line between detection and investigation. Once that line starts to dissolve, a lot of the assumptions baked into the “just tune your detections” advice stop holding. This is an architectural shift, not a capacity upgrade, and the alert-overload framing is a symptom-level read of something happening one layer down.

Let me walk you through why.

Why we needed detections to be nearly perfect

For most of the history of the SOC, the design of our detection layer has been shaped by one hard constraint: humans are finite, and their throughput for investigating alerts is low compared to anything automated. If a person has to look at every alert, then every detection you generate is a claim on a scarce and expensive resource.

That constraint pushed us toward tuning detections with a strong precision bias. We wanted the signal that reached a human to be worth their time. To confirm a true positive before bothering the analyst, we had to build detections that would correlate across multiple data sources, as a single source rarely tells the whole story.

So where did that correlation happen? At detection time, in a centralized place. The natural home for “send me everything so I can correlate it” was the SIEM. That’s a big part of why the SIEM exists in the shape it does, not just as a log store, but as the place where detection-time correlation could occur, which meant the data had to physically be there.

UEBA, which was later absorbed by the SIEM, pushed this model about as far as it could go. The promise was to ingest all the raw telemetry, build behavioral baselines for every user and every entity in the environment, and surface situations where multiple anomalies across all of those sources for a single entity would emerge. It was genuinely hard to do, partly for compute reasons, but just as much because it required shipping all of that raw telemetry into one centralized layer to make the correlation possible at all. The architecture demanded centralization, and centralization was the bottleneck (and major cost driver).

The whole edifice (accurate detections, low false-positive rates, the SIEM as the gravity well for data) was a rational response to the throughput constraint and the centralization requirement. Change those two things, and the edifice doesn’t need to stand the way it did.

What autonomous investigation actually changes

That centralized, complex correlation-based detection system is exactly what AI-driven autonomous investigation changes. AI SOC systems can go out to multiple places, gather the data they need, and run the correlation and investigation work at investigation time, rather than requiring all of that data to be pre-centralized so a detection rule could correlate it up front.

And because the investigation itself is automated, the throughput concern that drove everything else largely relaxes. We are no longer rationing a scarce human’s attention across every alert.

Once that’s true, something interesting happens to what a “detection” even is. It no longer has to be a high precision claim that something bad is happening. It can be a signal (a simple indication that something might be wrong) that triggers an investigation rather than something that has to stand on its own. The detection layer fires a precursor; the investigation layer does the confirming work. We should optimize detection for recall, and investigation for precision.

Put differently: detection plus investigation, together, are now what we used to think of as just “detection.” We’ve split it into two phases. The first generates a signal worth investigating. The second does all the correlation and confirmation we used to try to cram into the detection layer.

The payoff is that the first phase can be distributed. We no longer need all the signals to live in the same place, because the investigation can come to them. Suspicious-activity signals can be generated where the activity is, on the EDR, in the network telemetry, in the cloud security stack, at the identity layer. Each of those can raise its hand and say “this looks off,” and only then does the investigation fan out to pull corroborating data from the other sources and decide whether the suspicious thing is actually malicious and worth acting on.

This is a fundamentally different way of doing threat detection. It’s the UEBA ambition (anomalies across many sources per entity) but without the requirement to haul all the raw telemetry into one centralized brain to get there.

Why this matters

This isn’t a tooling preference. It changes how we should think about several things at once.

The centralized correlation point matters less. The need for a single location where you correlate everything at detection time is no longer as strong as it was, because we now have a layer that can gather and correlate data on demand, after an initial signal. The gravitational pull of the SIEM weakens. It also makes building security data lakes simpler, as we don’t need to design for conflicting requirements such as compute (for the analytics doing the correlation work) and storage (for search and long term data retention) at the same time.

We can stop over-tuning. This one deserves more attention than it gets. Every time we squeeze the false-positive rate of a detection down, we raise the risk of false negatives. We are optimizing for precision at expense of recall. That’s just what happens when you tune a detection system to be quiet. For years we’ve traded away our ability to find things in exchange for not annoying our analysts. When the early signal is just a signal (something that’s going to be investigated and correlated downstream anyway), we don’t have to push so hard on false-positive reduction at that layer. We can let the signal layer be noisier and more sensitive, and let the investigation layer sort it out. That’s a meaningful relaxation of a tradeoff we’ve been stuck with for a long time.

Detection and investigation become one process. Keeping the technology tools separate still makes sense, for flexibility, for mixing and matching best-of-breed components, and for maximizing the distribution of work, but conceptually it’s no longer “automated detection, then a human investigates.” It’s a single process that begins with automated signal generation and ends with automated investigation of that signal. (Yes, all the human-in-the-loop and human-on-the-loop conversations still have to happen, that’s a separate and important discussion.) The practical consequence is that detection engineering now has to account for both halves: how you generate the early signals and how those signals get investigated once they exist. Those used to be two distinct disciplines. They’re becoming one.

Why we couldn’t do this before

The obvious objection is: we’ve wanted this for years. Why is it possible now?

Because the last time we tried to wire detection and investigation into a single automated process, we did it with SOAR and static playbooks, and that turned out to be very hard to sustain. You had to write playbooks in advance for every potential signal and every investigation path you might want to run. That’s an enormous amount of work up front, and the playbooks went stale fast, because the things they describe change constantly. The maintenance burden is what killed the dream for most teams.

What’s different now is that AI in the SOC can generate those investigations dynamically, effectively building the playbook on the fly for each specific signal, against whatever combination of data sources happen to be available in that organization at that moment. You’re not maintaining a brittle library of pre-written logic anymore. That’s the unlock that makes the two-phase, distributed model actually workable rather than aspirational.

So, is it hype?

There is a lot of hype in the space, as the most recent Gartner Hype Cycle says. We are at the “peak of inflated expectations”. But it’s a lot about overstated AI capabilities and funny notions of fully autonomous SOCs. But to the folks saying “AI SOC is overhyped, instead of all this you just need to get better at tuning your detections”: no. That advice answers a question nobody serious is really asking. The point isn’t that we found a faster way to chew through a noisy alert queue. The point is that we’re changing the architecture underneath: where signals are generated, where correlation happens, how much the detection layer has to centralize, and how hard we have to tune.

Better tuning is good hygiene. It’s not the thing that’s changing. The thing that’s changing is that detection and investigation are collapsing into a single, dynamic, distributed process, and that’s a far bigger story than “you have too many false positives.”