Guide

How does SAP Business Data Cloud support AI — the five mechanisms a consultant designs

As of 2026-09-25

Edited by Cédric-Olivier Mâry, sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

SAP Business Data Cloud supports AI by supplying what a model cannot invent: business data with its meaning, its lineage and its access rules attached. Governed Data Products carry the data, Datasphere carries the semantics, the Databricks lakehouse carries machine learning, the SAP Knowledge Graph carries the relationships between business entities, and one Catalog carries the access rules to every consumer, Joule and agents included.

BDC does not host the models themselves. Those run in SAP AI Core and its generative AI hub; BDC is what they are grounded on. The consultant's job is therefore a data-platform job, not a prompt-writing one.

Where BDC sits in SAP's AI architecture

At Sapphire 2026 SAP described the SAP Business AI Platform in three tiers: a context layer made of the SAP Knowledge Graph, SAP Domain Models and SAP Business Data Cloud; a build layer, Joule Studio; and a governance layer anchored by SAP AI Agent Hub on SAP LeanIX. BDC is therefore one of the three pillars of the context layer, not the whole of SAP's AI story.

An agent that explains a margin variance is only as good as the context it retrieves; BDC makes that context governed, so the number Joule quotes is the number the controller sees in SAP Analytics Cloud.

Mechanism 1 — Data Products and the Catalog

A Data Product is a governed, subscribable data asset with a declared schema, a service-level agreement, lineage and data-access-control rules. It is authored in Data Product Studio, passes a mandatory consumer review, and publishes into the BDC Catalog. Breaking changes trigger a major version and a 90-day deprecation cycle.

For AI this matters more than for reporting: a dashboard user notices a wrong column, an agent repeats it with confidence. Anything Joule will ground against should go through Studio, however small it looks.

The Catalog is what turns five components into one stack. A data-access-control rule defined once at Catalog level applies automatically to what Joule surfaces in an answer. Deferring the Catalog reproduces pre-BDC fragmentation inside a BDC contract.

Mechanism 2 — Datasphere semantics and the Knowledge Graph

Datasphere Analytic Models carry business meaning: hierarchies, currency conversion, measures defined once. Joule agents consume these models for business context, which is why SAP-delivered semantic content is the core of the BDC argument for an SAP-majority estate.

The SAP Knowledge Graph sits underneath as an SAP-managed semantic map linking Customer, Material, Order and other entities across the estate. SAP Learning describes the S/4HANA graph as built on 452,000 ABAP tables, 80,000 CDS views and 7.3 million fields — that is the scale of mapping no project team rebuilds by hand. The graph carries meaning and relationships; facts and aggregations stay in Data Products, Datasphere or HANA tables. Use it when the question is about how entities connect, not about text similarity.

Mechanism 3 — Databricks inside BDC for machine learning

BDC includes a Databricks-managed lakehouse, pre-provisioned and billed through SAP, reachable through Spark notebooks, MLflow or DBSQL and governed through Unity Catalog. Delta Sharing lets SAP data be read in Databricks without an extract-and-load copy, carrying row-level security from SAP's data-access controls.

The AI loop closes through write-back: a churn score or demand forecast produced in a notebook lands in a Delta table, is shared back, registered as a remote table in Datasphere and then served to an SAC KPI or used for Joule grounding.

Two cautions from our pattern card. The DAC rules and Unity Catalog row-level security must be verified as aligned, not assumed — otherwise a notebook can see rows a user in the same role cannot. And the pattern is conditional: without a Python-native data team or an existing Databricks investment, it adds a second platform that buys nothing.

Mechanism 4 — grounding Joule and agents

Grounding happens along three routes, and a mature agent often combines them. Structured business answers come from Analytic Models and Data Products through Joule's analytical skills. Relationship questions go to the Knowledge Graph. Document-shaped content goes through the document grounding capability of the generative AI hub, whose managed pipelines store embeddings in a HANA vector store.

That last route has limits you design around: content refreshes daily and each pipeline holds at most 8,000 documents. It also has a sharp caveat on the Joule side. SAP's integration guide states that documents ingested into Joule's document grounding are available to all Joule business users of the tenant, and answers do not yet filter by user permissions. Confidential content therefore stays out of that route and goes into a separate AI Core grounding repository reached only by the agent that needs it.

A worked sizing example

AI load is not free inside a BDC tenant. Joule grounding queries and Knowledge Graph traversal draw on the same capacity-unit pool as replication flows, SAC live queries and Analytic Model evaluation. The smallest BDC tenant starts at 128 capacity units, against 64 for a standalone Datasphere tenant (BDC Capacity Units card).

Our own sizing estimate for a Tier-1 workload — an Analytics Legends estimate, not an SAP figure — lands at 130 to 240 capacity units steady-state and 280 to 360 at peak. Quoting the 128-unit floor and then adding Joule sets up a capacity conversation mid-project. Joule's grounding load scales with active users, so measure it in the tenant rather than borrowing one.

Decision table — which BDC mechanism for which AI need

Agent must answer a governed KPI question → Datasphere Analytic Model exposed through a Data Product; Joule analytical skill. Agent must reason over how customers, materials and orders connect → SAP Knowledge Graph; facts stay in Data Products. Agent must cite policies, manuals or tickets → document grounding pipeline; keep confidential repositories out of Joule's tenant-wide grounding. Data science team trains a forecast or churn model → Databricks-in-BDC with Delta Sharing and write-back; only with a Python-native team. SAP-only estate, business-user reporting, no ML team → Datasphere and Data Products; skip the Databricks tier. Any of the above for more than one consumer team → publish through Data Product Studio with consumer review first.

What we cannot assert

SAP publishes no price or SKU for the SAP Knowledge Graph in our corpus, and the Tier-1 capacity figures above are our own estimate, not SAP sizing guidance. We cannot state how many capacity units a given Joule rollout consumes: SAP publishes no rule of thumb, and it depends on active users measured in the tenant.

Frequently asked

Does SAP Business Data Cloud run the AI models?

No. Foundation models and your own models run in SAP AI Core and its generative AI hub. BDC supplies the governed data, semantics and relationships those models and Joule agents are grounded on.

Is the SAP Knowledge Graph part of BDC?

It is one of BDC's five components alongside the Catalog, Datasphere, the Databricks lakehouse and Joule, and SAP lists it with BDC in the context layer of the SAP Business AI Platform. Our corpus records no public price or SKU for it, so confirm packaging per deal.

Do I need Databricks to use BDC for AI?

No. Joule grounding on Analytic Models and Data Products works without it. The Databricks tier earns its place when a team trains its own models on large volumes or already runs Databricks.

Can Joule see data a user is not allowed to see?

For structured data, Catalog-level access rules apply to what Joule surfaces. For documents ingested into Joule's own document grounding, SAP states they are visible to every Joule user of the tenant, so that route needs classification before ingestion.