Who Owns the Stop Decision? A RACI for AI Pilots

RACI assigns four roles to a decision: Accountable (A) owns the outcome and there is exactly one per decision; Responsible (R) does the work; Consulted (C) gives input before the decision; Informed (I) hears about it after. Most RACI charts fail at the first letter, because a committee is listed as "A" and no single person can be held to the outcome. For stop authority, write a person's name, not a title alone.

The separation of A from R is the point. The pilot lead is the person closest to the system and should be able to execute an operational stop without a meeting. The business owner is the person who owns the consequences of continuing, and so owns the decision to end the pilot permanently. If the same person is both A and R, you have a pilot lead who can quietly keep a failing experiment alive, or kill one that a business unit still needs.

One chart for all stops confuses two different decisions with different clocks and different evidence.

An operational stop is triggered by something happening now: a data leak, an agent taking an unapproved action, unsafe output reaching a customer, or an outage caused by the integration. The response should be minutes, and the accountable owner validates the call afterward rather than authorizing it beforehand. The enterprise security literature is explicit that containment speed depends on predefined authority, because shared service accounts and embedded API tokens make improvised containment slow and uncertain (Ampcus Cyber). Pre-approved stop authority, exercised by the pilot lead and reviewed by the business owner, is how you get minutes instead of a meeting.

A governance stop is triggered by evidence arriving over weeks: the business metric is not moving, legal conditions cannot be met, or costs at production volume exceed the case. This is decided at a stage gate, with the business owner accountable and legal, security and finance consulted. A simple four-question framework does this well: what problem does it solve, what can you prove it delivers against what it costs, what would it take to scale, and who is driving it. Three weak answers means stop; strong value but weak preconditions means continue with a timeframe; strong on all four means scale up (Spark Academy). Note the fourth question: "who is driving it" has no strong answer unless a named owner exists.

Write both types into the chart with separate rows, separate clocks and separate triggers. A governance stop does not need an on-call number; an operational stop does not need a steering committee.

"Stop if quality is unacceptable" is not a rule. A rule names a measure, a threshold, and a comparison point. The readiness checklist used in pilot design already asks for exactly this under ownership and decision rights: people should know who approves changes, resolves issues and stops the test, and stop rules should be in place for the pilot (Alex Lieberman).

A useful pattern is: measure, threshold, window, comparator. For example, "if human correction time exceeds 50% of baseline task time for ten consecutive business days, the pilot lead executes an operational pause and the business owner is informed within one hour." The 50% figure is a red band in a published pilot scorecard, not a universal law, so calibrate it to your workflow (Wavect). What matters is that the number, the window and the person are written down together.

Include the restart condition in the same row. A stop with no restart path becomes a silent cancellation, and the people who built the pilot will resist pulling it.

The reason stop rules quietly rot is turnover. The named owner changes jobs, the pilot lead goes on leave, the sponsor moves to another division, and the rule now points at a person who cannot act. Design for this in advance.

First, name a role as well as a person, in that order: "Ana Ruiz, Director of Claims Operations, and in her absence the Claims Operations duty manager." Role-based delegation keeps the authority attached to the function rather than the individual. The team-staffing literature makes the same point about AI programs generally: the jobs that have to get done, Builder, Scaler and Operator, are roles, not job titles, and can be staffed internally, by a vendor or as a hybrid, but all three have to exist (Roboflow). Stop authority is one of those jobs.

Second, give the delegate a written limit. A common and defensible rule: the delegate may execute operational pauses and must escalate any restart or permanent stop decision to the accountable owner or their manager within one business day. That way an incident on a Friday night is handled, but the pilot cannot be killed by someone who was never accountable for its outcome.

Third, keep the list of names outside the pilot team's control. A short registry in the governance repository, with a review date, is enough. When the pilot lead checks the chart at a gate, a stale name is visible.

A claims operations team runs a pilot that drafts responses to first-line customer claims. The baseline is 18 minutes of handling time per claim across 240 claims a week. The pilot's success gate is a 15% reduction in average handling time with no rise in escalations, measured over four weeks of live traffic.

Before kickoff the team writes the RACI:

• Accountable: the Head of Claims Operations, who owns the service level and the headcount budget.
• Responsible: the pilot lead, a delivery manager who also holds the disable switch.
• Consulted: legal (regulated correspondence), the data steward (customer records), and the complaints process owner.
• Informed: the steering committee, finance, and the frontline team via their manager.

The stop rules are written as conditions. If average handling time does not fall by at least 5% of baseline by week four, the business owner decides at the gate whether to continue for a second four-week window or stop. If any draft response containing a figure reaches a customer without human approval, the pilot lead pauses the pilot immediately. If the projected cost per successful action at production volume exceeds the baseline cost per claim, finance's estimate goes into the gate pack as a consulted input, and the business owner decides.

Run the arithmetic before the gate. At the baseline, 240 claims a week at 18 minutes is 72 hours of work. A 15% reduction is 10.8 hours a week, roughly 1.35 working days. If the pilot has consumed two engineer-months and the projected saving is 10.8 hours a week for the eight weeks remaining in the pilot window, the case at the gate is thin on pure labor, and it has to be argued on customer response time or consistency instead. Writing that down in advance stops the gate from becoming a debate about enthusiasm.

Cost per successful action deserves its own line, because price lists hide most of the bill. The right unit is expected cost per completed task, which is cost per attempt divided by the success rate, plus the cost of cleaning up wrong outputs that escape automated checks (DoiT). A cheaper model that needs more retries and more human review is not cheaper. Put that number in the gate pack, with its source.

If the team needs to pull model spend or usage data from a pilot to fill the cost row, a single API key across text, image and other models makes the ledger simpler, which is what Quanta Inference is built for.

A RACI chart is a document until someone reads it under pressure. Run a tabletop exercise every quarter, with the chart in front of the participants.

1. Pick a scenario from the trigger table, for example a draft response with an incorrect figure reaching a customer.
2. Ask the person on call, not the pilot lead, to say out loud what they would do first, second and third.
3. Time how long it takes them to find the named owner, the delegate and the restart condition in the chart.
4. Check whether the consulted parties had a time bound; an open legal review is a blocked stop, not a consulted input.
5. Record the gaps and fix the chart, not the people.

Incident response practice supports a version of this: replay closed incidents and compare the produced timeline and recommendation against what the team actually did, then run it in advisory mode on live incidents before granting execution authority (Sweet Security). For pilot governance the equivalent is walking a stop scenario before a real one hits.

The exercise also catches the structural problem. If the on-call person cannot act without a committee, the chart has the wrong A. If the delegate cannot be found because they left the company, the registry is stale. If the restart condition is blank, the stop will be treated as a cancellation and quietly ignored.

A reorganization is the main event that breaks stop rules, because it reassigns the people the chart names and often the business unit that owns the outcome. Add a revalidation step to the same process that approves the new structure: within two weeks of a reorganization, the pilot lead confirms that the accountable name, the delegate, the consulted reviewers and the informed list are still correct, and that the gate date has not moved.

The same applies to vendor and platform changes. If the pilot moves to a different inference provider or a different orchestration layer, the disable mechanism changes with it, and the person responsible for executing an operational stop needs to know the new mechanism. Treat that as a change that requires a fresh tabletop exercise, not a footnote.

One practical shortcut: express the chart as data, not as a slide. A small file in the repository can be checked automatically for blank delegates and past review dates.

pilot: claims-drafting
accountable:
  name: Ana Ruiz
  role: Head of Claims Operations
  delegate: claims-ops-duty-manager
operational_stop:
  responsible: pilot-lead
  triggers:
    - id: unapproved_figure
      condition: draft with a figure reaches customer without human approval
      clock: immediate
  restart_requires: accountable
governance_gate:
  date: end of week 4
  consulted: [legal, data-steward, finance]
  stop_if: handling_time_reduction_below_5_percent_of_baseline
review_due: after any reorganization or platform change

That file is auditable, survives job changes better than a slide, and can be read by anyone who picks up the phone during an incident.

If the organization would rather have a specialist own the design of stop rules and stage gates for a line of business, that is the kind of work Quanta Experts is set up for: experts that read your context and hand back finished deliverables. A free discovery call with Quanta Consulting is the lighter option when the chart needs a second pair of eyes before the next gate.