AI governance roles and decision rights need clearer RACI models

At a glance

What this is: This is an analysis of AI governance roles, decision rights, and stakeholder accountability, with the key finding that clear RACI models are required to make AI governance auditable and operational.

Why it matters: It matters because IAM, IGA, and security teams now have to govern AI access, approvals, and evidence across internal and external stakeholders, not just human users.

By the numbers:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read Knostic's analysis of AI governance roles and stakeholder accountability

Context

AI governance fails when organisations treat it as a policy exercise instead of a decision-rights problem. In practice, the board, CDAO, CISO, DPO, legal, audit, platform engineering, and IAM all touch the same control plane, but too many programmes still leave ownership implicit.

For identity teams, the hard part is not writing guidance. It is aligning access approvals, runtime controls, evidence collection, and incident response to a RACI that survives audit and platform change. That is where AI governance starts to look like identity governance, only with more stakeholders and tighter deadlines.

The article’s focus on the EU AI Act, NIST, and OECD reflects a broader shift: governance is becoming operational, not advisory. The programmes that will hold up are the ones that can show who approved what, who enforced it, and who can prove it later.

Key questions

Q: How should organisations assign accountability in AI governance programmes?

A: Organisations should assign one accountable owner for each governance decision, then separate that role from the people who implement controls, review privacy impacts, or handle incidents. AI governance fails when everyone is consulted but nobody is responsible. A usable RACI should cover approvals, runtime enforcement, evidence generation, and escalation so the audit trail stays intact.

Q: Why do AI governance programmes need both policy and runtime controls?

A: Policy defines intent, but runtime controls decide whether that intent is enforced where AI actually operates. Without runtime enforcement, policies become documentation that can be bypassed by prompts, tools, or data flows. Security and IAM teams should require evidence that every sensitive decision has a production control, a log source, and an owner.

Q: What do security teams get wrong about stakeholder maps in AI governance?

A: The common mistake is treating stakeholder maps as a communications exercise instead of a control design exercise. A stakeholder map only matters when it clarifies who approves, who blocks, who reviews, and who can prove compliance later. If those answers are missing, the map is not governing anything.

Q: Who is accountable when AI governance failures happen?

A: Accountability sits with the role that owns the decision and the evidence for that decision, not with every team that was copied into the process. In practice, the accountable owner should be able to show approval records, control status, and incident follow-up. That is what makes governance defensible to auditors and regulators.

Technical breakdown

RACI models turn AI governance into auditable control ownership

A RACI model is the simplest way to stop governance from dissolving into shared responsibility and unowned risk. In AI programmes, it clarifies who is Responsible for implementation, who is Accountable for the outcome, who must be Consulted, and who only needs to be Informed. That distinction matters because governance evidence is created across policy, engineering, legal review, and incident response. Without an explicit ownership map, controls exist on paper but fail in the audit trail. The real value is not the table itself but the decisions it forces about approvals, exceptions, and escalation.

Practical implication: define a decision matrix for use-case approval, runtime access, and incident handling before the first high-risk AI deployment.

Runtime control and evidence are part of governance, not separate tasks

The article correctly treats runtime enforcement and KPI reporting as governance work, not just security operations. For AI systems, a policy is only meaningful if it can be enforced at answer time, logged, and tied back to the responsible role. That is why AI governance increasingly depends on controls such as prompt filtering, output redaction, access policy, and tamper-evident logs. The same applies to evidence: if a board cannot see approval times, incident rates, and model quality trends, then the programme cannot prove it is working. Governance without runtime evidence becomes retrospective documentation.

Practical implication: pair every AI policy with a control, a log source, and a KPI that proves the policy is active in production.

External obligations reshape internal identity and access processes

The EU AI Act changes AI governance by making external timelines and obligations part of the operating model. That means internal teams are no longer just coordinating among themselves. They are mapping their roles, controls, and evidence to a regulatory schedule that affects deployment gates, documentation, and escalation. Standards such as NIST and OECD help translate that external pressure into lifecycle tasks, but the core issue remains the same: who has authority to approve, block, investigate, and attest. For IAM and privacy teams, this turns AI governance into a lifecycle and accountability problem, not only a compliance one.

Practical implication: map internal stakeholders to external obligations now, then test whether your approval and evidence flow can survive a regulator or auditor review.

NHI Mgmt Group analysis

AI governance is becoming an identity governance problem with broader stakeholder coverage. The article shows that boards, security, privacy, legal, audit, engineering, and operations now share responsibility for the same AI control surface. That is structurally similar to IAM and IGA, but the decision chain is wider and faster, which makes ownership gaps more dangerous. Practitioners should treat AI governance as a cross-functional access and evidence discipline, not a policy annex.

Decision rights are the real control plane. RACI models matter because AI programmes fail when approvals, exceptions, and incident responsibility are implicit. The article’s emphasis on auditability reflects a mature governance view: if a decision cannot be attributed, it cannot be defended. Practitioners should expect more scrutiny on who can approve use cases, who can block deployment, and who owns post-incident action.

Runtime enforcement separates governance theatre from operational control. The article links policy to runtime controls, KPIs, and evidence, which is the right direction for any AI governance programme. A policy stack without enforcement simply relocates risk into documentation. Practitioners should align governance artefacts with production controls so evidence is generated where the decision actually happens.

AI governance accountability: the governance assumption that policy owners can stay separate from runtime owners fails once AI decisions affect access, output, and incident response in the same workflow. That assumption was designed for slower, siloed control environments. It breaks when the same use case must satisfy legal, security, privacy, and operational obligations at the point of execution. Practitioners should redesign ownership around the control path, not the org chart.

The governance model is shifting from advisory oversight to measurable operational assurance. The article’s KPI focus signals where the field is heading: programmes will be judged by approval times, incident trends, and evidence quality, not by the existence of a policy document. Practitioners should prepare to prove that governance changes behaviour at runtime, not just in committee.

From our research:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• 69% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the same survey.
• For a broader lifecycle view, read NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns that also shape AI governance evidence.

What this signals

AI governance is converging with identity governance faster than most programmes are ready for. When 44% of organisations have any policies for AI agents while 92% say governance is critical, the gap is not awareness but operationalisation. That makes ownership, evidence, and lifecycle control the next practical battleground for IAM and security teams.

Decision rights will matter more than committee structure. The organisations that can tie approvals, runtime controls, and incident response to named owners will have a defensible audit position. Those that cannot will keep producing governance artefacts without proving enforcement.

The next phase of AI governance will be measured in control fidelity, not policy volume. For identity teams, that means aligning access policy, evidence collection, and review workflows with the actual systems that issue prompts, tools, and outputs.

For practitioners

• Build a single AI governance RACI for every high-risk use case Assign one accountable owner for approval, one for runtime enforcement, one for privacy review, and one for incident response. Keep the matrix tied to the use-case register so ownership does not drift as models, tools, and data sources change.
• Map governance controls to auditable artifacts For each policy, define the evidence it should produce, such as model cards, approval logs, DPIAs, access matrices, and incident tickets. If a control cannot emit evidence, it will be difficult to defend in audit or post-incident review.
• Tie AI access decisions to runtime enforcement Make IAM and platform teams responsible for the controls that actually constrain prompts, tools, data egress, and redaction. The goal is to prevent policy from living in a separate document from the production system.
• Track governance KPIs that reflect operational reality Measure time to approve new use cases, incident trends, review completion, and quality pass rates. Use those metrics to show whether governance is reducing risk or only adding process.
• Align internal decision rights with external deadlines Translate the EU AI Act and related standards into a programme calendar with owners for each obligation. That makes it easier to see where approvals, documentation, and controls need to be in place before a deadline hits.

Key takeaways

• AI governance breaks down when decision rights, runtime controls, and evidence ownership are split across too many teams.
• The article’s core message is operational, not theoretical: governance must be provable at the point where AI decisions are made.
• IAM, privacy, legal, audit, and engineering need a shared RACI if they want AI controls to survive scrutiny from boards and regulators.

Key terms

• RACI Model: A RACI model is a decision-rights framework that clarifies who is responsible, accountable, consulted, and informed for each governance activity. In AI governance, it prevents ambiguity across policy, security, privacy, legal, audit, and engineering by assigning ownership to specific decisions and evidence outputs.
• Decision Rights: Decision rights are the formal authority to approve, block, escalate, or close a governance action. In AI programmes, they determine who can accept risk, who can enforce controls, and who must preserve evidence when regulators or auditors ask how a decision was made.
• Runtime Controls: Runtime controls are enforcement mechanisms that act while the system is operating, not just during design or review. For AI governance, they include access policy, prompt filtering, output redaction, and logging that prove policy is being enforced where the decision actually occurs.

What's in the full article

Knostic's full article covers the operational detail this post intentionally leaves for the source:

• The role-by-role matrix for board, CDAO, CISO, DPO, legal, audit, IAM, and engineering.
• The EU AI Act timeline mapping for provider, deployer, and operator obligations.
• The KPI examples for approval latency, incident rates, and governance evidence.
• The sample RACI structure used to separate responsible, accountable, consulted, and informed roles.

👉 Knostic's full post covers the stakeholder matrix, RACI examples, and EU AI Act timing details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.