Every Detection Product Now Says "AI." Most SOC Teams Still Ask the Same Two Questions.
Walk any security expo floor in the last two years and the booths blur together. Threat detection, network monitoring, endpoint protection, log analytics, all of it now carries the same three-letter badge. The market data backs up the shift. IDC's 2024 study of China's cyber threat detection and response market (Doc # CHC52196225) put the category at RMB 2.36 billion and singled out one dominant trend: vendors like QAX, NSFOCUS, Sangfor and DAS-Security are folding machine learning and generative models directly into their network detection and response products to analyse larger volumes of traffic, catch unknown threats, and speed up incident handling.
That trend is real, and it matters well beyond China. But when we sit down with a bank's security team in the GCC, or a critical-infrastructure operator worried about their operational network, the questions have not changed at all. Does this actually reduce the time my analysts spend chasing noise? And what new risk am I taking on by wiring a language model into the middle of my detection pipeline? Those are the right questions. This article is our attempt to answer both from the operator's chair rather than the vendor's slide deck.
Know What the Model on the Other Side Actually Is
Before you trust anything to triage your alerts, it helps to understand what a large language model does when you hand it a prompt, because the behaviour is stranger than the marketing suggests. A recent engineering breakdown of how commercial chatbots work laid out a few properties that every security architect should sit with.
The model is stateless. It keeps nothing between requests. Every "conversation" you see on screen is rebuilt and resent in full on each turn, which means the context you feed it is the only thing it knows. It is also probabilistic in a way that surprises people: send the exact same prompt to a large model a thousand times, with randomness switched off, and you can still get dozens of distinct completions, because the maths is sensitive to how requests are batched together on shared hardware. And accuracy degrades as the input grows. A longer prompt does not throw an error. It quietly gets less precise, token by token.
Sit with those three facts for a moment. A detection assistant that is stateless will not remember the attacker campaign it flagged yesterday unless your pipeline explicitly feeds that history back in. One that is probabilistic will not give you a reproducible verdict on the same alert every time, which is a problem the day an auditor or an incident review asks why a specific event was closed. And one whose accuracy falls off with context length will get worse, not better, exactly when you dump a noisy 40,000-line log into it hoping for a miracle. None of this makes the technology useless. It makes it a component with a datasheet, and components with datasheets have to be engineered around, not believed in.
Where AI Genuinely Earns Its Place in Detection
Strip away the hype and there is a solid core of work where these models pull real weight. In our experience the wins cluster in a few specific places.
Cutting the alert pile down to what a human should see
The oldest problem in any security operations centre is volume. A mid-sized SIEM deployment throws off tens of thousands of events a day, and the vast majority are duplicates, benign anomalies, or known-good behaviour that a tuned rule should have suppressed months ago. This is where model-driven triage does honest work: clustering near-identical alerts, scoring them against historical patterns, and mapping observed behaviour to MITRE ATT&CK techniques so an analyst opens a case that already reads like the start of an investigation rather than a raw log line. The point is not that the model decides. The point is that it hands your Tier 1 analyst a shorter, better-ordered queue.
Reading traffic you cannot decrypt
The IDC analysis flagged encrypted traffic detection as a core competency separating the serious vendors from the rest, and that reflects what we see in the field. A growing share of malicious activity now hides inside TLS, and full decryption is often off the table for privacy, performance, or regulatory reasons. Models trained on traffic metadata, flow features, and TLS fingerprinting (JA3/JA4 and similar approaches) can flag suspicious sessions without ever seeing the plaintext. The same report noted the rising demand for east-west traffic inspection inside cloud-native environments, where the old perimeter model tells you nothing about a workload quietly talking to another workload it has no business reaching.
Enrichment and the boring parts of an investigation
A large fraction of investigation time goes to gathering context: pulling the asset owner, the recent authentication history, the threat-intelligence reputation of an IP, the change tickets around a host. This is assembly work, and a well-instrumented assistant does it in seconds, then summarises it in plain language. That same natural-language layer lets a junior analyst ask "show me every host that talked to this domain in the last 24 hours" without writing the query by hand. It lowers the skill floor for routine questions, which matters enormously when good analysts are scarce and expensive.
Where It Still Falls Short
The failure modes are as important as the wins, and vendors rarely lead with them. A model that scores confidence will sometimes be confidently wrong, presenting a hallucinated explanation of an alert with the same fluent tone it uses when it is right. Attackers adapt: adversarial inputs crafted to slip past a detection model are an active field, and a determined intruder will probe your automation until they find the shape of activity it ignores. Over-automation carries its own danger. The moment a SOAR playbook auto-isolates a host or disables an account on a model's say-so, a false positive stops being an annoyance and becomes an outage, or a self-inflicted denial of service on your own business.
The governing frameworks already account for this. NIST CSF 2.0 splits the work into Detect and Respond for a reason. Detection can tolerate a machine's probabilistic guess because a human still reads the case. Response, especially response that changes the state of a production system, needs a level of certainty and accountability that a stateless, probabilistic component cannot provide on its own. Keep that line bright.
Traditional SOC vs. AI-Augmented SOC
The honest comparison is not "old and broken" against "new and smart." It is a shift in where human effort goes and where new risk appears.
DimensionTraditional rule-based SOCAI-augmented SOC
Alert triage
Manual, analyst reads each queue item
Clustered and pre-scored; analyst reviews a shorter, ranked list
Unknown threats
Weak; depends on signatures and written rules
Stronger; behavioural models flag deviations without a prior signature
Encrypted traffic
Blind without decryption
Metadata and fingerprint analysis flag risk without plaintext
Analyst skill floor
High; query languages and deep tool knowledge required
Lower for routine questions via natural-language investigation
Reproducibility
Deterministic; same rule, same result
Probabilistic; verdicts can vary, so decisions need logging
New attack surface
The tooling itself
The tooling plus the model: prompt injection, data leakage, poisoning
Failure mode
Missed detection from a stale rule
Confident wrong answer or over-eager automated response
The AI You Deploy Becomes Part of Your Attack Surface
This is the half of the conversation the excitement tends to skip. The industry has started to catch up. A recent Cyber Magazine briefing on securing AI showed the pattern clearly: Palo Alto Networks talking about securing AI data centres by design, Deutsche Telekom putting AI at the centre of a group security strategy, vendor after vendor treating the AI layer as something that must itself be defended. When you add a model to your detection stack, you have added a new system that ingests untrusted input, holds access to sensitive telemetry, and increasingly can take actions through connected tools.
The concrete risks are now well catalogued. Prompt injection, where hostile content in a log line or an email the model is asked to analyse smuggles in instructions, sits at the top of the OWASP Top 10 for LLM Applications for good reason. Sensitive data leakage happens when telemetry fed into a model ends up in a place, or a provider, it was never cleared for. Model and data poisoning targets the training or tuning pipeline. Excessive agency, granting a model or an agent more tool access than the task requires, turns a small compromise into a large one. We have watched a Microsoft Teams business email compromise start from nothing more than a convincing message; an autonomous agent wired into that same environment, with permission to act, raises the stakes considerably.
The controls are not exotic. Treat the model as an untrusted-input processor: validate and constrain what goes in and what it is allowed to do. Scope its access with the same least-privilege discipline you would apply to any service account. Log every prompt and every action for the audit trail you will eventually need. Frameworks exist to structure this work: the NIST AI Risk Management Framework, ISO/IEC 42001 for AI management systems, and the AI-specific guidance now layering on top of ISO/IEC 27001 and the CIS Controls. Defense-in-depth did not stop applying because the new component is clever.
Where AI Fits in the Detection-and-Response Pipeline
The diagram below shows how we position these models in a working pipeline. The model augments the middle of the flow, where volume is highest and human time is most wasted. The consequential decisions, the ones that change production, stay with a person, and the model layer itself sits inside a governance boundary rather than outside it.
A Practical Adoption Checklist
If you are weighing an AI-driven detection capability, or trying to get value from one you have already bought, this is the sequence we walk clients through.
- Fix your telemetry first. A model cannot detect what your logging never captured. Endpoint, network, cloud control-plane and identity signals need to be flowing and normalised before any model adds value.
- Define the human-in-the-loop line explicitly. Decide, in writing, which actions a model may recommend and which it may never take without a person. Tie automated response to confidence thresholds and reversibility.
- Demand reproducibility where it counts. For any verdict that closes a case or triggers a response, log the input, the model's output, and the reasoning, so the decision survives an audit or an incident review.
- Threat-model the model. Run it through the OWASP LLM Top 10. Assume prompt injection from any untrusted input the model touches, and constrain its tool access accordingly.
- Measure the outcome that matters. Track mean time to detect and mean time to respond before and after, plus the analyst hours reclaimed. If those numbers do not move, the badge on the box was decoration.
- Keep the framework mapping current. Map the capability to NIST CSF 2.0 functions and to your compliance obligations (ISO 27001, PCI-DSS, and sector rules) so the tool supports your audit posture instead of complicating it.
How Aydahwa Enterprise Can Help
We build and assess security operations for organisations that cannot afford a wrong bet, in banking, telecom and critical national infrastructure across the UAE and the wider GCC. Our work is grounded in the standards that matter to regulated businesses: ISO/IEC 27001, PCI-DSS, the NIST Cybersecurity Framework and CIS Benchmarks, backed by hands-on architecture experience and Microsoft Cybersecurity Architect Expert certification.
If you are evaluating an AI-driven detection and response capability, we can pressure-test the vendor claims against your actual environment, design the human-in-the-loop and governance controls around it, and make sure the model layer is secured rather than left as an open flank. Start with our free cyber security self-assessment or the cybersecurity readiness checklist to see where you stand today. Explore our cybersecurity services and cloud security and migration practice, or reach out through our contact page to talk through your detection strategy with someone who has sat in the operator's chair.
