As the race to deploy generative AI and autonomous agents accelerates across global enterprises, a quiet but consequential institutional consensus is forming: the limiting factor is not the model — it is the data the model is fed.
Think of it like building a high-performance race engine and then filling the tank with contaminated fuel. The engineering inside the engine might be flawless, but the car still stalls. That is precisely the situation most large organizations find themselves in today. They have invested heavily in sophisticated AI infrastructure, yet the data flowing through it carries years of accumulated inconsistencies, ownership gaps, and structural fragmentation.
What Is Enterprise Data Quality?
Data quality refers to the degree to which data is accurate, consistent, complete, timely, and trustworthy enough to be reliably used in decision-making systems — including AI models. In an enterprise context, this is harder than it sounds. Large organizations accumulate data across ERP systems (enterprise resource planning software that manages core business processes like finance and supply chain), custom databases, spreadsheets, emails, and dozens of disconnected third-party applications, often spanning decades of technological change.
The result is that the same product might carry three different names across three different divisions. A financial figure might be calculated differently depending on which team’s spreadsheet you open. When an AI model is trained or prompted against this kind of environment, it inherits every one of those inconsistencies.
“We are not struggling with the amount of data,” said Bejoy John, senior director of enterprise data management at Wesco. “We are sitting on volumes and volumes of it. But the data lacks quality, ownership, observability and accountability. That’s why many AI systems become brittle and people stop trusting them.”
The Real Mechanics
The mechanics of data failure in AI systems are specific and worth unpacking in detail. There are four distinct failure modes that practitioners encounter repeatedly in enterprise deployments.
1. Lack of ownership and accountability. When no one is clearly responsible for the quality of a particular dataset, errors accumulate silently. Fields go unstandardized. Null values multiply. Timestamps drift out of sync.
2. Missing observability. Observability in data engineering means the ability to monitor what is happening inside data pipelines in real time — detecting anomalies, schema changes, or data drift before they corrupt downstream models. Without it, AI systems degrade quietly rather than loudly.
3. Poor data lineage. Data lineage — the ability to trace how a value moved from a source system through transformations into its final form — is what John describes as following “breadcrumbs.” Without it, when a model produces an unexpected output, engineers cannot diagnose why. John put it plainly: “You should be able to explain exactly how a number travelled from a source system all the way into a financial report or AI model.”
4. Absent versioning and context. Padmashree Shagrithaya, executive VP and head of insights & data for India at Capgemini, raised a particularly sharp example: AI-powered HR policy assistants. In most large companies, HR policies evolve over years, creating overlapping documentation. Humans instinctively apply timeline context — they know the 2019 policy was superseded by the 2022 revision. AI systems do not, unless the data is properly versioned and tagged. “If the data is not versioned properly, the AI agent may pull the wrong policy or wrong context,” she said.
The HP case is instructive as a real-world stress test. Kamlesh Solanki, director of data engineering at HP, described an AI system that monitors millions of PCs and printers globally, detecting early signs of hardware failure by analysing telemetry data — battery degradation, storage health, thermal performance — before customers notice a problem. Automated tickets are generated and replacement parts dispatched proactively. It is a genuinely impressive deployment. But Solanki was unambiguous about the dependency: “If the telemetry data is noisy or inconsistent, the AI starts recommending the wrong parts and you are back to square one. Then you have wasted logistics, multiple repair visits and frustrated customers.”
This pattern — where the AI system architecture is sound but the data pipeline is the point of failure — is consistent across industries. Understanding it is foundational for anyone serious about optimising data analytics with AI at scale.
Why Real-Time Data Governance Is Now a Safety Issue
The stakes escalate sharply when AI systems operate in physical environments. Naveen Kamat, chief digital and AI officer at Larsen & Toubro, the Indian engineering and construction conglomerate, described deploying drones, robotics, and physical AI systems on active construction sites. The systems monitor workers in hazardous environments, detecting in near real time whether safety equipment is being worn correctly and alerting managers immediately when it is not.
“If the data is not available within the window where it can make an impact, it may no longer be relevant,” Kamat said.
This is a qualitatively different problem from a misclassified product name in a catalogue. Latency and data freshness become safety-critical variables. A data pipeline that delivers information five minutes late in a finance context is annoying. In a live construction site monitoring context, it could mean a worker in a hazardous environment is not flagged in time.
The convergence of two trends — the rise of autonomous AI agents capable of taking independent action, and the expansion of AI into physical-world environments — creates a compounding governance risk that the industry has not yet fully priced in. Shagrithaya’s observation that agentic AI transforms “garbage in, garbage out” from an analytics inconvenience into a genuine business risk is actually an understatement in physical deployment contexts: when the system controls logistics, maintenance scheduling, or worker safety alerts, poor data quality stops being a data engineering problem and becomes an operational liability. This is a structural reason why combating data integrity issues in AI needs to move from a data team concern to a board-level governance priority.
How Data Quality Compares to Other AI Failure Modes
| Failure Mode | Typical Cause | Visibility | Fix Complexity | Time to Impact |
|---|---|---|---|---|
| Data Quality | Legacy fragmentation, no ownership | Low — silent degradation | High — requires org-wide process change | Immediate in production |
| Model Architecture | Wrong model class for the task | Medium — benchmark failure | Medium — swap or fine-tune | Caught in evaluation |
| Infrastructure / Latency | Underpowered pipelines, cold-start delays | High — measurable SLA breaches | Medium — scale or optimize | Operational, not strategic |
| Prompt / Context Window Design | Poor RAG retrieval, context pollution | Medium — inconsistent outputs | Low-medium — prompt engineering | Rapid iteration possible |
Edge Cases
The data quality problem is not uniform across all AI use cases, and it is worth being precise about where the failure modes bite hardest.
Retrieval-augmented generation (RAG) systems — architectures where a language model queries a private knowledge base at inference time rather than relying solely on its training data — are highly sensitive to document versioning and metadata quality. Inconsistent timestamps or missing source identifiers cause the retriever to surface stale or conflicting documents, exactly the scenario Shagrithaya described with HR policies.
Time-series models used in predictive maintenance (like HP’s hardware monitoring system) are sensitive to telemetry drift — gradual shifts in sensor calibration that aren’t errors per se, but silently corrupt the signal distribution the model was trained on. This is a form of data quality failure that has nothing to do with human error and everything to do with physical-world entropy.
Multi-modal pipelines that ingest drone imagery, engineering drawings, and ERP records simultaneously — as Larsen & Toubro does — face schema misalignment problems at every integration boundary. Ensuring that a drone timestamp, a procurement event, and a safety log all refer to the same site, contractor, and time window requires persistent entity resolution infrastructure. This is one of the less-discussed challenges covered in analyses of advanced analytics in supply chain management.
Common Misconceptions
Misconception 1: “More data solves quality problems.” This is probably the most expensive misconception in enterprise AI. Scale amplifies inconsistency — it does not dilute it. Doubling the volume of poorly labelled, ungoverned data doubles the surface area for model error. Solanki’s reframe is useful here: the differentiator is not who has the most data, but who has “the most trusted, governed and contextual data.”
Misconception 2: “Data quality is a one-time cleanup project.” Many organisations treat data remediation as a migration sprint — clean everything up for the AI launch, then move on. But data is not static. New records arrive continuously, systems change, business logic evolves, and models drift. Governance has to be a continuous operational discipline, not a periodic compliance exercise. The shift to agentic AI makes this even more critical, since autonomous systems make decisions on live data rather than snapshots.
Misconception 3: “The model will learn around bad data.” Fine-tuned or heavily trained models can mask data quality issues temporarily, but they do not resolve them. They learn the noise as signal. When the noise pattern changes — a sensor is recalibrated, a taxonomy is updated, a supplier renames a product — the model’s learned compensation breaks down. Engineers end up debugging what looks like a model regression but is actually a data shift. Understanding this distinction is essential for teams trying to build genuinely data-driven AI practices.
Where to Learn More
- DAMA International’s Data Management Body of Knowledge (DMBOK) — the industry standard framework for enterprise data governance, lineage, and quality management.
- dbt documentation — the most widely adopted practitioner toolchain for building observable, tested, and lineage-tracked data transformation pipelines.
- McKinsey’s “The Data-Driven Enterprise of 2025” — provides institutional framing on how leading organisations are restructuring data ownership and governance at the executive level.
How Serious Players Should Respond
The practitioner consensus emerging from executives at HP, Capgemini, Wesco, and Larsen & Toubro carries a clear institutional message: organizations that treat data governance as an IT housekeeping task will not be able to scale AI into production systems that matter. The response required is structural. Chief data officers and engineering leaders need to establish continuous data observability infrastructure — not one-time audits — with clear ownership assigned at the domain level, not the platform level. Data lineage tooling should be a prerequisite for any AI deployment entering production, not a retrospective add-on.
For engineering teams specifically, the immediate priority is instrumentation: every data pipeline feeding a production AI system should emit quality metrics — completeness, freshness, distribution drift — to a centralized observability layer. The goal is to make data failures as loud and actionable as application errors, not silent and ambiguous. Teams that have invested heavily in model evaluation frameworks should apply the same rigour upstream, at the data layer, where the actual risk lives.
At the board and regulatory level, the expansion of autonomous AI agents into pricing, logistics, safety monitoring, and HR processes means that data governance is no longer an efficiency question — it is a liability question. Institutions that cannot demonstrate auditable data lineage and version control for the inputs feeding autonomous decision systems will face increasing scrutiny from regulators and counterparties alike. The organizations that build that infrastructure now will have a durable structural advantage that a better model cannot easily replicate.
