SAP AI Core: A Developer's Guide

SAP AI Core is SAP's service on SAP Business Technology Platform for running and operating AI workloads. It is part of SAP AI Foundation, the tooling layer underneath SAP Business AI, and it gives developers the infrastructure to train, deploy, and serve models — including models they bring themselves — alongside the generative AI capabilities of the Generative AI Hub.

If your team already builds on BTP, AI Core is the piece that turns AI from an external API you call into workloads that run inside your own landscape, with your tenant, your resource groups, and your deployment lifecycle. This guide explains what AI Core is, how it relates to AI Launchpad and the Generative AI Hub, the concepts you meet on day one, and the setup a developer actually walks through.

AI Core, AI Launchpad, and the Generative AI Hub

The three names show up together constantly and get conflated just as constantly. They are distinct pieces:

Put simply: AI Core runs the workloads, the Generative AI Hub puts a curated set of foundation models behind the same API, and AI Launchpad is the web UI where you configure and monitor both.

The Generative AI Hub matters because it standardizes access. Instead of integrating a different vendor SDK for every model, you work through the AI API against deployments of generative models, and you switch models by changing the deployment or configuration rather than rewriting integration code. The catalog of available models changes over time, so treat the model list on the SAP Help Portal as the source of truth rather than any blog post — including this one.

Key Concepts

AI Core has a small set of nouns that everything else hangs on.

Tenants and resource groups

Your AI Core service instance comes with a tenant. Inside that tenant, resource groups partition workloads and artifacts — scenarios, configurations, deployments — so different teams or projects do not see each other's objects. Every AI API call is scoped to a resource group, and a default resource group exists out of the box. A typical setup maps teams or project stages onto resource groups within a tenant.

Executables, configurations, and workflows

Training workloads are defined as templates called executables — one kind for batch workflows (training pipelines) and one kind for serving (deployments). A configuration fills in the parameters for a run, and executing it produces an execution. The templates live in a Git repository you connect to AI Core (GitHub and GitLab are among the supported providers); AI Core syncs the repository and reads the templates from it. This Git-based flow is what keeps the training side reproducible: the pipeline definition is versioned code, not a UI artifact.

Deployments and inference endpoints

A deployment takes a serving executable, runs it, and gives you an inference endpoint — a URL your applications call for predictions. Deployments have a lifecycle (pending, running, stopped, and similar states) and can be stopped, redeployed, and deleted. For generative models, deployments of foundation models are what back Generative AI Hub calls.

The AI API

Everything above is reachable through the AI API — a REST API documented on the SAP API Business Hub and governed by an open specification that SAP publishes. The practical consequences for a developer:

• One authentication model: OAuth 2.0 client credentials, sourced from your service binding.
• One scoping mechanism: a resource-group header on every call.
• The same API surface for classic ML scenarios and generative deployments.

That last point is the quiet superpower. Your operational tooling — deployment scripts, monitoring, endpoint rotation — does not care whether the URL serves a classifier you trained yourself or a large language model from the Generative AI Hub catalog. One integration pattern covers both.

Serving Your Own Models vs. Consuming Generative AI

Two distinct jobs run on the same infrastructure.

Bring your own model. You package your model as a container image, push it to a connected registry (Docker Hub and the major cloud provider registries are among the options — the supported list is on the SAP Help Portal), and register a serving template that tells AI Core how to start it. AI Core runs the container and exposes the endpoint. You stay responsible for the image, the model inside it, and keeping both patched.

Consume generative AI. You skip containers entirely. The Generative AI Hub exposes a curated set of foundation models through the AI API; you create or use deployments of those models from AI Launchpad or programmatically. This is the path most application developers start with — chat completions, embeddings, and similar capabilities without operating anything yourself.

Orchestration

Gluing prompts, data, and filters together is where generative applications get real. The Generative AI Hub's orchestration capabilities, usable through the SAP AI SDKs, cover the patterns you end up needing: prompt templates with parameters, grounding against your own content, input filtering, and chained module calls. If your use case is a single call with a system prompt, plain AI API requests are enough. Once you need grounding or multi-step flows, orchestration is the layer that keeps that logic server-side and out of your frontend.

Typical Developer Setup

The bootstrap is the standard BTP service flow, followed by credentials plumbing:

1. Entitle and create an AI Core service instance in a subaccount (Cloud Foundry or Kyma both work).
2. Create a service binding — or a service key for code running off-platform. The binding carries the pieces you need:

{
  "clientid": "<oauth client id>",
  "clientsecret": "<oauth client secret>",
  "url": "https://<subaccount>.authentication.<region>.hana.ondemand.com",
  "AI_API_URL": "https://api.<region>.ai.ml.hana.ondemand.com"
}

1. Authenticate with client credentials against the token endpoint, then call the AI API — or use an SDK that wraps both steps.

In Python, the AI Core SDK turns the binding into a client in a few lines (field names follow the binding above; check the SDK docs for the current constructor):

from ai_core_sdk.ai_core_v2_client import AICoreV2Client

client = AICoreV2Client(
    base_url=credentials["AI_API_URL"],
    auth_url=credentials["url"] + "/oauth/token",
    client_id=credentials["clientid"],
    client_secret=credentials["clientsecret"],
)

for deployment in client.deployment.query(
    resource_group="default"
).resources:
    print(deployment.id, deployment.target_status)

For JavaScript and Java, the SAP Cloud SDK for AI provides the same kind of typed access, including modules for the Generative AI Hub and orchestration. For the account mechanics behind steps 1 and 2 — entitlements, instances, bindings — the SAP BTP skills category has the coverage.

What the free options are and where the current limits sit — plans, resource groups, deployment counts — varies over time and by account type. Check the current limits on the SAP Help Portal rather than caching numbers from tutorials.

Where to Start

Two entry points cover the first week:

• SAP Help Portal — the AI Core and AI Launchpad documentation is the canonical reference for concepts, plans, and limits.
• SAP AI Launchpad — subscribe to it in the BTP cockpit, connect your AI Core tenant, and use the Generative AI Hub playground to make your first model call before writing any code.

Common first tasks, roughly in order: create the service instance and binding, open AI Launchpad and create a resource group for your project, run a chat completion in the playground, then repeat that call from a small script with the SDK. Training pipelines come later — they need the Git, registry, and object store plumbing — and most teams validate the serving side first anyway.

Developing AI Core Workloads with an AI Assistant

Here is the uncomfortable truth about asking a general-purpose assistant to write AI Core code: the AI API surface, SDK method names, and available models change faster than assistant training data. Helpers confidently produce plausible-looking calls with wrong header names, invented endpoints, or SDK imports that do not exist. The failure mode is subtle — the code looks right and fails at runtime.

The fix is the same as for the rest of the SAP ecosystem: give the assistant curated context. The sap-ai-core skill packages AI Core and Generative AI Hub conventions — API patterns, SDK usage, deployment flows — so generated code matches the real surface. Pair it with the SAP Cloud SDK for AI skill when you are working in the SDK itself:

npx skills add secondsky/sap-skills --skill sap-ai-core
npx skills add secondsky/sap-skills --skill sap-cloud-sdk-ai

For the broader picture of AI-assisted SAP work, the SAP MCP server guide covers connecting assistants to live SAP systems, and the SAP AI agents guide goes deeper on agent patterns across the SAP AI stack.

Where to Go From Here

Pick one path and follow it end to end: subscribe to AI Launchpad, run a playground call, then reproduce it from the SDK in a script you control. That single loop teaches you the tenant model, resource groups, deployments, and the AI API without touching training infrastructure. When you want assistant-ready context for the rest of the stack, browse the SAP AI skills category and the full skills catalog.