Notifications
Clear all
Topic starter
02/08/2026 11:42 am
TL;DR: SOC teams are adopting AI tools without making them operational, with 40% using AI or ML outside defined workflows and 42% relying on out-of-the-box settings, according to Panther. The practical lesson is that structured telemetry, detection-as-code, and phased rollout matter more than procurement if teams want trustworthy automation.
NHIMG editorial — based on content published by Panther: How to Build an AI-Enabled SOC: Lessons From Teams That Did It Without Ripping and Replacing
By the numbers:
- 40% use AI or ML tools without integrating them into defined operations.
- 42% rely on out-of-the-box AI or ML with no customization.
- 69% of SOCs still handle metrics reporting manually or mostly manually.
Questions worth separating out
Q: How should security teams use AI in the SOC without losing human control?
A: Use AI to remove repetitive work, enrich alerts, and accelerate triage, but keep humans accountable for escalation, containment, and exception handling.
Q: Why do AI SOC projects stall even when teams already own AI tools?
A: They stall because procurement does not create operational readiness.
Q: What breaks when detection logic is not treated as code?
A: Without version control, testing, and review, detection changes become hard to validate and easy to break.
Practitioner guidance
- Normalize telemetry before expanding AI use Standardize field names, event types, and identity context across endpoint, cloud, SaaS, and network sources so AI has consistent inputs for triage and enrichment.
- Move detection logic into version control Store rules in Git, require peer review, and add automated tests so every AI-assisted detection change is visible, reversible, and auditable.
- Start with alert triage in a supervised phase Use shadow observation first, then allow AI to enrich and prioritise alerts before any automated response is permitted, with human approval retained for escalation.
What's in the full article
Panther's full blog covers the operational detail this post intentionally leaves for the source:
- The workflow patterns teams used to move from manual alert handling to AI-supported triage without disrupting existing SOC processes.
- The example detection engineering practices behind version-controlled rules, testing, and CI/CD deployment in security operations.
- The phased adoption model for shadow observation, supervised augmentation, and limited automation across different alert types.
- The practical metrics teams used to judge whether AI changed workload, detection quality, and coverage rather than only reducing ticket volume.
👉 Read Panther's analysis of how to build an AI-enabled SOC →
AI-enabled SOCs: what foundations teams need before automation?
Explore further
02/08/2026 12:54 pm
AI in the SOC is an operational governance problem before it is an AI problem. The article shows that teams stall when they buy tools before defining workflows, review points, and data standards. That means the real control gap is not model quality but operational discipline. Security leaders should treat AI enablement as a workflow governance programme, not a feature deployment.
A question worth separating out:
Q: Who is accountable when an AI triage system misses an incident?
A: The organisation remains accountable, even if software performed the first-pass analysis. Risk owners, SOC leadership, and the control owner for the workflow need to define approval rights, review obligations, and evidence retention before the system is relied upon.
👉 Read our full editorial: AI-enabled SOCs succeed when foundations come before automation
