The ‘AI in Security’ Vendor Pitch Is Not the Same as AI in Security

Every security vendor now says they use AI. The phrase, in the security context, is even more inflated than the broader “we use AI” problem, because the security buyer is, in most cases, less technical than the security vendor’s engineers assume. The result is a generation of security products that have AI features which are, in many cases, marketing positions rather than operational capabilities. The products that actually use AI in security, in ways that materially change detection, response, or prevention, are a small subset. The products that say they use AI are most of them.

The gap becomes the source of the buyer’s confusion, and the source of the security industry’s marketing problem. The buyer is paying for AI. The buyer is getting, in many cases, a rules engine with the word AI in the documentation. The buyer does not have the technical depth, in most cases, to tell the difference. The vendor knows this. The vendor uses it. The result is a market full of products that are positioned as AI and that are, in operational terms, the same as the products that were on the market 10 years ago.

The companies that have figured this out are buying the small number of products that actually use AI in security, in ways that change the outcomes. The companies that have not figured this out are paying the marketing price, getting the marketing product, and not getting the AI security they were sold.

The “AI in security” claim

Every security vendor, in 2026, says they use AI. The claim is on the website. The claim is in the sales deck. The claim is in the RFP response. The claim is, in most cases, true. The vendor does, in fact, use AI somewhere in the product. The question is not whether the vendor uses AI. The question is what the AI does, what data it sees, what the failure modes are, and whether the AI is doing the work the vendor says it is doing.

The question is, in most cases, hard to answer. The vendor’s sales engineers do not, in most cases, have the technical depth to explain the AI in operational terms. The vendor’s documentation describes the AI in marketing terms. The vendor’s product demo shows the AI in the best light. The buyer, in most cases, has to take the vendor’s word for it, or has to do the technical evaluation themselves, which most buyers do not have the time or the expertise to do.

The four flavours, applied to security

The four flavours of “we use AI” from the broader “we use AI” piece apply to security with some specific characteristics. Flavour one, genuine AI, in security, becomes the model doing real work that materially changes the product. CrowdStrike’s Charlotte AI, which triages alerts using a model trained on the CrowdStrike telemetry, is a real example. SentinelOne’s Purple AI, which does similar triage using a model trained on SentinelOne’s data, is another. Microsoft’s Security Copilot, which integrates with the Defender suite and uses GPT-4 to assist analysts, is a third. The products in this category are real. The products change the operations. The products are, however, a small subset.

Flavour two, AI augmented, in security, amounts to the rules based core with AI features bolted on. Most SIEMs, most EDRs, most IDPs, most CSPMs, are in this category. The product worked before the AI. The product works better with the AI. The product would still work without the AI, just less well. The AI is doing some work. The AI is not doing all the work. The marketing suggests the AI is doing all the work. The product is, in practice, the same product with an AI feature.

Flavour three, AI in marketing only, in security, counts as the rules engine with the word AI in the documentation. The product is a rules engine, a database, a workflow tool, with no AI in the runtime behaviour. The product’s marketing mentions AI. The mention is, in many cases, about a future feature, a beta, a roadmap item. The product is sold as AI enabled. The product is, in practice, not.

Flavour four, AI in name only and the product is worse, in security, stands as the rules engine with bolted on AI features that the underlying product does not need. The AI features are slow. The AI features are expensive. The AI features are often wrong. The product would be better without the AI, but the marketing required the AI, so the AI was added. The phrase “we use AI” is accurate. The phrase should be a warning.

The detection problem

The detection problem runs as the single most important problem in security operations. The detection problem is, in most enterprises, an alert volume problem. The SOC has too many alerts. The SOC cannot triage them all. The SOC, as a result, misses the alerts that matter. The AI in detection, when it works, reduces the alert volume by clustering related alerts, by suppressing low confidence alerts, by prioritising high confidence alerts. The AI in detection, when it does not work, produces more alerts, with more noise, with the same volume problem in a different form.

The AI in detection that works stands as the AI that has been trained on the vendor’s telemetry, with the vendor’s labels, integrated with the vendor’s detection stack. The AI in detection that does not work becomes the AI that has been bolted on as a post processor, without access to the underlying signals, with a generic model trained on generic data. The difference is, in the buyer’s experience, the difference between a SOC that can keep up and a SOC that cannot.

The alert triage problem

The alert triage problem runs as the second most important problem in security operations. The alert triage problem is, in most enterprises, an analyst time problem. The analyst has too many alerts to triage. The analyst, as a result, triages the easy alerts and skips the hard ones. The AI in alert triage, when it works, summarises the alert, suggests the response, provides the context. The AI in alert triage, when it does not work, produces generic summaries that do not help, suggestions that are not actionable, context that is not relevant.

The AI in alert triage that works sits as the AI that has been integrated with the SIEM, the EDR, the IDP, the ticketing system, with the analyst’s workflow. The AI in alert triage that does not work serves as the AI that has been bolted on as a chat interface, with a generic model, with no integration. The difference is, in the analyst’s experience, the difference between a tool that saves time and a tool that adds time.

The response problem

The response problem sits as the third most important problem in security operations. The response problem is, in most enterprises, a speed problem. The attacker moves fast. The defender has to move faster. The AI in response, when it works, automates the response, contains the attack, preserves the evidence. The AI in response, when it does not work, automates the wrong things, contains the wrong attack, destroys the evidence.

The AI in response that works becomes the AI that has been trained on the specific environment, with the specific response playbooks, integrated with the specific security stack. The AI in response that does not work becomes the AI that has been bolted on as a generic automation tool, with generic playbooks, with no integration. The difference is, in the incident’s outcome, the difference between a contained breach and an uncontained one.

What useful AI in security actually looks like

Useful AI in security, in 2026, has four properties. The first is integration. The AI is integrated with the security stack, the data sources, the workflows. The AI is not a separate product. The AI is a feature of the existing product. The AI sees the data, makes the inference, presents the result in the analyst’s existing workflow.

The second is context. The AI has been trained on the relevant data, with the relevant labels, for the relevant use case. The AI is not a generic model. The AI is a domain specific model, or a generic model with domain specific fine tuning. The context is what makes the AI useful.

The third sits as the human in the loop. The AI suggests. The human approves. The AI is not autonomous. The human is, in all significant decisions, the decision maker. The AI becomes the input to the decision. The human amounts to the decision.

The fourth sits as the failure mode. The AI fails gracefully. The AI does not, on failure, block the analyst’s workflow. The AI does not, on failure, produce a wrong response. The AI fails in a way that the system can handle. The failure mode stands as the test of whether the AI is real or whether the AI is marketing.

How to tell the real from the marketing

1. Ask for the model card. The model card amounts to the document that describes what the model was trained on, what the model’s performance is, what the model’s failure modes are. The vendor that has the model card has a real AI. The vendor that does not have the model card has a marketing position.
2. Ask for the integration architecture. The integration architecture describes how the AI sees the data, how the AI presents the result, how the AI fits into the workflow. The vendor that has the architecture has a real AI. The vendor that does not have the architecture has a marketing position.
3. Ask for a demo on your data. The vendor that can demo on your data, with your context, with your labels, is confident the AI will work in your environment. The vendor that cannot demo on your data is not confident. Take the non confidence as a signal.
4. Ask for a reference customer in your industry. The reference customer sits as the proof. The reference customer has the same use case, the same data, the same workflow. The reference customer’s experience serves as the prediction of your experience.
5. Ask for the false positive rate. The false positive rate runs as the single most important metric. The vendor that knows the false positive rate has measured it. The vendor that does not know the false positive rate has not measured it. The AI that has not been measured is not an AI, it is a marketing position.

What the buyer should do

The buyer who is buying security AI should treat the purchase the same way they would treat any other high stakes enterprise software purchase. Define the use case. Define the success criteria. Define the failure mode. Run a proof of concept on the buyer’s data, in the buyer’s environment, with the buyer’s workflow. Measure the outcome. Compare the outcome to the success criteria. Compare the AI to the non AI baseline. Buy the AI that materially outperforms the baseline, on the buyer’s data, in the buyer’s workflow.

The buyer who does this will end up buying a small number of products that actually use AI in security. The buyer who does not do this will end up buying a large number of products that say they use AI, that perform, in the buyer’s environment, the same as the products that did not. The buyer who does the work amounts to the buyer who gets the value.

The bottom line

Every security vendor says they use AI. The phrase is, in most cases, marketing. The products that actually use AI in security, in ways that change the outcomes, are a small subset. The buyer who treats the purchase as a marketing decision will get the marketing product. The buyer who treats the purchase as a technical evaluation, with the right questions and the right measurements, will get the real product.

The fix sits as the work. The fix stands as the questions. The fix counts as the proof of concept on the buyer’s data. The fix runs as the measurement. The fix is not the marketing. The fix stands as the buyer’s discipline. The discipline stands as the work. The work is yours.