Every few weeks another demo lands on my feed: someone pipes a security alert into a large language model, gets back a paragraph that sounds like a SOC analyst, and declares Tier-1 automated. Having spent years on the receiving end of enterprise alert queues — Cisco FTD intrusion events, Defender detections, sign-in risk alerts — I can tell you why those demos fall apart in production:
Alerts in isolation are noise. The signal is the story across alerts: the same actor showing up in a risky Entra ID sign-in, then AWS recon, then a persistence action. An LLM triaging one alert at a time can't see the campaign.
Cost scales with alert volume, and alert volume is enormous. If every event costs an API call, your triage bill grows linearly with your noisiest sensor.
Free-text verdicts aren't actionable. "This looks suspicious" doesn't page anyone. You need structured output a downstream system can route on.
If you haven't worked a queue like this, the ratios are hard to believe. A single FTD intrusion policy tuned one notch too aggressive will emit thousands of IPS events a day, most of them the same few signatures firing on scanner traffic that never reached anything vulnerable. A MECM patch wave lights up endpoint AV with detections on installer behavior that looks exactly like the droppers the heuristics were trained on. In most shops the alert-to-incident ratio is measured in orders of magnitude, not percentages. So the interesting engineering problem was never "can a model write a plausible paragraph about one alert." It's what you do with everything else.
