Last year, a security team I spoke with automated log filtering with an AI agent. It worked beautifully, volume dropped 40%, costs came down, nobody complained. Six months later, during an incident investigation, they discovered the agent had been quietly deprioritizing DNS resolution logs from a subset of endpoints. The logs weren't gone. They'd been sampled down to 5%. The forensic trail had holes they couldn't fill.
Nobody made a bad decision. That's the problem. Nobody made the decision at all.
There's a pitch making the rounds at every security conference right now: let AI handle the messy data work, remove humans from the loop, and increase efficiency. It sounds obvious until you remember what "the messy data work" actually is in security operations.
This is the layer where raw telemetry gets parsed, mapped, filtered, enriched, routed, stored, and exposed to every downstream tool and team. When something goes wrong here, detections miss. Investigations slow. Sensitive data leaks. The blast radius is the entire security program.
The goal is not to avoid AI. It's to be precise about where AI recommends and where a human still approves.
Here are five decisions where that line matters most.
1. Dropping or filtering security-relevant data
AI is genuinely good at finding noise. Repetitive events, redundant fields, obvious reduction candidates. A model can surface these in minutes instead of the weeks it takes a human to audit manually. Use it for that.
But don't let it decide what disappears from your pipeline.
A "low-value" event is only unimportant until it becomes the missing clue. Security teams already live with the tradeoff between volume, fidelity, and cost. If AI makes production drop decisions unilaterally, it creates blind spots you won't see until after an incident. When "why don't we have those logs?" is a question nobody can answer.
The line: AI identifies reduction opportunities. A human reviews before filters hit production. Rollback stays simple and fast. Every proposed drop gets tested against known detection logic and past investigations.
2. Schema mapping that changes the meaning of data
This is where AI delivers some of its clearest value. Mapping raw telemetry to OCSF or another standard schema is tedious, error-prone, and exactly the kind of pattern-matching work models excel at. Teams that use AI here onboard new sources in hours instead of days.
The risk isn't speed. It's false confidence.
An authentication event mapped incorrectly might never trigger the brute-force detection that analysts rely on. A field mapping isn't a formatting choice. It determines how detections fire, how analysts pivot, how dashboards aggregate, and how downstream tools interpret events. A bad mapping can look clean on the surface. All fields populated. No errors. Schema validates. Yet the meaning is wrong underneath. “src_ip” mapped to the proxy address instead of the origin. “severity” translated with the wrong vendor-specific scale. Quiet degradation across the entire stack.
The line: AI proposes mappings. Humans validate whether the translation is actually correct. Especially edge cases, vendor-specific fields, and fields that feed detection logic. Schema approval is a control point, not a rubber stamp.
3. Masking, redaction, and retention decisions
AI can find sensitive data you didn't know was there. Social security numbers in freeform log fields. API keys in debug output. PII in places your DLP rules never thought to look. That discovery capability is legitimately valuable.
But discovery is not policy.
Mask too little and you have regulatory exposure. Mask too much and you strip the context analysts need for investigations. Retain too long and governance suffers. Retain too little and you lose evidence. These aren't pattern-matching problems. They're business decisions with legal, privacy, compliance, and security stakeholders who all have standing to weigh in.
An AI model doesn't know your data processing agreements. It doesn't know which customer contracts have specific retention clauses. It doesn't know that your legal team made an exception for a particular data class last quarter. Humans own policy. AI enforces it.
The line: AI identifies likely sensitive fields and suggests actions. Policy definition stays with human owners. Masking outcomes get reviewed for both compliance and forensic usefulness. Changes to retention and redaction rules get audited like any other high-risk control change.
4. Production pipeline or routing changes
This one should be obvious but apparently isn't, given how many vendors pitch "just tell the AI what you want and it'll configure your pipeline."
We don't let unreviewed code push to production. We don't let untested firewall rules roll out at scale. We don't let detection logic change without peer review. Data pipelines carry the same risk and deserve the same discipline.
AI should absolutely draft configs, write expressions, generate pipeline logic, and troubleshoot problems. It can cut authoring time dramatically. But "I can write it faster" is not the same as "it should go live without review."
A routing change that silently stops forwarding identity logs to your SIEM can leave detections healthy on paper while blind in practice.
Organizations should be able to reconstruct what the model recommended, what changed, who approved it, and when.
The line: AI drafts. Humans preview, test, and approve before deployment. Every production change gets logged, what changed, why, and who approved it. Rollback paths exist for every AI-assisted modification.
5. Incident severity and investigative conclusions
Here's where the stakes are highest and the temptation is strongest.
AI can summarize evidence, surface correlations, recommend queries, highlight anomalies, and compress hours of triage into minutes. Those are real, high-value capabilities. Use them aggressively.
What AI cannot do is understand that the "low severity" alert it's looking at hit a system that was part of an unannounced acquisition. Or that the "benign" PowerShell execution matches a pattern from a red team exercise that ended last week, or didn't. Or that the affected server is the one a departing employee had unauthorized access to last month, per a conversation that happened by the water cooler and never made it into a ticket.
Incident context lives in places models can't reach: architecture decisions, business exceptions, recent changes, compensating controls, institutional memory. A model that sounds certain while missing this context is more dangerous than one that admits uncertainty.
The line: AI accelerates triage and summarizes evidence. Severity assignment and final conclusions stay with analysts or incident leads. AI outputs are inputs to judgment, not replacements for it.
The real question
Nobody is debating whether AI belongs in security data operations. It does. It's already there.
The debate is where you draw the approval boundary. Teams that use AI for parsing, mapping, discovery, drafting, and acceleration will move faster. Teams that let AI quietly own filtering, meaning, policy, production, and investigative truth will eventually discover what they gave up, usually during the incident where they needed it most.
The question isn't whether AI can make these decisions. In many cases it can. The question is who owns the consequences when it's wrong.
