Models that gather the intelligence around an alert, correlate it across cases and pick the runbook that fits, so the day goes to review and the customer instead of the queue.
An alert is rarely the hard part. The hard part is everything around it: what else touched the host, whether an address has been seen before, which of several hundred procedures applies, and what to do first. That work is reading and correlation, and it is where an analyst's day goes.
Models do that reading. They pull intelligence from the sources the team already pays for and from the ones it does not, correlate it across cases rather than one alert at a time, and hand back the larger picture: the account, the host, the campaign, the thing that links them. Then they pick the runbook that fits and start it. Triage, containment, remediation, and the monitoring that has to be running before the case can close. That is most of a Tier 1 and Tier 2 analyst's day, and it is the part that can be handed to a model without lowering the standard.
What separates that from a conventional automation is the case nobody wrote for. A hard-coded pipeline is a decision tree. It covers the branches somebody anticipated, and when the situation does not match, it stops, or it does the wrong thing confidently. A model can research what it does not know: read an unfamiliar log format, find the vendor's documentation, ask the next question. That is what keeps the work moving at three in the morning on a case the team has never seen. It is also what leaves the analyst free for customer care and full review, which is the work that actually needs a person.
The queue is triaged and the runbook chosen before a person opens it. What is left for the analyst is judgment, the customer and the review that signs off on the work. Security automation builds the runbooks; this is the layer that chooses between them and runs the first pass.