There is a version of the AI conversation that goes nowhere. It starts with a capability list, moves to a pilot, and ends with a proof-of-concept nobody puts into production, because the output is not trusted where it matters.

A pilot can fail even when the model performs well if data, process, authorization, and human boundaries are weak. Where that is the case, the condition can predate the pilot and persist through it.

What a governed Business AI use case stands on A six-layer stack listed from the foundation upward: ownership, semantics, process consistency, authorization, human boundary, operability. A dashed band above the stack holds the AI use cases, which rest on all six layers. AI use cases 1 Ownership 2 Semantics 3 Process consistency 4 Authorization 5 Human boundary 6 Operability Readiness Foundation What a governed Business AI use case stands on A six-layer stack listed from the foundation upward: ownership, semantics, process consistency, authorization, human boundary, operability. A dashed band above the stack holds the AI use cases, which rest on all six layers. AI use cases 1 Ownership 2 Semantics 3 Process consistency 4 Authorization 5 Human boundary 6 Operability Foundation
Six ordinary questions, each of which needs an owner before the use case above it is worth discussing.

What SAP is shipping

Briefly, so the rest of this is grounded. SAP Business AI is SAP's umbrella for AI across its applications. Joule is SAP's AI copilot, embedded across SAP solutions, and SAP has extended the portfolio toward task-specific agents. On the data side, SAP Business Data Cloud — announced in February 2025 — brings together SAP Datasphere, SAP Analytics Cloud and SAP Business Warehouse, with SAP Databricks as a first-party service.

This portfolio is real, it is moving quickly, and none of it changes the readiness question.

The readiness question

AI in an ERP context does one of two things: it summarizes, or it acts. The distinction determines how much you need to have in order first.

Summarizing is forgiving. A copilot that drafts a response, explains a variance or finds the right transaction is useful even when the underlying data is imperfect, because a human reads the output before anything happens. A lower-risk starting point is work of this kind, which needs less preparation than vendors' readiness checklists imply.

Acting is not forgiving. Anything that posts, routes, approves or triggers downstream work inherits every weakness in your master data and process design, and applies it consistently and quickly. If your vendor master has duplicates, an agent that automates invoice matching does not reduce duplicate-payment exposure; incorrect automation can amplify an existing control weakness.

So the readiness question isn't "which features should we enable". It is: for which specific decisions is our data good enough to let something act without a human in the loop? Naming the specific decisions that qualify — and the ones that do not — is a better foundation than a pilot.

  • Ownership — someone decides what a valid record is.
  • Semantics — the same term means the same thing across systems.
  • Process consistency — the process runs the same way twice.
  • Authorization — what a person may see governs what an assistant may use.
  • Human boundary — which decisions stay with a person, decided in advance.
  • Operability — someone owns the result after it goes live.

Four things worth establishing first

1. Master data ownership, by domain. Not a data-quality project — an owner. Who decides what a valid vendor record looks like, and who is accountable when it isn't? Ask the question for your top three domains; everything downstream depends on the answer.

2. Process consistency where you intend to automate. If the same transaction is handled three ways across two entities because of history, automation will encode whichever way is present in its inputs. Reconcile the variants, or narrow the automation scope to where they don't exist.

3. A defensible data foundation. Whether SAP Business Data Cloud is the right destination is a genuine architectural question with genuine trade-offs. But the first question is whether the numbers your business already relies on can be traced to a source anyone would defend in an audit. Where that isn't true, no platform decision fixes it.

4. A clear position on the boundary. Decide in advance where a human must remain in the loop — period-close postings, partner billing, anything touching statutory reporting — and write it down. Set the human boundary before adoption so accountability is explicit from the beginning.

Where this leaves you

Nothing above says don't adopt AI. It says sequence it: select lower-consequence use cases for initial assessment, where a human reads the output, fix ownership and consistency in the domains where you intend to automate, and treat the platform decision as a consequence of those, not a prerequisite.

Getting value from AI in an ERP estate depends less on adopting early than on whether master data was already someone's job.

Scope of this note

This describes readiness assessment and governance. No SAP Business AI, Joule, SAP Business Data Cloud, SAP Datasphere or SAP Analytics Cloud implementation experience is claimed.

BTP, data and AI readiness