Should organisations prioritise analyst-like AI before adding more alert rules?

Why This Matters for Security Teams

This question matters because alert rules and analyst-like AI solve different problems. Rules are useful when the goal is consistent signal generation from known patterns. Analyst-like AI is useful when the problem is interpretation, triage, and cross-system reasoning. Security teams often add more rules when the real bottleneck is not coverage but the time it takes to understand what already fired. That creates noise, not confidence.

A useful reference point is the NIST Cybersecurity Framework 2.0, which emphasises governance, detection, response, and continual improvement as a connected operating model rather than a single control choice. The practical issue is that overly aggressive rule expansion can increase alert fatigue, while premature AI adoption can introduce opaque recommendations if the system is not bounded by clear workflows. The right priority depends on whether the team needs broader detection or faster investigation. In practice, many security teams encounter the limits of rule tuning only after incidents have already generated too many ambiguous alerts to investigate effectively.

How It Works in Practice

In operational terms, analyst-like AI should be introduced where humans already spend time reading context, comparing evidence, and deciding whether an event is benign, suspicious, or confirmed malicious. That means summarising related alerts, correlating identity activity, endpoint telemetry, cloud events, and threat intelligence, then presenting a defensible rationale. This is not the same as autonomous decision-making. The better model is supervised assistance, where the AI drafts an investigation path and the analyst still owns the final call.

By contrast, alert rules still matter for deterministic detections such as impossible travel, privilege escalation, suspicious logins, or known bad hashes. The question is sequencing. If coverage gaps exist for a high-risk technique, rules may be the first fix. If the team already receives enough signal but cannot keep pace with triage, analyst-like AI can reduce dwell time by grouping evidence and highlighting contradictions. The MITRE ATT&CK framework is helpful here because it encourages teams to think in terms of techniques, tactics, and observable behaviour, which makes it easier to decide whether a gap is a detection problem or an investigation problem.

A practical rollout usually looks like this:

• Map the alert backlog to common investigation patterns, not just detection sources.
• Identify cases where analysts repeatedly check the same logs, identities, or asset context.
• Use analyst-like AI to summarise evidence, suggest next questions, and rank likely explanations.
• Keep rule creation focused on known high-confidence detections and regulatory requirements.
• Measure whether the AI shortens triage time without increasing missed incidents or false confidence.

This approach also aligns with response maturity guidance in the CISA incident response guidance, where preparation, analysis, containment, and lessons learned should be operationally linked. These controls tend to break down in highly fragmented environments because the AI cannot reliably correlate events when telemetry is incomplete, inconsistent, or locked behind separate teams and tools.

Common Variations and Edge Cases

Tighter detection coverage often increases maintenance overhead, requiring organisations to balance rule precision against analyst capacity. That tradeoff becomes more visible in large enterprises, regulated sectors, and hybrid environments where the same behaviour appears differently across cloud, endpoint, identity, and SaaS systems. In those settings, adding more rules can create a brittle detection stack that is expensive to tune and still hard to interpret.

There is also no universal standard for how much reasoning an analyst-like AI should be allowed to perform. Current guidance suggests keeping the model within bounded tasks such as summarisation, clustering, and evidence comparison, rather than letting it make final security judgments without review. The NIST AI Risk Management Framework is useful for setting that boundary because it emphasises validity, reliability, safety, accountability, and transparency. Where the organisation handles sensitive data, identity context, or privileged access activity, the AI should be restricted to the minimum evidence needed for the task.

Analyst-like AI is less compelling when telemetry quality is poor, when detections are immature, or when the organisation needs compliance-driven coverage before anything else. In those cases, rule expansion may still be the better first step. The best practice is evolving, but the operational test is simple: if the team already knows what to look for and just needs more of it, add rules; if the team has the signal but cannot make sense of it quickly enough, prioritise analyst-like AI. This decision becomes hardest in low-volume environments where one rare alert can still require deep manual validation.

Related resources from NHI Mgmt Group

• Should organisations prioritise identity governance before expanding agentic AI?
• Should organisations prioritise least privilege before adding more cloud controls?
• Should organisations prioritise AI agent access controls before broader NHI cleanup?
• Should organisations prioritise AI data governance before scaling AI adoption?