SAP AI has become one of the most overloaded phrases in enterprise software. Depending on who is speaking, it can mean SAP's own embedded copilots, a machine-learning service on BTP, or a developer calling a large language model from ABAP. This page is the hub for how we treat the topic on AIxSAP: AI in SAP as an architecture discipline — concrete integration patterns, production use cases, and the governance work that keeps AI systems trustworthy inside an ERP landscape.
Every guide linked below comes from real implementation work, with working code and the trade-offs spelled out. If you are evaluating how to bring AI into an SAP system — or cleaning up an experiment that grew into production — start here.
What "SAP AI" actually means in practice
It helps to separate three layers that usually get mixed together:
- Embedded SAP AI. Capabilities SAP ships inside its own products — Joule, predictive scenarios in S/4HANA, the AI services on Business Technology Platform. You configure and consume these; you don't architect them.
- Platform AI on BTP. SAP AI Core, generative AI hub, and the surrounding BTP services. Powerful, but they add licensing, infrastructure, and organizational prerequisites that many teams don't have yet.
- Custom AI integration. Your SAP system talking to AI models directly — LLM APIs called from ABAP, retrieval pipelines over SAP knowledge, vision models reading documents that end up as postings. This is where architects make or break the outcome, and it is the main focus of this hub.
The third layer is not a workaround. For many scenarios — code review, document extraction, anomaly detection, internal assistants — a direct, well-governed integration is simpler, cheaper, and easier to audit than standing up a full platform stack. The catch is that "well-governed" is doing a lot of work in that sentence. That is what the articles below are about.
SAP AI integration patterns: calling LLM APIs from ABAP
The foundational question for any SAP AI integration: how does the model get called, and what happens when the call misbehaves? An LLM endpoint is just an HTTPS API — but one with streaming responses, token-based pricing, aggressive rate limits, and failure modes (overloaded models, mid-stream disconnects) that classic RFC-era error handling doesn't anticipate.
Three deep dives cover this layer end to end:
- Claude API ABAP Integration Without BTP — the reference pattern for connecting ABAP directly to a modern LLM API: SM59 destinations, TLS, API-key handling, request construction, and why you don't need a BTP subscription to do this cleanly.
- OpenAI API in ABAP: Auth, Streaming & Errors — the production-hardening layer: authentication strategy, handling streamed responses in a language that predates SSE, and building retry logic around real API error semantics.
- Claude Function Calling with ABAP: Safe BAPI Triggers — the step most teams get wrong. Letting a model trigger BAPIs is agentic AI inside your ERP; this guide covers the allowlisting, validation, and authorization boundaries that make it safe rather than terrifying.
The common thread: treat the model as an untrusted external system. Validate at the boundary, never let generated output flow into a posting or a dynamic statement unchecked, and design for the day the API is down.
RAG: grounding AI in your SAP knowledge
A raw LLM knows SAP in general and your system not at all. Retrieval-augmented generation closes that gap: index your functional specs, custom code documentation, and configuration rationale, retrieve the relevant pieces at question time, and let the model answer from evidence instead of memory.
RAG Pipeline for SAP Docs with Open-Source LLMs builds this with open-source models — embeddings, chunking decisions that respect how SAP documentation is actually structured, and the evaluation loop that tells you whether retrieval is helping or just adding latency. Running it on open models also keeps sensitive system documentation inside your own infrastructure, which for many SAP shops is the deciding factor.
AI use cases in SAP that survive contact with production
Two families of use cases have consistently justified their cost in our experience:
- AI Invoice Extraction in SAP with LLM Vision — vision-capable models reading supplier invoices and producing structured data for posting. The interesting part is not the extraction; it's the confidence thresholds, human-in-the-loop routing, and reconciliation checks between the model and the ERP that make the numbers trustworthy.
- AI Anomaly Detection in SAP: Practical Guide — finding the postings, price changes, and master-data edits that don't fit the pattern. This one deliberately weighs classic statistical methods against ML approaches, because the honest answer is that you rarely need a neural network to catch a duplicated invoice.
Both share a design rule worth stealing: AI proposes, deterministic logic disposes. The model's output is a candidate, never a fact, until a rule-based check or a human confirms it.
Guardrails and governance: the unglamorous part that decides everything
The gap between an impressive demo and a production SAP AI system is governance. Models hallucinate, drift, and fail in ways that traditional software doesn't, and an ERP is the last place to discover that in an audit.
AI Guardrails for SAP: Stop Hallucinations in Prod is the playbook: input and output validation layers, grounding checks, confidence gating, audit trails for every model decision, and the organizational question of who owns an AI mistake. If you read only one article from this hub before shipping, make it this one.
AI-generated ABAP: using LLMs on the development side
The other half of SAP AI is AI for SAP engineering — models writing and reviewing ABAP. Generated code that compiles is easy; generated code you can merge is not. LLM Generated ABAP Code: Quality and Review Guide lays out a review framework for the specific ways LLMs get ABAP wrong: plausible-but-obsolete patterns, hallucinated function modules, performance anti-patterns on HANA, and the checks (ATC, unit tests, human review tiers) that catch them before transport.
Intelligent process automation on BTP
Where AI meets workflow: combining RPA-style automation with model-based decisions on SAP BTP. SAP BTP ile RPA ve AI Entegrasyonu: Mimari Kararlar (in Turkish) works through the architectural decisions — what belongs in a bot, what belongs in a model, and what should have been a plain interface all along.
Where to start
A sequencing that has worked repeatedly:
- Pick a use case where wrong answers are cheap — code review assistance, documentation Q&A, anomaly flagging for human review. Not autonomous posting.
- Build the integration layer properly once — auth, error handling, logging, cost monitoring — using the direct API pattern. Every later use case reuses it.
- Add guardrails before widening scope — validation, audit trails, and confidence gates from the guardrails playbook, not after the first incident.
- Only then consider platform investment. If you reach the point where model orchestration, fine-tuning, or multi-team governance is the bottleneck, BTP's AI stack starts earning its complexity.
This hub grows as the field does — new patterns, new failure modes, new articles. For everything else on SAP architecture, ABAP craftsmanship, and S/4HANA, the full library is at /articles/.