Where AI genuinely helps in a monitoring operation
The following are candidate uses, not guaranteed gains. Grouping and enrichment can also be implemented with deterministic rules and ordinary automation; compare the model with that baseline. Numerical scenarios below are illustrative, not results from a Dyasol client.
Deduplication and grouping. One misconfigured backup agent produces four hundred alerts. One password-spray attempt produces one per targeted account. Clustering on shared entities - account, host, source address, process ancestry - and on a time window turns those into a single case with four hundred pieces of evidence attached. The saving is measurable: cases opened per shift, against alerts raised per shift.
Enrichment. This is where most of the real time goes and most of the real gain sits. Before an analyst can judge an alert they need to know who owns the asset, whether the account is privileged, whether the source address appeared in the last ninety days, whether the binary is signed, whether the mailbox rule is new. Each is a lookup in a different system. Assembling them before a human opens the case changes the shape of a shift.
Summarising an event chain. A readable sequence can help a duty manager understand a large case. Keep source references beside material claims and check omissions and invented causal links. Retaining raw events helps verification; it does not make summarisation intrinsically low-risk.
Drafting the incident record. A model can prepare a timeline and list of known facts, estimates and open questions. The authorised person verifies and submits the report. The incident reporting guide sets out the separate NIS2 and DORA clocks and exceptions.
Surfacing rare sequences. Static rules only find what someone wrote a rule for. A model that has learned what normal looks like in your environment can flag a sequence nobody anticipated - a service account authenticating interactively, an administrative interface reached from a new country, a process chain seen twice in a year. Genuinely additive, also the noisiest item here, and its output is a lead, not a finding.
Where it does not help, or actively hurts
Confident wrong explanations. A model that tells you "this is routine activity from the backup service account" reads exactly like a model that is right. There is no tone difference between a correct conclusion and a fabricated one. The damage is not the wrong answer - analysts are used to being wrong - it is that a fluent summary stops people opening the raw events. Fluency is not evidence.
Opaque detection logic. Limited access to training data or model logic makes some failure modes harder to explain. Evaluate behaviour through representative tests, documented coverage and change monitoring. A transparent rule can also miss attacks; transparency alone does not establish superior detection.
Alert volume that falls because of suppression. A queue dropping from 900 to 120 items a week is presented as efficiency. It is efficiency if 780 were duplicates of 12 real events. It is a loss if some were suppressed by a confidence threshold nobody chose deliberately. On a dashboard the two look identical. Ask for the accounting.
Missing telemetry. A model may infer activity from indirect evidence, but inference does not replace an absent record. Distinguish observed events from hypotheses. Verify source coverage and retention against investigation needs, rather than assuming a particular retention period is always sufficient or always inadequate.
A quieter fifth problem: running every event through a large model is expensive, so products batch, sample or gate. Reasonable engineering - but the fraction the model actually sees is rarely on the datasheet. Ask for it.
Task by task: what changes, what does not
| Monitoring task | What AI genuinely changes | What stays a human decision | How to verify the claim |
|---|---|---|---|
| Deduplication and grouping | Alerts sharing an entity and a time window become one case; queue volume falls | Whether a grouped case is one incident or two that overlap | Replay a known noisy day; compare cases against alerts; confirm no true positive was absorbed |
| Enrichment | Owner, privilege, prior history and reputation are attached before a human opens the case | Whether that context is sufficient to close | Take 20 recently closed alerts; check every enriched field against the source system |
| Summarising an event chain | Thousands of events become a readable narrative in seconds | The classification and the severity | Give the same chain to an analyst and to the model; compare both against the raw timeline |
| Drafting the incident record | A first timeline and impact statement exist in minutes | Every fact stated to a regulator, a customer or an insurer | Diff the draft against the final signed record from a real incident |
| Rare sequence detection | Sequences no rule covers get surfaced | Whether the anomaly is malicious or a new business process | Perform a controlled test action; record whether it was flagged, and separately what telemetry captured |
| Automated response | Containment in seconds instead of after a phone call | The decision to act against a person's account or a production system | Tabletop the false positive: it isolates the wrong host at 03:00 - who reverses it |
"Our AI detects X" is a declared control
Our SIEMvolution publication provides the research context for AI enhancements in managed security. The practical buyer question is narrower: what improves in this deployment, against what baseline and with what evidence? Identity-control verification is one useful test area.
An “AI detects lateral movement” claim needs a defined technique, prerequisites and evidence. Test whether the action is recorded, whether an alert is raised for the intended reason and whether a responder can investigate it. A successful single scenario establishes that scenario, not universal coverage.
The regulation already agrees. DORA Article 10 requires mechanisms to promptly detect anomalous activities and alert thresholds that trigger the incident response process - and it requires those detection mechanisms to be tested regularly. NIS2 Article 21(2)(b) puts incident handling among the required risk-management measures. Neither text says "buy detection". Both ask whether the mechanism works, which a controlled test answers and a datasheet does not. If you are still working out which regime applies to you, start with the comparison of DORA and NIS2.
Six questions to put to a provider that claims AI
Each of these has an answer that should worry you.
1. Which specific steps in your pipeline use a model, and which use a rule? Worrying answer: "AI is applied throughout the platform." A provider who cannot draw that line has not drawn it internally either.
2. Which log sources must I send for your detections to work, and which detections silently degrade if one is missing? Worrying answer: "we ingest everything, more data is better." The second half is the real question. Silent degradation is the failure mode that costs you an incident.
3. Can you show me a detection that fired during a controlled test, with the raw telemetry behind it? Worrying answer: a recorded demo, a public benchmark, or an anonymised story about another customer. Also worrying: confidentiality cited when you asked about your own tenant.
4. When alert volume dropped, where did those alerts go - grouped, suppressed, or auto-closed by a model? Worrying answer: a percentage with no accounting behind it. "We reduced noise by 80%" is a claim about their product, not about your risk.
5. What can the model do without a human, and who is accountable when it gets it wrong? Worrying answer: "there is always a human in the loop", with no named approval step and no log of overrides. If a model can disable an employee's account, your organisation is making a decision about a person.
6. Does the model process my data, where does it run, and is my data used to train anything? Worrying answer: "your data is secure." You asked for a location, a retention period and a yes or no on training - the same discipline that belongs in your own AI use policy.
What to do first
- List your log sources and confirm ingestion, not intention. Check each source on the architecture diagram against what the platform actually received in the last seven days, and note the retention period beside it. This finds more gaps than any tuning session.
- Run one controlled test action this week. Something small, in your own environment, with permission: an inbox forwarding rule on a test mailbox, a test account added to a privileged group, a known-benign discovery command on a workstation. Record three facts - did an alert fire, what did the telemetry capture, how long until a human looked.
- Put the six questions to your provider in writing. Written answers behave differently from answers on a call.
- Add two columns to your control register: last tested, and by whom. For every entry that mentions detection or AI. An empty pair of cells is a declared control, now visible as one.
- Decide in advance what the model may do alone. If the answer includes isolating a host or disabling an account, name the person who signs that off at 03:00 and the procedure for reversing it.
- Fix collection before buying analytics. If step 1 found a missing source, that is the next purchase. A model over a gap does not close the gap - and the gap is the ground ransomware still uses in 2026.
The boundary
None of this argues against the tools. The grouping, enrichment and drafting gains are real, and an operation that refuses them wastes analyst hours on clerical work. The argument is narrower: a claim about detection is not evidence about detection.
Reporting responsibilities remain with the organisation; use the first-24-hours guide for the applicable deadlines. AI Act classification depends on the system and use. Review AI literacy under the current amended Article 4 and the company AI policy guide, rather than assuming that an AI security product is automatically high-risk or exempt.
Book practical security improvements if you want the detection you already pay for tested against a controlled attack, with the telemetry examined afterwards.
Note: general information, not legal advice. Applicability depends on the specific entity, activity, licence, size, group structure and national implementation.
When buying monitoring, ask the provider to demonstrate the agreed chain with the MDR and SOC acceptance scorecard.
Protect the analysis from the evidence it reads
Logs, emails and tickets can contain attacker-controlled text, including instructions intended to manipulate a language model. Treat that content as untrusted data. Separate it from operational instructions, restrict tool permissions, require source-backed conclusions and define reversible, pre-authorised response actions with escalation limits. Test misleading evidence and prompt injection alongside normal detections. Use the SIEM evaluation checklist to record the results.