Accountability: Who Picks Up the Phone When the AI Is Wrong
A nonprofit board chair called me the morning after their AI fundraising tool sent 18,000 donors an appeal letter referencing the wrong campaign. The ask amount was correct. The campaign description was for a program that had been retired in 2024. Three donors had already replied. One was a major gift prospect.
The board chair had one question: "Who do we call?"
The IT director was on the phone too. He said: "The vendor."
The development director joined. She said: "The platform admin."
The platform admin joined. He said: "The vendor's tier-1 support, but they only respond Monday through Friday during business hours and today is Saturday."
The board chair waited for one of them to take responsibility. Nobody did.
I have replayed that conversation a dozen times in client engagements since. The question is always the same. The answer is almost never ready.
This is what the fourth guiding principle of the CCC AI Center of Excellence addresses.
The Principle
Accountability. Every AI deployment has a named human owner responsible for outcomes. AI does not make consequential decisions without human authorization.
That sentence sounds obvious. It is the most violated principle in real AI deployments I review.
Most AI governance documents talk about accountability in passive voice. "Decisions will be reviewed." "Outcomes will be monitored." "Issues will be escalated." None of that survives a Saturday morning incident. The board chair does not need a passive-voice policy. The board chair needs a name and a phone number.
What "Named Owner" Actually Means
In CCC engagements, accountability is not a sentence in the policy document. It is a row in a table. Every AI deployment produces a one-page Accountability Map before it goes live.
The map answers four questions:
- Who owns the deployment?
- Who reviews the deployment's outputs?
- Who has authority to halt the deployment?
- Who picks up the phone when something goes wrong?
The four answers can be the same person. They cannot be empty. They cannot be "the team." They cannot be "the vendor." They must be a name with a job title and contact information.
The named owner has three responsibilities:
- Authorization. Before any consequential AI action runs in production, the named owner has signed off in writing.
- Review. The named owner reviews exception reports on a documented cadence: daily for high-risk, weekly for medium-risk, monthly for low-risk.
- Response. When something goes wrong, the named owner is the first call.
If the named owner cannot do all three, the deployment does not run.
The Named-Owner Test
Before any CCC engagement deploys AI in a client environment, we run a five-question test. If any answer is unclear, the deployment is not ready.
- If the AI takes a wrong action at 2 a.m., who is paged?
- If a regulator asks who authorized this AI feature, who responds and what document do they show?
- If a customer reports an AI error, who has the authority to halt the system within 15 minutes?
- If the named owner is on vacation, who is the documented backup?
- If the named owner leaves the organization, what is the handoff procedure?
Three out of five is not good enough. All five must have answers in writing before launch.
Where Accountability Disappears
Three patterns show up in the field where ownership goes missing.
The first: vendor accountability. The organization assumes the vendor owns the deployment. The vendor's contract says they own the platform. Platform ownership and deployment accountability are different things. The vendor does not own how the AI is used in your environment. You do.
The second: consultant accountability. The organization assumes the consultant who built the deployment owns it after launch. Most consulting agreements end at go-live. Accountability does not. If your governance plan requires the consultant to be on call and the contract does not, you have a gap.
The third: committee accountability. The organization stands up an "AI Steering Committee" and assigns ownership to the committee. Committees do not pick up phones. Individuals do. A committee can review. A committee can advise. A committee cannot own a Saturday morning incident.
The Authorization Gate
The second half of the principle deserves its own treatment: "AI does not make consequential decisions without human authorization."
This is where most deployments cut corners. The AI is given the keys and told to drive. Then the first incident happens and the post-mortem reveals that no human ever signed off on the specific action the AI took.
A consequential decision is any decision that affects revenue, customer experience, regulatory compliance, or safety. In a Salesforce environment, this includes creating or modifying customer records, sending external communications, processing financial transactions, escalating to legal review, and modifying compliance flags.
For each consequential decision class, the deployment must specify whether human authorization is required at the action level (every action), the batch level (groups of actions reviewed together), or the policy level (a documented policy authorizes a class of actions in advance).
Action-level for high-risk. Batch-level for medium-risk. Policy-level only for actions where the documented policy is rigorous enough to satisfy a regulator's review without further evidence.
If the deployment does not specify which authorization level applies to which action class, accountability is not real. It is paperwork.
What This Looks Like in Practice
For a nonprofit Agentforce deployment, the Accountability Map for a fundraising agent might read:
| Action | Authorization Level | Owner |
|---|---|---|
| Read donor records | Policy-level (documented in Privacy Policy) | Development Director |
| Draft donor email | Policy-level (with mandatory human review before send) | Development Director |
| Send donor email | Action-level (per email, until 30-day audit clears) | Development Director |
| Modify donor record | Action-level (always) | Database Administrator |
| Process gift | Action-level (always) | Finance Director |
Five rows. It took 20 minutes to write. It is more accountability than most AI deployments have.
The deployment ran for six months without an incident. When the first incident did happen (a duplicate donor email), the development director's name was on the document. She picked up the phone. She halted the agent. She filed the incident report. She was back online in 90 minutes.
That is what accountability looks like when it is real.
The Cost of Unowned AI
Unowned AI is not free AI. It is deferred-cost AI.
The cost shows up in three places.
The first: incident response time. Without a named owner, the first 30 minutes of every incident are spent figuring out who is responsible. Those 30 minutes are when most of the damage compounds.
The second: regulatory exposure. OMB M-25-21 explicitly requires named ownership for federal AI deployments. EU AI Act's high-risk categories require documented oversight roles. HIPAA's 2025 AI guidance requires named accountability for AI processing protected health information. "We are still working out who owns it" is not a defense.
The third: organizational learning. AI deployments without named owners do not generate institutional memory. The same mistakes recur since nobody is responsible for documenting them. The same questions surface in every audit since nobody owns the answers.
What's Next
The next article in this series covers Proportionality. Not every AI decision needs a committee. The trick is knowing which decisions need lighter governance and which decisions need heavier governance, and writing that distinction into your deployment plan before you find out the hard way.
Until then: if you have an AI deployment in production and you are not sure who picks up the phone when something goes wrong, the AI Readiness Scorecard is the right starting point. The Accountability questions live in the Governance Readiness section.
