The Next SOC Challenge Is Staying Accountable For AI-Created Risk

The push to layer AI into SOC environments often runs up against legacy governance practices, highlighting major friction points between automated SOCs and risk management best practices. Teams add AI to move faster, but bolting new tools onto static frameworks often hides risk rather than reducing it, and that's a major problem for security operations that need speed, accuracy, and integrity across their SOC.

As the Cybersecurity Program Lead at Nike and AI Security and Governance Consultant at Sekena Consulting, Aliyana Isom handles the mechanics of this exact problem. Over a decade spent at Fortune 500 companies like Citi and Wells Fargo, she has turned abstract frameworks into measurable controls and looks at automation strictly through an operational lens. For her, the success of AI in the SOC depends less on speed and more on whether the organization can still see who owns the risk. Accordingly, speed combined with that lack of visibility is a recipe for problems. "Compliance theater is expensive, and it gives leadership false confidence in risk visibility that just doesn't exist. That combination is genuinely dangerous," she says.

Governance as a living practice

Often, business units that move quickly to deploy new tools view governance as a drag. While security operators use governance to keep training data and access patterns in check, that best practice proves difficult when systems change daily, introducing unapproved shadow IT, new cloud integrations, and third-party models that pull in sensitive information. Treating data mapping and controls as one-time documents instead of ongoing work creates blind spots.

The deeper issue, she says, is that compliance documentation often gets frozen in time. "What I consistently see is that data flow mapping exists as a one-time artifact rather than a living practice. Organizations need to get ahead of data mapping and threat modeling and make sure it is not a one-time process. Compliance and auditing can sometimes be treated as one-and-done. But our organizations are growing and changing, so it can't be a one-time exercise. The environment keeps moving: new cloud integrations, AI tools routing sensitive data to third-party model providers, and shadow IT that nobody formally approved. Getting ahead of that and making sure it's a culture shift more than a technical one is critical."

Compliance theater and the limits of SOC 2

Some teams invest in AI governance simply because they see the expanded attack surface that comes with AI tools. Others move mainly in response to auditors for frameworks like SOC 2 that are working to integrate AI. The problem with the latter approach is that relying solely on external certifications to justify AI deployments turns security work into a theatrical performance rather than a rigorous, secure implementation.

But putting tools in place is not the same as building real posture; that's why organizations need to lean on governance frameworks, and frameworks need to adopt AI standards faster than they are. "Frameworks are closing the gap, or they need to, by merging AI-specific audit standards, because they force organizations to treat governance as a distinct risk with distinct controls. Requirements like SOC 2 will need to evolve significantly, or it becomes a credential that signals less and less about real security posture."

Outside the SOC, teams also deal with fragmented regulations. A lack of a unified approach leaves security teams working with inconsistent expectations as they build defenses around new technology. Acknowledging that the industry is still very early in its adoption, Isom notes that a more unified U.S. framework, similar to the EU AI Act, would provide organizations with a clearer baseline. Even with that baseline, however, regulatory frameworks can sometimes struggle to keep pace with new threats. Major vendors are already embedding an automated AI governance operating system into their platforms to keep testing and oversight closer to how their systems actually run.

"I think we're going to see a lot more automated AI governance versus just having an AI governance committee," Isom says. "A committee is still needed, because we still need a human in the loop, but we also obviously need to keep up as these bots and agents are becoming smarter. It is always evolving. And that's why I say we need AI to govern AI. We definitely need more automation to move us at a faster pace."

Leverage over headcount reduction

For many organizations, securing these environments involves using automation to give human analysts more leverage. The organizations that handle this well do not start by asking how to remove people from the loop. Instead, they design systems that know when to escalate and build governance into the work from the first feasibility conversation. Achieving that kind of structural change works best when governance is integrated early and treated as part of the platform's foundation.

"The organizations and teams that are doing this well are not asking how to automate the human out of the loop; they are asking how to give the human more leverage," Isom says. "Automation executes a defined playbook. Before any team crosses into true autonomy, they need a defined confidence threshold at which the system escalates. Accountability is a guardrail, and that part cannot be automated. The human analyst stays in the loop."

That same logic applies to how governance gets sequenced inside a build. "We know that we are going in the right direction when we have trust requirements for deployment, with validation that is specifically required, like red team testing, prompt injection, and goal manipulation," she says. "As these bots and agents are being built, AI governance should not be at the end of the conversation; it should be at the beginning. From the very beginning, even from a feasibility standpoint, when the idea of a platform is first being talked about, governance needs to be in those conversations. It needs to be a pillar."

Ownership of transferred risk

Deploying AI agents also forces workforce changes. Treating automation primarily as a quick way to reduce headcount can weaken an organization's security posture if the remaining team lacks the skills to oversee those systems. A simple test for any AI implementation is whether the organization can clearly see who owns the new risks it introduces and how they will be managed. "When you automate a detection or response function, you do not eliminate the risk. You transfer it to the automation layer," Isom says. "So now your exposure includes the model being manipulated and the organization losing the human expertise to catch those failures because they stop doing the work manually."

Ownership, she argues, is the question that separates real risk reduction from theater. "When it comes to evaluation, I always ask who owns the new risk that the automation has introduced," Isom says. "If the answer is nobody, or there is finger-pointing, the organization has not reduced risk; it has obscured it. Organizations that cut headcount before building that new skill layer will find themselves less capable in both dimensions at the same time. It's really about having accountability and having incident response teams that can not just shift risk, but actually manage it."