Security operations has a volume problem that predates AI by twenty years. There are more alerts than analysts, most alerts are nothing, and the interesting one is somewhere in the middle of the pile.
AI assistants help with that, but not in the way the marketing suggests. They are useful for preparing work, not for deciding it.
The Best Use: Compression
When an analyst opens an alert, the first several minutes go to gathering context. What is this host and who owns it. Who is this user and what is their role. What else happened around this time. Has this fired before, and how was it resolved.
All of that is retrieval and summarization, which is exactly what these tools are good at. Cutting five minutes off every alert in a queue of three hundred is a real gain, and it does not require the model to make any judgment call.
The key design point is that the analyst still sees the underlying evidence. The summary is a starting point with links, not a replacement for the data.
The Second Best Use: Explanation
Junior analysts spend a lot of time not knowing what they are looking at. A base64 encoded PowerShell command. An unfamiliar Windows event ID. A registry path. A process nobody recognizes.
Getting a plain language explanation in seconds instead of twenty minutes of searching is a genuine accelerator, and it happens to be good training as long as the analyst is taught to verify. Command flags and event ID meanings are exactly the kind of specific detail models get wrong occasionally and confidently.
Translation Between Query Languages
Every SIEM has its own language. Splunk has SPL, Microsoft Sentinel has KQL, Elastic has its own syntax, and open detection rules are often published in Sigma format.
Translating a detection from one to another is mechanical work that models do well, because it is a structured transformation of text. Verify the result against real data before trusting it, because field names differ between environments even when the syntax is right. More on this in detection engineering.
Drafting Reports and Tickets
Incident reports, ticket updates, and executive summaries are writing tasks that analysts generally dislike and often postpone. Turning bullet notes into a first draft is a strong use case.
The rule is that the analyst supplies the facts and the model supplies the prose, never the other way round. A model asked to write an incident report without the underlying evidence will produce something that reads beautifully and contains invented details. See the incident response guide for what a report has to contain.
What Must Stay Human
The close or escalate decision. A wrongly closed alert generates no error and no complaint, which makes this the most dangerous place to automate. It fails silently and looks like efficiency.
Containment actions with business impact. Isolating a host, disabling an account, or blocking a network path can cause an outage. Those decisions need someone accountable.
Attribution and intent. Models will happily produce confident claims about who did something and why. Those claims are assessments, they need evidence and a confidence level, and they have serious consequences when wrong.
Anything that goes to a regulator, a customer, or a court. Legal statements need a human author.
Data Handling Is Not Optional
SOC data is among the most sensitive data a company has. It contains user names, host names, internal addresses, business processes, and the details of your own weaknesses.
Before any of it goes into an AI service, someone has to answer specific questions: where does the data go, is it retained, is it used for training, who at the provider can see it, and does the contract say so in writing. Enterprise tiers from providers such as Anthropic, OpenAI, Microsoft Azure, and Google Cloud generally have different terms than consumer products, and the differences matter.
The alternative is a model running inside your own environment, which trades some capability for complete control. That is a legitimate choice for regulated industries. See shadow AI for how to keep the unapproved version of this from happening anyway.
Measuring Whether It Helped
The metrics worth tracking are time to triage, time to contain, the percentage of alerts closed without escalation, and how many closed alerts turn out later to have mattered.
That last one is the honest metric and almost nobody measures it. Sample closed alerts and re-examine them. If the AI assisted queue is closing more things incorrectly than the manual one was, you have made throughput better and outcomes worse.
Learn This at HackRange
Week 11 of the mentorship uses these tools in a real workflow, and grades you partly on catching what the assistant got wrong.