There is a familiar pattern in enterprise AI. A prototype built in a fortnight is genuinely impressive. Eighteen months later it has not reached production, and the reasons have almost nothing to do with the model.

They have to do with data: where it came from, who is allowed to see it, whether it is correct, and whether anyone can prove any of that after the fact.

The demo problem

A prototype runs on a convenient extract. Someone exported the relevant tables, cleaned them by hand, and worked with a static snapshot. Every hard problem was quietly deferred.

Production reverses each of those conveniences. Data arrives continuously and inconsistently. Access is restricted per user, and those restrictions are the point. Records are corrected retrospectively. Upstream schemas change without notice. Nothing is hand-cleaned, because nobody can hand-clean a stream.

The prototype does not scale into this environment; it has to be rebuilt for it. Teams that recognise this early spend their first months on data infrastructure and ship. Teams that treat it as a deployment detail spend those months discovering the problem one incident at a time.

Lineage: knowing where a number came from

Lineage is the record of how a piece of data arrived at its current value — which sources, which transformations, which version of which job, at what time.

In an AI system it is load-bearing for reasons that go beyond compliance. When an output is wrong, lineage is what converts an unbounded investigation into a bounded one. Without it, a single questionable figure can occupy a team for days and end in a shrug — which, repeated a few times, is how organisations quietly stop trusting a system while continuing to pay for it.

Lineage also determines whether you can respond to change. When a source system is found to have been miscoding a field for months, the question is which downstream outputs were affected. With lineage, that is a query. Without it, it is a guess.

It has to be captured automatically as a property of the pipeline. Lineage maintained by hand in documentation describes the system as someone once believed it to be.

Access control has to survive the model

This is where AI systems most often fail enterprise review, and the failure is subtle.

Enterprise data carries fine-grained permissions. A salesperson sees their accounts; an HR system partitions by region and seniority. These controls are typically enforced at the query layer — which is exactly the layer an AI pipeline tends to bypass when it ingests everything into an index.

Once content from documents a user cannot open has been embedded into a shared index, a retrieval system will happily surface it to them. No rule was consciously broken. The access model simply did not survive the transformation.

Handling this properly means carrying permissions through as first-class metadata and enforcing them at retrieval time, filtering the candidate set by the requesting user's entitlements before anything reaches a model. Where sensitivity differs sharply, separate indexes are cleaner than filtering a shared one.

The test to apply: if a user asks a question whose answer lies entirely in documents they cannot access, the system must decline rather than answer. Systems that have not been designed for this will answer, and nobody will notice until someone does.

Quality is not a cleanup task

Data quality is usually framed as remediation — a project to fix the warehouse. Framed that way it never finishes, because quality is a rate, not a state.

The more useful framing is that quality is enforced continuously at boundaries. Data contracts make the expected shape and semantics of a feed explicit, so violations are detected where they enter rather than inferred later from a strange result. Validation runs as part of the pipeline. Anomalies in volume, distribution or freshness are alerted on.

AI raises the stakes because it launders errors. A dashboard showing an implausible number invites scrutiny. A model given the same input produces a fluent, confident statement with the error absorbed invisibly into it. The error does not announce itself — it just makes the output quietly wrong.

Auditability and the right to an explanation

Regulated environments require that a decision can be reconstructed after the fact — often long after, and usually by someone who was not involved.

Reconstruction requires more than logging the output. It requires knowing which model version ran, which data it saw, which configuration was active, and what the state of the retrieved sources was at that moment rather than now. Systems that log only inputs and outputs cannot reproduce a decision once the underlying data has moved on.

This is best treated as an architectural requirement from the start. Retrofitting reconstruction into a system that did not record what it needed is, in most cases, not possible at all.

Governance as an accelerator

Governance is usually cast as the brake — the process that slows delivery down. In practice, the causation frequently runs the other way.

Ungoverned AI projects stall in review. They cannot demonstrate provenance, cannot show that access rules hold, cannot reconstruct a decision, and so cannot obtain approval to touch real data or real users. The work is complete and cannot ship.

Projects built on governed foundations clear those reviews because the evidence is a by-product of how they were built. The governed path is slower for the first month and faster from then on — and it is the only one of the two that reliably ends in production.

What good looks like

A system worth trusting inside an enterprise can answer these without special effort:

  • Which sources produced this output, and what state were they in at the time?
  • Is this user entitled to every piece of data that contributed to this answer?
  • Which model and configuration produced it, and can that be reproduced?
  • If an upstream source is found to be wrong, which outputs are affected?
  • When the system is not confident, does it say so — and does it decline when it should?

None of these are model questions. All of them are data and architecture questions, and they are decided early. The organisations getting durable value from AI are not generally the ones with the best models. They are the ones that built foundations capable of supporting a model worth trusting.