AI architecture: why data governance decides the outcome
AI projects stall on data, not models. What a data foundation needs — integration, master data, lineage, access control — before AI is worth starting.
An AI programme is a data programme wearing better clothes. That is not a criticism of AI — it is a statement about where the work sits.
Models are increasingly commoditised. You can rent a very good one by the token. What you cannot rent is a clean, joined, documented view of your own business, and that is the part every stalled AI project turns out to be missing.
The pattern behind stalled AI projects
It rarely fails loudly. The sequence looks like this:
A pilot works on an extract someone prepared by hand. It is convincing enough to fund. Then the team tries to run it on live data and discovers the extract was not representative — it was cleaned, deduplicated and joined by a person who made a hundred small judgement calls nobody wrote down.
Reproducing those judgement calls in a pipeline turns out to be the actual project. It was never scoped, so the timeline slips, and the sponsor’s confidence goes with it.
The diagnostic question: could you answer the question your model answers today, using SQL and enough time? If no, the model will not answer it either — it will produce a plausible number with no basis.
What governance means here
“Data governance” carries committee connotations that put engineers off. In this context it means four concrete capabilities, each of which is buildable.
Integrated data systems
The first blocker is almost always fragmentation. Customer data in three systems with three different keys, no agreed definition of which is authoritative, and reconciliation done by a person.
What integration needs is less glamorous than a platform purchase: an agreed system of record per domain, a defined way data moves between systems, and a resolution rule for disagreements. The technology matters less than the agreement.
Master data management
Master data is the small set of entities everything else references — customer, product, supplier, employee, site. When these have no single definition, every downstream number is negotiable.
The symptom is familiar: two departments produce different revenue figures and both are defensible, because they counted different sets of customers.
For AI this is not a reporting inconvenience. A model trained on inconsistent entity definitions learns the inconsistency.
Metadata and lineage
Lineage answers a simple question with awkward implications: where did this number come from?
You need it for three separate reasons:
- Debugging. When output looks wrong, you trace it back. Without lineage you guess.
- Trust. A business user who cannot see the derivation will not act on the result, and adoption dies quietly.
- Regulation. Under the EU AI Act, high-risk systems require documented data governance covering training and input data. Under revDSG/nDSG and GDPR, you have to be able to explain automated decisions affecting individuals. Both require lineage you can produce on request.
Retro-fitting lineage after a model is in production is one of the more expensive corrections available, because sometimes the only honest fix is to retrain from a documented base.
Access control, not just storage location
This is the one most often mis-stated, and it matters more in Switzerland than in most markets.
Storing data in a Swiss or EU region answers the residency question. It does not answer who can reach it — support staff in another jurisdiction, a sub-processor two layers down, an administrator with standing access nobody reviews.
Residency and access are different questions. Swiss and German procurement asks both, and only one of them is answered by a region setting.
What this costs if you skip it
Three costs, in ascending order of pain:
- Rework. The pipeline gets built twice, because the first version encoded assumptions from the hand-made extract.
- Abandonment. The model works but nobody trusts it, so it is never used for anything consequential. This is the most common outcome and the least visible, because nothing was ever declared a failure.
- Retraining under obligation. A regulator or a customer asks for provenance, it cannot be produced, and the only clean answer is to rebuild from a documented base.
A realistic sequence
You do not need a finished data platform before starting AI. You need enough foundation for the specific use case, which is a much smaller ask.
- Pick the use case first, then map only the data it touches. A full enterprise data programme ahead of any AI is how three-year initiatives with nothing to show get started.
- Fix identity for the entities that use case needs. Usually one or two, not all of them.
- Instrument lineage from the beginning for that path. Adding it later is the expensive direction.
- Settle the access question before the architecture, not after. It constrains hosting choices, and reversing a hosting decision is costly.
That is deliberately narrow. It gets one use case into production with a foundation that the second and third can extend, rather than a platform nobody has used yet.
Related reading
- Six AI adoption challenges Swiss companies hit — where this sits among the other blockers
- The EU AI Act is enforceable: what DACH CTOs should do now — the documentation obligations in detail
- AI Strategy & Consulting and MLOps & AI infrastructure
If you want to know whether your data foundation supports the use case you have in mind, the AI Sprint is scoped for exactly that question. Or book a call — no obligation.