Data governance for AI. The prerequisite everyone skips.

Four data layers, four failure modes.

When we walk a leadership team through the data governance work that AI requires, we usually start by naming the four layers we have to govern together. The first is the source systems, the operational and analytical platforms that hold the canonical record of customers, transactions, content and operations. The second is the feature store or curated layer where data is transformed for use by models and agents. The third is the retrieval index, the vector store or search system that the agent reaches into at inference time. The fourth is the output trail, the log of what the agent produced, when, for whom and on what context.

Each layer has its own governance failure mode, and most enterprises we work with have governance that covers one or two of the four. Source systems usually have access controls and an audit trail because the finance and audit functions have demanded them for years. Feature stores tend to be governed informally by the data team. Retrieval indexes are often new enough that they have no controls at all. Output trails exist in fragmented form across logging tools that were never designed to support an audit conversation.

The conversation that produces real progress is the one that names all four layers explicitly, assigns an owner to each, and accepts that the governance work is not a single project but a small portfolio with four parallel streams.

The governance gaps we keep seeing.

Four specific gaps come up in almost every assessment we run. The first is unowned access controls in the retrieval index. The vector store contains chunks of source documents, but the access control logic on the original document is not always carried through to the chunk. An employee who could not have read the original PDF can sometimes ask the agent a question and receive a chunk of its contents in the answer.

The second is PII handling that is documented in a policy but not enforced in the runtime. The data team has a stated rule about masking customer identifiers before they reach the model context window. The actual codepath that constructs the context sometimes bypasses the masking when a developer is in a hurry. The gap between the policy and the runtime is where the regulator's question lands.

The third is broken lineage. When the regulator or the internal auditor asks how a specific output was produced, the team can usually answer for the model and the prompt, but not for the upstream transformation that produced the feature that influenced the answer. The lineage chain breaks somewhere between the source system and the retrieval index, and the recovery work is forensic rather than systematic.

The fourth is inconsistent retention. The source data has a retention rule. The feature store has a different one. The retrieval index often has no rule at all, and the output trail is sometimes retained forever for debugging reasons. A regulator asking for the right to be forgotten cannot be answered cleanly when the retention policies do not agree across the four layers.

A pragmatic baseline before the first agent ships.

The version of this baseline that works tends to be short and concrete. We name a canonical source for each data domain the agent will use. We document and enforce access controls at the retrieval index, mirroring the source system rules. We mask or tokenise PII before the model sees it, with the masking enforced by a shared library rather than developer discipline. We instrument lineage from source through to output trail so that any answer the agent produces can be traced back to its inputs. We agree a retention rule that holds across all four layers and is honoured by the deletion pipeline.

None of these moves require new technology in most cases. They require the data team and the AI engineering team to agree on a shared runtime, with shared libraries and shared logs. The conversation tends to take longer than the implementation, and the conversation is the work that compounds.

The teams we work with who have done this baseline well report that the second and third agent they ship cost far less, because the governance plumbing is already in place. The teams who skip the baseline report that every new agent re-opens the same fights, and the fights get harder as the audit pressure builds.

How to phase governance without freezing the pipeline.

The mistake we see most often when an organisation tries to take governance seriously is to declare a full programme that has to complete before any new AI work can ship. The pipeline freezes, the political support for governance erodes, and the next agent ships eighteen months later in a tactical bypass that undoes the original intent.

The phasing that works is the one that ties governance to the first three or four real use cases. For each use case, the team builds the governance baseline that the use case actually needs, contributes the reusable parts to the shared platform, and ships. After three or four cycles, the platform carries enough of the baseline that new use cases inherit most of what they need rather than re-building.

The advantage of this phasing is that governance work is visibly tied to delivered value. The disadvantage is that it requires discipline from the data and engineering teams to actually contribute to the platform rather than ship and move on. That discipline is, in our experience, the single biggest predictor of whether the governance baseline matures over time or stays at one.

Governance as a feature, not a brake.

The framing that has worked best with the leadership teams we advise is to treat governance as a feature of the AI programme rather than a tax on it. A well-governed AI stack is faster to extend, easier to defend in front of a regulator, and far cheaper to operate at scale than the alternative. The teams we have seen reach that state describe the same shift in conversation: the question of whether a new agent can ship moves from a debate about risk to a check against a shared runtime, and the debate moves to where it should have been from the start, which is the value of the use case.

If your organisation is preparing to ship its first or second agent, the practical move we recommend is to name the four data layers, assign an owner to each, and produce the one-page baseline that says what is in place for each. The first time the conversation has been had explicitly is almost always the moment the gaps become visible and the next quarter of work becomes obvious.

The Consulting and Tech Factory teams in our Paris, Dubai, Singapore and Bali offices are reachable from the brief form below. We answer within one working day, with a partner who will sit on the file.