Privacy, data, and AI governance are being managed as separate programs long after the risk stopped behaving that way.
Most organisations now have a privacy program, a data governance program, and (more recently) an AI governance program. The structures usually evolved separately, sit in different parts of the business, and report on different clocks. That made sense when the three risks had different shapes. It is harder to defend now, because the work each program governs has converged, and the operating model around them mostly hasn’t.
Privacy outcomes depend on lineage, retention, access, lawful purpose and escalation pathways. AI governance depends on the same controls, with added pressure around decision design, model oversight and post-deployment accountability. Data governance determines whether the organisation can actually explain what data it holds, where it came from, how it is used, and which decisions rely on it. The three programs are governing different views of the same data and the same decisions.
Three separate programs sitting over the same data and the same decisions produce something that often gets reported to the board as governance. When the board receives three updates with three separate dashboards and three teams maintaining different frameworks, this becomes a coordination risk dressed up as oversight. In reality, the exposure is one exposure divided into smaller reports.
Consider a demerger. The board asks a single question: what are the privacy obligations once the demerger goes through? The program reporting on the demerger covers data migration risks but treats privacy as someone else’s section, so the privacy answer is routed through the compliance paper instead. With no one inside the program carrying the privacy question through, the next-most-likely path is the General Counsel returning it as a legal interpretation, instead of whoever is working through the operational consequences. The answer ends up in the wrong paper, in the wrong register, disconnected from the data migration work it should be sitting alongside.
The Programs Were Built Around Where They Reported
The separation usually persists because of where each program landed in the first place. Privacy is often in legal. Data governance sits in technology, transformation, or a central data function. AI governance ends up wherever the AI conversation is loudest, whether that is risk, innovation, an executive sponsor, or a newly stood-up committee.
Each placement is defensible in isolation. Most consequential decisions now cut across all three, which is when the problem shows up. Privacy asks notice, lawful basis and customer-interaction questions; data asks lineage, quality and ownership questions; the model team asks validation, performance and fairness questions. Each set is competent inside its remit, and none of them is the question the decision actually turns on: whether the organisation should make this decision in this way, on this data, with these controls, for this duration, and under whose ongoing accountability.
The same pattern shows up in incident response. A breach, a model failure, or an unauthorised use of data rarely stays inside one risk category for long; cyber, privacy, data governance, customer harm, and sometimes AI governance all become relevant inside the first 48 hours. The board often receives those dimensions through separate streams, has to infer the dependencies, and ends up making decisions on a picture the organisation never actually assembled (which is not the same thing as the organisation hiding something; it is the operating model genuinely not having a place for that picture to be drawn).
Adding An AI Committee Does Not Fix Coordination Risk
The intuitive response is to stand up a fourth thing: an AI governance committee. That can help. It can also recreate the same problem one layer up, because the work of integration is structural, not procedural.
Most material AI questions are extensions of existing governance questions. What data is being used? Under what authority? With what quality controls? For which decisions? Under whose accountability? With what escalation when outcomes deviate? A committee that meets monthly to review use cases will improve visibility. It won’t change where the decisions are actually being made, what evidence is required before they are made, or who has authority to slow them down. If those things sit outside the committee, the committee is reporting on decisions, not governing them.
Integrated governance has to be built into how decisions are made, not added as another forum that meets to review them. The question is not “where do we coordinate” but “where is accountability designed to land when a decision is shared across privacy, data and AI.” Shared risk taxonomy, common intake and assessment pathways, and decision rights that operate across the three domains are the work. So is a reporting model that lets management and the board see one risk picture instead of three adjacent updates that have to be mentally stitched together.
This kind of redesign is harder to commission than a committee, because it doesn’t produce something leadership can point to in the short term. The results arrive months later, in decisions being made faster, more consistently, and with clearer accountability, by people who didn’t previously have to assemble five frameworks to act.
Across multiple organisations, I have watched consultants propose an AI council as part of their AI framework or project proposal, presented as something they will deliver without genuine consideration of the organisation’s existing governance or what is already in place. The board pushes back with feedback along the lines of “this looks like death by committee”. The consultants respond with a rationale that reveals the proposal was templated rather than tailored, and the same model gets proposed at the next organisation.
What Happens When One Decision Crosses All Three
Boards and executives can spend a long time evaluating whether each individual program is performing, and miss the question the operating model is actually failing to answer. The useful test is whether the organisation can take a single consequential decision that involves personal data, a model and a business outcome, and identify who owns the risk across all three domains, what evidence they need, and where the decision finally rests. That is a different question from whether each program is performing in isolation, and most operating models can’t answer it without assembling three teams after the fact.
If that answer takes more than one conversation to put together, the governance model is lagging the way the risk now behaves. The cost shows up in slower decisions, inconsistent advice to the business, duplicated assurance work, and a board view of risk that mirrors the organisation chart rather than the exposure. By the time those costs become visible, usually through an incident, a regulator question, or a senior executive asking the cross-domain question and getting three half-answers, the design choices that created the gap are already embedded in years of investment.
There are early signs that boards are pushing back when consultants propose another committee, recognising that they shouldn’t reinvent the wheel when existing governance functions could carry the work. That instinct is correct as far as it goes, but the harder leap (seeing privacy, data and AI as one governance question rather than three adjacent ones) hasn’t yet happened in most rooms. The boards that get there before the incident usually do it because someone insisted on asking how a single decision touching all three would actually be answered, and kept asking it until the operating model had to change.