Ask five departments who owns AI governance and you may hear five sensible answers.
Product owns the feature. IT owns the platform. Security owns access. A privacy specialist owns the data review. Operations owns the workflow.
The difficulty comes when a decision crosses those boundaries. Who can approve a new use? Who follows up on an unresolved concern? Who can stop the system while the issue is examined?
I would begin with those decisions and work backwards to the responsibilities.
Separate coordination from ownership of a use case
Someone needs to coordinate the overall governance approach: the inventory, review process, records, escalation routes and leadership reporting.
Each use case also needs an accountable business owner. That person should understand the purpose of the activity, its operating boundaries and the people needed to review it.
The coordinator should not become the default owner of every AI-related problem. A product owner should not have to make a privacy judgement alone. The responsibilities need to connect.
NIST addresses documented roles and communication in GOVERN 2.1, and responsibility for AI risk decisions at leadership level in GOVERN 2.3. The allocation below is an example to adapt to your structure. Source: NIST Playbook, Govern.
Assign people to decisions that actually occur
For each priority use case, identify who does the following work:
- Proposes the use: Describes the purpose, benefit, data and intended action.
- Reviews the evidence: Examines the relevant technical, operational, security, privacy or legal questions.
- Approves the decision: Has authority to accept the use within defined conditions, or refuse it.
- Operates the workflow: Carries out the instructions and reports problems.
- Maintains the record: Updates ownership, scope, evidence and review dates.
- Pauses or restricts the use: Can act when a concern needs investigation.
Some roles may sit with the same person in a smaller company. Record that openly. Where independence matters, ask whether a separate review is needed and feasible.
“Consulted” and “informed” are useful categories, but they should not obscure who decides.
Work through a change request
Illustrative scenario: A customer success team has approval to use an assistant that drafts suggested replies. It now wants the assistant to issue account credits.
The operations manager can explain the business need. Product or Engineering can describe the proposed permissions. Security can examine access. Finance can review transaction controls. Other specialists may be needed depending on the data, customers and contractual context.
Someone must then decide whether the new use can proceed and under what conditions.
I would record who authorizes the change, which questions remain open, what must be demonstrated before release and who can disable the transaction capability. Assign a backup for that last role.
A meeting attended by all the right departments can still leave this decision unclear. The written outcome matters.
Make authority workable in daily operations
There is a practical difference between saying that a manager can pause a system and giving that manager an effective route to do it.
Check access, availability and escalation. Can the responsible person reach the technical operator? Does a pause stop future actions, or only hide the interface? Who handles work that arrives while the feature is disabled?
These questions need a joint operational and technical walkthrough. Do not describe a pause mechanism to customers until the relevant team has confirmed what it actually does.
The same care applies to approvals. If an approver is absent, employees need to know whether there is a delegate or whether the decision waits.
Keep commercial communication in the responsibility map
Marketing and Sales should know which claims have been approved and where their supporting evidence sits.
If Product changes the feature's boundaries, customer-facing language may need review. If a salesperson receives a question about training data or safeguards, there should be a route to an evidence owner.
My B2B perspective is that this handoff deserves explicit attention. A careful internal decision has limited value for buyer understanding if the website or sales deck describes something broader.
Try the ownership map before relying on it
Choose one ordinary change and one problem scenario. Ask the people involved to describe what they would do.
Who receives the request? Who reviews it? Who decides? Who updates the records? What happens if the usual owner is unavailable?
If the answers disagree, revise the map. This exercise can reveal a gap without waiting for a live incident.
Start with the free readiness check, or review the assessment scope.
One response to “Who Owns AI Governance? Defining Responsibilities Across Teams”
[…] Who Owns AI Governance? Defining Responsibilities Across Teams […]