The Data Contract Is Your Real AI Roadmap

We have reviewed enough stalled AI initiatives to notice a pattern. The pilot works. The demo impresses the steering committee. Then the solution meets production data and quietly dies — not because the model was wrong, but because nobody could say who owns the customer record, what active means in the source system, or whether last quarter's schema change was intentional. The failure is almost never algorithmic. It is contractual.

Our position is blunt: before you fund another AI use case, fund the data contracts that use case depends on. A data contract — an explicit, versioned agreement between a producing system and its consumers covering schema, semantics, quality thresholds, refresh cadence, and ownership — is the smallest unit of governance that actually changes AI outcomes. Everything else in a typical data strategy deck is downstream of it.

Why lake-first thinking keeps failing AI programs

The last decade taught enterprises to centralise first and figure out meaning later. Land everything, worry about semantics when someone asks. That worked reasonably well for dashboards, where a human analyst supplies the missing context and silently corrects for oddities. It fails badly for AI, because models cannot infer intent. They absorb whatever ambiguity you feed them and express it as confident output.

In one commerce engagement we found four defensible definitions of "order value" — with and without tax, with and without cancelled lines, in transaction currency and in reporting currency. None were wrong. All were undocumented. A margin-prediction model trained across that ambiguity produced results that were plausible enough to be dangerous. No amount of feature engineering fixes a semantics problem; it only obscures it.

What a workable data contract actually contains

Contracts fail when they become documentation exercises. Keep them small, machine-readable, and enforced in the pipeline rather than in a policy PDF.

• A named owner with budget. Not a committee, not "the data team" — an accountable product or platform owner in the producing domain who can prioritise fixes.
• Schema plus semantics. Field types are the easy part. The valuable part is what each field means, its permitted values, and the business event it represents.
• Quality and freshness thresholds. Explicit, measurable commitments: completeness targets, acceptable null rates, maximum latency. Consumers build against these, so breaches become incidents, not surprises.
• Versioning and deprecation rules. Breaking changes are legitimate; unannounced breaking changes are not. Contracts define notice periods and parallel-run windows.
• Lineage and permitted use. Where the data came from and what it may legally be used for — increasingly non-negotiable under the EU AI Act and comparable regimes.

Governance as an enabling function, not a gate

The word governance triggers understandable resistance because it usually arrives as a review board that adds six weeks to every request. That model is incompatible with AI delivery cycles. The alternative is governance implemented as platform capability: automated contract validation in CI, quality tests running against every pipeline execution, catalogue entries generated from code rather than maintained by hand, access provisioned through policy-as-code.

Measured properly, this makes teams faster. When a data scientist can find a dataset, read its contract, see its freshness SLA, and request access in an afternoon, discovery work collapses from weeks to hours. Governance stops being the tax on AI and becomes the reason AI ships.

Where to start when everything needs fixing

Nobody contracts an entire estate. Work backwards from value. Pick the two or three AI use cases with genuine executive sponsorship, trace their critical data dependencies to source, and contract only those. In a typical SAP-centric landscape that is a handful of entities — customer, product, order, interaction history — not hundreds.

Then insist on one discipline: no new AI use case enters build until its data dependencies are under contract. It feels slow for a quarter. It compounds thereafter, because the second use case inherits contracts from the first, and the fifth inherits most of what it needs.

The forward view

As agentic systems begin acting on enterprise data rather than merely reporting on it, the cost of ambiguous semantics shifts from a bad chart to a bad transaction. Organisations that treated governance as compliance theatre will discover their AI ambitions are capped by their weakest data definition. Those that built contracts early will find that the models were always the cheap part.