RACI for Data: Who's Accountable When Something Breaks

Opening Scene

A town bridge collapses in the night, and by morning the builder blames the stonemason, the stonemason blames the inspector, and the inspector insists his job was only to check the plans, not the finished work — a chaos of finger-pointing that could have been avoided entirely if someone, before the first stone was laid, had written down exactly who was responsible, who merely consulted, and who simply needed to be informed.

In Plain English

A RACI chart — Responsible, Accountable, Consulted, Informed — assigns exactly one of these four roles to every person or team touching a given piece of data or process, so that when something breaks, there’s no ambiguity about who fixes it, who’s ultimately answerable, who should have had input, and who just needs to know. Data RACI charts apply this same discipline to governance activities like defining a metric, approving a schema change, or granting access.

The Old Way

Before accountability was mapped in advance:

Data incidents triggered informal, ad hoc investigations to figure out who was even responsible, wasting time that should have gone to the actual fix.
Multiple people believed themselves “accountable” for the same dataset, leading to duplicated or conflicting fixes applied independently.
Some critical data processes had no accountable owner at all, discovered only when something broke and nobody stepped forward.

Mapping accountability before an incident, rather than reconstructing it during one, is the entire point of a data RACI chart.

What’s Changing (and Why AI Is the Reason)

Organizations increasingly build RACI charts directly into their data catalog entries, so accountability is visible at the moment someone is looking at the data, not buried in a separate document.
This connects to this content library’s dedicated access control and data security series, since access-granting decisions are one of the clearest cases where Responsible and Accountable roles genuinely need to be different people.
AI pipelines add new roles to govern — who’s accountable for a model’s training data, who’s responsible for monitoring drift — extending the same RACI discipline into territory that didn’t exist when most existing charts were first drawn up.

The Metaphor, Fully Extended

The Collapsed Bridge Investigation	The Data Incident Investigation
Builder, stonemason, and inspector blaming each other	Multiple teams claiming or denying data ownership
No record made before construction of who did what	No RACI chart in place before the incident
A single master builder, accountable and named up front	A single accountable data owner, defined up front
Consulted engineers and informed town officials, distinct roles	Consulted stewards and informed stakeholders, distinct roles

For Beginners: What to Actually Do

Learn to distinguish the four RACI roles clearly: only one person should ever be Accountable for a given item, even if several are Responsible for pieces of it.
Check whether the datasets you work with daily have a documented RACI, and ask who to contact if they don’t.
Practice naming your own role precisely — are you actually Responsible for a task, or just Consulted on it?

For Practitioners and Leaders: The Deeper Layer

Build data RACI charts directly into the catalog or governance tooling so they’re visible in context, not filed away separately.
Audit RACI charts after every significant incident to check whether the assigned roles matched what actually happened.
Extend RACI discipline explicitly to AI pipeline stages, including training data selection and model monitoring, rather than assuming existing charts already cover it.

Quick Recap

RACI charts assign exactly one Accountable party and clear Responsible, Consulted, and Informed roles to data processes.
Ambiguous accountability turns every incident into a time-consuming investigation.
RACI charts work best when embedded in the tools people actually use daily.
AI pipelines introduce new roles that need the same explicit accountability treatment.

Where This Fits in the Series

Article 8 covered getting everyone to agree on what data terms mean. Article 9 covered getting everyone to agree on who’s accountable when something built on those terms breaks. Article 10 pulls back to a bigger question both of these feed into: how do you actually measure how mature an organization’s governance is overall?