Intro
Generative AI has arrived in board packs as both opportunity and anxiety. SAP customers are being shown copilots for finance, procurement, supply chain, shop-floor operations, and “intelligent” extensions on BTP. The demos are compelling. The platform implications are often less visible.
If your ERP landscape still has fragmented master data, ad hoc integrations, unclear API ownership, or inconsistent controls, AI will not fix the foundation. It will amplify the weaknesses. Leadership teams need a sequence that protects regulated data and connects AI investment to decisions already being made around S/4HANA, cloud, integration, and data governance.
Executive summary
Treat every SAP AI pilot as an architecture decision, not an innovation side-project. The questions that matter for executives are rarely about the demo. They are about data residency, identity, access control, logging, auditability, and accountability when a model-assisted process influences inventory, revenue, purchasing, or personal data.
A practical sequence is simple: stabilise the data and integration foundations, define which data classes may be used by AI services, then fund use cases with measurable outcomes linked to the SAP and BTP roadmap. Skip that sequence and you risk buying demonstrations rather than building capability.
Why pilots multiply without strategy
Business units can now launch AI proofs of concept faster than enterprise architecture can review them. Each pilot may choose its own data copy, integration route, security model, monitoring approach, and cost assumptions. Within two quarters, organisations can find themselves with a shadow AI estate sitting around the core ERP landscape.
That creates three risks for leadership: duplicated spend, unclear accountability, and architecture debt hidden behind attractive prototypes. The point is not to slow innovation. The point is to separate experiments that inform a platform strategy from experiments that quietly become permanent exceptions.
BTP, APIs, and the integration you already owe
SAP Business Technology Platform is often the natural home for SAP extensions, automation, integration, and AI services. But BTP does not remove the need for architecture discipline. It makes that discipline more important.
Before scaling copilots or AI-enabled processes, leadership teams should ask whether the organisation has clear API ownership, agreed integration patterns, event and data standards, identity controls, and monitoring across the landscape. When models start reading master data, triggering workflows, or supporting business decisions, weak integration design becomes a business risk.
Governance also needs to be short, practical, and enforceable. Useful guardrails include approved data classes, prohibited use cases, human review requirements for sensitive decisions, prompt and output retention rules, and clear accountability for audit trails. Legal, security, architecture, and data protection teams need plain-language decision flows, not just technical diagrams.
Practical leadership takeaway
The right question is not “Which AI pilot should we launch?” The better question is “What platform, data, and governance decisions must be in place before AI becomes part of our operating model?”
Before approving SAP AI spend, leadership teams should ask:
1. Which business decision or process outcome will this improve?
2. What SAP, BTP, integration, and data dependencies does it create?
3. Which data classes will the AI service access, store, or infer from?
4. Who owns the decision if the AI-assisted output is wrong?
5. Can this pilot scale into the enterprise architecture, or will it become another exception to govern later?
AI can create real value in SAP landscapes, but only when it is treated as part of the platform strategy. Otherwise, the organisation may gain an impressive demo and inherit another layer of complexity.