Why do traditional GRC and model risk programs fall short for modern AI?

Why This Matters for Security Teams

Traditional GRC and model risk programs assume a stable asset, a clearly owned change process, and predictable outcomes between review cycles. Modern AI breaks those assumptions. Models can be updated frequently, embedded in products and workflows, connected to external services, and influenced by prompts, retrieval sources, and tool execution. That means risk is not only about initial approval, but also about runtime behaviour, data lineage, and control drift.

For security and governance teams, the operational mistake is treating AI as a static application or a single model file. A live AI service may inherit risk from training data, prompt handling, identity and access design, vendor dependencies, and the way outputs are consumed downstream. Current guidance from NIST Cybersecurity Framework 2.0 supports continuous, outcome-based governance, which is far closer to the needs of AI than a quarterly review cycle.

In practice, many security teams encounter AI risk only after a business unit has already shipped a model into production with no clear owner, no evidence trail, and no reliable rollback path.

How It Works in Practice

AI governance has to operate across the full lifecycle, not just at model approval. That includes data sourcing, training, fine-tuning, evaluation, deployment, monitoring, and retirement. The control model also needs to account for AI-specific failure modes such as prompt injection, model poisoning, retrieval tampering, insecure tool use, and output misuse. A conventional model risk review rarely captures those attack paths because it was designed to assess statistical performance, not adversarial manipulation.

Practical governance usually needs a layered approach:

• Maintain a live inventory of models, agents, datasets, prompts, and external dependencies.
• Track business ownership, technical ownership, and security ownership separately where responsibilities differ.
• Require validation before release and monitoring after release, including drift, abuse signals, and unsafe output patterns.
• Define what the model is allowed to do, what data it may access, and when human approval is required.
• Log prompts, outputs, tool calls, and policy decisions so incidents can be investigated and reproduced.

Identity controls matter here as well. If an AI agent can call tools, access records, or trigger workflows, it needs explicit identity boundaries and privilege limits, not just an application API key. That is where digital identity discipline becomes relevant, and the operating model should reflect principles in NIST SP 800-63 Digital Identity Guidelines and the control intent of ISO/IEC 27002:2022 Information Security Controls.

The guidance is strongest where there is a stable service boundary and clear human ownership, and it becomes weaker when AI is composed from many vendor-hosted components, ephemeral agents, and rapidly changing prompts because the control surface is harder to evidence and keep current.

Common Variations and Edge Cases

Tighter AI governance often increases deployment friction, requiring organisations to balance speed of experimentation against traceability, approval latency, and monitoring overhead.

Not every AI use case needs the same level of control. A low-risk internal summarisation tool does not deserve the same governance burden as an agent that can approve spend, modify records, or execute code. Best practice is evolving, but current guidance suggests calibrating oversight to the impact of the use case, the sensitivity of the data, and the degree of autonomy. There is no universal standard for this yet, so teams should document the rationale for risk tiers and review them regularly.

Edge cases are often where traditional programs fail most visibly. A vendor-managed model may sit outside the organisation’s direct training pipeline, yet still create operational and legal exposure. A retrieval-augmented system may appear compliant at the model layer while silently pulling sensitive or stale content from poorly governed sources. An autonomous agent may pass a standard risk review and still become dangerous once it receives tool access, delegated credentials, or broad workflow permissions. Those intersections are where governance, security, and identity controls must be joined up rather than managed in separate forums.

For deeper control mapping, the most useful starting point is usually the governance and risk function in NIST Cybersecurity Framework 2.0, then extending into AI-specific assurance and access boundaries as the system becomes more autonomous.

Related resources from NHI Mgmt Group

• Why do traditional GRC tools fall short for AI governance?
• Why do traditional cybersecurity programs fall short for AI systems that generate outputs from prompts and data fragments?
• When does just-in-time access reduce risk for agentic AI, and when does it fall short?
• When does AI agent posture management reduce risk, and when does it fall short?