Why do AI governance programmes need risk-based controls instead of a one-size-fits-all policy?

Why This Matters for Security Teams

A one-size-fits-all AI policy creates two failures at once: it overburdens low-risk use cases and under-controls the systems that can actually cause harm. Risk-based governance is the practical answer because AI systems differ by model type, data sensitivity, autonomy, and regulatory exposure. Current guidance from the NIST AI Risk Management Framework treats governance as a tiered discipline, not a fixed checklist, and NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks similarly frames identity and access decisions as context-driven.

This matters because enterprise AI is no longer limited to passive analytics. Some systems only classify content, while others can trigger workflows, call tools, or change infrastructure. A uniform policy ignores those differences and often leads to either approval bottlenecks or blind spots. The better model is to set controls based on real impact, not organisational convenience. In practice, many security teams encounter AI misuse only after a low-risk pilot has quietly expanded into a higher-risk production workflow.

How It Works in Practice

Risk-based AI governance starts by classifying use cases along a few operational dimensions: what data the system touches, whether it can make decisions independently, whether it has external tool access, and what legal or contractual obligations apply. That classification then determines the control baseline. For example, a public-facing summarisation tool may need content filtering and logging, while an agent that can approve payments or modify infrastructure needs stronger approval gates, human oversight, and auditability.

That approach aligns with the NIST Cybersecurity Framework 2.0 and the NIST AI 600-1 GenAI Profile, both of which support proportional controls rather than rigid, universal requirements. For NHI and agent governance, this usually means pairing policy tiers with identity tiers: low-risk systems may use shared service identities with limited scopes, while higher-risk workloads require individual workload identity, short-lived credentials, and tighter approval workflows. The NHIMG OWASP NHI Top 10 is useful here because it shows how over-privilege, secret leakage, and weak lifecycle controls become more dangerous as autonomy increases.

• Set policy tiers by use-case risk, not by model label alone.
• Require stronger review for systems with tool use, external side effects, or regulated data.
• Use logging, human approval, and revocation controls in proportion to impact.
• Review controls whenever the workflow, data class, or autonomy changes.

These controls tend to break down when teams treat pilot exceptions as permanent production permissions, because the risk profile changes faster than the policy does.

Common Variations and Edge Cases

Tighter governance often increases delivery friction, so organisations have to balance speed against exposure. That tradeoff is real, and guidance is still evolving on the exact thresholds for escalation. For low-impact internal assistants, best practice is usually lighter-weight oversight and clearer documentation. For agentic systems that chain actions across systems, current guidance suggests moving toward stricter authorisation, explicit task boundaries, and stronger evidence of control effectiveness.

Regulatory context also changes the answer. A use case that is acceptable in one business unit may require more rigorous controls if it processes personal data, financial records, or safety-critical information. The EU AI Act and NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives both reinforce the same practical point: governance should scale with risk, impact, and accountability. The highest-risk edge cases are not usually the most visible models; they are the quiet internal automations that sit close to credentials, APIs, or privileged workflows.

There is no universal standard for this yet, but organisations that adopt a risk-tier model usually gain better control coverage without forcing every AI use case through the same approval path.

Related resources from NHI Mgmt Group

• Why do AI governance programmes need both policy and runtime controls?
• Why do AI governance programmes need both documentation and operational controls for high-risk systems?
• When does AI agent access become a governance risk instead of an automation benefit?
• How do governance controls improve AI ROI instead of slowing it down?