Where AI belongs in your SOC: The trust vs impact framework | Nerdy 30, Episode 8

Introduction: The right question to ask

Ben Baker: Unless you’ve been living under a rock, everybody’s talking about AI, and specifically in security, AI’s place. Is it going to replace the security analyst? We think that’s the wrong question to ask.

The better one—and the one we’re going to spend the next 30 minutes on—is: Where does AI actually belong in your SOC, and where do humans need to remain?

A month ago, our team published a white paper called Trust vs. Impact, which is a framework for thinking through exactly that question. The TL;DR is we recommend mapping any SOC workflow or task against two variables:

1. How bad is it if that thing goes wrong?
2. How much do you trust the system to get it right?

Where those two lines meet tells you whether to automate it, keep humans around, or stay out of it entirely.

We’ve also built an interactive tool that walks through the framework using your own workflows. You can find both the white paper and the tool at expel.com/trust.

The Trust vs. Impact framework explained

Ben Baker: Walk us through the trust versus impact framework. What are the two axes? Why those two variables, and how should a SOC leader actually use it?

Nick Hatcher: You did a pretty good job in the intro of explaining the two axes: trust, impact. How much do you trust the machine to get it right? How bad would it be if it got it wrong?

We went with those two because there’s already a lot of hoopla going around about this topic, so we just wanted to anchor it in something that was really simple. It naturally also—if you do it with your team as a security leader—you might not even be able to get a point on that graph, because you might have a passionate discussion, let’s call it, of where you all think it is. That’s valuable in and of itself.

We anchored it in those two so that it could actually result in something that teams could use. It makes it really visual, and I think it also helps teams get to a point where they’re not just saying no to things—they’re saying either “not right now” or “absolutely yes, we’ll let it go there.”

Nick Hatcher: They can start having the conversation about: If they find something in that quadrant where AI doesn’t go anywhere near this, you’re naturally going to have the conversation of, “Well, why do you guys think that, and what would it take for you to trust it more, or to lower the amount of impact it would have if it goes wrong?”

When you go back to other teams internally, or maybe to vendors, you can say, “It’s got to be this tall to ride the ride.” You’re no longer the team of “No, I don’t want AI,” because I really don’t think you can be that anymore. That was maybe last year’s argument, but this year, if you’re drawing that hard line in the sand, it’s going to be a tough go for you internally, or just in general—not just in cyber, just in tech in general.

Ben Baker: At the end of the day, we want it to be a conversation starter. Being able to plot these out as a group, as a team, and then share this out and use that as a place to start that conversation—you don’t want to be the department of no.

The interactive tool: Map your own SOC workflows

The interactive tool at expel.com/trust allows you to:

1. Add your SOC tasks: List specific workflows your team performs (alert triage, incident investigation, remediation, reporting, etc.)
2. Answer guided questions: For each task, answer questions about:
   • What’s the impact if this goes wrong?
   • How much do you trust AI to complete this correctly?
   • What guardrails or validation would be needed?
3. Plot tasks on the matrix: As you answer, tasks are automatically plotted on the trust vs impact grid
4. See automation recommendations: Each quadrant provides guidance:
   • Quadrant 1 (Low trust, low impact): Safe to automate
   • Quadrant 2 (Low trust, high impact): AI assists, humans decide
   • Quadrant 3 (High trust, high impact): Humans drive, AI supports
   • Quadrant 4 (Fundamentally broken): Don’t automate OR have humans do this—fix the underlying process
5. Share your assessment: Generate a unique URL to share your plotted tasks with colleagues, leadership, or vendors to start conversations about AI deployment

Ben Baker: If you hover over any of these dots, you can see our recommendation for automation along with these tasks. You can expand this and take a look, and then you can click “share the assessment,” it’ll give you a unique URL, and you can send that to anyone. That will send them an example of that grid with all of your tasks plotted on it, and you can start a conversation from there.

Where the framework came from

Ben Baker: Where did the framework come from? Were you inspired by something when you first started riffing?

Nick Hatcher: I’d love for it to be some amazing epiphany moment or a funny story—”Oh, I was in the shower one day and thought of it”—but more like, I just refuse to start that awkward five minutes of a Zoom meeting when you’re waiting for everyone to get on. I really try not to ask about the weather.

I have the privilege of talking to a lot of customers by the nature of what I do at Expel, and it was starting to get kind of crazy. A year ago, I had a lot of people saying, “Oh, we’re not going to implement AI.”

Then there was this very sudden shift where a lot of people stopped saying that and they were saying, “Oh, we were coming from this meeting where we’re figuring out where or how, but we’re not sure where we can put things.”

Nick Hatcher: It was just a matter of: There’s got to be something that we can anchor it around. Having a background in consulting and project management, I thought—back in the day, the IR team I was a part of did tabletop exercises for people, simulated breach things. This is pretty close to how we would have done it. We would have just sat there and helped people have a conversation.

Being intentional about AI: Not shoving it at every problem

Ben Baker: When I think about this framework, it’s all about AI intentionality—being intentional about where you’re using AI. The tendency these days is to just shove AI at the problem rather than thinking critically: Does AI belong here? Does it really belong here? Or could it belong here eventually, but maybe it doesn’t today?

From your experience, Ray, in the SOC—our SOC’s been using AI and automation since the jump—why is it so critical and important to think critically about where AI fits in SOC workflows?

Ray Pugh: I think it’s immensely important. It understandably fits into the framework that Nick built and Ben Baker, master developer, built this really nifty tool.

I think it is really important to be intentional because, trying to think about it in a practical sense, I use AI in my personal life as well as my professional job duties. There are certain untouchable areas where I wouldn’t trust AI—like to parent my children. That seems like a weird spot.

Ray Pugh: I think being intentional—as well as operators and folks in the SOC, we have a risk aversion and a skepticism that makes us interrogate things very closely—but it almost feels backwards to try to jam it into everything.

Focus on any problem we’re trying to solve: What’s the outcome we’re trying to achieve, and how important is that outcome? Are there a variety of ways we can achieve that outcome? There’s always a trade space of the buckets of people, process, and technology. How can we fine-tune those things to find the right mix, also considering our constraints?

Overall, I think that intention is really important, but focusing on what you’re trying to solve and working your way backward feels like the right order.

What the framework is really about: Pointing AI at the right hard problems

Ben Baker: A lot of frameworks like this end up being about what not to automate, but it really feels like this is all about pointing AI at the right hard problems. What’s the difference, and why does it matter?

Nick Hatcher: If we developed a framework that helped you rule things out, I think you’re going to get some funny looks from people inside your business. It does rule things out—it helps you put some things up on the shelf, maybe for later.

But most people are surprised how much stuff it does say, “Oh, maybe it is an opportunity.”

The quadrant I find most interesting is the one where if something ends up here, you don’t—you shouldn’t have humans or AI doing it. It’s just fundamentally broken. You’re either burning out a human or you’re gonna have AI just go rampant and maybe make some really bad decisions because either the data isn’t there or things like that.

Nick Hatcher: It’s not so binary. It helps people figure out where all these tasks are.

It’s an interesting problem because this is one of the first problems I’ve seen in security where—the example I used with a customer was data residency, where there’s not really a lot of room to play there. CISOs can talk to each other, and there are rules and things like that.

But this is one of those things where if we could take everyone’s quadrant that’s done this, none of them are going to look the same. Even people in the same vertical, same industry, same size—it’s going to be different.

Other customers can’t really help each other because the problem itself is too bespoke to be that binary.

Ben Baker: That goes back to the crux of the framework. Nobody’s use cases are the same. Nobody’s experience is the same. So throwing a tool at somebody’s environment and saying, “Hey, AI, go do the magic stuff”—there’s context. Everybody’s got different context in the way they’re working, and it just doesn’t really work that way. Everybody’s a little bespoke.

Real-world example: Identity alerts at Expel

Ben Baker: In all of our prep calls, you both pointed to identity alerts here at Expel as a cool use case for how AI comes into play. Ray, walk us through what that looks like in the SOC. What does the AI do? What does it not do? What had to be true before you trusted it to run?

Ray Pugh: This is an interesting use case because identity alerts traditionally can be very ambiguous. On certain other surfaces it can be very decisive—”Oh, that file is bad, that is malware, everything it touches is bad.”

Whereas identity—baselining both user behavior, what’s normal in that environment, what we’ve seen in other customer environments—is a fairly time-intensive endeavor which analysts have gotten very good at doing manually. It just plainly takes time.

Ray Pugh: The AI capability we use—rapid alert triage—is a workflow that runs against these. It frames itself and puts itself in the mind of an analyst.

An analyst starts to look at an alert like our OSCAR framework, where you have two paths for everything you look at:

• What is the potentially non-threat story or legitimate story?
• What’s the potential threat story?

You’re going to have a creep score that’s bouncing, that’s skewing one way or the other based on what you’re reviewing.

Ray Pugh: The AI takes in that full context—against that user, that specific customer environment, what we’ve seen in other customer environments—explains both of those potential theories, and then has a confidence interval.

At the top end, it’s going to say, “I know this is bad for specifically these reasons.”

And to your question about what it does not do: It doesn’t today make decisions. We don’t trust it to do that. But it serves up all of that information to an analyst to have that human-in-the-loop dynamic to more quickly arrive at the same conclusion, or deprioritize something we are fairly certain is benign.

We’ve also had to condition the analysts to be extremely comfortable disagreeing with the AI. If it is agreeable to us, however, it’s not a two-way street—we need to be very comfortable not agreeing with it.

It’s been a really cool capability we’re actively working on right now, and that’s just one of the many things on the list.

Ben Baker: When I heard Ray explain that—serve it up and say “we’re relatively confident that this is the answer, but it might not be”—and then leaning into the analyst to make the decision, that seems like something that would fall in quadrant two, which is high impact, low trust.

That’s exactly the kind of thing we’re looking to achieve inside that quadrant, where AI is doing the work of rounding up the evidence and then leaning into the analyst to make that decision.

Nick Hatcher: Yeah, and I think it would have been easy—identity and endpoint are two of our big sources of finding evil. It would be easy to sit down and say, “I don’t want to go near that, because if it goes wrong, that’s one of our best ways to find evil inside someone’s environment.”

Instead of approaching it from that lens, we said, “Well, here’s an opportunity to turbocharge one of our best ways of finding evil in customer environments and make our SOC much more effective and build this world-class decision support system.”

Nick Hatcher: But it’s going to have to meet some pretty high bars, and some of those bars it hasn’t met—we haven’t let it go and run rampant and start turning things on and off and closing things.

But a lot of the bars it had to meet to even be able to get the time of day and talk to one of Ray’s analysts—it took a while for it to get there. And now it has.

It’s a great example of a high-impact thing, both in positive and negative, that I think some people might have stayed away from. But if you put the right guardrails around it and put some good metrics around it, it’s a great opportunity for a success story.

The rollout process: From idea to production

Ben Baker: Ray, before any AI deployment goes live in our SOC, what is the process of rolling that out? What does that look like in terms of getting SOC analysts up to speed on what it does, and what does it have to clear to get to that point?

Ray Pugh: That’s a really good question, and that’s something we felt really strongly about from the jump when these conversations started: It needs to still—there’s tons of potential, and it’s exciting—but it needs to adhere to our product and engineering principles and enablement and thorough testing with representative real data, instead of just throwing experimental things in front of very busy people. That can go sideways pretty fast.

That’s why we’re thankful for Nick and the other folks on the product team for adapting our time-tested frameworks. Here’s how we conceptualize something and write the right documentation and requirements. Really exciting stuff, but so important.

Ray Pugh: A bunch of “to the left” work before anything actually is live. There’s a lot of intention and prioritization of what’s going to have the best impact. Also being unafraid of: If initial testing isn’t showing the results we would expect, let’s table that and let’s try the next thing on the list. Being free to experiment—that’s where innovation lives.

There’s a lot of control gates before something gets in front of analysts. At that point, my expectation is it’s going to be about 80% complete, and we’re probably going to still have some robust feedback and fine-tuning and iteration we’re going to have to do. But it should be pretty darn close before we do.

Ben Baker: I think that’s one of the advantages of working with Expel—we’ve done the hard work of seeing what works, what doesn’t work. For every capability that you see, there’s experimentation and failure behind it to find the thing that works. We are able to fail in order to find the thing that works.

Where does the AI deployment idea start?

Ben Baker: Nick, from your perspective on the product side, where does that process start with you guys? Are you whiteboarding? Are you looking at points of friction in the SOC? Where does the idea start?

Nick Hatcher: A little all of the above. Specifically for my side of being involved with the platform—things that happen even before it makes it to Ray in the SOC—any of those tasks that we know right now are either highly manual, or we know we could embed the context that we need into a model to help make those decisions, we start looking at those.

But we approach them in a very similar way that Ray does. We have agents doing things far before they reach the visible surface of Workbench. But there’s still at some critical juncture that we define—and I think that’s the question we’re always trying to figure out—where’s the critical juncture that we want to put a human there to gut-check and make sure?

Are there metrics we can have that would make us feel comfortable for that human to walk away or not be there on a per-record basis? Maybe they only evaluate it once a week, but that thing continues instead of walking alongside it.

Nick Hatcher: That’s how we approach it. I think it’s why it works so well here—we all just have a similar way of looking at it. No one’s trying to go full automation upstream of the SOC, and the SOC’s definitely not trying to go full automation downstream of us. As long as you and your team are all on the same page, you’re at least all measuring it the same way and can get some good outcomes out of it.

The feedback loop: How SOC analysts shape AI capabilities

Ben Baker: Ray, whenever a new AI capability or automation comes online, tell me about the feedback loop you have with your SOC team. Are they providing you feedback—maybe even negative feedback like “this isn’t really working for us”? Is that an ongoing conversation you’re having with analysts, and are you taking that back to the product team?

Ray Pugh: Yes, that’s a great question. That’s something we actually lean into pretty hard: The most direct, with the least frills, feedback you’re going to get is from shift analysts. They’re going to tell you exactly what they think, and it’s a beautiful thing.

Obviously we don’t want to bog them down in “let’s have a two-hour feedback session.” It needs to be really easy for them to do. Collect those small pieces of feedback in volume, have somebody who gathers them together and has those conversations—one of our SOC managers as a central point.

Ray Pugh: We absolutely make the feedback loops really accessible to the SOC.

Some of these things—AI is so good at so many things, but one of the things it’s also really good at is taking something that should be 500 words and making it 5,000 words. It can be overly verbose.

An analyst is like, “I want to be able to read this in 20 seconds. Can we make it 30% of the words that it is now?”

So minor changes. As I said earlier, delivering 80% solutions, not letting perfection be the enemy of progress, but then being ready to have those conversations and iterate rapidly directly after, when it is fresh and you get that initial fresh perspective—people aren’t accustomed to it yet—that’s the best time to get that feedback.

Ray Pugh: Those first few days are really the time to get it buttoned up and then move on to the next thing.

Ben Baker: I can imagine an automation that works well can provide a lot of value to a SOC analyst moving really quickly at high volume. But something that doesn’t provide the benefit they were expecting can really create a drag. Obviously you want to keep tabs on that.

Understanding the four quadrants

Quadrant 1: Low trust, low impact → Automate fully

Tasks where you’re comfortable deploying automation because even if it gets it wrong, the consequences are manageable:

Examples:

• Enriching alerts with threat intelligence
• Gathering standard context (user location, device info, recent activity)
• Initial data collection for investigations
• Routine reporting and metrics
• Basic categorization and tagging

Guidance: Automate these tasks fully. Monitor performance, but don’t require human review of every instance.

Quadrant 2: Low trust, high impact → AI assists, humans decide

This is where the identity alert example lives. Tasks where getting it wrong would be serious, but you don’t yet fully trust the AI:

Examples:

• Alert triage and prioritization
• Incident classification
• Determining whether activity is malicious or benign
• Recommending response actions
• Identifying lateral movement or persistence

Guidance: AI does the heavy lifting—gathering evidence, analyzing patterns, proposing theories—but humans make the final decision. The AI serves as a decision support system, not an autonomous agent.

Ben Baker: This quadrant is where AI is doing the work of rounding up the evidence and then leaning into the analyst to make that decision.

Quadrant 3: High trust, high impact → Humans drive, AI supports

Nick Hatcher: This is stuff your team agrees is way too risky if it goes wrong—lots of PagerDuty phones going off, critical systems going down, you have to disclose something, things like that.

And the team—maybe the process itself is really bespoke. A good example of something on the opposite side is when I need to do research about an integration we’re going to build and pull back API documents. That’s something AI can handle really well. I can tell it “only look at vendor-authored things, bring back everything” so I can look at all my research and start to build out requirements.

On the other end, where you don’t have that level of granular things you can give it and give it really clear instructions—maybe if you start making a flowchart, there’s a lot of stems going in different directions—you’re going to find yourself in that quadrant pretty fast.

Examples of quadrant 3 tasks:

• Writing detection rules (some organizations put this here because they’re very shy of putting the thing that triggers the whole process in AI’s hands)
• Remediation actions—taking systems offline (scares a lot of people because AI might hallucinate and take down a critical server because it didn’t check the allow list)
• Major incident decision-making
• Customer communication about breaches
• Executive briefings

Guidance: Humans remain in control. AI can assist with research, documentation, or routine tasks, but critical decisions and actions require human judgment.

Nick Hatcher: It’s a pretty big range. When I’ve talked to customers about it, some people have things like writing detections in there because they’re very shy of putting the thing that triggers this whole process in AI’s hands.

A more common one I hear is remediation—handing over the ability to take a system offline if you need to scares a lot of people because it might not be compromised or malicious. It might just have a little hallucinate moment and then take down a critical server because it didn’t look at the allow list or deny list.

Quadrant 4: Fundamentally broken → Fix the process first

If a task lands here, it indicates a broken process that shouldn’t be done by humans OR AI:

Indicators:

• Data quality is so poor that neither humans nor AI can make good decisions
• The process itself is inconsistent or poorly defined
• Success requires information that doesn’t exist or can’t be accessed
• The task shouldn’t exist at all (legacy process no longer serving its purpose)

Guidance: Don’t try to automate or staff this. Fix the underlying process, improve data quality, clarify requirements, or eliminate the task entirely.

The new hire analogy: Treating AI like a junior analyst

Nick Hatcher: I just tell people: Look at it, take the word AI out of it, and take it as if you hired a new hire on your team.

There are certain tasks that—when Ray hires a new analyst, they don’t get to do the big scary incident on day three. There are certain things Ray has to see before that analyst gets to do those things.

And when they do get to do them, I would assume, Ray, you’re watching certain things to make sure they’re doing them the way Expel wants them to do, and then you give them feedback afterwards.

It’s the exact same thing—just instead of talking to a human, you’re going to be evaluating an agent to do it.

This analogy provides several practical insights:

Training and validation: Just as new analysts need training before handling complex incidents, AI needs testing and validation before being trusted with high-stakes tasks.

Progressive responsibility: Junior analysts start with simpler tasks and gradually take on more complexity as they demonstrate competence. AI deployment should follow the same pattern.

Supervision and feedback: Managers watch how new analysts perform and provide coaching. AI requires similar oversight—monitoring performance, catching errors, and adjusting behavior.

Building trust over time: Trust in a new analyst develops through observation of consistent, quality work. Trust in AI develops the same way—through demonstrated reliability over many iterations.

Clear expectations: New hires receive clear guidance about what’s expected. AI needs equally clear instructions, guardrails, and success criteria.

Not all tasks are suitable: Some tasks require years of experience or specialized expertise. Similarly, some SOC tasks require human judgment that AI can’t replicate.

Where to start: The Monday morning action plan

Ben Baker: For a SOC leader watching who doesn’t have a framework like this, who’s just overwhelmed with the amount of AI chatter out there—where do they start on Monday morning? What’s one thing each of you wishes that more security leaders understood about this topic?

Nick Hatcher: I think you have to get the core team together and have an honest conversation. You’re going to find out that your team is doing a lot more things than you think they’re doing, and bending over backwards to make processes work that maybe you thought were a lot cleaner or automated than they are.

This only works if you have a really honest conversation with each other about: How bespoke is this thing we ask an analyst to do? Could it be handed off to a machine if we gave it the right instructions?

Nick Hatcher: Once you’ve mapped it all out, you then have to start thinking about the autonomy of those decisions.

If you own the LLM and all that, that’s great. Maybe your team doesn’t own it—that’s still important. You have to take a ticket and get in line with your data science team or something like that.

If you don’t have the ability to rapidly iterate and you lose that autonomy of the LLM or whatever it is to influence it and embed the smarts that your analysts or team have into it, you’ll pretty quickly run out of control with it.

All the amazing things I see come out of the SOC happen because the team can innovate. But if you get to a point where everything’s tied to an LLM you don’t have the ability to influence, the innovation train is going to stop because people are just going to say, “Well, I don’t have the ability to do that.”

Nick Hatcher: I think Satya Nadella talked about that at the World Economic Forum this year: Autonomy is the next question. Transparency is the baseline, then you have trust, and then: Do you have the ability to change what this thing is going to do? Or are you just renting someone else’s knowledge?

Ray Pugh: I think, especially if you’re at the beginning of the journey, advice I would give—probably when we talked about metrics, episode two—crawl, walk, run.

If this is a starting point, start small, do some experimentation. It overlaps a lot with what Nick was saying: You have to be intentional and have a really rationalized plan instead of just arbitrarily going out and trying to slap an AI bumper sticker on something.

Have some intention, have some prioritization, have organizational buy-in and alignment. But then don’t be afraid to experiment. Also, don’t be set in your ways and be afraid to change your mind.

Ray Pugh: If something doesn’t work out how you thought it would, make a new plan and pivot from there. Be adaptive and flexible.

What’s coming next: Constructive feedback and V2

Ben Baker: What’s some of the constructive feedback you’ve been hearing about the framework, and maybe some different aspects that may be worth looking into for V2?

Nick Hatcher: I think helping people come up with some of those metrics—it’s all well and good to get some dots on a graph, but also helping people come up with the metrics that move those dots around the graph, or be able to read out a bit more, is a common one. That will help people get there.

That’s the main one people say: “This is great, but I don’t want to put this up on the screen to my boss and then they go, ‘Well, what would it take for that to move there?’ and I go, ‘…okay.'”

Sharing how we have rated a human against an AI to say when it’s ready to be given to the SOC—hopefully we can get that out to people so they can use those in their organizations or see if there’s anything they would add to it.

Frequently asked questions about AI in the SOC

What are the two axes in the Trust vs Impact framework?

Trust (horizontal axis): How much do you trust the AI system to complete this task correctly? This includes technical capability, reliability, accuracy, and your team’s confidence in the system. Impact (vertical axis): How bad would it be if this task goes wrong? This considers business impact, security consequences, customer trust, and potential for damage. Plotting tasks on these two dimensions reveals which should be automated, which need human oversight, and which shouldn’t be done at all.

Why doesn’t the framework just tell me what not to automate?

Because every organization’s context is different. Two companies in the same industry, same size, same vertical will plot tasks differently based on their risk tolerance, existing processes, team capabilities, and specific environment. The framework helps teams have informed conversations about their specific situation rather than prescribing universal rules that wouldn’t fit anyone perfectly.

How does Expel use AI for identity alert triage?

Expel’s rapid alert triage capability uses AI to baseline user behavior across the specific customer environment and broader patterns from hundreds of environments. It explains both the potential threat story and the legitimate explanation, provides confidence intervals, and surfaces all evidence to analysts. However, AI doesn’t make the final decision—analysts maintain human-in-the-loop control to approve or reject the AI’s assessment.

Should I treat AI like a new employee?

Yes, according to Nick Hatcher’s analogy. New analysts don’t handle major incidents on day three—they need training, supervision, and progressive responsibility. AI should be treated the same: start with simpler tasks, validate performance, provide feedback, and gradually expand responsibilities as the system proves reliable. Just as you wouldn’t hand critical decisions to untrained staff, don’t hand them to unproven AI.

What if my team doesn’t own or control the AI model?

This is the autonomy question. If your team can’t influence, tune, or customize the AI system—if you’re just renting someone else’s knowledge—innovation becomes difficult. When something doesn’t work as expected, you’re dependent on the vendor’s roadmap rather than your team’s ability to adapt. Where possible, prioritize AI solutions you can customize and improve based on your team’s expertise and feedback.

How long does it take to roll out AI capabilities in production?

At Expel, significant “to the left” work happens before anything reaches analysts—thorough testing with representative real data, documentation, enablement materials, and validation. By the time analysts see it, the capability should be about 80% complete. Then expect a few days of fresh feedback and rapid iteration to fine-tune. Don’t rush experimental capabilities in front of busy analysts—it can go sideways fast.

What should I do if initial AI testing doesn’t show expected results?

Table it and try the next thing on the list. Being free to experiment means being comfortable with some experiments not panning out. Don’t force a solution that isn’t working—pivot to another opportunity. Innovation requires trying multiple approaches and being honest about what’s delivering value versus what’s not.

Key takeaways

The Trust vs Impact framework and this conversation reveal critical insights about deploying AI in SOCs:

Two simple variables unlock complex decisions: Trust and impact provide an anchor for conversations that otherwise devolve into “AI everywhere” or “AI nowhere.” The framework forces specificity about what you’re actually trying to automate and why.

No two organizations are the same: Unlike data residency or other security problems where CISOs can share answers, AI deployment is inherently bespoke. Your quadrant won’t look like anyone else’s, even in your same industry and size. That’s okay—use the framework to have your own honest conversation.

The framework is a conversation starter: You might not even agree where to plot tasks initially, and that passionate discussion is valuable. It reveals assumptions, concerns, and priorities that inform better AI deployment decisions.

High-impact areas can benefit from AI: Don’t automatically exclude your best detection surfaces (like identity alerts) from AI. Instead, ask: How can we turbocharge this with the right guardrails? Expel’s identity triage shows that high-impact + low-trust can work with proper human oversight.

80% solutions beat perfection paralysis: Don’t wait for perfect AI capabilities. Deploy at 80%, gather rapid feedback, iterate quickly. The first few days provide the freshest perspective before teams get accustomed to new tools.

Treat AI like a new hire: Progressive responsibility, supervision, feedback, and training apply to both. New analysts don’t handle critical incidents immediately—neither should untested AI. Build trust through demonstrated performance over time.

Autonomy matters as much as capability: If you can’t influence, tune, or customize your AI systems, innovation stalls. When problems arise, you’re dependent on vendor timelines rather than your team’s ability to adapt. Prioritize solutions where you maintain control.

Analyst feedback is gold: Shift analysts will tell you exactly what they think with no frills. Make it easy for them to provide feedback, collect it in volume, and act on it rapidly. Their front-line experience reveals what actually works versus what looks good in theory.

Start with honest conversations: Gather your core team and discuss what tasks analysts actually do (versus what you think they do). You’ll discover more manual work and workarounds than expected. That’s your opportunity list for AI deployment.

Crawl, walk, run: Start small with experimentation. Be intentional with prioritization. Get organizational buy-in. Don’t be afraid to change your mind if something doesn’t work. Adapt and pivot based on results.

Don’t be the department of no: Drawing hard lines against AI in 2026 is a tough position internally and externally. Use the framework to say “not right now” or “yes with guardrails” rather than blanket refusal. Define what it takes to earn trust rather than categorical rejection.

Focus on outcomes, work backward: Start with what you’re trying to achieve and why it matters. Then evaluate people, process, and technology trade-offs considering your constraints. This order ensures AI serves your goals rather than becoming a solution looking for a problem.

This transcript has been edited and condensed for clarity and readability.

For the Trust vs Impact white paper and interactive tool, visit expel.com/trust. To learn more about how Expel deploys AI and automation in security operations, or to see how Expel’s 24×7 SOC leverages human-AI partnership for better detection and response, schedule a demo today.