Who Gets to Decide on AI in the Organization?

# Who Gets to Decide on AI in the Organization?

Most AI transformations do not fail on technology. They fail on ambiguity: who can make a decision, who only advises, who signs off on risk, and who owns outcomes. When decision rights are not explicit, companies fall into two extremes. Either decentralization without control, where every function deploys AI in its own way, or central paralysis, where everything waits for the "AI committee."

This playbook has one goal: help leaders quickly and practically build a map of AI decision rights so the organization can be both fast and accountable.

Why Decision Rights Are Critical Right Now

Deloitte, in *State of GenAI in the Enterprise 2024*, shows that companies are moving from pilots to scaling, and this is exactly where tension rises between speed and control. In pilots, you can "sort it out ad hoc." At scale, ad hoc turns into cost: delays, conflicts, and blurred accountability.

NIST AI RMF 1.0 (2023) and the OECD AI Principles (2019) stress that AI accountability must be assigned, auditable, and proportional to risk. In other words, saying "the business owns it" is not enough. You must define which specific decisions belong to the business and which belong to risk, security, or architecture functions.

Seven Decisions That Require Formal Decision Rights

In practice, start with seven decision types that show up in every organization:

1. **AI use case prioritization** Who decides what gets implemented, and by what value criteria?

2. **Use case risk-class acceptance** Who approves that a given use case can operate under specific controls?

3. **Model and vendor selection** Who decides build vs buy, and who accepts contractual risk?

4. **Production release approval** Who signs off on operational, quality, and security readiness?

5. **Model or configuration changes in production** Who can initiate change, and who owns regression testing?

6. **AI incident response** Who leads during crisis, who can stop the service, and who communicates impact?

7. **Use case retirement or escalation** Who decides to stop a solution when risk outweighs value?

If even one of these decisions has no explicit owner, chaos is an open invitation.

The DRIFT Model: A Simple Decision-Rights Backbone

> **Editorial note:** DRIFT is a synthesis model developed for AI&Scale, built on RACI (PMI), COBIT 2019 (ISACA), and NIST AI RMF 1.0. It extends classical decision-rights frameworks with AI-specific requirements: veto rights, audit traceability, and mandatory information inputs.

To avoid heavy bureaucracy, use the DRIFT model.

D (Decision Catalog): list key AI decisions and define them.

R (Rights Allocation): assign rights to "decide / recommend / review / veto / execute."

I (Information Requirements): define the minimum data package required for a decision.

F (Forum): define where and how often decisions are made (for example, weekly review, monthly committee).

T (Traceability): keep a decision trail: who decided what, when, and on what basis.

DRIFT combines the spirit of RACI with AI governance requirements. RACI defines responsibility and consultation; DRIFT extends it with veto rights, required decision data, and audit evidence.

How to Assign Decision Rights Without Overloading the System

The most common mistake is assigning everything to the board or a central AI team. That lowers speed and reduces decision quality because business context is local.

A better approach is the three-level principle:

- **Strategic level (board / risk committee):** risk appetite, capital allocation, high-impact decisions. - **Tactical level (business domain owners + IT + risk):** use case selection, implementation control, quarterly priorities. - **Operational level (product / operations teams):** day-to-day execution decisions within approved controls.

Core rule: the higher the risk and stakeholder impact, the higher the approval level. The lower the risk, the more team autonomy.

Decision Rights Matrix for AI

The following matrix can serve as a baseline standard:

- **Business owner:** decides use case value and business KPI. - **AI product owner / delivery lead:** recommends solution, leads delivery, owns operational quality. - **Architecture / IT platform:** approves technical fit, integration, and scalability. - **Security:** has veto rights on critical security risks. - **Risk & compliance:** approves risk classes and regulatory controls. - **Legal / procurement:** decides on contract terms and vendor liability acceptance. - **AI / risk committee:** resolves disputes and decisions above risk thresholds.

This setup works only if each role has explicit SLA timelines for decisions. Without that, "review rights" become informal vetoes.

When Veto Rights Are Needed and When They Are Not

Veto rights are an exceptional instrument. Give them to too many roles and the organization loses execution capacity. Give them to no one and the organization loses control.

A good standard:

- security has veto for critical policy violations, - compliance has veto for unacceptable regulatory risk, - business owner has veto for use cases with no credible business value, - committee has arbitration authority when value and risk conflict.

Every veto should require written rationale and a proposed unblock condition. That reduces the risk of permanent deadlock.

A 30-60-90 Rollout for Decision Rights

### Days 1-30: map decisions and roles

Identify the seven core AI decisions, describe each in one sentence, and assign initial roles. Do not optimize for perfection. The goal is to remove ambiguity.

### Days 31-60: pilot on 3-5 use cases

Apply the matrix to real cases. Measure decision cycle time, number of escalations, and documentation quality.

### Days 61-90: formalize and scale

Set risk thresholds, update go-live procedures, connect decision traceability to audit and management dashboard.

After 90 days, the organization should have one shared language: who decides, who reviews, who owns.

Scenario: Conflict Between Sales and Compliance

Sales wants to quickly deploy a proposal assistant for key accounts. Compliance raises risk around sensitive data processing, and IT flags missing integration with access-control systems.

In a company without clear decision rights, this conflict drags on for weeks, and the eventual call is still made by instinct. In a company using DRIFT, the flow is different: the business owner presents value, security and compliance define boundary conditions, and the committee decides based on data package and risk thresholds. The decision is faster, and accountability is explicit.

The key is not to avoid conflict forever. The key is to end conflict with a decision, not delay.

Five Metrics to Track Decision-Rights Quality

- median decision time for AI use cases, - share of decisions with complete data and rationale trail, - number of escalations breaching decision SLAs, - share of deployments stopped for issues detected only after go-live, - number of incidents where accountability was unclear.

If metrics show speed without quality, strengthen controls. If they show quality without speed, remove unnecessary approval points.

Most Common Anti-Patterns

Anti-pattern one: "the committee decides everything." That is a central bottleneck.

Anti-pattern two: "the business decides everything." That is decentralization without safeguards.

Anti-pattern three: RACI without veto rights and risk thresholds. The document exists, but it does not work.

Anti-pattern four: no decision SLAs. Decisions have formal owners but in practice sit in queue.

Anti-pattern five: no rationale trail. The organization does not learn from decisions and is not audit-ready.

How to Connect Decision Rights to Organizational Culture

A formal matrix is half the result. Leadership behavior is the other half. If leaders escalate everything upward, the organization never develops decision maturity. If they ignore control functions in the name of speed, they build risk debt.

Mature AI culture is a culture of intentional delegation: decisions are made as close to the problem as possible, but within explicit rules and accountability boundaries.

How to Launch Decision Forums Without Bureaucracy

Leaders often fear that formal decision rights will slow execution. You can avoid that if the forum cadence is simple and scope is clear.

A practical setup:

- weekly operational forum (30-45 minutes) for ongoing decisions, - monthly tactical forum for disputes and threshold changes, - quarterly strategic forum for investment and risk-appetite decisions.

Each forum should use a fixed intake template: decision needed, options, data, recommendation, risk, execution owner. That way meetings end in decisions, not another information-gathering loop.

Minimum Data Package for AI Decisions

One major source of conflict is lack of a common data standard. Define a "minimum package" below which decisions are not processed:

- business objective and value metric, - use case risk classification and stakeholder impact, - quality and operational test results, - total-cost view (implementation + run + risk), - owner recommendation plus rejected alternative.

This minimum improves transparency and reduces authority-based decisions unsupported by evidence.

Arbitration Mechanism for Value-Risk Conflicts

In mature organizations, conflict between business and control functions is normal. It becomes a problem only when no arbitration process exists.

An effective mechanism includes:

- bounded time window for both sides to present arguments, - one accountable person for final decision at the right level, - documented decision plus post-implementation monitoring conditions, - mandatory 30-60 day decision review.

This process reduces political tension and converts conflict into a manageable trade-off.

Executive Takeaway

What changed? At AI scale, formally assigned decision rights became critical because ad hoc no longer works as use cases, risk, and dependencies grow.

Why it matters? Without clear decision rights, organizations fall into chaos or paralysis, lose implementation speed, and increase incident and accountability-conflict risk.

What leaders should do? Implement DRIFT, map the seven key AI decisions, assign roles with veto where necessary, and monitor both decision speed and quality.