It has to be shared. AI teams define how systems behave, while IAM and data governance teams control what those systems can access and how that access is logged. When AI agents become operational actors, identity governance becomes part of responsible AI, not a separate concern.
Why this is a shared governance problem, not an either-or decision
responsible ai breaks down if it is owned only by model builders or only by access administrators. AI teams understand model behavior, prompts, tool selection, and failure modes; IAM and data governance teams understand entitlements, approvals, auditability, segregation, and how access is revoked or constrained. The operating model has to join both, because responsible AI is partly about what the system does and partly about what the system is allowed to touch.
That shared model matters most when an AI system can act, not just recommend. If the system can call tools, read records, trigger workflows, or write back into business systems, then access boundaries and identity controls become part of the responsible AI control surface, not an external afterthought.
What each team owns in practice
AI teams should own model scope, intended use, evaluation, prompt and tool behavior, output quality, and the guardrails that keep the system aligned with its purpose. IAM teams should own identity lifecycle, authentication, authorization, privileged access, credential handling, logging, and review of who or what can use the system. Data governance teams should own data classification, permitted data use, retention, masking, and approval for sensitive datasets.
The cleanest split is not “who owns AI,” but “who owns the decision that changes risk.” If a change alters model behavior, it belongs with the AI team. If a change alters who can access data, systems, or actions, it belongs with IAM or data governance. That is why mature organisations treat responsible AI as an operating model with shared controls, not a single team’s backlog.
For teams building agents or tool-using assistants, the boundary becomes even more important. An agent with execution authority should be reviewed the way any other privileged actor is reviewed: defined scope, explicit approvals, time-bound access where possible, and traceable action logs. NHIMG’s Ultimate Guide to NHIs – Regulatory and Audit Perspectives is a useful reference when AI governance starts to depend on auditability and access review.
How to decide the operating model for agentic and non-agentic AI
Non-agentic AI, such as a classifier or copiloting layer that only produces suggestions, can often be governed primarily through AI policy, model review, and data controls. Once the system can initiate actions, use credentials, or access downstream services, the question changes from “is the output trustworthy?” to “is the actor constrained?” That is where IAM becomes a core responsibility, because the control objective shifts from content quality to delegated authority.
In practice, the best model is usually federated: AI teams define risk acceptance criteria for the system, while IAM defines the access architecture that makes those criteria enforceable. Identity Security Programme Guide is a good example of how identity governance can sit across human, non-human, and AI-agent identities without turning every AI issue into an IAM-only issue.
For agentic systems, the practical test is simple: if the AI can create material business impact without a human in the loop, the access model must be designed as tightly as any other privileged automation. That usually means explicit ownership, bounded entitlements, monitored use, and a revocation path that is faster than the system’s ability to keep acting. NHIMG’s Cloud Workload Identity Guide shows how keyless, short-lived, and federated access patterns reduce the risk of long-lived secrets in machine and agent workflows.
Risk and Threat Considerations
When responsible AI is split into separate AI and IAM silos, the biggest failure mode is uncontrolled authority. A well-behaved model can still become a security problem if it can access too much data, trigger too many actions, or reuse credentials that were never meant for autonomous use. The reverse is also true: strong access controls do not make an unsafe model safe if prompts, tool calls, or outputs are still poorly governed.
Failure mechanism: The system inherits excessive privilege, ambiguous ownership, or weak audit trails, then uses that access in ways the business did not intend. In agentic workflows, that can turn a model error, prompt injection, or workflow misuse into a real-world action path.
Impact: The result can be data exposure, unauthorized transactions, privilege escalation, or difficult-to-investigate incidents where no team can clearly explain who approved the action or which control failed first.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 42001:2023 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 42001:2023 | 4.1 — Understanding the organization and its context | Shared AI governance depends on defined roles and operating context. |
| Recommendation — Define AI governance ownership and boundaries across model, access, and data controls. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Agentic AI must be constrained to the minimum access needed to act safely. |
| AU-2 — Event Logging | Responsible AI needs traceability for tool use, access, and automated actions. | |
| IA-5 — Authenticator Management | AI and automation often depend on credentials, tokens, or keys that must be governed. | |
| Recommendation — Restrict AI and agent permissions to the minimum required for each approved task. Log AI-initiated access and actions so reviews can reconstruct what happened. Manage AI credentials with rotation, protection, and revocation controls. | ||
Practitioner Guidance
What to prioritise: Assign a single accountable owner for the overall responsible AI control model, then split execution by control type. AI teams should own model and agent behavior; IAM should own access, entitlements, and auditability; data governance should own data permissions and usage limits.
What to verify: Before trusting an AI system in production, verify whether it can act, what it can reach, whether those permissions are time-bound or persistent, and whether every sensitive action is attributable in logs. If you cannot answer those questions cleanly, the system is not yet governed as responsible AI.
Practitioner takeaway: The right operating model is shared ownership with clear control boundaries, because responsible AI fails when behavioral governance and access governance are treated as separate problems.