A model that reads bad data does not throw an exception. It answers confidently, and the answer is wrong in a way nobody notices until a customer, an auditor, or a board member points it out. This is the failure mode that separates AI pipelines from the batch ETL jobs enterprises have run for decades. A traditional pipeline breaks loudly when an upstream schema changes: a column disappears, a job fails, an engineer gets paged. An AI pipeline absorbs the change, produces a plausible summary or recommendation from the altered data, and keeps running. The system looks healthy. The output is not.
The root cause is almost never the model. It is that most enterprises have never formalized what an upstream system owes a downstream consumer. A product team renames a field, changes a currency from cents to dollars, or starts backfilling nulls with zero, and nothing in the architecture stops that change from flowing straight into an embedding pipeline, a retrieval index, or an agent’s context window. Data contracts exist to close that gap. A data contract is an explicit, versioned agreement between the team that produces a dataset and every system that consumes it, covering the schema, the semantics of each field, freshness guarantees, and what happens when the producer needs to change something.
Enterprise AI raises the stakes on this discipline for two reasons. First, RAG pipelines and agent context windows treat data as prose, not as typed rows, so a subtle semantic shift, like a status code that used to mean “cancelled” now meaning “cancelled by customer” versus “cancelled by system”, never triggers a validation error. It just changes what the model believes to be true. Second, the consumers of enterprise data have multiplied. A table that once fed a single nightly report now feeds a vector index, a fine-tuning dataset, an agent’s tool call, and a dashboard, often with no single owner tracking who depends on what.
A working data contract for an AI pipeline should specify more than column names and types. It should state the business meaning of each field, the acceptable range and null handling, the update cadence and staleness tolerance the consumer can rely on, and a deprecation window before any breaking change ships. It should be enforced with automated schema validation at the point of ingestion, not discovered when an analyst notices the numbers look strange three weeks later. Treat the contract itself as a versioned artifact in source control, reviewed the same way an API change would be reviewed, because that is functionally what it is.
The organizational piece is the one enterprises underinvest in. Someone has to own each contract, someone has to be notified before a breaking change, and someone has to be accountable when a consumer silently degrades because a producer moved fast without checking who was downstream. This is not a tooling gap most enterprises have; it is a governance gap. The platform teams already building AI gateways, observability layers, and identity boundaries for agents are the right owners for this, because a data contract is simply the read side of the same trust boundary they are already enforcing on the write side.
If your AI outputs have started drifting in ways nobody can quite explain, do not start the investigation with the model. Start it with the last schema change nobody told the AI team about.
