The AI conversation in most enterprises starts with the model. The data conversation usually comes later
Which model should we use? Should we build or buy? How do we introduce RAG? What happens when we move from copilots to agents?
Those are important questions. But there is another question that tends to arrive later.
Where does the AI get its understanding of the business from?
That question sounds like a data question. It is.
And increasingly, I think it is also an architecture question.
I have watched the same pattern play out in organisations across different industries. An AI team builds a promising prototype. The model works. The business sponsor is excited. Then someone asks a few fairly ordinary questions.
Where did this number come from?
Who owns the data?
When was it last updated?
What exactly does "active customer" mean?
Is this the same definition Finance uses?
Suddenly, the conversation changes.
The problem is no longer whether the model can answer the question. It is whether the organisation can trust the information it is answering from.
That is where the conversation about Data Mesh becomes interesting.
Not because AI requires Data Mesh. It doesn't.
But because many of the properties that make a data architecture useful for AI are the same properties that Data Mesh was designed to introduce: ownership, context, discoverability, quality, contracts and accountability.
AI may be changing the reason we care about data architecture.
What AI Actually Needs From Data
Before connecting Data Mesh to AI, it is worth stepping back and asking what AI actually needs.
Traditional BI and AI are not asking the same thing from enterprise data.
A dashboard needs accurate historical data. It can often tolerate some latency. If yesterday's number is wrong, a human analyst can notice it, question it and find someone who knows what happened.
Traditional machine learning has a different requirement. It needs representative, historically consistent datasets with appropriate labels and features. The data does not necessarily need to be real-time. It needs to be good enough for the model to learn from.
Generative AI introduces another requirement.
Context.
If I ask an AI system about our revenue, customers or products, the model's general knowledge is not enough. It needs access to the organisation's own information.
That is why RAG became such an important pattern. The model can retrieve information from enterprise sources and use that information as context for its response.
But this creates an uncomfortable question.
What happens when the retrieval layer is connected to data that nobody really understands?
A dataset might contain a column called revenue.
But is it gross revenue?
Net revenue?
Revenue after returns?
Recognised revenue?
Revenue for the current financial period?
A human who has worked with the data for years may know the answer.
The model doesn't.
It sees the context it has been given and reasons from it.
This is where poor data architecture becomes an AI problem.
And agents make the problem more serious.
A chatbot can give you a bad answer.
An agent can take action based on one.
An agent deciding which customers to contact, which invoices to escalate or which inventory to replenish does not just consume data. It acts on its interpretation of that data.
The more autonomy we give AI, the less comfortable we should be with ambiguity underneath it.
The Data Problem Was Always There
There is an important distinction here.
AI did not create these data problems. We have had them for years.
Analysts know which tables to trust. They know which dataset is the "real" customer table. They know that the Finance number is different from the Sales number. They know who to call when something does not look right.
A surprising amount of enterprise data quality is maintained by institutional knowledge that never made it into the architecture.
Humans compensate for missing metadata. For missing ownership. For undocumented definitions. For stale data.
But AI cannot compensate in the same way.
That is what has changed.
The cost of poor data architecture used to be a frustrated analyst and a delayed report.
Increasingly, it can be an automated decision made at machine speed and at scale.
Three Data Problems That Become AI Problems
The failure modes we have discussed throughout this series become particularly visible when AI starts consuming enterprise data.
1. Ownership vacuum
When nobody is accountable for a dataset, quality becomes everyone's problem and therefore nobody's problem.
Consider customer data.
Sales may define an active customer one way.
Finance may define it another way.
Marketing may have a third definition.
A human analyst knows this because they have learned the organisation's history.
An AI system may retrieve all three definitions and produce an answer that is internally inconsistent.
The model is not necessarily hallucinating. It may simply be reasoning correctly over contradictory information.
The thing that needs fixing is not the model. It is the data.
And data quality is not created by a model. It is created by ownership and accountability.
2. Context gets lost
Centralised data platforms are very good at bringing data together.
They are not automatically good at preserving the meaning that came with it.
The column is called revenue.
The technical documentation says "revenue."
But the business context that tells us what that revenue actually represents may still exist only in the heads of the people who produced the data.
This is particularly problematic for AI.
A model does not know which definition is authoritative simply because one dataset happens to be in the enterprise data lake.
It needs context. It needs semantics. It needs to know what the data represents, where it came from and how much confidence we should place in it.
3. Stale data becomes stale decisions
The traditional enterprise data platform was often designed around batch processing.
That made sense.
A nightly pipeline was sufficient for a morning report.
But consider an agent making operational decisions.
Should we contact this customer?
Should we expedite this shipment?
Should we approve this transaction?
Should we recommend this product?
The acceptable age of the data depends on the decision being made.
A four-hour-old inventory figure might be perfectly acceptable for one analytical use case and completely unacceptable for an autonomous operational decision.
The point is not that all AI requires real-time data.
The point is that AI needs the data's freshness characteristics to be explicit.
An agent needs to know what it can safely assume.
So Where Does Data Mesh Fit?
This is where I think the connection to Data Mesh becomes much clearer.
Data Mesh does not solve AI.
It addresses a set of organisational and architectural problems that become increasingly important when AI consumes data directly.
The first is domain ownership.
If Sales owns a customer data product, then Sales is accountable for what "active customer" means in the context of that product.
That definition is no longer just tribal knowledge.
It can become part of the product's metadata, documentation and contract.
The second is self-describing data products.
A data product should not require a meeting with its creator before another team can understand what it contains. It should explain itself.
What does this field mean?
Where did it come from?
How fresh is it?
What quality guarantees exist?
Who owns it?
What are its known limitations?
These are useful properties for humans.
They are even more important when the consumer is an AI system.
The third is data contracts.
A contract gives consumers something to reason about.
If a product promises that its data will be no more than two hours old, that is materially different from a dataset that happens to be updated roughly every few hours.
The difference is accountability.
And the fourth is governance.
When an AI agent accesses sensitive customer information, we need more than a general statement that "access is governed."
We need governance that can operate at the same speed as the systems consuming the data.
This is one reason federated computational governance becomes interesting in an AI context.
The value of Data Products has increased becuase of AI even though it was not originally built for AI
There is an interesting irony here.
The idea of a data product was not invented for AI. The original motivation was much simpler.
Make data usable by its consumers.
Give it an owner.
Make it discoverable.
Document it.
Give consumers a reliable interface and explicit expectations.
Those requirements existed before generative AI.
But look at what an AI system needs when it is consuming enterprise data.
It needs to discover the right information.
It needs to understand what that information means.
It needs to know whether the information is trustworthy.
It needs to understand where it came from.
It needs to know whether it is fresh enough for the task.
It needs to operate within the access policies associated with that data.
That sounds remarkably similar to a well-designed data product.
I don't think data products were invented for AI.
I think AI has made the reason for building them much harder to ignore.
From Data Mesh to an Intelligence Mesh
There is another possibility that becomes interesting as AI agents become more capable.
What happens when the consumer of a data product is not a human analyst, but another agent?
Imagine a Sales agent that understands the Sales domain.
It knows the definitions used by Sales.
It understands the customer data product.
It knows which metrics are authoritative.
It understands the limitations of the data it is consuming.
Now imagine a Finance agent doing the same thing for Finance.
The two agents can collaborate because the underlying data products have explicit interfaces, shared standards and defined semantics.
The architecture starts to look different.
We are no longer simply moving data between domains.
We are allowing intelligence operating in different domains to work together through governed, interoperable data.
This is the idea behind what Eric Broda describes as a Data Product Agent Mesh.
It is still an emerging concept, and I would be careful about treating it as an established architectural pattern.
But the direction is interesting.
The more autonomous AI becomes, the more important the quality and boundaries of the data it operates on become.
The Gulf Has an Interesting Problem
The relevance of this discussion is particularly obvious in the Gulf.
Saudi Arabia's Vision 2030 and the UAE's AI strategy represent serious commitments to becoming leaders in AI.
There is substantial investment going into AI infrastructure, talent, applications and national capabilities. But AI capability does not exist independently of data capability.
I have seen data infrastructure across government entities and large enterprises in the region.
The pattern is familiar. A strong AI team. A serious AI strategy.
Modern models and infrastructure. And underneath it, a data estate that has accumulated over years with fragmented ownership, inconsistent definitions and limited semantic context.
The AI team is then asked to build intelligence on top of it. The problem is not that the AI team is incapable. The problem is that the foundation underneath them was not designed for this operating model.
The AI strategy and the data architecture cannot continue to be designed in separate rooms. They are becoming the same conversation.
Should You Build Data Mesh Before AI?
This is where I would resist the temptation to give a simple answer.
No.
You do not need to complete a Data Mesh transformation before building AI.
That would be another version of boiling the ocean.
You also do not need to wait for the perfect data architecture before experimenting with AI.
There is value in starting with a controlled use case and allowing the experience to expose where the data problems actually are.
In fact, AI can be a useful diagnostic tool.
Take one use case.
Trace the data it requires.
Find the ownership gaps.
Find the semantic ambiguity.
Find the freshness problem.
Find the governance problem.
Then fix those things.
That is much more useful than launching a three-year programme to "prepare the data for AI" without knowing which data actually matters.
The same incremental logic we discussed in Part 6 applies here.
One domain. One data product. One AI use case.
Make it work.
Measure what failed.
Fix the underlying problem.
Then expand.
The Question Has Changed
When we started this series, the central question was:
Should your organisation adopt Data Mesh?
I think AI changes the question slightly.
The question is no longer simply whether you should distribute your data ownership.
It is whether the architecture you have today can support a world in which software systems increasingly consume, interpret and act on your data without a human sitting between the two.
That is a much higher bar.
Humans can ask for clarification. Agents may not.
Humans know which numbers they don't trust. Agents only know what the system tells them.
Humans can remember that a dataset has an exception at month-end. An agent needs that exception represented somewhere it can understand.
This is why I think the importance of Data Mesh may ultimately have less to do with data itself.
And more to do with trust.
Data Mesh began as a response to the problems created when organisations grew too large for a central data team to understand every domain.
AI creates another reason to solve the same problem.
Because when machines become consumers of enterprise data, the missing context, missing ownership and missing accountability can no longer be filled in by a human who happens to know better.
The AI strategy is therefore, at least partly, a data strategy.
And the organisations that understand that early will have an advantage that has very little to do with which model they chose.
You can change the model. But it is changing the data foundation where the value lies.
--------- ----------