Your AI Is Only as Smart as Your Data Catalog (And Yours Is Probably a Mess)
Here’s a scenario that plays out in boardrooms everywhere: the executive team watches a demo of an AI agent that can autonomously handle customer support tickets, and suddenly everyone’s a technologist. Budget gets approved. Teams get hired. Expectations get set. Twelve months later, the “revolutionary” agent is still a pilot, still fed by a hand-curated extract that one engineer refreshes on Tuesday mornings.
The model didn’t fail. The infrastructure didn’t fail. The data did, specifically, your data’s complete inability to be found, understood, and trusted by anything other than the human who originally built the pipeline.
The Uncomfortable Question Nobody Wants to Ask
The data engineering community has been circling a question that makes AI evangelists uncomfortable: are we so obsessed with building sophisticated AI systems that we’re skipping the boring, unglamorous work of making data actually usable?
The metaphor that keeps coming up in engineering forums is apt: we’re obsessing over engine efficiency while feeding the engine unrefined crude oil. Everyone wants agentic automation, RAG pipelines, and autonomous decision-making. Almost nobody wants to fund the data catalog, the lineage tracking, and the quality gates that make those systems trustworthy.
And look, I get it. Data governance isn’t sexy. Nobody’s getting a standing ovation for updating metadata. But the numbers suggest we’ve hit a crisis point where our enthusiasm for AI has massively outpaced our data foundations.
The Evidence Is Brutal
Let’s look at what actually happens when organizations rush AI without fixing discoverability first. The research is remarkably consistent across independent sources:
- 88% of AI proofs of concept never reach production. IDC’s work with Lenovo on the CIO Playbook 2025 found that for every 33 AI pilots launched, only four graduated to production. That’s not a model problem, that’s a foundations problem.
- 95% of organizations see no measurable P&L return from generative AI. MIT’s Project NANDA reviewed 300+ AI initiatives and conducted 52 structured interviews to reach this damning conclusion.
- 60% of AI projects will be abandoned without AI-ready data. Gartner’s prediction for 2026 is essentially saying: your data is the reason your AI dreams will die.
- 97% of enterprises have allocated agentic AI budget, but only 18% have fully deployed anything. The Qlik 2025 Agentic AI Study found that data quality and integration barriers ranked above model performance as the biggest obstacles.
Four different research programs. Four different methodologies. One conclusion: the money is committed and the strategy is agreed. What’s missing is data readiness, and no amount of model fine-tuning substitutes for it.
Why “Good Enough for BI” Is a Death Sentence for AI
Here’s where the discoverability crisis gets subtle. Most organizations think they’ve solved their data problems because they have a data warehouse, some dashboards, and a reporting cadence everyone trusts. None of that means your data is AI-ready.
The difference comes down to who, or what, is sitting between the data and the decision:
| Tier | What It Delivers | Refresh Cadence | Good Enough For |
|---|---|---|---|
| Reporting-ready | Static exports, monthly reconciliation | Weekly/monthly | Board decks, quarterly reviews |
| Analytics-ready | Structured warehouse, dashboards | Daily | BI, historical trend analysis |
| AI-ready | Governed, use-case-aligned, quality-gated at ingestion | Continuous/near real-time | Model training, production inference |
A human analyst absorbs an incredible amount of data mess. They notice when a regional total looks wrong. They remember the ERP cutover from last quarter. They quietly adjust for the supplier that’s always late with their data.
Take the human out of the loop and those tolerances disappear.
An AI agent booking a replenishment order doesn’t pause because the supplier record looks unusual. A fraud model scoring a transaction has no memory of last quarter’s system migration. The standard moves from “accurate enough to interpret” to “accurate, timely, and traceable enough to act on unattended.”
The Three Failure Modes That Sabotage Everything
If you want to audit your AI readiness this week, start with these three patterns:
1. Batch Pipelines Feeding Real-Time Decisions
A nightly ETL window is invisible during a pilot that gets evaluated on historical accuracy. It becomes catastrophic in production when your model is pricing a transaction or judging a supply position that moved four hours ago.
The fix isn’t a faster batch job. It’s log-based change data capture that reads changes from your source systems as they happen, without adding load to production. Tools like Qlik Replicate and Talend Cloud do this for SAP, Oracle, and mainframe sources.
2. Quality Assessed After the Fact
Most enterprises validate data in a dashboard that someone reviews on Monday morning. By then, the model has already trained on that garbage. Or worse, it’s already answered a customer.
Measurement without enforcement is reporting, not control. The quality gate needs to live in the pipeline itself, failing batches get quarantined before they land, not flagged after they’ve done damage. Qlik’s Trust Score for AI, now generally available in Qlik Talend Cloud, scores data across diversity, timeliness, accuracy, discoverability, and usage. That last dimension, discoverability, is the one traditional data quality tooling almost always misses.
3. Raw Tables Handed to AI Teams
When every use case starts from raw schema, every team re-cleans, re-joins, and re-interprets the same entities in slightly different ways. You don’t end up with one definition of a customer. You end up with eleven, each technically defensible on its own terms.
The answer is packaging data as governed data products: domain-owned, contract-backed, versioned assets with named owners. HBR research cited by Qlik suggests this approach can cut implementation time for new use cases by up to 90% and total cost of ownership by up to 30%.
The “What If I Told You…” Problem
Here’s where this conversation gets cynical, and honestly, the cynicism is earned. When data engineers raise these concerns, they often get met with a version of “you’re stating the obvious.” There’s a suspicion in the community that anyone posting about data fundamentals is about to pitch you a data catalog.
But the deeper issue is organizational. Management wants AI pushed into everything. If you don’t do it, some other team will, and they’ll get the promotion. One engineer put it bluntly: “You can scream at the top of your lungs and say that’s not how things work technically, nobody’s going to care.”
The incentives are misaligned. Building data foundations is a hard sell because the ROI is invisible. A consultant with 15 years of experience trying to sell data catalog implementations put it this way: when you tell decision-makers “your data is better” or “future updates are easier”, the answer is almost always no. What do they get from it? Does it make them more money today?
It’s like insurance. You can’t meaningfully estimate the cost savings from preventing a failure that hasn’t happened yet.
There’s No Such Thing as “AI-Ready Data” (for Everything)
One of the more nuanced takes emerging from the data engineering community is that data readiness is contextual. There is no universal AI-ready dataset. A forecasting model needs point-in-time history and future known drivers. RAG needs source documents, permissions, versioning, and retrievable structure. Computer vision needs representative images and labels. Agents need reliable tool interfaces and authoritative state.
The practical consequence: don’t launch a giant project to make all data AI-ready. Define the highest-value AI decisions first, derive their data requirements, and build governed data products that meet those requirements repeatedly.
This cuts against the instinct to build a generic data platform for years with no measurable AI decision waiting for it. The gap between high-performance data formats and poor data governance is exactly where this problem lives, you can have blazing-fast vector operations and still have no idea what’s actually in those 50+ Lance datasets scattered across S3.
Architecture Decisions That Set Your Ceiling
Two architecture decisions deserve special attention because they determine whether your AI program can scale or whether it’ll hit a wall.
Open Table Formats Decide Your Unit Economics
If your AI data sits in a proprietary silo, every additional engine you point at it, training, retrieval, BI, feature engineering, means another copy and another compute bill. That cost compounds quietly and caps how many use cases your platform can carry before finance starts asking hard questions.
Apache Iceberg has emerged as the common answer. Qlik Open Lakehouse maintains one continuously optimized copy of data queryable from Snowflake, Databricks, Spark, Trino, Athena, and SageMaker, with reported 2.5x to 5x query performance against unoptimized tables and up to 50% lower cost.
Unstructured Content Needs the Same Controls as Your SQL Estate
Policies, contracts, manuals, and support transcripts are production inputs now. They feed retrieval systems that answer customers and staff. A retrieval system pointed at an open file share inherits every stale document and every misconfigured folder in it.
A vector index built from uncontrolled files can reproduce outdated or restricted information even if the underlying data lake is well governed. And embeddings can encode semantic information from sensitive source content, access to vectors and indexes should inherit source permissions where the derived representation could enable retrieval of protected information.
The 30-Day Data Roadmap You Can Start Monday
If you’re tired of reading about the problem and want something actionable, here’s a concrete starting point. Pick one stalled pilot. Don’t try to fix the entire data estate. Then measure three numbers:
- The age of its data at inference time. Compare against the staleness the decision can tolerate. A negative gap tells you the delivery pattern is wrong, not the model.
- The share of its inputs covered by an enforced quality contract. “Enforced” means a failing batch stops moving. Anything below 100% coverage is an open path from bad data to a live decision.
- Engineer-days spent preparing data per use case. When preparation is measured in weeks, you’re paying the data-product tax repeatedly instead of once.
If data age exceeds decision tolerance, coverage sits below 100%, or preparation runs into weeks, you have your roadmap. It’s a data roadmap, not a model roadmap, and the sequence matters: ownership and contracts first, enforcement second, architecture third.
Enforcement without a named owner produces alerts nobody acts on. New architecture without contracts moves the same ambiguity onto a faster platform.
The Pipeline Problem Nobody Wants to Own
Interestingly, the data engineering community has been wrestling with pipeline observability and reproducibility almost as much as data quality itself. Pipeline reproducibility and discoverability in complex data environments often get treated as nice-to-haves, but they’re foundational to trusting any AI output. And the challenges of integrating data observability tools and achieving accurate lineage show that even when organizations invest in tooling, the integrations are often messy enough to defeat the purpose.
Even the data pipeline ecosystem itself struggles with discoverability. Improving discoverability in complex data ecosystems with centralized registries has become a priority precisely because finding the right operator or module in a sprawling ecosystem of 98 official providers and 1,602 modules is genuinely hard.
The Boring Conclusion
You cannot prompt your way out of a data foundation problem. A model that performs beautifully in the sandbox and a system you can defend in production are separated by data readiness, not model quality.
The organizations that will win the AI race aren’t the ones with the flashiest demos or the biggest model budgets. They’re the ones that grudgingly accept that data governance, discoverability, and quality are prerequisites, not optional extras. They’re the ones that package data as products with owners, contracts, and versioning. They’re the ones that move quality gates into their pipelines so failing batches get quarantined before they train a model or answer a customer.
And they’re the ones that will have an answer, backed by lineage documentation, not vibes, when an auditor asks where a specific AI output came from.
The data discoverability crisis isn’t a technology problem. It’s a prioritization problem. And the longer organizations treat data fundamentals as “boring” while chasing the AI hype cycle, the more pilots will stall, the more budgets will be wasted, and the more “revolutionary” AI initiatives will produce nothing but expensive PowerPoint decks.
The good news? The fix starts with measurement. And measurement is what turns a stalled pilot into a funded plan. You can’t prompt your way out of this, but you can measure your way into it.
