Most SOCs are not short on detections. They are short on judgment applied to detections. A queue of 4,000 alerts is not a visibility problem. It is a decision problem.
The decision is usually the same few questions. Is this real? Does it matter for us? Has anything like it happened before? What would confirm it, and what would close it?
An analyst answers those by reading the alert, then reading three other things. The asset owner. The recent change log. Whether the same rule fired last month and what happened. The triage step is mostly retrieval plus a short summary, and that is exactly the shape of work a model does well now.
What the model needs to be useful
A model without context writes plausible triage notes that nobody trusts. A model with the right context writes notes an analyst can act on. The difference is the context, not the model.
Give it the alert, the rule that fired, and the raw event. Give it what the analyst would open: asset inventory, identity provider history, recent deploys, the ticket system.
Then give it a tight job. Not "investigate this." Something like: name the likely cause, list the evidence for and against, say what would confirm it, and pick one of four dispositions. The narrow job is easier to evaluate and easier to trust.
Keep the analyst in the loop, and keep the data out of the vendor
Two things go wrong when teams try this.
First, they automate the close. The model marks alerts benign, the analyst stops looking, and a real incident sits in the closed pile. Keep a human on anything that touches a crown jewel. Let the model take the first pass on the long tail.
Second, they send the whole alert corpus to a hosted API. Now the SOC's most sensitive data, which is to say the company's incidents, is in someone else's logs under someone else's retention policy. Many teams only notice this when legal asks.
The second problem is why we care about zero data retention for this use case. Triage needs the raw events. Raw events are the crown jewels. If the model provider keeps them, the SOC has created a second copy of its worst days.
Measure the thing you actually care about
Track two numbers, not one. How many alerts the model closes without an analyst opening them, and how many of those the analyst would have escalated. The first number goes up if you loosen the rules. The second is the one that matters.
A model-assisted queue should move the analyst from 40 alerts to 8, with the same number of true positives found. If it moves the count but loses the incidents, it is not triage. It is noise.
Where to start
Pick one rule that fires too much. Attach the context the analyst uses. Have the model write the note, not the disposition, for two weeks. Read every note. Then let it choose a disposition on the tail.
That is a small enough change to evaluate and large enough to matter. The queue is a model problem now. The teams that treat it that way will get their analysts back.