AI governance needs decision rights, not another committee

Imagine the workflow register says the AI steering committee owns the support-summary assistant.

Then a customer asks why the summary omitted a contractual exception. The support manager can see the problem but is unsure whether they may pause the tool. The AI team can disable the approved tool but cannot judge the customer commitment. Security owns access controls, not the support process. The steering committee meets later.

The organization has governance. It does not have an owner.

Committees are useful for setting policy, resolving exceptions, and accepting risks that cross business boundaries. They are poor substitutes for a person or accountable group close enough to the work to recognize a bad output, change the review step, restrict the data, or stop the workflow.

The fix is not a larger responsibility matrix. It is a short set of decision rights: who may approve, change, pause, and retire each part of the AI-assisted process.

Separate the system from the work

The central AI team should own the governance system. It can define intake lanes, minimum evidence, approved patterns, inventory fields, review triggers, and escalation paths. It can compare risks across use cases and prevent every department from inventing its own standard.

The business workflow owner should own the work. That means the purpose, acceptable inputs, required output quality, human review, operating metrics, exception handling, and decision to pause when the workflow no longer performs as intended.

Those are different jobs.

ISO describes an AI management system as the interrelated elements used to establish policies, objectives, and processes for responsible development, provision, or use of AI systems. Its public overview also emphasizes maintaining and continually improving that management system ISO/IEC 42001. A management system can govern many applications without making its central administrator the operational owner of every application.

NIST makes a similar distinction operationally. Its AI Risk Management Framework calls for clear accountability structures, documented roles and lines of communication, executive responsibility for AI risk decisions, and defined human-AI oversight responsibilities NIST AI RMF Core. The point is not to attach everyone to every decision. It is to make the right person able and expected to act.

Give each decision a home

Start with decisions, not job titles. Titles vary across organizations; the work does not.

Decision area	Accountable owner	What that owner decides
Governance system	Central AI program or governance function	Intake lanes, baseline controls, inventory requirements, review triggers, prohibited uses, exceptions, and reporting
Business workflow	Named operational owner	Intended use, acceptable quality, human review, user access, exceptions, performance response, pause, and retirement
Technical platform	IT, engineering, or platform owner	Identity, integrations, deployment, model configuration, logging, resilience, change control, and technical shutdown
Data boundary	Data owner with privacy and security support	Allowed sources, purposes, access, retention, deletion, residency, and incident response
Specialist judgment	Legal, compliance, security, privacy, safety, or domain reviewers	Interpretation and approval within their expertise, including conditions that must remain true
Residual risk	Executive or delegated risk authority	Whether material unresolved risk is accepted, reduced, transferred, or avoided

This is not a claim that every workflow needs a committee of specialists. A private drafting aid using approved public material may need only a workflow owner and existing acceptable-use controls. A connected system that reads customer records and writes to a case-management platform needs a wider set of decision owners because more boundaries can fail.

The OECD AI Principles frame accountability according to each actor’s role, context, and ability to act across the AI system lifecycle. They also recognize that risk management may require cooperation among users, suppliers, and other stakeholders OECD AI Principles. That is a better model than asking one central team to absorb responsibility it cannot exercise.

The ownership record should fit beside the workflow

Do not bury decision rights in an organization chart. Put them in the same record that describes the approved workflow.

For example, suppose a support team uses an approved assistant to draft internal case summaries from ticket history. Its ownership record might say:

Field	Recorded decision
Intended use	Draft an internal case summary for an assigned support agent
Workflow owner	Support operations lead
Platform owner	Enterprise applications team
Allowed data	Ticket text and approved account fields for the assigned case
Human review	Assigned agent checks source tickets before saving the summary
Local change right	Support owner may change instructions without adding data, audiences, or tool permissions
Re-review triggers	New data source, customer-visible output, automated write, provider change, or removal of human review
Pause right	Support owner and security incident lead may disable the workflow
Escalation	Privacy reviews new personal-data use; legal reviews use in disputes; AI governance resolves lane changes

The example is hypothetical. Its value is the shape of the record: a later operator can tell who decides and what conditions the approval assumed.

This record should link to evidence rather than copy it. Platform configuration belongs with the platform. Privacy analysis belongs with the privacy record. Test cases and known limits belong with the workflow. The ownership record tells people where those artifacts are and who can act on them.

Keep the central team out of the operational queue

A central team becomes a bottleneck when routine operating changes require its permission even though the business and control boundaries have not changed.

If the support owner cannot adjust an internal prompt, remove a user, strengthen a review instruction, or pause the workflow without waiting for a central meeting, ownership is only ceremonial. Conversely, if the owner can add a new data source, enable an external send, or remove human review without re-entering governance, delegation is too broad.

Set a local change envelope. Inside it, the workflow owner can operate. Crossing it triggers the appropriate review. This pairs naturally with intake lanes and change-based review: the central team designs the routing logic, while the local owner notices and reports the change.

The UK Government’s AI Playbook offers a useful public example of role separation. It describes governance-board oversight, accountability, risk management, and strategic guidance while also requiring defined responsibilities for people and organizations that develop, deploy, or use AI UK Government AI Playbook. Private organizations will use different titles, but the operating principle travels: oversight is not the same job as day-to-day control.

Do not hand the problem to an AI champion

AI champions can demonstrate tools, collect friction, teach safe patterns, and connect teams to reviewers. They should not become the default owner of workflows they do not manage.

Making the most enthusiastic user accountable creates predictable problems. They may not control staffing, process policy, customer commitments, or system access. Their informal role may disappear when they change jobs. And colleagues may treat their enthusiasm as approval even when security, privacy, legal, or operational conditions remain unresolved.

Champions are a support network. Ownership should follow authority over the business process.

The opposite failure is local fragmentation. A workflow owner should not be free to select any vendor, move any data, or create a private risk standard. Central guardrails still matter. Shared platforms, identity, procurement, security baselines, incident response, and inventory are precisely where central ownership earns its cost.

Some decisions should stay central

Keep control central when a decision changes the company’s risk posture rather than one workflow’s operation. Examples include approving a new enterprise provider, defining prohibited uses, changing the minimum privacy or security baseline, accepting risk that affects several business units, or coordinating an incident across shared infrastructure.

Central ownership may also be practical during an early pilot when the organization has no capable local owner. Treat that as a temporary condition with an exit test, not a permanent operating model. Before the workflow becomes routine, the receiving owner should be able to explain its purpose, inspect its evidence, manage user access, respond to failures, trigger review, and invoke the off switch.

If nobody in the business can take those decisions, the workflow is not ready to scale. The alternatives are to keep it as a centrally managed experiment, narrow it to a low-risk tool, replace it with deterministic automation, buy a managed service with clearer accountability, or stop it.

Use the incident test

Read the ownership record and imagine that the workflow exposes sensitive data, produces a materially wrong result, or starts acting outside its approved use.

Can the people named in the record answer these questions without convening a new committee?

• Who pauses the workflow now?
• Who determines which records and people may be affected?
• Who owns the business correction?
• Who handles the security, privacy, legal, or customer response?
• Who decides whether and under what conditions the workflow resumes?

If the answers collapse into “AI committee,” the organization still has a coordination body where it needs decision rights.

Good AI governance does not remove central oversight. It makes central oversight precise. The central team owns the rules, common infrastructure, inventory, escalation, and cross-company risk. The workflow owner owns the work. Specialist functions own judgments within their mandates. Executives own material residual risk.

That division costs more attention up front than assigning everything to a committee. It costs much less than discovering during an incident that everyone was consulted and nobody was authorized to act.