Author: Rob Demain, Founder & CEO
The security industry cycles through terminology fast. ‘Cloud-native’ gave way to ‘zero-trust’, which gave way to ‘AI-powered’. Each wave brings innovation, and each wave brings a much larger volume of vendors who have applied the new language to products that have not materially changed. After more than 25 years in enterprise security, I have watched this pattern repeat with enough consistency that the cycle itself is a useful filter.
The challenge for security and commercial leaders right now is not finding AI-labelled tooling. The market is saturated with it. The challenge is distinguishing platforms that have built genuine AI capability into their detection and response architecture from those where AI is a layer of marketing on top of a legacy product.
This article gives you a framework for making that distinction. It will not tell you which vendor to choose. It will give you the questions and criteria that separate real capability from noise, so you can make that judgement yourself.
If this is a topic you’re struggling with, sign up to a free 1-2-1 AI strategy session with Rob Demain: https://e2e-assure.com/ai-strategy
Genuine AI capability versus AI-washed marketing
Not all AI security tooling is the same, and the differences are not subtle once you know what to look for. Most of what is currently marketed as AI-powered falls into one of three categories.
AI-native. Detection and response logic is built around AI from the ground up. The AI is not assisting a human-first workflow: it is the first line of analysis. Alert correlation, threat prioritisation, and investigation happen in the AI layer before any human sees an alert. This is a fundamentally different architecture to what existed before large language models and agentic AI became operationally viable.
AI-augmented. Existing workflows are enhanced by AI-assisted tools. Analysts still perform first-line triage; AI helps them work more efficiently. Alert summarisation, draft incident reports, and suggested search queries are typical features. This is useful. It reduces some workload. But it does not change the detection model or the speed at which threats are identified and contained.
AI-branded. Existing products with updated marketing copy. The detection engine is the same rule-based architecture it was before; the product page now includes the word AI. This category is larger than vendors would prefer to acknowledge.
Ask the vendor to demonstrate, in a live environment, where AI sits in the detection pipeline. Walk through a real alert from first signal to analyst notification. A vendor with genuine AI-native capability will show you that walkthrough without hesitation. One whose AI is primarily a UI feature will pivot to slides.
Five questions every buyer should ask
These questions are designed to produce answers that reveal the architecture, not the pitch. Ask them of every vendor you evaluate.
- Where is my data processed, and under whose jurisdiction? This is not a storage question. You need to know where AI inference runs: where your security telemetry is being processed by the model that makes detection decisions. Most vendors use hyperscaler infrastructure in the US or EU. For UK organisations in regulated sectors, that is an architectural risk that needs to be addressed explicitly, not assumed away. Ask for a data flow diagram. A data residency statement is not sufficient.
- How many AI agents are running on my alerts, and what does each one do? If the answer is vague, the AI layer is probably thin. A platform with genuine agentic capability can tell you precisely how many specialist agents are running in parallel on each analysis, what each agent assesses, and how their outputs are synthesised into a prioritised conclusion. If the answer is ‘our AI analyses your alerts,’ press for specifics.
- What human oversight exists on AI outputs before they reach my team? Any AI system in a security context should have a validation layer between AI output and human action. Ask specifically what that layer looks like. Is it a separate checking agent? Is it analyst review? What is the process when the AI and the validator disagree? A platform that cannot answer this question clearly has not designed the governance model properly.
- Does the platform integrate with my existing stack, or does it require rip-and-replace? Most organisations have already committed budget to Microsoft Sentinel, Defender, CrowdStrike, SentinelOne, Splunk, Okta, ServiceNow, or a combination. A genuine AI SOC platform extends those investments. It does not require you to abandon them to capture value. Ask for a specific list of pre-built integrations and ask what happens to your existing data in each. If the answer involves significant re-ingestion costs or parallel running periods that double your spend, factor that into the total cost of ownership.
- What does the commercial model look like at three times my current data volume? Per-alert and per-seat pricing models can look attractive at current volumes and become painful as environments grow. Ask for a cost projection at significantly higher data volumes before you commit. Ingestion-based pricing in particular has produced budget surprises for organisations that grew faster than their security budget forecasts assumed. Fixed-cost or outcome-based models give finance teams more predictability.
Integration flexibility – protecting existing investments
Security technology procurement decisions rarely happen in isolation. Most organisations evaluating AI security tooling have already spent on their stack. That investment represents both sunk cost and ongoing licensing. An AI platform that requires organisations to retire their existing tools to function is asking for a much larger commitment than its licence fee implies.
The right question is not ‘does this replace what I have?’ but ‘does this work with what I have, and does it make it more effective?’ A well-designed AI SOC platform connects to your existing SIEM, EDR, cloud security tools, and ITSM without requiring parallel running or data migration as a precondition for value.
Vendor lock-in is a specific risk to manage. Platforms that ingest your data into proprietary formats, or that build detection logic in ways that cannot be exported, reduce your future flexibility. Ask how you would exit the relationship if you needed to. The answer will tell you something useful about how the vendor thinks about the buyer’s interests.
A technology-agnostic architecture, with a broad range of pre-built integrations maintained and updated as the underlying tools evolve, is the standard you should be evaluating against. The number of integrations matters less than their depth and maintenance posture. An integration built two years ago for a tool that has since updated its API is not an integration: it is a liability.
Cost transparency – what AI cyber security tooling actually costs to run
SIEM ingestion costs are one of the most consistent sources of budget frustration in enterprise security. The model is simple in principle and expensive in practice: you pay for the volume of data you send to the platform. As your environment grows, as you add cloud workloads, as OT systems come into scope, the volume grows. The bill grows with it.
AI security tooling has introduced a new version of this problem. Platforms that process large volumes of telemetry through cloud-hosted AI models have their own scaling cost dynamics. If the platform does not manage what it sends to the AI layer, the cost scales with the noise, not just the signal.
The alternative is smart log routing: local collectors that assess events at source and send only what requires deeper analysis to the AI layer. This is not a new idea, but it requires engineering discipline to implement well. Organisations that have moved to this model have reduced ingestion overhead by up to 80% compared with unmanaged SIEM setups, without reducing detection coverage. That figure represents a material difference in the total cost of ownership over a three-year contract.
When evaluating vendors, ask for a worked cost model that shows licence fees, ingestion costs, and any AI processing charges separately. Ask what happens to that model as your data volume doubles. Ask specifically whether smart log routing or local filtering is included or is an add-on. The answers will tell you whether the vendor has designed the commercial model around the customer’s interests or around their own revenue scaling.
Data sovereignty – where does your data go?
For UK organisations in regulated sectors, data sovereignty is not a preference: it is a requirement. The practical question is not whether your data is stored in the UK, but where the AI that processes it runs.
Security telemetry contains information about your infrastructure, your vulnerabilities, your users’ behaviour, and your incident history. When an AI model processes that telemetry to make detection decisions, the processing itself has sovereignty implications. A platform that stores logs in a UK data centre but runs AI inference on US hyperscaler infrastructure has not solved the sovereignty problem. It has moved it.
Ask vendors three specific questions. Where is the large language model hosted? Where is personally identifiable information processed and at what point is it sanitised? What happens to log data after it has been analysed? The answers should be specific, not general. ‘We use a major cloud provider with UK regions’ is not a sufficient answer if the AI workload runs in a different region or under a different jurisdictional arrangement.
For organisations in critical national infrastructure, central government, or the defence supply chain, the bar is higher. UK-sovereign operations means UK-hosted AI infrastructure, UK-jurisdiction data governance, and SC-cleared personnel reviewing outputs. That combination is not available from every vendor in the market. It is worth establishing which vendors can genuinely meet it before investing time in evaluation.
The difference between a point tool and an AI SOC platform
Understanding which problem you are trying to solve before you evaluate any product will save considerable time and money.
A point tool addresses a specific gap. An AI-powered endpoint detection product, an AI-assisted SOAR for automating playbooks, or an AI model that enhances threat intelligence enrichment are all point tools. They improve a specific part of the security workflow. They do not connect those parts into a coherent operational model.
An AI SOC platform integrates detection, triage, investigation, and response in a single workflow, with AI running across the full chain. The analyst experience changes not just in one workflow step but across the whole engagement model. Alerts are correlated before a human sees them. Investigations are structured by AI before analysts open them. Response actions are prepared for analyst approval rather than built from scratch.
Neither approach is universally correct. An organisation with a strong internal SOC and a specific capability gap may be best served by a point tool. An organisation that is building or rebuilding its security operations model, or that is looking to extend coverage across IT and OT without adding proportionate headcount, is more likely to benefit from a platform approach.
The mistake to avoid is buying a point tool in the expectation that it will deliver platform-level outcomes. The integration work required to connect multiple point tools into a coherent operating model is significant, often underestimated, and typically requires ongoing engineering resource to maintain. That cost should be in the total cost of ownership calculation before the first vendor conversation.
If you are at the stage of evaluating AI SOC platforms, Cumulo is built to answer each of the questions in this article. Book a demo at e2e-assure.com/cumulo to see how the architecture, commercial model, and UK sovereign design address them in practice.
Further reading
Threat Detection and Response Services e2e-assure.com/services/threat-detection-response
Cyber Security Assessment Services e2e-assure.com/services/cyber-assessment-services