Roles & Decision Rights

When AI delivery speeds up—and accountability disappears

A company rolls out three AI features in one quarter: a churn model, a support copilot, and an automated invoice matcher. Each team ships fast. Then a production incident hits: the copilot starts leaking sensitive snippets into summaries, and customer complaints trend upward. The immediate questions sound simple—“Who approved this?” “Who turns it off?” “Who fixes the prompt?”—but they expose something deeper: the organisation shipped capability without agreeing on decision rights.

This is why roles and decision rights matter now. AI systems change frequently (data drifts, models get swapped, prompts get edited), and risks span privacy, security, bias, reliability, and vendor exposure. Without clear ownership, organisations end up with either “everyone can ship” (fast but unsafe) or “a committee must approve everything” (safe but slow). The goal is neither extreme; it’s clarity that enables speed.

In this lesson, you’ll map the essential AI roles and define who decides what across the AI lifecycle—so your operating model pattern (centralised, federated, embedded, platform-led, or hybrid) can actually work in practice.

The vocabulary that prevents governance-by-meeting

Roles are the accountable positions involved in AI work (often played by teams, not individuals). Decision rights define who has the authority to make a specific call (approve, reject, select, escalate), and under what conditions. Accountability means a named owner is answerable for outcomes; responsibility means someone does the work. When these blur, you get “shadow decisions” (made informally) and “orphaned work” (no operational owner).

A practical way to ground this is to tie decision rights to the AI lifecycle “moments” that must produce evidence: approving data access, validating data quality, evaluating performance and safety, approving deployment, monitoring drift, and managing incidents. In the previous lesson, governance was framed as guardrails that scale with risk, not a one-size-fits-all review committee. Roles and decision rights are the mechanism that makes those guardrails enforceable without turning into bureaucracy.

A useful analogy is a city with building codes. Builders can build quickly because the codes are clear, inspections are predictable, and utilities are standardised. In AI, platform defaults (logging, evaluation templates, change tracking) help, but they don’t replace decision rights. Somebody still needs the authority to say “this is acceptable risk,” “this is the approved vendor,” or “roll back now.”

Two principles keep this from becoming paperwork. First: the decision should be made by the party closest to the impact, unless enterprise risk forces centralisation. Second: the decision should be made once and reused—through standards, paved roads, and pre-approved patterns—rather than re-litigated for every use case.

The four decision layers every AI-driven organisation needs

1) Business value decisions: what gets built, and what “good” means

Value decisions answer: Which use cases do we fund, what outcomes matter, and when do we stop? These decisions fail most often because AI work is treated as a technical project rather than an operating change. A technically strong model can still fail if frontline workflows don’t adopt it, or if incentives punish its use. Decision rights here prevent “AI theatre”—shipping impressive pilots that never become durable capabilities.

At intermediate maturity, the key best practice is to separate strategy choices from delivery choices. Strategy choices set the portfolio: which domains (support, marketing, risk, operations) and which categories (automation, augmentation, prediction) are in scope, plus the organisation’s risk stance. Delivery choices belong to product and delivery teams: how to design the feature, how to A/B test, how to stage rollout, and how to measure adoption and business impact. When these get mixed, executives either micromanage model details or teams assume “value” will be judged later, after launch.

Common pitfalls show up in prioritisation. If there is no clear decision owner for “what do we build next?”, demand floods the AI function and prioritisation becomes political. If OKRs focus on model metrics (accuracy) rather than business metrics (reduced churn, lower handle time, fewer defects), teams optimise the wrong thing. A misconception to correct: business owners don’t need to understand every AI technique, but they must own the definition of success, the operational change, and the tolerance for failure modes.

A simple, scalable rule is: business value decisions should sit with a product/business owner accountable for outcomes, informed by AI and risk specialists. This aligns with the earlier operating model idea that adoption ownership cannot be “dumped” on a central team. The more embedded your operating model, the more these decisions live in the domain; the more centralised you are, the more you need explicit agreements to ensure adoption and operations are owned outside the CoE.

2) Technical decisions: how it’s built, run, and changed safely

Technical decisions include architecture, toolchains, evaluation methods, and operational readiness: What model approach do we use? How do we deploy? What do we log? What triggers retraining or rollback? In the previous lesson, a recurring failure mode across patterns was inconsistency—duplicated pipelines, incompatible tools, uneven monitoring. Decision rights are where you convert “standards” from a document into reality.

Best practice is to distinguish between guardrails (non-negotiables) and design freedom (team-level choice). Guardrails include things like approved deployment patterns, minimum logging and monitoring, incident response procedures, and mandatory artifacts such as model cards, evaluation reports, and change logs. Within those guardrails, teams can choose model types, feature engineering strategies, prompt designs, and UX. This is how federated and embedded models avoid fragmentation without reverting to central bottlenecks.

A technical misconception that causes real harm is thinking “if it runs, it’s done.” AI systems are live: data shifts, user behavior adapts, third-party model behavior changes, and prompt edits can alter outputs dramatically. So the operational decision rights (“who can change a prompt in production?”, “who approves a model version bump?”, “who owns monitoring dashboards and the on-call rotation?”) are not secondary—they’re central. Without them, you get silent changes and delayed detection, especially in GenAI where small tweaks can have outsized effects.

A common pitfall is creating a platform team or central architecture function that becomes “the team that says no.” The fix is to make technical decision rights explicit: platform/architecture owns the paved roads and non-negotiables; delivery teams own implementation decisions inside that paved road; and exceptions follow a defined escalation path with time-bound approvals. This mirrors the earlier idea that good governance enables speed by making decisions predictable and reusable.

3) Risk decisions: who sets the rules, and who signs off on exceptions

Risk decisions answer: Is this acceptable to deploy given privacy, security, bias, reliability, and regulatory exposure? The previous lesson emphasized tiered governance: not every use case deserves the same gates. Decision rights are how you implement those tiers without “one committee for everything.”

Best practice is to separate risk policy from risk execution. Risk policy defines the organisation’s tolerance and minimum controls (e.g., logging requirements, data handling rules, third-party model constraints, red-teaming expectations, documentation standards). Risk execution is the application: the actual evaluation, evidence collection, and sign-off for a specific system at a specific risk tier. When policy and execution are mixed, risk teams either become overloaded reviewers or disconnected authors of policies that teams ignore.

A frequent pitfall is unclear accountability during incidents. If a model harms customers, the organisation needs one owner with authority to trigger containment (disable feature, roll back version, block a vendor endpoint) and one owner accountable for post-incident remediation (new evals, changed prompts, retraining, improved monitoring). Without decision rights, incidents become a blame loop between product, data, security, and legal. The misconception to fix: risk teams do not “own” risk alone. They set and assure controls, but the business and product owners remain accountable for deploying a system into real operations.

Risk decision rights should also explicitly cover third-party services—especially common in GenAI. Procurement can negotiate contracts, but someone must decide: Which vendors are approved? What data can be sent? What auditing evidence is required? What happens when the vendor model changes behavior? Treating vendor AI as “just a tool purchase” is a classic route to late legal surprises and uncontrolled exposure.

4) Data decisions: who grants access, defines meaning, and enforces quality

Data decisions are often the hidden reason AI stalls at scale: definitions differ across units, access is slow or inconsistent, and model results can’t be trusted. Decision rights here cover data access approvals, data contracts, lineage, and who resolves disputes about “what is the correct metric.” In the previous lesson, these showed up as duplicated tooling and inconsistent definitions—symptoms of missing ownership.

Best practice is to split data decision rights into three layers: meaning, access, and quality. Meaning is semantic governance—what “churn,” “active customer,” or “fraud” actually means. Access is the security and privacy layer—who can use which data for which purpose under which controls. Quality is operational—who fixes broken pipelines, missing fields, and schema changes. When one group tries to own all three, they become a bottleneck; when nobody owns them, teams create local definitions and “shortcut datasets,” which fracture comparability and increase risk.

A common pitfall is treating data access as a one-time approval. For AI, the question isn’t only “can you access it?” but “can you continue to access it safely as the model evolves?” If a feature requires new data sources later, decision rights must define whether that is a material change requiring renewed approval and evaluation. This matters in both classic ML (new features) and GenAI (new retrieval sources, new tools, new grounding corpora).

Misconception to correct: “Data ownership” does not mean “data hoarding.” Strong decision rights enable safe self-serve: clear data contracts, standard pipelines, and predictable approvals. That is the “paved road” idea applied to data—teams move faster because they don’t renegotiate access and definitions from scratch for every project.

A decision-rights map you can actually use

The table below is a practical, lifecycle-based view: what decisions exist, and which roles commonly hold them. Titles vary by company; focus on the function.

Lifecycle decision	What gets decided	Typical decision owner (decision right)	Key contributors (must be consulted)	Evidence/artifacts that make it auditable
Use case selection & funding	Priority, budget, success metrics, kill criteria	Business/Product owner (portfolio lead in some orgs)	AI lead, Finance, Ops leaders, Risk lead (for high-risk domains)	Business case, KPI definition, adoption plan
Data access approval	Purpose limitation, allowed fields, retention, sharing	Data owner + Security/Privacy (joint)	Product owner, AI/DS lead, Legal/Compliance	Access request, data classification, lineage, DPAs where needed
Model/prompt approach	Architecture choice, retrieval strategy, feature set, prompt patterns	Delivery tech lead / ML lead	Platform/Architecture, Security (for threat model), Risk (tier-based)	Design doc, threat model notes, eval plan
Evaluation readiness	What “good enough” means for performance + safety	Product owner + Risk owner (tier-based)	ML/DS, QA, Domain SMEs, Security/Privacy	Evaluation report, known failure modes, model card/prompt card
Deployment approval	Can it go live, rollout plan, guardrails, human fallback	Release authority (varies: product + platform; or CoE)	SRE/IT Ops, Security, Risk/Compliance	Change record, monitoring plan, rollback plan, sign-off log
Monitoring & incident response	Alerts, thresholds, who is on-call, escalation path	Service owner (often product/engineering)	Platform/SRE, Risk, Security	Dashboard, runbooks, incident tickets, postmortems
Material change control	What changes require re-evaluation (model version, prompt, data source)	Service owner + Risk owner (for high-risk tiers)	Platform, Security/Privacy	Change log, re-eval results, updated documentation
Retirement	When to sunset, archive, access removal	Product owner	Data owner, Platform/SRE, Risk/Compliance	Decommission plan, archival record, access revocation proof

A key pattern to notice: decision rights often split by tier. Low-risk internal copilots may allow product teams to approve within guardrails, while high-impact decisions (credit, safety-critical operations) require explicit risk sign-off and stricter change control. This is how you keep governance enabling rather than blocking.

Where organisations get decision rights wrong (and how to fix it)

Three failure modes show up repeatedly across operating model patterns. First is the “committee default.” When roles aren’t clear, organisations create a review board for everything. It feels safe, but it becomes a queue; teams learn to bypass it, and reviews become superficial. The fix is to move from “single gate” to tiered gates with clear owners, plus automated evidence capture where possible.

Second is “central builds, local suffers.” A central CoE or platform team ships a model, but product teams don’t own adoption, monitoring, and incident response. This is how you end up with models in production that aren’t used—or worse, are used without anyone watching them. The fix is explicit: the receiving domain must have a service owner with operational responsibility, and the build team must hand over with documented runbooks, monitoring, and change control.

Third is “autonomy without standards.” In embedded or loosely federated models, teams optimise locally. Tool sprawl grows, evaluation metrics diverge, and risk controls become uneven. The fix is to set non-negotiables (logging, evaluation minimums, incident process, approved vendors/data patterns) and make the compliant path the easiest path through platform defaults and templates.

[[flowchart-placeholder]]

Applied example 1: Retail bank support copilot (federated delivery, high risk)

A retail bank launches a GenAI assistant for contact-center agents: summarising calls, drafting responses, and recommending next-best actions. The operating model fit is federated with strong central governance enablement, but success depends on decision rights. The bank first sets non-negotiables centrally: approved model providers, redaction rules, logging requirements, and a standard evaluation suite (groundedness, toxicity, privacy leakage checks). Crucially, the central function has explicit decision rights over vendor approval and minimum controls, so teams don’t negotiate these repeatedly.

Then the contact-center “spoke” team owns the product: agent workflow integration, UI, and adoption metrics like average handle time and escalation rate. Decision rights make this real: the product owner decides rollout pacing and defines “good,” while the risk owner decides which failure modes are unacceptable (e.g., hallucinated financial advice) and what human fallback is mandatory. The delivery tech lead decides the retrieval strategy and prompt approach, but only within guardrails (e.g., no sending unredacted PII to external endpoints).

When a prompt update is proposed to improve tone, change control matters. The bank defines “material changes” up front: prompt edits that affect advice language require re-evaluation and risk sign-off; cosmetic formatting changes do not. The impact is speed with control: the spoke can iterate weekly, while monitoring and incident escalation are consistent enterprise-wide. The limitation is coordination overhead; the bank mitigates it by making the evidence artifacts (eval report, change log, model/prompt card) lightweight and partially automated via shared templates.

Applied example 2: Manufacturer predictive maintenance across 40 plants (platform + federation)

A manufacturer deploys predictive maintenance models across 40 plants with uneven data maturity. Here, decision rights must prevent both extremes: a central bottleneck that can’t scale, and local autonomy that creates incompatible pipelines. The organisation sets up an AI platform team that owns the “paved road”: standard ingestion, feature frameworks, serving patterns, and monitoring defaults. The platform team holds decision rights for the non-negotiables—logging format, model registry usage, and deployment standards—so performance and incidents can be compared across sites.

Regional analytics teams (spokes) then tailor models to local equipment and failure patterns. They have decision rights over feature choices and model selection, but they must meet minimum evidence requirements before deployment: data quality thresholds, evaluation results, and a rollback plan. Data decision rights are split intentionally: local plant data owners approve specific operational datasets; enterprise security sets access rules; and a data governance function resolves semantic disputes so “failure event” means the same thing across plants.

When one plant’s sensor feed becomes unstable, monitoring triggers an incident. The service owner (often in the regional team) has authority to degrade gracefully—switch to conservative thresholds or disable automated scheduling suggestions—while the platform team supports with standardized telemetry and incident tooling. The benefit is leverage: build once, reuse many; and leadership gets comparable metrics. The limitation is adoption risk: if the platform is hard to use, plants bypass it. The decision-right fix is explicit exception handling: teams can deviate only with documented rationale and time-bound remediation, preventing permanent fragmentation.

The takeaway: clarity is how you scale without freezing

Roles and decision rights turn AI governance from aspiration into execution. When you know who decides on value, tech, risk, and data—and what evidence they need—you reduce duplication, shorten approval cycles, and handle incidents decisively.

Key takeaways:

• Separate decision layers: business value, technical design/operations, risk policy/execution, and data meaning/access/quality.

• Make guardrails non-negotiable and reusable, and leave freedom inside them to avoid bottlenecks.

• Tie decision rights to lifecycle moments (access, evaluation, deploy, monitor, change, retire) so governance becomes operational.

• Define “material change” up front, especially for GenAI prompts, retrieval sources, and vendor model updates.

Now that the foundation is in place, we'll move into Ways of Working (Product/Platform/Squads) [25 minutes].