At 9:30 on a Tuesday night, I was sitting at my desk reviewing a vendor's SOC 2 Type II report. It needed to be finished by the end of the week. I was about fifteen pages in, and my ability to absorb another paragraph of auditor dialect was rapidly approaching zero.
The question I needed to answer was fairly simple: should we trust this vendor with our data? Getting there required understanding what the report actually covered, what it didn't, and what responsibilities belonged to us. Important work. Also the kind of work that makes you read the same sentence three times and briefly consider a career involving fewer PDFs.
So I gave an AI tool the relevant sections and specific instructions about what I wanted it to examine. In about three minutes, it flagged two complementary user entity controls I'd missed. Those are controls the vendor expects its customers to handle, which makes overlooking them a problem for the people relying on the report.
I went back to the source and checked both. Then I considered whether they mattered for our relationship with that vendor and what we needed to do about them. The tool helped me find something worth examining. I still owned the decision. I probably would have spent another hour finding those items myself, assuming my tired brain caught them at all.
That is the kind of AI conversation I want security leaders to have. We spend plenty of time discussing what attackers might do with it and listening to vendors explain how their product will revolutionize everything except the purchase order. We spend less time talking about the ordinary, useful work it can help practitioners finish on a Tuesday night.
I've written before about organizations adopting AI because somebody on the board read an article and decided we needed some. I still stand by that criticism. Buying a capability before identifying the problem tends to produce an expensive answer to a question nobody asked.
But I use AI in my security work almost every day, and in my personal life too. I find it useful when I can name the task, explain what a good result looks like, and verify the output. Reviewing a report, preparing an investigation, or improving a policy gives me something concrete to evaluate. An announcement about our exciting AI journey gives me considerably less.
AI can take some work out of the tenth hour, when even experienced people are tired and the next document still needs reviewing. That help is useful only if the time saved leaves us room to do the thinking that makes the result trustworthy.
Log analysis is a good example. I've spent more hours staring at Windows event logs, authentication records, and firewall traffic than I care to calculate. Much of that time goes into finding a meaningful sequence buried inside activity that is completely normal for the environment.
AI can help organize an initial review and suggest things worth investigating. A prompt like this gives it a useful starting point:
"Review these Windows Event Log entries from a domain controller covering the last 24 hours. Identify candidate sequences that could indicate credential harvesting, lateral movement, or privilege escalation. For each finding, cite the supporting records, explain plausible benign explanations, and identify additional evidence needed to confirm or rule out malicious activity. State any limits caused by missing log sources or context."
Asking for benign explanations matters. A tool that labels everything suspicious creates more work for the analyst. I want help deciding where to spend attention, including reasons a finding might turn out to be routine.
I've had AI flag service account activity that made perfect sense once I supplied the environment's context. A backup process doing its job at 2 AM can look interesting if you don't know that it runs every night. The model needs that information, and I need to verify that it used it correctly.
I treat the output as a set of leads. I check the underlying records, compare them with known behavior, and decide what deserves further investigation. The tool can shorten the sorting process. It can also miss the thing that matters, which is why a clean-looking summary never settles the investigation.
Using AI for policy and compliance work has probably saved me the most time. Nobody is packing a conference room to hear about my latest access control policy revision, but that document still affects how people work and what the organization can demonstrate during an audit.
Much of the effort involves comparing requirements with language that has survived several revisions and somehow become less clear with each one. AI can help identify those gaps if you give it the actual material to compare:
"Compare this access control policy with the supplied NIST SP 800-53 Access Control requirements. For each applicable control, cite the relevant policy section and identify missing or ambiguous language. Suggest specific, measurable revisions where needed. Flag requirements that would be difficult to audit as written, and distinguish policy coverage from evidence that a control is operating."
That distinction matters. A policy can describe a control beautifully while the organization struggles to perform it consistently. The wording needs to make responsibilities and expectations clear enough that people can implement the control and someone else can assess it.
I've written language that technically addressed a requirement while leaving far too much room for interpretation. By revision eight, "access will be reviewed periodically" starts looking acceptable because everybody wants the document finished. It still leaves people guessing about the schedule and who is responsible. AI can help spot that ambiguity. I have to decide what the organization can actually commit to doing.
During incident response, I use it to help organize early triage. Those first thirty minutes can involve incomplete information, competing explanations, and someone asking whether we should shut something down. A structured second pass can be useful when your brain is trying to handle all of that before the coffee has arrived.
Take a potential business email compromise:
"We are investigating suspicious wire transfer instructions sent in an executive's name at 6:15 AM. We have no known corporate login by the executive at that time, an unregistered mobile device is associated with the message, and the reply-to address differs from the executive's real address by one character. Treat account compromise and spoofing as separate hypotheses. Prioritize immediate payment verification, evidence preservation, and investigation steps. Identify what to examine in identity-provider sign-in and audit logs, what to ask the executive, and what evidence would support or weaken each hypothesis."
The answer may include things an experienced responder already knows. That's fine. Under pressure, remembering a useful step is valuable even if it won't win an innovation award.
But the model can omit steps, misread evidence, or recommend an action that doesn't fit the incident. I compare its suggestions with our procedures and the facts we have. The responder still decides what to preserve, what to contain, and when to escalate. An AI-generated checklist has no authority to approve a wire transfer or explain why we disrupted a business process.
Another useful area is translating technical risk into business language. Security leaders spend a lot of time understanding technical details, then need to explain what those details mean to people deciding how the organization should respond.
Being close to a problem can make that explanation harder. You know every technical qualification and want to include all of them. Meanwhile, the board wants to understand the potential impact, the available options, and what you recommend. It probably doesn't need your entire relationship history with the vulnerable application.
I've used prompts like this to get a cleaner first draft:
"Draft a three-sentence explanation for the board of a critical vulnerability in our customer portal that permits unauthenticated remote code execution. Patching requires four hours of downtime during business hours. Explain the potential business impact and the trade-off without technical jargon. Use only these facts, identify uncertainty, and avoid inventing exposure or financial losses. Suggest one likely board question and identify what information we would need to answer it."
I still edit the result. Sometimes AI removes a qualification that matters or makes the risk sound more certain than the evidence supports. Plain language helps only if it preserves the truth. A polished explanation that misleads a decision-maker is a security problem with better grammar.
Vendor questionnaires involve a related task: turning existing documentation into answers someone else can use. If you've answered enough of them, you know the experience of seeing the same question phrased seventeen different ways and wondering whether security questionnaires are breeding when nobody is watching.
AI can help prepare an initial response using documentation you already maintain:
"Using only the supplied information security policy, incident response plan summary, and SOC 2 report executive summary, draft answers to this security questionnaire. Cite the source document and relevant section for every answer. Where the documentation is insufficient, write 'requires manual input.' Do not infer that a practice exists merely because the policy requires it."
Those instructions help focus the work, but they don't guarantee accurate answers. I check the citations and make sure each response reflects what we actually do. My team still reviews everything before it goes out. A statement about our controls can become a commitment someone expects us to honor.
For this work, drafting time dropped from several hours to about forty-five minutes. That matters because questionnaire work competes with everything else the team needs to accomplish. The useful measure is how much time remains saved after review and corrections, with answers we can stand behind.
Detection engineering is another place where AI can help with the first draft and with questions we might overlook. A useful rule needs sound logic, available telemetry, and an understanding of normal activity. Generating something that looks like a rule is the easy part.
For example:
"Draft a Sigma detection for scheduled task creation through schtasks.exe where the task runs as SYSTEM. Explain the required telemetry and which parts of the proposed logic depend on fields or correlation that may not be available. Describe how known management tools could be handled without creating overly broad exclusions. Include likely false positives, two plausible variations of the behavior, and additional detection opportunities for those variations."
The follow-up thinking is often as useful as the draft. Asking about variations can reveal that we've focused too closely on the exact behavior in the threat report we just read. It gives us additional ideas to assess against the environment and the available data.
Then we validate the syntax and fields, test with representative activity, and examine the false positives. The model may invent a field or assume the logs contain information they don't. Putting that rule into production without checking it could leave us believing we have coverage that exists only in a conversation.
That brings me to the limitations, because I've had enough useful results to keep using AI and enough bad ones to keep checking it.
It gets things wrong. I've seen nonexistent CVE numbers, inaccurate descriptions of attack techniques, and log analysis that confidently flagged benign activity while missing the indicator that mattered. Calling that a hallucination doesn't change the work required to catch it. A confident sentence still needs evidence.
I can verify a CVE against the actual advisory or compare a finding with the original log. If I can't trace an important claim back to evidence, it hasn't earned a place in the decision. Asking the tool to cite sources helps me review its work; I still have to confirm the source exists and supports the claim.
Environment context creates another problem. The model doesn't automatically know why a service account exists, which system supports payment processing, or what downtime would do to a business function. We can provide relevant context, but we need to check whether the output reflects it. An answer can be reasonable in general and still be wrong for our organization.
Data handling deserves the same scrutiny we'd apply to another external service. A vendor report can contain confidential information. Logs can reveal details about users and systems. Before putting either into an AI tool, we need to understand where the data goes, who can access it, how long it's retained, and whether it can be used for training. Use a tool approved for the information involved and respect the obligations attached to that information. Anonymize or minimize inputs where appropriate. Convenience doesn't change the data classification, and calling something a prompt doesn't make it any less of a disclosure.
The limitation I find hardest to manage is my own reaction to speed. I've caught myself accepting output because it looked reasonable and arrived quickly. If I'd spent an hour reaching that conclusion manually, I would have worked through questions I hadn't considered when the answer appeared in seconds. Some of that slow work was tedious. Some of it was the thinking I needed to do. I try to distinguish the two by asking whether I can explain the conclusion and defend it using the evidence. If all I can do is repeat the model's explanation, I need to go back and do more work.
I also think about what this means for junior analysts. Reading logs manually, working through a policy requirement, and building a detection line by line teach you how to recognize a good answer. They teach you what to question when the answer looks suspiciously clean.
AI can support that learning. Ask it to explain why an event matters, suggest an alternative interpretation, or walk through a rule. Then check the explanation against the evidence. Used that way, it can give an analyst more opportunities to practice reasoning.
The concern is allowing people to skip that reasoning entirely. If an analyst can produce a finding but can't explain how the evidence supports it, the team has a development problem. That would be true with or without AI. The tool can make the gap harder to notice because the output sounds so capable.
Senior practitioners need to leave room for people to learn the work and show their thinking. We can't demand judgment from analysts while organizing the job around accepting answers as quickly as possible.
One more use I've found helpful is asking AI to challenge my own decisions. When another senior architect isn't available, I can give the tool a design and ask it to examine the assumptions behind it:
"Review this network segmentation design for a payment processing environment. Challenge the assumptions, identify potential single points of failure, and describe where the design may leave opportunities for an attacker. Tie each concern to the supplied design, distinguish evidence from speculation, and identify what additional information would change the assessment."
Roughly one time in three, it has raised something I hadn't considered. That makes the exercise worth a few minutes. I still examine the concern myself, and the output doesn't tell me what a real attacker could accomplish in our environment. It gives me questions to take into the next design review.
I'm still figuring out which uses work best and where the verification effort eats up the benefit. I expect that to continue. What I want from security leaders is a willingness to try specific workflows and judge them by the quality of the work they produce.
Start with a task that consumes time and has a result you can evaluate. Give the tool the context it needs, within appropriate data handling limits. Check the output and measure the effort required to reach something useful. If it helps, build that into the workflow. If it creates more cleanup than value, change the approach.
On that Tuesday night, AI helped me notice two responsibilities buried in a report. I still had to decide what they meant for our organization. That is a useful division of work, and it gives me a concrete reason to keep using the tool.
I want my team to spend less of its time fighting through repetitive work when a tool can help. I want the time we recover going into investigation, better decisions, and the kind of learning that makes the next review stronger. At the tenth hour, having help matters. So does being able to explain the answer when someone asks how we reached it.