Summary: Conventional AI readiness follows a staircase: clean the data for years, then build AI on top. That ordering places all the cost in year one and all the value in year three, which is precisely the shape of programme enterprise governance is designed to kill. Inverting the order, applying AI to the data estate first, profiling, describing, standardising, and quality-scoring it with AI rather than waiting for it to be clean, turns data readiness into the cheapest AI use case rather than its prerequisite.
In brief: Most of what constitutes data readiness, profiling, documentation, metadata generation, deduplication, quality-rule authoring, is tedious, pattern-heavy, language-heavy work. That happens to be exactly the class of work large language models and tabular foundation models handle well on messy data as it stands, no cleanup required first. This piece sets out a five-stage flywheel, Discover, Describe, Improve, Protect, Serve, that builds a single enterprise data knowledge graph with a confidence-weighted trust overlay, and a measurable graduation gate that decides when a data domain is actually ready for predictive or agentic AI. It maps directly onto SAP Business Technology Platform, and closes with a 24-week programme at a fictional FMCG company demonstrating how the measurement system works in practice.
In This Article:
- The problem: why the staircase model stalls
- The solution: an AI-for-Data flywheel, not a data-for-AI staircase
- The graduation gate, and why it matters more than the framework itself
- Where this maps onto SAP BTP
- A fictional programme demonstrating the measurement system
- The vision: why foundation models make trusted data more valuable, not less
The problem: why the staircase model stalls
Enterprise AI readiness programmes fail less often because the data dependency is false, and more often because the investment ordering is backwards. Cleaning, integrating, and governing data before building any AI on top of it is not a wrong dependency. AI systems pointed at duplicate customer records, inconsistent units of measure, and undocumented tables genuinely do fail, only faster and at greater scale. The ordering is the actual problem.
A staircase model places all the cost in year one and all the value in year three. That is precisely the shape of programme enterprise governance is built to kill, because a multi-year data cleaning effort with no business-visible outcome for twelve months reads as risk, not investment, to anyone holding the budget. The phrase "we are not ready for AI yet" is rarely a statement about the data itself. It is a statement about the business case for fixing it, and a business case that defers all value for a year or more struggles to survive its own governance review.
The solution: an AI-for-Data flywheel, not a data-for-AI staircase
Applying AI to the data estate itself, before any predictive or agentic use case, converts data readiness into the cheapest AI use case rather than its prerequisite, because profiling, documentation, and quality-scoring are exactly the kind of tedious, language-heavy work large language models already do well on data as messy as it currently is. This is the actual inversion the framework proposes.
Three properties make this an unusually good entry point for AI adoption specifically. The technical barrier is low, since the tools are designed for the mess rather than requiring cleanup first. The risk is low, since the work stays internal-facing and human-reviewed, an incorrectly drafted glossary entry gets corrected, not shipped to a customer. And the cultural effect compounds: the data organisation builds real AI fluency by using AI on its own problems, so that by the time higher-stakes AI use cases arrive, both the data and the people working with it are actually ready.
The framework organises this into five stages, each one adding structure to a single enterprise data knowledge graph rather than producing a standalone deliverable.
-
Discover. AI crawls and profiles the landscape, what data exists, where, in what shape, how fresh, how it is actually used, producing a living inventory nobody had to compile by hand.
-
Describe. AI drafts metadata, business-glossary entries, and table documentation, and reconstructs lineage by parsing SQL, views, and integration flows, turning tribal knowledge into reviewable text.
-
Improve. AI proposes quality rules, detects anomalies, standardises inconsistent variants, and resolves duplicate entities, with every change human-approved before it counts.
-
Protect. AI classifies sensitive data, personal, contractual, regulated, and suggests access policies, bootstrapping governance rather than waiting for a committee to design it from scratch.
-
Serve. A semantic layer with natural-language access delivers the first business-visible AI win, built entirely on the trust the first four stages have already accumulated.
Every stage writes into the same graph rather than producing an isolated output. Discover contributes nodes. Describe contributes semantic and lineage edges. Improve contributes identity edges and a trust overlay. Serve queries the finished structure. A denser graph makes every subsequent AI use case cheaper, which is the flywheel's actual mechanism, not a metaphor sitting on top of it.
In fig. The AI-for-Data flywheel. Five stages apply AI to the data estate itself; each pass compounds trust.
The graduation gate, and why it matters more than the framework itself
A data domain graduates from AI-for-Data to data-for-AI only when measurable conditions hold, not when a programme timeline says it should, which converts "are we ready for AI" from a feeling into a number a steering committee can actually track. This gate is arguably the single most important part of the whole framework, because it is what keeps the inversion honest rather than becoming an excuse to skip governance entirely.
Every AI-produced artefact in the framework, a glossary entry, a same-as link, an inferred lineage hop, an imputed value, is born probabilistic and carries a confidence score on a three-step ladder: AI-drafted, human-reviewed, certified. The Serve stage answers over certified paths by default, and stewards work a queue of high-value uncertain artefacts, prioritised by how much downstream value a given repair would create, not worked in an arbitrary order.
The gate itself checks four conditions before a domain graduates: coverage, a defined percentage of critical assets profiled and described; trust, a composite quality score above a set threshold, with a required percentage of edges certified rather than merely drafted; muscle, a minimum number of human-validated AI-on-data workflows the domain team has actually shipped; and guardrails, sensitivity classification and access policy in place for every asset the intended use case touches. Thresholds are set per risk class of the downstream use case, so a low-stakes internal dashboard and a customer-facing prediction do not graduate under the same bar.
Quality itself is not scored asset by asset in isolation. It propagates along lineage, so a downstream asset inherits trust from its weakest upstream parent, weighted by how strongly that weakest link should dominate the score. That framing turns remediation into an optimisation problem rather than an audit exercise: the highest-value repair is not necessarily the messiest-looking source, it is the one whose trust deficit, multiplied by how much downstream work depends on it, is largest. A visibly messy spreadsheet with few downstream dependents can matter less than a moderately imperfect source feeding a dozen critical processes.
In fig. One enterprise data knowledge graph, built in layers. Each stage densifies the same structure; the graph, not any single deliverable, is the compounding asset.
Where this maps onto SAP BTP
On an SAP-centric estate, the graph, the LLM access layer, the stewardship workflow, and the lakehouse for foundation-model workloads can all live inside SAP Business Technology Platform, which matters because co-locating them removes an entire synchronisation problem rather than adding one. Three design choices explain why.
The graph lives in HANA Cloud, triples, vector embeddings, and the relational data they describe, in one engine, which lets the trust overlay participate directly in authorisation: a query through Joule can be constrained, inside the database, to certified paths only. LLM access is brokered through the Generative AI Hub rather than embedded ad hoc, centralising model choice, prompt logging, data residency, and cost control as an audit requirement, not a convenience layer bolted on afterwards. And foundation-model workloads run where the lakehouse already is, inside Business Data Cloud's embedded Databricks environment, with the graduation gate implemented literally: a domain's data products are not exposed to the prediction workspace until the gate conditions actually evaluate true against the graph, not on a calendar date someone picked in advance.
| Stage | Primary SAP BTP / Business AI components |
|---|---|
| Discover | Datasphere catalog crawlers; BDC connectors to S/4HANA, ECC, and non-SAP sources; profiling jobs on SAP Databricks; LLM semantic typing via the Generative AI Hub |
| Describe | Generative AI Hub for glossary and documentation drafting; lineage parsing of CDS views and integration flows; graph written to the HANA Cloud knowledge-graph engine |
| Improve | MDG stewardship workflows consuming AI-drafted match and merge proposals; rule synthesis via the Generative AI Hub, executed in Datasphere and Databricks pipelines; foundation-model imputation and disagreement probes on SAP Databricks |
| Protect | LLM sensitivity classification; policy suggestions surfaced to data-governance workflows; tags in the graph drive authorisation |
| Serve | Joule and conversational analytics over certified semantic models; text-to-SQL restricted to certified paths |
| Graduate | Foundation-model workloads on SAP Databricks within BDC; predictions written back to S/4HANA processes; Joule agents consume gated domains |
A fictional programme demonstrating the measurement system
Buttered AB is a fictional Nordic FMCG company, and every figure attached to it is simulated, built to demonstrate how the framework's measurement system works, not to claim real-world performance. With that stated plainly once, the story is worth walking through for what it demonstrates about the mechanics.
The fictional case runs a 24-week AI-for-Data programme across three domains, customer, material, and trade promotions, starting from an estate that looks like most enterprises' actual mess: duplicate records, inconsistent formats, and undocumented pipelines, quantified below at week zero.
Two of the three domains pass the graduation gate by week twenty; the third does not, which is the point, a gate is meant to actually gate something, not wave every domain through on schedule. Two post-graduation pilots then isolate a specific effect worth naming directly: a demand-forecasting pilot and a churn-prediction pilot both show a measurable gap between a foundation model run on the raw, ungoverned estate and the same model run on certified data, with roughly half the improvement attributed to the data programme itself rather than to the model change. Whether that specific split holds in a real deployment remains an open, empirical question this story does not settle.
Simulated figures, shown to illustrate the measurement system
| Metric | Week 0 | Week 24 |
|---|---|---|
| Critical assets profiled | 8% | 96% |
| Columns with certified semantics | 3% | 71% |
| Duplicate customer records | 14.2% | 1.9% |
| Unit-of-measure variants (count) | 31 | 6 |
| SKUs missing GTIN or shelf-life data | 22% | 4% |
| Forecast-pipeline lineage documented | 0% | 100% |
| Assets with sensitivity tags | 11% | 93% |
| Composite quality score, customer domain | 0.66 | 0.90 |
| Composite quality score, material domain | 0.71 | 0.92 |
| Composite quality score, promotions and POS | 0.48 | 0.81 |
The same fictional programme also compares effort against a conventional, staircase-style approach reaching equivalent readiness in the same three domains:
| Traditional approach | AI-for-Data | |
|---|---|---|
| Elapsed time | 18 to 24 months | 6 months |
| Effort | Roughly 26 FTE-months | Roughly 9 FTE-months |
| First business-visible outcome | Month 12 or later | Week 8 |
| Documentation and glossary authored manually | Roughly 100% | Roughly 15% |
| AI-literate data team members at close | 0 | 11 |
The value of walking through it is not the numbers themselves. It is what the story demonstrates about the measurement system: an auditable, week-by-week narrative a steering committee can track, rather than a year-three promise with nothing to show before then.
The vision: why foundation models make trusted data more valuable, not less
As tabular and relational foundation models mature, predictions that once required months of feature engineering are becoming a rentable commodity, which shifts enterprise differentiation away from model-building and directly onto data trust, the exact asset this framework is built to accumulate. That is the strategic argument underneath the technical one, and it is worth stating plainly rather than leaving implicit.
Recent advances in this space support the maturity claim directly. Tabular foundation models now demonstrate accuracy competitive with tuned ensembles on small tabular data, with calibrated predictive uncertainty attached to every prediction, and the latest generation extends that regime to tens of thousands of rows and thousands of features, reaching parity with ensembles that previously took hours to tune. On the relational side, foundation models built specifically for zero-shot prediction over connected enterprise tables now report outperforming fully supervised baselines across multiple relational benchmarks.
Two consequences follow directly from that maturity, and they cut in the same direction. Foundation models plug straight into the flywheel already described: zero-shot imputation strengthens the completion stage with real confidence scores, disagreement detection between a model's prediction and a recorded value strengthens quality scoring, and embedding-based matching strengthens harmonisation. More importantly, the same maturity collapses the graduation barrier on the far side of the staircase. A foundation model pointed at duplicate customer records simply automates being wrong faster. The knowledge graph with its trust overlay is the asset a competitor cannot rent from a vendor, and as foundation models become more capable and more commoditised, that asset becomes more valuable, not less.
If your organisation's AI programme is stalled in a multi-year data cleanup phase, talk to Tarento's Data & Analytics team about what an AI-for-Data flywheel would look like on your own estate.
