Why Data Modernization is Key to Enterprise AI Strategy

A GydeBites conversation with Sourabh Mukherjee, Head of AI and Data Strategy at Accenture, on why AI agents need a shared business meaning before they can be trusted.

Most enterprises believe they have an AI problem. What many actually have is a data-meaning problem that AI has made impossible to ignore.

For years, analysts patched the gaps. They knew which spreadsheet was the real one, which report to distrust, and how finance and sales defined an “active customer.” That tribal knowledge kept dashboards working.

Agents do not have tribal knowledge. They take the data at face value, reason over it, and act. If the enterprise can't agree on what its data means, agents won't figure it out on their own.

I spoke with Sourabh Mukherjee, Head of AI and Data Strategy at Accenture, on this episode of GydeBites. Sourabh has spent nearly three decades in data, analytics, and AI, helping global enterprises with AI strategy, data modernization, and large-scale transformation. He is also a published author, keynote speaker, and academic advisor. The full episode is on GydeBites. It runs about 18 minutes.

Why does AI inherit every data problem you never fixed?

Sourabh frames the issue as a stack, and the stack explains why AI failures feel so sudden. At the bottom, critical data sits in legacy vendor applications, spreadsheets, and personal drives. With multiple ingestion paths, nobody is sure which source is the truth, so teams keep cleansing and re-cleansing the same data.

One layer up, teams build bespoke pipelines for each need rather than designing them for reuse. Most platforms still struggle with unstructured, semi-structured, and synthetic data, which limits how widely and quickly models can be trained.

On top of that, datasets often lack quality guarantees, access controls, and lineage. An agent looking at them has no way to tell which ones are trustworthy or secure. At the top, without a shared business taxonomy, models end up reasoning over ambiguous data.

His sharpest point is that these problems do not stay contained. An unresolved issue at the infrastructure layer compounds at every level above it. By the time it reaches an agent’s output, it looks like an AI problem, even though it started years earlier as a data ownership problem.

What does traditional data engineering miss in the AI era?

Change data capture, cleansing, and transformation are still necessary. Sourabh argues they are now table stakes, not the whole job.

Much enterprise knowledge lives in documents, transcripts, and images. A modern platform needs ingestion that can handle those formats, plus built-in embedding and vectorization, rather than bolting them on later.

He adds a second layer of capability that most data teams have not historically owned: annotating and labeling data for model training, detecting anomalies, and detecting bias. These are not data science side projects. They belong in the engineering platform itself.

The implication is uncomfortable for many data teams. The skill set that made them effective five years ago is necessary but no longer sufficient.

Are you paying a data tax on every AI use case?

This was the most useful part of the conversation for anyone building a business case. Sourabh describes per-use-case data preparation as a tax. Every new model or agent pays it again because the pipeline built for the last project cannot be reused for the next.

The alternative is to build data products instead of pipelines. A data product is certified, validated, owned by a defined team, and easy for data scientists and AI practitioners to discover. It is a one-time investment whose cost is spread across many models and use cases over time.

He acknowledges that the data mesh label has lost some of its buzz. He argues that the underlying mechanics still hold for agentic AI: domain teams own their data products, governance is federated, and a marketplace lets consumers find what they need.

The shift is from treating data as a project input to treating it as an asset with an owner and a lifecycle. That is an organizational change before it is a technical one.

Why do agents fail even when retrieval works?

Sourabh’s observation here deserves attention. Agents often fail in production not because they cannot retrieve or extract data, but because the data's meaning is ambiguous.

This is where the semantic layer and knowledge graph come in. He pushes back on the idea that a knowledge graph is just a way to connect data sources. In his view, it encodes the business ontology and the logical relationships between entities, so reasoning and inference can happen natively, for example in an RDF-based system.

He summarizes its value with three letters: M, L, and T. Meaning gives data a business definition and taxonomy. Logic lets the AI reason over relationships between entities. Trust comes from tracing any insight or prediction back to its origin in the graph.

Get Prasanna Vaidya’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

That traceability is what makes outputs explainable and less prone to hallucination. When I asked him which data practice an enterprise should modernize first, he answered immediately: the semantic layer.

Which modernization moves are failing?

Sourabh was just as clear about what does not work. A lift-and-shift cloud migration moves fragmentation without resolving it. The data is now in the cloud, and it is still siloed.

Heavy dependence on a central IT function also doesn't scale. Neither do large monolithic platforms, when what agents need is a composable, plug-and-play, productized architecture.

He also calls out the absence of a central data catalog that documents metadata, ownership, and business meaning. And he warns against every department or line of business building its own AI and data stack instead of working within an enterprise framework.

Each of these can look like progress on a roadmap. None of them changes whether an agent can understand the business context it is acting in.

Where are the data platforms heading?

Sourabh points to the major platforms as evidence that the direction is settled. Databricks is investing in Unity Catalog and Genie. Snowflake is building semantic views, Horizon Catalog, and Cortex. Microsoft is bringing Fabric, OneLake, Purview, and Copilot together. Google is doing similar work across BigQuery, Dataplex, and Vertex AI.

The common thread is a move away from the plain data warehouse or data lake toward what he calls agent-ready knowledge platforms. Data products, knowledge graphs, lineage, and observability are becoming core features, not add-ons.

He advises leaders to track these platforms' roadmaps closely, because semantic and AI capabilities are being added to product bundles quickly. What required a custom build two years ago may now come with the platform.

For data teams, he names two skills worth building now: data product engineering and semantic modeling.

How do you know your modernization program is working?

This was Sourabh’s practical advice, and it is the cleanest test I have heard. Modernization usually starts with a use case, but you measure its success by the foundation it leaves behind.

Say you start with one or two use cases. As you deliver them, you should also build reusable data products, a semantic layer with a knowledge graph, and federated governance.

If that foundation is based in reality, the second and third rounds of use cases should cost noticeably less than the first. If each new use case costs about the same, or more, something is wrong with the strategy.

Any leader can ask their team a simple question. Is the marginal cost of our next AI use case going down?

Final Note: Is data modernization an AI project or a business project?

The core tension in this conversation is timing. Enterprises want AI outcomes now, and data foundations take time. The temptation is to skip the foundation and go straight to the agent.

What Sourabh describes is a way out of that tradeoff. You do not have to choose between shipping use cases and building the foundation. You build the foundation through the use cases, and you hold yourself accountable for whether each one makes the next one cheaper.

The harder part is not technical. Domain ownership, federated governance, and a shared business vocabulary require people across the business to agree on what their data means and who is responsible for it. No platform can make that decision for you.

If you take one question back to your team, it is this: when our agents act, whose definition of the business are they using?

That question sits underneath much of what we explore on GydeBites, and this episode with Sourabh is a good place to start if your AI ambitions are running ahead of your data.

Suggested Readings

1. Top Trends in D&A for 2026: Making Composite Semantic Layers Interoperable, Gartner (February 2026). Full report is paywalled; the abstract is public.
2. Data Mesh Principles and Logical Architecture, Zhamak Dehghani, martinfowler.com (2020).
3. RDF 1.1 Primer, W3C Working Group Note (2014).
4. What is Unity Catalog?, Databricks documentation.
5. Overview of semantic views, Snowflake documentation.