The page the vendor deck skips. Read this one even if you skipped the others.
A colleague runs IT for a mid-size professional services firm. About thirty servers, a hundred and fifty workstations, a small team. Two years ago he deployed a commercial AI-assisted security platform — not a toy, a real product from a name-brand vendor. It had behavioral analytics, anomaly detection, automated response. He went through the implementation, tuned it for months, got the false positive rate down to something manageable. He was proud of it. It was genuinely better than what he had before.
Eight months later his firm got hit with ransomware. Full encryption event across most of the file shares. Recovery took eleven days. The AI security platform had been running the entire time. It had generated alerts. Some of them were even about the right things. They were in a queue with four hundred other alerts that week. Nobody had gotten to them.
The platform did not fail. It detected anomalies. The detection did not prevent the breach because detection and response are two different problems, and the shop only had resources to solve one of them.
This page is about the gap between what AI security tools promise and what they actually deliver — not to discourage you from using them, but so you deploy them with clear eyes and realistic expectations.
Every honest conversation about AI security has to start here. The attacker and the defender are not playing the same game.
Alert fatigue is the most common way AI security deployments fail, and it is almost never mentioned in vendor documentation. Here is how it happens:
| Stage | What happens |
|---|---|
| Week 1–2 | Tool deployed. Generates alerts. Team reviews them carefully. Learns the environment. |
| Week 3–4 | Alert volume is higher than expected. Many are false positives. Team starts triaging faster. |
| Month 2 | Tuning reduces some noise. Other alerts keep firing. Team develops informal rules about which alert types to skip. |
| Month 3–6 | Alert review becomes a checkbox activity. The queue is always full. Real alerts are in there. Nobody has time to find them. |
| Month 6+ | The tool is running. Reports show it is generating alerts. Management assumes coverage exists. The actual security value has collapsed. |
This is not a hypothetical. It is the modal outcome for SIEM deployments that are not staffed appropriately. The tool works. The process breaks.
Before deploying any of the tools from Page 3, answer this question honestly: how many alerts per day can your team actually investigate? Not review. Not triage. Actually investigate — look at the context, make a judgment, take action or document the reason for no action.
For a sysadmin with other responsibilities, that number is probably five to fifteen per day. Design your alert thresholds around that number. If your tool generates two hundred alerts a day and your capacity is ten, you do not have security monitoring — you have security theater with extra steps.
Beyond alert fatigue, AI security tools have specific technical blind spots that are worth understanding before you trust them with your environment:
The tool does not know that your lead developer always works from a coffee shop on Thursdays. It does not know that the database server makes a weekly outbound connection to your backup provider. It does not know that last Tuesday's spike in failed logins was you testing a script, not an attacker. Every one of those becomes an alert. You carry the institutional knowledge to dismiss them in seconds. A junior analyst or an automated response system does not.
This context cannot be fully encoded into any tool. It lives in experienced people who know the environment. When those people leave, the context goes with them unless it has been documented somewhere.
Behavioral baselines flag statistical outliers. An attacker who understands this moves slowly enough to stay within the statistical norm. One lateral move per week. Data staged at a rate indistinguishable from normal user activity. Reconnaissance that mimics normal admin behavior. Given enough time and patience, a skilled attacker can become part of your baseline.
The dwell time timeline from Page 2 showed this problem. Tools help. They do not solve it completely against a patient adversary.
A malicious insider already has legitimate access, knows what normal behavior looks like for their account, and can time their actions to blend with their own baseline. Behavioral analytics catches the careless insider. It struggles with the deliberate one. The most damaging insider incidents in history were not caught by anomaly detection — they were caught by human relationships, tip lines, and old-fashioned investigation.
ML models trained on historical attack data recognize historical attack patterns. A genuinely novel technique — a new living-off-the-land method, an exploit for a vulnerability nobody has weaponized before, a social engineering approach that does not leave log traces — has no signature and no behavioral precedent. The model has never seen it. It will not flag it.
This is not a criticism of the tools. It is a property of any detection system that learns from the past. The frontier of attack technique is always ahead of the frontier of detection.
AI log analysis is bounded by what gets logged. Physical access does not generate a syslog entry. A compromised hardware supply chain does not show up in auth.log. Social engineering that results in a legitimate password reset goes through your normal helpdesk process. Side-channel attacks on shared infrastructure leave no application-layer trace. Your detection capability ends at the boundary of your log coverage.
| Attack vector | Log visibility | AI detection potential |
|---|---|---|
| SSH brute force | High — auth.log captures every attempt | High — well-understood pattern |
| Credential stuffing with valid credentials | Medium — successful logins look normal | Medium — behavioral anomaly on login pattern |
| Slow lateral movement with valid creds | Medium — each step logged individually | Low-Medium — requires sequence correlation over time |
| Insider threat, deliberate | Medium — actions logged, context missing | Low — stays within behavioral baseline by design |
| Physical access to hardware | None | None |
| Social engineering / helpdesk manipulation | Low — may leave ticket trail only | Very low |
| Supply chain compromise | Low — activity looks like legitimate software behavior | Low — no behavioral precedent |
| Zero-day exploit, no prior signature | Varies — depends on what the exploit does | Low — no historical pattern to match |
AI security is a market. Vendors compete on claimed detection rates, coverage breadth, and AI sophistication. Some of that competition produces genuinely good technology. Some of it produces marketing claims that do not survive contact with a real environment.
Things to push back on when evaluating any AI security product:
| Vendor claim | The question to ask |
|---|---|
| "Detects unknown threats with AI" | What is your false positive rate in a production environment? Can I see data from a shop similar to mine? |
| "Reduces alert fatigue" | How many alerts per day does a typical deployment generate? What is the average time-to-investigate per alert? |
| "Behavioral baseline established in days" | What is the recommended minimum baseline period before anomaly scores are reliable? What happens during that window? |
| "Autonomous response capabilities" | What are the failure modes of automated response? What happens when it blocks a legitimate admin action at 2 AM? |
| "Covers your entire environment" | What does not generate telemetry? What attack surfaces are outside the scope of this product? |
| Detection rate percentages | What dataset was that measured against? Was it a curated test set or a live production environment? Who conducted the test? |
None of this means AI security tools are not worth deploying. They are. The shops that use them well get genuine value. Here is what that looks like in practice — the things that actually move the needle:
Given everything on this page, here is what a realistic AI-assisted security posture looks like for a small-to-medium Linux shop:
| Layer | What it does | Realistic expectation |
|---|---|---|
| Patch management | Eliminates known exploitable vulnerabilities | Removes the largest attack surface. Not optional. Do this first. |
| Log centralization | Gets logs off hosts, retained, searchable | Foundational. Enables everything else. Wazuh or ELK. |
| File integrity monitoring | Alerts on changes to critical files | High signal, low noise. Catches persistence mechanisms reliably. |
| Rule-based detection | Catches known-bad patterns | Good coverage of commodity attacks. Tuning required. |
| Behavioral / AI detection | Flags anomalies against baseline | Useful triage layer. Requires human review. Not autonomous. |
| AI log analysis (ad hoc) | Faster investigation when something happens | High value. Use the pipelines from Page 1 starting today. |
| Incident response plan | Defines what to do when tools fail | Detection without response is just a better view of the fire. |
In most ransomware incidents at shops with AI security tools, the tools worked as designed. Anomalies were detected. Alerts were generated. The gap was not in the technology — it was in the staffing model, the alert review process, and the response plan.
Deploying a better detection tool without addressing alert fatigue, staffing, and response planning is rearranging deck chairs. The tool becomes the answer to "did you have security monitoring?" at the insurance claim, not actual protection.
The shops that come out of incidents well are the ones who know their environment deeply, review alerts consistently even when the queue is boring, and have practiced what to do when something fires. The AI tool is the instrument. The team is the musician. You need both.
Four pages. Here is what you should take away from all of them: