AI tools for security teams of one: what to hand over and what to keep
The model produced a Sentinel rule in nine seconds. It was well-formed KQL, it referenced a table, it had a sensible name and a MITRE tactic. It also queried a table that does not exist in the workspace, and it would have sat in the portal looking exactly like the working rules and never firing.
That is the shape of the whole question. Ai tools for security teams are genuinely useful for things where being roughly right is a good starting point, and actively dangerous for anything that has to be true about your specific environment, because the failure mode is a confident, plausible, well-formatted answer.
Where ai tools for security teams actually earn their keep
Four categories, and the common property is that you can verify the output cheaply.
First drafts of documents. Policies, procedures, incident report structures, questionnaire answers you then correct. A first draft you rewrite is faster than a blank page, and the rewriting is where your knowledge gets added. The risk is adopting the draft rather than editing it, which produces a policy asserting practices you do not have, which is a finding you wrote yourself.
Query syntax. KQL, PowerShell, Graph filters, Resource Graph. This is a good use because the output is immediately testable: run it, see whether it returns what you expected. The model is helping with syntax rather than with facts about your estate, and syntax it knows.
Summarising things you already have. A long alert, a vendor's SOC 2 report, a supplier's terms. Summarising a document you can check beats reading forty pages, provided you check the parts that matter.
Rephrasing. Turning a technical finding into something a director will read, or an answer you already wrote into the wording a questionnaire wants. Nothing factual is being generated.
Where it fails, specifically
Not vaguely, because the specific failures are predictable.
Anything about your environment. Table names, policy names, group names, which subscriptions exist, what your retention is set to. The model does not know and will produce something plausible. The Sentinel rule at the top of this note is the canonical example, and it is why validation before deployment matters more once you start generating rules quickly.
Current facts about products and regulation. Cloud services change monthly and regulation changes by amendment. A confident statement about a licensing requirement, a retention default or a compliance deadline is exactly the kind of thing to verify at source. The EU AI Act timeline has already moved once by amendment, which is a good illustration: a model trained before that change would state the old dates with complete confidence.
Anything where being 90 percent right is worthless. A policy that is mostly right is fine, because you edit it. A firewall rule that is mostly right is not. A questionnaire answer that is mostly right is a contractual representation that is partly false.
Judgement about your risks. A model can list generic risks for a SaaS company. It cannot know which of them matter to you, what your contracts commit you to, or what your board will accept, which is the entire content of a risk assessment.
Rules for what goes in the window
The practical question people avoid: can you paste logs into a chatbot.
The honest answer is that it depends on the tool, the contract behind it and what is in the logs, and that most people have not checked any of the three.
Four rules that survive scrutiny:
Know whether inputs are retained or used for training. This is a configurable setting on most business offerings and a contractual term. It is also the single question a customer or an auditor will ask, so find out and write it down. Consumer accounts and business accounts frequently differ.
No customer personal data, by default. If a log contains user identifiers, email addresses or content, it is personal data and pasting it into a third-party service is a processing decision with a legal basis and, frequently, an international transfer question behind it. That does not make it impossible, it makes it something to decide deliberately rather than at the point of debugging.
No secrets, ever. Keys, tokens, connection strings, certificates. Obvious, and it happens constantly because the fastest way to get help with a configuration is to paste the configuration.
Redact before pasting, and make it easy. If sanitising a log takes five minutes, nobody does it under pressure. If there is a script that strips identifiers, people use it. The tooling determines the behaviour more than the policy does.
Then record the decision. Which tools are approved, on what account type, for what data. That record is an entry in the AI inventory and it is the answer to the questionnaire question about internal AI use, which arrives eventually.
The audit trail problem
A harder question that gets less attention. If a model drafted your policy, suggested your risk scoring, or produced the detection logic, what does that mean for the evidence.
The reasonable position: the artefact is yours because you reviewed and approved it, and the review is the control. What matters is that a competent person checked it, and that they could defend it if asked. An auditor is unlikely to ask what tool produced a draft. They are certain to ask who approved it and whether that person understands it.
Which sets a clear line. If you cannot explain why a detection rule is written the way it is, or why a risk is scored as it is, you have not reviewed it, you have accepted it. That is fine for prose and not fine for anything you will be asked to defend.
The honest summary
These tools have made the documentation half of a one-person security function materially faster, which matters because documentation was the part that got deferred. They have not made the judgement half faster at all, and they introduce a new failure mode where a confident answer about your own environment is wrong in a way that looks right.
So the split that works: hand over the writing, keep the deciding. Verify anything that claims to be a fact about your estate, and verify anything that claims to be a current fact about a product or a regulation, because both change and the model's confidence does not vary with its accuracy.
The rest of the AI regulation notes cover the obligations rather than the tooling, and the security and compliance work is the option where the judgement half is what you are short of.