What should security teams do first when they cannot answer AI risk questions confidently?

Start by separating the problem into attacker use of AI, employee use of AI, and risk inside AI systems themselves. Then identify the live control already in place for each area, the owner of that control, and the telemetry that proves it is working. That prevents solutioneering and gives the board an honest baseline.

Why This Matters for Security Teams

When AI risk questions cannot be answered confidently, the problem is usually not a missing tool. It is a missing decomposition of the risk into distinct control domains: adversary use of AI, employee use of AI, and risk embedded inside AI systems. That distinction matters because each domain has different owners, evidence sources, and failure modes. A board asking for assurance does not need a vague AI strategy; it needs a credible baseline of live controls, telemetry, and accountability.

Current guidance suggests anchoring that baseline in a recognised control structure rather than starting with a new AI-specific programme. The NIST Cybersecurity Framework 2.0 gives security teams a broad way to inventory governance, protect, detect, respond, and recover controls before they debate model-specific safeguards. NHI Management Group recommends pairing that operational view with the question of who owns each control and what evidence proves it is working. Without that discipline, teams often confuse policy statements with operational reality, especially where AI features have been adopted through shadow IT, procurement shortcuts, or business-led pilots.

In practice, many security teams encounter AI risk only after a board, regulator, or incident has already forced the question, rather than through intentional control design.

How It Works in Practice

The first step is to build a three-column working view: threat source, control owner, and proof of operation. For attacker use of AI, the team should look at phishing, impersonation, automated recon, and malicious content generation. For employee use of AI, the focus shifts to data handling, approved tool usage, prompt leakage, and policy enforcement. For risk inside AI systems themselves, attention moves to training data integrity, prompt injection, output validation, model provenance, and abuse of agent permissions.

This is where the NIST AI Risk Management Framework is useful because it pushes teams toward governance, mapping, measurement, and ongoing management rather than one-time approval. Where the concern is specifically cyber-enabled attack paths against AI, the NIST IR 8596 Cyber AI Profile helps translate abstract AI concern into security operations language. A practical workflow usually looks like this:

• Identify each live AI exposure, including internal copilots, external SaaS tools, and embedded model features.
• Name the control owner for each exposure, such as security, IT, legal, data governance, or product engineering.
• Collect telemetry that shows the control is active, such as logs, policy events, access records, model monitoring, or DLP alerts.
• Record where evidence is missing, because no evidence is itself a finding.

This approach works best when the organisation can map AI use to existing identity, endpoint, cloud, and data controls instead of inventing a separate AI security stack. These controls tend to break down when AI is deployed through unmanaged third-party services and telemetry never reaches the security team.

Common Variations and Edge Cases

Tighter AI oversight often increases operational overhead, requiring organisations to balance visibility against speed of adoption. That tradeoff becomes sharper when business teams are using generative AI in procurement, customer support, or software delivery without a central approval path. Best practice is evolving here, and there is no universal standard for exactly how much monitoring is enough.

One common edge case is that employee AI use may be low risk at the model layer but high risk at the data layer. A second is that agentic systems can appear compliant while still holding excessive tool access, which creates an identity and privilege problem as much as an AI one. That is where the AI security conversation intersects with NHI governance: if an agent can call APIs, access data, or trigger workflows, its identity, secrets, and permissions must be governed like any other machine actor.

Where the question is really about assurance, not implementation, NHI Management Group recommends documenting what is known, what is assumed, and what is unverified. That is also why teams sometimes supplement cyber controls with the ISO/IEC 42001:2023 AI Management System Standard when they need a management-system lens for ownership and continual improvement. The practical limit appears in fast-moving environments where experimental AI tools are being deployed daily, because control ownership changes faster than evidence collection.

Related resources from NHI Mgmt Group

• How should security teams prevent a channel member from using an AI agent to reach resources they cannot access directly?
• How should security teams handle secrets they cannot confidently map to an NHI?
• Why do AI security posture tools create more risk when they stop at alerts and cannot enforce controls?
• How should security teams limit the risk from AI agents that have access to production systems?