Most security teams treat SOAR’s underperformance as a tooling problem, and that diagnosis is wrong. SOAR didn’t fall short because the automation was bad. It fell short because the industry (generally) didn’t focus on detailed process analysis, deconstruction, modeling, API research, scripting, and triggering to extract the value.  To be fair, these are not skills security teams are trained for, and your teams all had critical work to do every day to keep the lights on.

While there are AI solutions claiming to be a panacea, they are templated solutions that may work well if you own all the right tools the vendor wants you to have, and they are configured how the AI tool expects them.  Building and designing enterprise-grade AI service automation still requires all the same skills SOAR needed.  This is your chance to right things using AI, but don’t make the same mistakes from SOAR.

SOAR technology was not bad. The problem is that many teams tried to automate the part of their work that wasn’t deterministic. Taking the same approach with AI will result in faster and faster mistakes and at higher stakes.

Deterministic work and everything else

Deterministic work has one right answer and a fixed set of steps to get there: isolate this host, block this hash, close this ticket if these three conditions are true. SOAR is good at this because a playbook is a deterministic recipe, and a computer executes recipes perfectly.

Most of what happens in a SOC is not deterministic. Alerts are ambiguous, logins look like both like travel and abuse, tools provide conflicting signals. Much of this work is non-deterministic by nature. Two competent analysts can look at the same evidence and reach different conclusions and both are defensible. That’s not a flaw in the process. It’s the nature of work.

One mistake teams made with SOAR were trying to force non-deterministic judgment calls into deterministic playbooks. The playbook worked fine for the narrow slice of decisions that really did have one right answer, then either broke or got abandoned the moment it hit a use case the original author didn’t anticipate. AI walks into the exact same trap if you let it. Handed a fully autonomous mandate over judgment calls, an AI agent doesn’t fail loudly: it fails confidently, which is worse.

SOAR replacement is real, oversight is the point

However, AI can replace what SOAR was supposed to do. It can do the deterministic work better than SOAR did because it doesn’t need every branch of a decision tree coded in advance. An agent can look at an alert, reason about which of several deterministic actions to apply, and execute it without an engineer maintaining a playbook for every edge case.

What changes is what happens at the edge of that deterministic phase. When SOAR hit a task its playbook didn’t cover, it stalled and waited for a human.  SOAR was at least honest about its limits. An AI agent given the same ambiguous task can generate a plausible-sounding answer whether or not it really knows what’s happening, and a plausible-sounding wrong answer at 2 a.m. is more dangerous than a stalled playbook, because nobody questions it until the damage is done.

Observability is what closes that gap. Every action a workflow takes, every judgment call it makes, and every point where confidence drops needs to be visible to someone who can catch it.  It can’t be buried in a log nobody reads until after the incident. That visibility is what makes the difference between an agent you can trust with autonomy and one you’re hoping gets lucky.

Don’t burn the boats

This is the argument for keeping a human backstop in the loop, not as a hedge against AI capability but as a design principle. The deterministic 80% of SOC work is exactly the part that should run without a human in the loop, freeing analysts from the repetitive load that burns them out. The non-deterministic 20%, the genuinely ambiguous calls, is where a human still needs to be the one who says Yes or No.

Knowing if a task should be deterministic or non-deterministic is what AI teams are not yet consistently solving. Teams that get it wrong in either direction pay for it: too conservative, and AI never delivers the efficiency it promised. Too aggressive, and the first bad autonomous call is the one that ends the program. While there is no perfect approach to choosing whether a task should be deterministic vs non-deterministic, start by understanding the repeatability of the task. If this something that is always done, with no caveats or complex scenarios that require the task to change, then this is likely a good candidate for a deterministic task. The most important part is to understand the task and all the various scenarios that it will handle, and then repeatedly test to ensure you chose the right course of action. Process beats technology, and understanding process is the key to success.

In Conclusion

SOAR didn’t fall short because automation was the wrong idea. It failed because teams tried to automate judgment instead of process.  SCALR AI is built to address this problem. It enables automatic deterministic tasks and uses AI for judgment calls with full observability into every step of the workflow, so nothing runs unreviewed. It’s free on the Azure Marketplace.  Knowing where your processes are deterministic/non-deterministic is a design decision. Download SCALR AI and schedule a workshop so SRA can help you think this through and give you a lasting platform.