The pitch is attractive: ask your SIEM a question in plain English, get an incident summarised in seconds, let an assistant work through the alert queue overnight. For an overstretched SOC, that sounds like exactly the help it needs. So it is fair to ask whether AI can really improve your SIEM, and what it costs you.
The honest answer is that AI helps with some SOC tasks, does little for others, and brings risks that are easy to overlook. It is worth separating them.
Where AI genuinely helps a SOC
- Writing queries. Turning “show me admins who signed in from a new country this week” into KQL or SPL is a good job for a language model, especially for newer analysts. You still check the query, but you get there faster.
- Summarising incidents. Condensing a long alert timeline into a readable paragraph for a handover or a manager saves time, as long as someone checks it against the raw events.
- Explaining unfamiliar artefacts. What does this command line do? What is this registry key used for? A model can give a useful first answer.
- Drafting documentation. Runbooks, use-case write-ups and post-incident reports come together faster with an assistant.
There is evidence that automation in security operations pays off. IBM’s 2025 Cost of a Data Breach study found that organisations using AI and automation extensively in security operations saved an average of $1.9 million per breach and shortened the breach lifecycle by 80 days. [1] Note that the study groups AI together with automation in general, which includes a lot of deterministic tooling.
Where AI helps less than you’d think
Detection itself. The core job of a SIEM is deciding whether something is an attack. That needs to be precise, repeatable and explainable: you must be able to say why an alert fired, and get the same answer tomorrow. Language models are probabilistic. The same question can produce different answers, and a confident wrong answer looks exactly like a right one. For detection logic, deterministic rules and correlation remain the better foundation.
Fixing coverage gaps. The average enterprise SIEM covers about 21% of MITRE ATT&CK techniques while ingesting enough data for more than 90%, and 13% of its rules are broken. [2] Those are engineering problems: missing rules, missing fields, broken parsing. An assistant on top of a SIEM with poor coverage gives you fluent answers about the attacks you can see, and nothing about the ones you can’t.
Reducing cost. AI features are usually priced on top of ingestion, and many search or summarise data you already pay to store. On their own, they don’t tell you which data no detection uses.
The privacy question that rarely makes the slide
Security logs are some of the most sensitive data an organisation holds. They contain user names and email addresses, internal host names and IP ranges, file paths, the URLs people visited, and sometimes things that should never have been logged at all: tokens in URLs, passwords typed into the wrong field, customer identifiers inside application errors.
When a SIEM’s AI feature, or a separate AI tool, sends that data to a model provider, you have added a processor to your data flow. Your privacy and risk teams will want answers to questions like these:
- Where is the data processed, and does that meet your data-residency obligations?
- Is any of it retained, logged or used to improve the provider’s models?
- Does it appear in your records of processing and your privacy impact assessments?
- Who can see the prompts and responses, and for how long?
There is a new attack surface too. A model that reads attacker-controlled text, such as a user agent, a URL or an email subject in your logs, can be steered by it. Prompt injection is ranked first in the OWASP Top 10 for large language model applications. [3] An assistant summarising a malicious log line can be told, by that log line, to leave something out.
Governance is lagging behind adoption. IBM found that 63% of breached organisations either had no AI governance policy or were still developing one. [1]
Improve your SIEM without sending logs to AI
LogLens uses no AI of any kind and needs no internet. It finds your coverage gaps, the logs you can cut and the use cases you can deploy with deterministic rules, and it redacts sensitive data as it reads each event.
Read about LogLens and privacy →Questions to ask before you switch on an AI feature
- What exactly is sent to the model: whole events, selected fields, or only my question?
- Is sensitive data masked before it leaves my environment?
- Where is it processed, and is it retained or used for training?
- Can I see and audit every prompt and response?
- Can the AI change detections or take response actions without a person approving it?
- How is it priced, and does the price grow with my ingestion?
What to improve first
If the goal is a better SIEM, the highest-return work usually isn’t AI. It is knowing which logs support which detections, deploying well-tested use cases for your gaps, correlating attack stages instead of single events, and cutting the data nothing uses. That work is deterministic, auditable and keeps your data where it is. Once it is in place, an AI assistant can make good analysts faster. Before then, it mostly makes a weak SIEM sound confident.