The missing layer: a practitioner's case for an AI Data Fabric

A few years ago I sat in a boardroom while a CDO walked me through his “unified data strategy.” Nice deck. Confident pitch. And three floors below us, his analysts were copy-pasting numbers between spreadsheets because the warehouse query took four hours to come back.

I’ve spent the better part of two decades building, selling, and occasionally watching data platforms fall over, mostly across the Middle East and Africa. That boardroom scene is the one I keep coming back to, because it’s so common. The gap between the strategy on the slide and the reality on the floor is where most data programs actually live.

Before I tell you where I think this is heading, it helps to remember how we got here.

How we got here

We started with the relational database, and for a while it was enough. Tables, views, the occasional materialized view. Analysts wrote SQL, reports came out, people went home on time. Then the data got bigger. Then it got bigger again. The nightly refresh that used to finish by 2am was still running at 9. And the first time someone asked to join the CRM data to the supply-chain numbers, the whole thing buckled.

So we moved everything somewhere else. Extract, transform, load. Pull from the source, clean it up, land it in a warehouse. It worked, and it built a few large software companies along the way. The trouble is that ETL pipelines are brittle. Rename one column upstream and the nightly job doesn’t crash, it just quietly starts producing nonsense. I watched a regional bank find out that three months of risk numbers were wrong for exactly that reason. The pipeline had been running the whole time. Nobody was watching what came out the other end.

Hadoop showed up and promised to fix this by not making us decide anything: just store everything, structured or not, and sort it out later. Later mostly never arrived. The lakes turned into swamps. Petabytes with no lineage, no catalog, and nobody left who remembered why half of it got ingested in the first place. An engineer at a Gulf telco once described his to me as “a landfill with a search bar.” That stuck with me.

The modern stack was a real step forward. Load raw, transform in the warehouse, put your SQL under version control, let compute scale on demand. Genuinely better. But it handed us a problem nobody had on the roadmap: sprawl. A typical enterprise now runs one tool for ingestion, another for transformation, another for compute, another for BI, another for quality, another for the catalog. Each one is very good at its job. The catch is that none of them owns the seams between them, so a person does. Usually several people, most of the week.

The thing everyone starts and nobody finishes

And then there’s governance, which everyone agrees matters and almost nobody pulls off. Gartner expects 80% of data and analytics governance programs to fail by 2027. The tools aren’t the reason. The reason is that governance keeps getting run as a project with a start and an end, when it’s really a habit that has to live inside the daily work.

You can see it even at the very top of the market. Banks have spent billions modernizing and still walked into nine-figure penalties for reporting bad numbers to regulators, with their own leadership tracing it back to decades of stitched-together systems. If that’s what happens with an unlimited budget, it’s worth asking what a mid-market company is supposed to do by bolting governance on at the end.

Today, complexity is the default

Here’s the scene I walk into at most companies. The CTO has signed off on a cloud migration. The CDO has a governance roadmap in a binder. Data engineering is heads-down building pipelines. The data scientists want a feature store. Compliance needs lineage. The business wants self-service. And the CFO is in the corner asking why the cloud bill tripled last quarter.

Everyone is doing good work. That’s the frustrating part. They’re all doing the right thing in their own lane, and the result is still a mess, because nobody owns the spaces in between. It isn’t any one vendor’s fault either. The big platforms are each built to shine inside their own world, which leaves the hardest job, making all of it work together across clouds and tools, sitting on your desk.

The layer that’s missing

After enough of these projects across the GCC and Africa, the same conclusion kept finding me. These organizations didn’t need another tool in the stack. They needed something sitting across the tools they already had, making them behave like one system. Something that reads the metadata, holds the governance line, takes the quality work off people, and uses AI as the connective tissue rather than as a slogan on the website.

That’s what I mean by an AI Data Fabric, and it’s why we built Celvari. It doesn’t replace your warehouse, your transformation tool, or your BI layer. It sits over them and does the work that used to land on a person.

It starts with metadata. AI-driven profiling builds a searchable map of your whole estate, organized by domain, down to the column-level transformations, with ownership and lineage captured as the work happens rather than reconstructed six months later in a panic.

Transformations are generated as plain, versioned SQL that runs on your own engine, so you can read it, review it, and reproduce it. That’s good for auditors, and it turns out to be good for the AI too: clean, versioned SQL is far easier for an agent to reason about than a wall of templated code.

The piece I care about most is the boundary between the agents and your data. The AI layer reasons and proposes. A separate, governed execution layer actually runs the work, under its own credentials and security policies. The agents never touch your database. What crosses the line is metadata, generated SQL, and prompts. Production data stays put. I’d call that a governance decision more than an architectural one, and it’s the part I’d want to interrogate hardest if I were the buyer.

Quality lives in a registry that maps rules to specific tables, columns, and quality dimensions, instead of getting sprinkled in wherever someone remembered to add a check. The practical payoff is that a question like “do we have a completeness check on every column feeding the financial reports?” gets answered with a query, not a week of manual auditing.

It’s open underneath, built on open standards and open formats, so your data, your metadata, your catalog, and your choice of model stay yours and stay on your infrastructure. And every step the agents take, every transformation, every check, is traced end to end. When something breaks, and in data something always breaks, you can go back and see exactly what the AI suggested and what the system actually ran.

What it looks like in practice

One of our early engagements was a fast-growing e-commerce business pushing thousands of orders a day across a handful of channels. The setup was the usual one: customers in one system, operations in another, marketing in a third, and a heap of unstructured logs off to the side. They had dashboards. What they didn’t have was trust in them, because every team calculated the headline metrics a little differently. Their inquiry-to-order conversion rate came back somewhere between 8% and 15% depending on who you asked. That’s not a rounding error. That’s flying blind on the number that drives the business.

Inside a few weeks they had one catalog covering every asset, and one agreed definition for the metrics that mattered. The real conversion rate turned out to be 12%, and for the first time they could see why, broken out by channel. Quality rules ran automatically and caught a large slice of records with broken marketing attribution before any of it reached a report. People could ask questions in plain language and get answers through governed models instead of poking at the database directly. The win wasn’t really “cleaner data.” It was that everyone was finally arguing about strategy from the same dashboard instead of arguing about whose number was right.

Why this lands differently in the GCC

If you operate in the Gulf, governance isn’t a nice-to-have. Saudi Arabia’s NDMO framework, the PDPL, and the NCA requirements are conditions of doing business, not aspirations. The UAE’s rules are moving fast. And the moment you hold a government contract, you have to be able to prove where your data lives.

This is exactly where building governance into the foundation pays off, because the catalog, the audit trail, and the access controls aren’t a separate workstream you have to go and stand up. They’re already there. And since it deploys on your own infrastructure, whether that’s cloud, on-prem, or a sovereign environment, the data stays inside your borders and under your control.

The honest version

I’m not going to tell you any of this fixes everything by Friday. No architecture does. The companies that get real value out of this approach tend to have made peace with two things.

The first is that the problem was never the tools, it was the gaps between them. You probably don’t need to rip anything out. You need a layer that makes what you already own act like one system.

The second is that governance has to be woven in, not stapled on. The minute it becomes a separate initiative run by a separate team off to the side, it’s already on its way to failing. It has to live in the data itself, from the moment it’s ingested to the moment someone makes a decision with it.

That’s what we built Celvari to do, and we’re watching it work.

If any of this hit close to home, the sprawl, the governance gaps, the multi-cloud tangle, or just a good team spending most of its week on plumbing instead of answers, I’d genuinely like to talk. Book a working session and we’ll take one real request off your backlog and turn it into a governed, tested data product, live, while you watch.