As artificial intelligence becomes more deeply embedded in enterprise security operations, the conversation is shifting from whether organizations should use AI to how they can use it responsibly, effectively, and without introducing new risks.
Ruchika Singh is a Security Engineer with eight years of experience spanning network security, identity and access management, cloud security, and compliance across hybrid, multi-cloud, and on-premises environments. Her work has included hands-on responsibility for network access controls, IAM and PAM platforms, cloud infrastructure, security automation, and regulatory frameworks including HIPAA, SOC 2 Type II, ISO 27001, and PCI-DSS.
In this interview, Singh discusses where AI is already making the biggest practical difference in enterprise security, from reducing SOC alert fatigue to improving access reviews and cloud risk prioritization. She also explores the risks of over-automation, why explainability remains critical in security tools, the challenges of applying AI in highly regulated healthcare environments, and how the role of the security engineer is likely to evolve as machines take on more detection and triage work while humans remain responsible for judgment, accountability, and high-stakes decisions.
You have worked across network security, identity and access management, cloud security, and compliance. Where are you seeing AI make the biggest practical difference in enterprise security today?
Across all of these areas, the biggest practical impact of AI is efficiency, but the way that shows up is different depending on the function.
In the SOC, AI is helping reduce noise more than it is uncovering things humans would have otherwise missed. Its real value is in correlating signals across multiple sources, reducing false positives, and allowing analysts to spend more of their time investigating meaningful threats instead of triaging endless alerts.
In identity and access management, AI is making access reviews much more effective. Historically, those reviews could become somewhat routine or even a rubber-stamp exercise. Now, organizations can use AI to identify privileges that should have been removed, flag anomalous entitlement patterns, and surface risky access combinations that might otherwise go unnoticed. That is particularly important because overly broad or outdated access remains a major source of security exposure.
Cloud security is another area where AI can improve both effectiveness and efficiency. Because so much of the cloud environment is API-accessible and structured, AI can consume and correlate large amounts of security data very quickly. The bigger opportunity is moving beyond simply identifying technical issues and helping teams prioritize the ones that are most likely to have a real business impact.
AI is increasingly used to detect anomalies and suspicious behavior across distributed cloud environments. What types of threats or access patterns can AI identify faster or more effectively than traditional rule based systems?
The role is shifting from human oversight of a queue to a role of judgment over the actions taken by an AI. The act of detection is becoming automated, and the time spent on triage is spent instead on determining the impact to the business and urgency of response.
There are still aspects of the job that are distinctly human. Threat modeling a new system involves anticipating attacks against something that does not yet exist and has no training data. The same applies to making incident response decisions under pressure, such as whether to take a system offline or not. Finally, in situations where the risk is accepted or mitigated, there must be a person who recognizes that there is risk and that a wrong choice might have been made. As AI becomes more capable of detecting anomalous behavior, these aspects of the job will become increasingly human-centric.
Security teams are often overwhelmed by alerts. How can AI help prioritize risk and reduce noise without creating a dangerous level of dependence on automated decision making?
The biggest challenge with implementing alert fatigue is not an absence of tools but too many alerts to triage for any given shift, which leads to prioritizing based on fatigue and actual problems getting overlooked. I think AI can be useful both in finding correlations between seemingly unrelated incidents that are in fact part of the same attack chain and prioritizing based on potential impact with consideration of the assets at risk, rather than treating a test server compromise the same way as a production database breach.
What are the biggest risks organizations face when they allow AI systems to automatically block users, devices, applications, or network activity without sufficient human oversight?
The biggest challenge with implementing alert fatigue is not an absence of tools but too many alerts to triage for any given shift, which leads to prioritizing based on fatigue and actual problems getting overlooked. I think AI can be useful both in finding correlations between seemingly unrelated incidents that are in fact part of the same attack chain and prioritizing based on potential impact with consideration of the assets at risk, rather than treating a test server compromise the same way as a production database breach.
I think the danger you mentioned is something teams should be aware of when utilising these systems. Essentially, you start developing the bias that everything automated is better, even if it starts subtly and slowly, such as learning that the model consistently scores benign anomalies low without understanding why. I think there is value in low risk operations being automated, but anything with destructive potential should require human oversight. I think it might also be important that teams review suppressed alerts, not just escalated ones, and test the model’s reaction to novel attacks it wasn’t trained on specifically to look for weaknesses.
How important is explainability in AI driven security tools, particularly when security teams need to understand why a user or service was flagged as suspicious?
Explainability makes a tool useful – not something that people will use recklessly or not at all. A black-box score means an analyst can’t make a nuanced assessment of when the tool is right or wrong, leaving them vulnerable to confirmation bias. In the name of “due diligence” they either approve everything, or ignore the tool entirely. There may be compliance reasons to understand your risk scores – a regulator or customer may ask why a particular transaction was rejected, and “the model said so” isn’t a satisfying answer, particularly in places with strict regulations like GDPR. Another reason for explainability is that it protects analysts from models that appear to work, but that are capturing the wrong signals. It’s all well and good to have a reliable score on aggregate, but an analyst can’t spot that if a model always triggers on one particular behavior.
In highly regulated healthcare environments, how do requirements such as HIPAA and strict access controls affect the way organizations can safely implement AI driven security automation?
HIPAA contains requirements not only about whether something is automated but also about who can access it, on what terms and with what audit trail. Tools that rely on large data sets for pattern-finding or system baseline can be challenged to show that the data they are using is not PHI, and therefore that they are not covered under HIPAA, even if they were not designed with healthcare in mind.
The control over access that HIPAA requires cuts the other way too: a tool that makes a medical record system unavailable for inspection cannot do so without justification, due to the potential for disruption to treatment. The ability to make decisions without explanation is not available to HIPAA-covered entities, due to the audit requirements. Even de-identified data needs to be handled carefully, as it may sometimes be possible to identify individuals from timestamps and the data surrounding them.
Poor or incomplete training data can create false positives and blind spots. What should security leaders look for when evaluating whether an AI security platform is actually reliable enough for enterprise use?
A vendor’s “98% accurate” claim is not useful information. Ask yourself if the data the model was trained on reflects your environment, as a model trained on financial traffic will not understand healthcare traffic. Ask yourself if the model updates as your traffic patterns update or if it was trained on a fixed set of rules, and request actual false positive and negative rates from similar applications of the product, not just theoretical numbers.
Ask yourself about the possibility of the model being poisoned in production and if the vendors account for this by performing any validation on the model before it is deployed. You should ask about the explainability of the model. Have it explain some positives and review if its logic makes sense. You should run it parallel to your existing tools for a period of time and see if your current system catches anything the new tool misses. Ask them how they plan to continue to re-validate the product in the future.
Looking ahead, how do you see the role of the security engineer changing as AI takes over more repetitive monitoring, analysis, and response tasks? Which responsibilities do you believe will remain firmly dependent on human judgment?
The role is evolving from monitoring the queue to making decisions about how to respond to what the machines have found. Detection work is becoming increasingly automated, and engineers can dedicate less time to triage and more to determining the potential impact on the business and prioritizing the response.
The work that requires human judgment is not going away. Coming up with threat models for brand-new systems involves imagining ways that an adversary might exploit them, long before there is any data to train on. During incident response, engineers need to make real time decisions about what sacrifices to make in the name of security without knowing what the real-world impact of those decisions will be; there may not be one right answer. There may be difficult decisions to make about whether to take a system offline or accept the risk to it in order to continue operations, with potentially career-ending consequences. The ability to make these decisions and accept these risks is a uniquely human quality and is not likely to be delegated to machines anytime soon. AI is becoming better at finding needles in haystacks, and it is up to humans to decide what to do about them.
