I want to avoid writing the guide that tells you AI is going to change everything and then gives you zero actionable information about what to actually do. There are already too many of those.
What I want instead is to give you the ground truth on where generative AI actually helps SOC analysts today — not in vendor demos, but in real investigations — and where it creates problems if you're not careful.
Fair warning: this is going to be different depending on your experience level, your tooling, and what you're actually trying to accomplish. I'll cover both junior and senior analyst use cases because the leverage points are genuinely different.
What Generative AI Is Actually Good At (In a SOC Context)
Splunk's research into AI use cases for security operations identified three high-value application areas that track closely with what practitioners are actually using in production. Let me break these down concretely.
1. Enabling Analyst Expertise — The Democratization Problem
Security operations has always had an expertise distribution problem. The difference in effectiveness between a junior analyst on day 30 and a senior analyst with 10 years of incident response experience is enormous. Institutional knowledge, pattern recognition developed over hundreds of investigations, the ability to see what matters in a sea of events — these compound dramatically over time.
Generative AI compresses that gap. Not closes it, but compresses it.
For junior analysts, the practical impact:
Log interpretation in plain language
Regular expressions and log formats are a significant barrier for junior analysts. Ask a junior analyst to interpret a 4688 Windows Security Event and they might pull up the documentation and spend 10 minutes cross-referencing fields. Ask an LLM to explain what a specific log entry means, with context about why it matters, and you get an instant mentor-style explanation.
The technique I've seen work well: paste the raw log into an AI assistant with the prompt "Explain what this log entry means, what it tells us about what happened, and what I should investigate next." The output won't replace experience, but it provides a scaffold that helps junior analysts ask better questions faster.
Investigation query suggestions
Junior analysts often know what they're looking for but not how to find it. "I want to see all PowerShell executions by this user in the last 24 hours" is a clear investigative need; writing the SPL, KQL, or Sigma rule to find it is a separate skill that takes time to develop.
AI assistants can draft those queries. The important caveat: always understand the logic of the query before running it, especially in environments where broad searches can generate expensive queries or overload your SIEM. "Here's the Splunk query the AI suggested — does this look right?" should become a standard junior analyst behavior before executing AI-generated queries in production.
Real-time contextual learning
This is underrated. When an AI explains why something is suspicious — "this combination of events matches the LOLBAS execution pattern commonly used in post-exploitation, specifically because..." — analysts learn from each investigation, not just from formal training. The AI becomes an always-available explainer running alongside the investigation, not just a query generator.
For senior analysts, different leverage points:
Senior analysts don't need help reading logs. What they need is leverage — the ability to cover more ground, surface non-obvious connections, and free up time from the investigative equivalent of busywork so they can focus on the work that actually requires their judgment.
Emerging tactics and IoC surfacing
AI systems trained on security-relevant data can synthesize threat intelligence at a pace that humans can't match. "Show me recent TTPs associated with this threat actor group" or "what are the known IoCs and behaviors for this malware family" used to require dedicated threat intelligence analysts or expensive platform subscriptions. AI assistants with good training data can surface this in seconds.
The quality of this varies enormously by model and recency of training data. For very recent threat intelligence (active campaigns in the last few weeks), AI may be outdated. For established threat actor profiles and mature malware families, it's often faster than manual research.
Dataset relationship highlighting
Senior analysts build mental models of relationships — between users, systems, behaviors, and events. Articulating those relationships for stakeholders or for documentation is often slower than the mental model formation. AI can help turn a complex investigation timeline into a clear narrative, highlight the relationships in a graph of connected entities, and suggest dataset relationships the analyst might not have explicitly modeled.
Automating tedious investigation steps
Every investigation has steps that are mechanical but time-consuming: enriching 50 IP addresses, checking hash reputation across multiple threat intel feeds, pulling user account history from Active Directory. These tasks don't require senior analyst judgment, but they do require senior analyst time if there's no automation in place. AI-assisted tooling can take these mechanical steps off the plate and bring back structured results.
2. Streamlining Investigations
Splunk's research is explicit about the magnitude of impact here: AI can reduce manual investigation time from hours to minutes for specific classes of incidents.
The mechanism is the investigation summary. Traditional investigation flow:
- Alert fires
- Analyst pulls context from SIEM
- Analyst checks EDR for endpoint details
- Analyst queries threat intelligence
- Analyst checks identity system for user context
- Analyst correlates findings mentally
- Analyst writes up summary and recommended actions
- Escalation decision or closure
Each context switch between tools adds latency. Each mental correlation step requires working memory. Each write-up is time spent documenting rather than investigating.
AI-native SOC platforms — and increasingly, AI features in established platforms — can collapse this flow. The investigation summary that used to be steps 2-8 can arrive as a pre-generated artifact when the alert triggers: here is the timeline, here are the affected assets, here is what we know about the threat actor, here is the recommended response.
What this actually requires to work:
The quality of AI-generated investigation summaries is entirely dependent on data quality and integration depth. An AI summary generated from full SIEM context, enriched with EDR telemetry, cross-referenced against threat intelligence, and correlated with identity data is genuinely useful. An AI summary generated from a single log event is not.
Building toward AI-assisted investigation means investing in data integration first. Your SIEM data quality, your EDR coverage, your threat intelligence feeds, your CMDB accuracy — all of these directly determine whether AI-generated summaries are actually useful or just confident-sounding noise.
3. Improving TDIR Workflows
Detection, triage, investigation, response. AI adds value across all four phases, but the leverage is unevenly distributed.
Detection: AI-powered detection engines are good at identifying statistical anomalies and correlating signals across large datasets. They're less good at understanding business context — why this anomaly is actually suspicious given this organization's specific environment. The best setups use AI for initial signal generation and human-crafted detection logic for the highest-confidence alerts.
Triage: This is where AI shows some of the most dramatic productivity gains. Alert triage — deciding what requires investigation vs. what can be closed as benign — is high-volume, pattern-matching work that AI handles well. Vendors like Dropzone AI reporting 10,000+ daily alerts handled aren't handling 10,000 complex investigations; they're handling the triage decision on 10,000 alerts, most of which are routine.
Investigation: Covered above. The summary generation and context correlation are high-value applications with real production results.
Response: This is where I'd urge the most caution. Automated response actions — isolating hosts, blocking domains, revoking credentials — carry significant blast radius if wrong. False positives in detection and triage are annoying. False positives in automated response can take down business systems or lock out legitimate users. The right architecture keeps humans in the loop for response actions while automating the evidence gathering and recommendation generation.
Prompt Engineering for Security Workflows
This isn't a nice-to-have skill. If you're using AI in security investigations, the quality of your prompts directly determines the quality of your outputs. Treat prompt construction as a technical skill.
Structure for investigation prompts:
Context: [Provide the relevant log data, alert details, or data you're working with]
Task: [Be specific about what you want — summarize, explain, generate queries, identify patterns]
Constraints: [Specify what you need to watch for — tool-specific syntax, data handling requirements, level of detail]
Format: [Tell the AI how to structure its output — bullet points, narrative, code block]
Examples that actually work:
For log analysis:
Context: Here is a Windows Security Event log entry: [paste raw log]
Task: Explain what this event represents, why it might be suspicious in an enterprise environment, and what follow-up investigation steps I should take.
Format: 1) Plain-language explanation of the event, 2) Why it's potentially suspicious, 3) Three specific follow-up investigation steps
For query generation:
Context: I'm using Splunk Enterprise Security. I'm investigating a potential data exfiltration event by user johndoe@company.com.
Task: Generate a SPL query to show me all file access events by this user in the last 48 hours, including the file paths accessed and the volume of data accessed. Also show me if this user accessed any network shares outside their normal department.
Constraints: Our index is "security_events", sourcetype is "wineventlog". Use stats and timechart for volume analysis.
For threat intelligence synthesis:
Context: I'm investigating an incident involving the following indicators: [IP addresses, hashes, domains]
Task: Summarize what you know about these indicators — threat actor associations, malware families, observed TTPs. If you don't have specific information about these indicators, tell me what investigative steps I should take to research them.
Format: Bullet points, organized by indicator type
Prompt construction anti-patterns:
- Vague requests: "Help me investigate this alert" gives the AI nothing to work with. Be specific about what you have and what you need.
- Missing context: AI can't tell you whether a PowerShell command is suspicious if it doesn't know your baseline. Provide context about your environment when it's relevant.
- Over-trusting outputs: AI is wrong sometimes, especially about specific IOC details, recent threat actor behavior, and tool-specific syntax. Validate before acting.
What Doesn't Work (And Why)
AI in security investigations has real failure modes. Knowing them makes you a better user.
Trust and accuracy issues
AI models can be confidently wrong. They can hallucinate IOCs, misattribute malware families, describe threat actor behavior that's inaccurate, or generate SIEM queries with subtle syntax errors that return wrong results. For everything consequential — action taken during an incident, information shared with stakeholders, queries run in production — verify the AI's output before relying on it.
This isn't a reason to avoid AI tools. It's a reason to build verification into your workflow rather than treating AI outputs as authoritative.
Sensitive data handling
The same AI tools that help you with investigations may be sending your data to external services. Before pasting incident data, customer information, or classified threat intelligence into a public AI system, understand your organization's policy and the AI tool's data handling practices. This is not abstract — there are documented cases of organizations inadvertently sharing sensitive incident data with public AI systems via copy-paste into productivity AI tools.
Use enterprise AI deployments (Azure OpenAI, Bedrock Claude, similar) or on-premise models for sensitive investigation data. Consumer AI services aren't appropriate for sensitive incident response work.
Alert noise amplification
Poorly configured AI-assisted triage can make your noise problem worse. If you deploy AI triage and it generates false positive recommendations, analysts learn to distrust it. Once trust is lost, the AI becomes noise on top of your existing alert noise. Start with use cases where the AI's performance is verifiable and where mistakes have low consequences. Build trust through demonstrated performance before expanding to high-stakes automation.
The "AI said so" accountability gap
When an analyst follows an AI-generated playbook or acts on an AI-generated recommendation, the accountability question becomes complex. In a post-incident review, "the AI told me to" is not an acceptable explanation. The analyst using AI tools is still responsible for the investigation judgment. This isn't punitive — it's structural. Analysts using AI tools need to develop the skill of evaluating AI outputs, not just acting on them.
Building AI Into Your Investigation Practice
Practical guidance for integrating AI into how you actually work:
Start with your most repetitive tasks. The best initial use cases are the ones you do many times a day, where the format is predictable, and where the output can be easily verified. IOC enrichment, log explanation, and documentation summarization fit this profile.
Build verification habits from day one. Pick two or three types of queries or outputs that you'll always verify before acting on. The habit of "AI suggestion → quick sanity check → act" is much better than "AI suggestion → act → discover it was wrong."
Track your deviations. When you modify or discard an AI-generated suggestion, note why. This makes you a better AI user over time, builds your intuition for where AI output quality is high vs. low, and gives you data to share with your team about what's actually working.
Version control your prompts. If you build prompts that work well — for specific investigation types, for specific tools, for specific scenarios — save them. A library of tested, reliable prompts is a genuine operational asset. Treat prompt engineering output the same way you treat detection rule output: document it, test it, version it.
Share what works. The SOC analyst community is figuring out AI tool use in real time. What works in your environment is valuable knowledge for peers. Sharing effective prompts, workflows, and lessons learned is how the whole field gets better faster.
The Foundational Principle
The analysts who will be most effective with AI tools aren't the ones who trust it most. They're the ones who've developed accurate mental models of where AI excels and where it fails in their specific context, and who've built verification habits that catch the failures before they matter.
AI in security operations is not a question of whether you'll use it. You'll use it. The question is whether you approach it with the same disciplined skepticism you apply to any security tool — understanding its capabilities, knowing its failure modes, validating its outputs, and keeping humans accountable for the judgment calls.
That's the mindset. Everything else is technique.