An analyst shouldn't need to open half a dozen systems just to understand a suspicious login. Authentication history, endpoint state, account privileges, recent changes, and related alerts may all be relevant. Collecting that context takes time, and it's often the same set of steps repeated throughout the day.
That's an area where I see practical value in AI. Give an assistant access to narrowly scoped, trustworthy sources and let it assemble a first-pass picture for the analyst. Include the underlying evidence so the person reviewing it can check the conclusions.
What I wouldn't do is jump from "this assistant summarizes an investigation" to "this assistant can suspend an account or isolate a machine on its own." Those are very different levels of authority. Bad context, a misleading log entry, or a prompt injected into retrieved material can turn a confident recommendation into the wrong action.
The OWASP Top 10 for LLM Applications describes risks such as prompt injection and excessive agency. The NIST AI Risk Management Framework offers a broader way to assess the risk of deploying AI systems. Neither reference removes the need to test the system against the mistakes and adversarial inputs it will encounter.
For an investigative assistant, I'd start with read-only access, clear source citations, visible uncertainty, and an audit trail of its tool calls. Keep approval with the analyst for consequential actions. Test it with conflicting evidence, missing context, and deliberately malicious data before trusting the output.
There are also many tasks where a script or a well-defined rule is simpler and more dependable than an LLM. We shouldn't use AI just to say we are using AI.
The question for me is whether it helps an analyst understand the situation and make a better decision. Faster is useful only if we're moving in the right direction.