Who should approve access requests when governance spans both data and AI assets?

Who Has the Final Say When Data and AI Governance Intersect?

When access requests span both data and AI assets, approval should follow the governance owner who is accountable for the asset’s classification, intended use, and permitted processing. That does not mean a single team can approve everything in isolation. It means the decision must preserve policy alignment across both domains so that convenience does not override control intent. For this topic, the most useful external reference is NIST Cybersecurity Framework 2.0, which is helpful for understanding governance and oversight at a control-plane level.

In practice, many organisations discover approval gaps only after a request route has already allowed access to a data set, a model endpoint, or both without a clear accountable owner.

How Approval Should Work Across Shared Data and AI Assets

Shared governance works best when the approval path follows the asset, not the ticket. If a request is only for data, the data owner or delegated steward should approve it. If it is only for model use, model governance should decide. If the request touches both, approval should either require dual sign-off or a clearly designated primary approver with an explicit consultation requirement for the other governance domain. The point is to avoid a workflow that treats AI as a special exception to data governance, or data as a blind spot inside AI governance.

A sound approval design should reflect how the access will be used. A researcher may need a read-only dataset for evaluation, while a product team may need model output access, prompt logging, or fine-tuning permissions. Those are different decisions because they create different exposure, retention, and misuse risks. The approval authority should therefore be tied to the risk-bearing owner for the relevant asset class, not merely to the requester’s department or the fastest available approver.

For governance to hold, the workflow should also record the basis for approval. That means capturing the asset classification, the business purpose, the scope of access, and any constraints such as time limits or downstream sharing restrictions. Without that evidence, the organisation may technically “approve” access while still failing to demonstrate why the access was appropriate.

• Use the asset owner or steward as the default decision-maker for that asset class.
• Require dual approval when one request spans both data usage and AI system access.
• Bind approval to purpose, scope, and duration rather than to a generic role request.
• Keep the decision record attached to the request so audit and review are possible later.

Where this breaks down is in highly federated environments where ownership is unclear, because then the workflow can turn into a handoff chain instead of a decision.

Where Dual Governance Becomes Harder, and What to Watch For

Tighter approval rules often increase cycle time, so organisations need to balance governance assurance against operational delay. That trade-off is real, especially when teams want fast experimentation with models while still protecting sensitive data.

One common edge case is where the AI asset itself does not hold sensitive data, but its outputs or prompts can infer or reveal restricted information. In that situation, approval should not stop at the data layer alone, because the AI use case may introduce a new control requirement. Another edge case is delegated approval in a shared platform team: delegation can improve scale, but only if it does not sever accountability from the owner who can judge the asset’s classification and intended use. Where the organisation has not defined ownership clearly, the right answer is usually to pause and assign it rather than to let the workflow auto-route by convenience. That is a governance problem, not just an access-management problem.

There is also a practical consensus issue here: some organisations prefer a single integrated approval board for both data and AI, while others keep separate owners with a routing layer between them. Both models can work if the accountability chain is explicit; what fails is pretending that a single approver can safely decide on a blended request without understanding both the data and the model context.

Practitioner Guidance

What to prioritise: Define who owns approval authority for each asset class before you automate the workflow. If data and AI access decisions are still ambiguous, the approval process will inherit that ambiguity and produce inconsistent outcomes.

Decision rule: If the request changes both data exposure and AI use, require explicit review from both governance perspectives. If only one side is affected, let the accountable owner decide, but keep the scope narrow and documented.

What to verify: Confirm that the approver can actually judge classification, intended use, and downstream sharing constraints. If the approver cannot explain why the access is acceptable, the workflow is delegating authority without real accountability.

Practitioner takeaway: The strongest approval model is not the fastest one, but the one that makes ownership, scope, and purpose unmistakable when a request crosses the boundary between data and AI governance.

Related resources from NHI Mgmt Group

• What makes agentic AI an NHI governance issue?
• Why is it important to integrate identity and data governance?
• Why is NHI governance critical in the age of AI attacks?
• What is the difference between role-based access and API key governance for NHI security?