Embedded AI across SAP applications

#The 60-second version

Embedded AI is the AI that SAP builds into its own applications. It shows up as a button, a suggestion or a score on a screen people already use. A Summarize button on an S/4HANA object page is embedded AI. So is a drafted performance goal in SuccessFactors, a payment match proposal or a machine learning forecast in planning.

You don't build embedded AI. You decide whether to switch it on, for whom, at what cost, and how you'll know it works. That makes it the first place to look before anyone builds a custom AI app.

Embedded AI comes in three broad shapes:

• Predict: a model scores or forecasts something, such as a demand forecast or a match proposal with a confidence value.
• Generate: a language model drafts, summarizes or explains text, such as a job description or an error message.
• Converse and act: Joule and its agents answer questions and carry out steps across apps.

The question for a leader is simple: what are we already paying for, or could switch on, before we fund a build?

#Why it matters to the business

Three reasons make embedded AI the cheapest first move.

• It's already where the work happens. Users don't need a new tool. The suggestion appears inside the transaction they already run.
• SAP maintains it. The vendor updates and supports the feature through normal releases. You don't run models, servers or prompts.
• Much of it is included. SAP's commercial model splits AI into Base AI, included in standard cloud subscriptions, and Premium AI, paid for in AI Units. As of October 2026, SAP Learning says most generative AI capabilities start moving from Premium to Base from Q3 2026.

The risks are just as real:

• Standard fits standard. The feature assumes SAP's standard process. If your blocked sales orders get blocked for company-specific reasons, a standard feature may not see them.
• You can't tune the model. If proposals are wrong too often, your levers are who gets it, where people must review, and whether to keep it.
• "Switched on" isn't "used". A feature nobody trusts saves nothing. Adoption needs measuring, like any process change.

Take the running examples. In order-to-cash, a payment matching feature proposes which open invoice an incoming payment clears. In procure-to-pay, an invoicing assistant helps with supplier invoices. In hire-to-retire, a manager drafts goals with AI help. Each one is a decision: switch on, pilot, or skip.

#How SAP does it

As of October 2026, embedded AI appears across SAP's cloud portfolio. Status and dates below are as SAP published them; planned dates are not commitments.

Three things decide whether a feature is live for you.

1. Licence. Base AI comes with the subscription. Premium AI draws on AI Units, bought annually and pooled across SAP solutions. Unused AI Units expire after 12 months, per SAP's pricing page.
2. Activation. Each application has its own switch. In S/4HANA Cloud Public Edition, users get a feature through an authorization (an IAM app or business catalog). In SuccessFactors, an administrator turns features on in AI Services Administration.
3. Data terms. SAP says it does not give customer data to other vendors to train their language models. Where permitted, it may use customer data to improve its own AI features; customers who accept those terms can see which solutions use their data and opt out.

Earlier topics go deeper on the pieces: the SAP Business AI landscape, where AI creates value in S/4HANA, Joule and Joule Studio and the AI business case.

#A decision guide: switch on, pilot, extend or build

The rule of thumb: check, pilot, then build. Building first means paying twice if SAP ships the feature next release.

#Questions to ask

• Which AI features are already included in our subscriptions, per application, and which are switched on today?
• For each candidate feature: is it Base or Premium, and what would a year cost in AI Units at our volumes?
• Who in our company can switch features on, and through which authorization or admin setting?
• What do our contracts say about SAP using our data to improve its AI features, and have we opted in or out?
• How will we measure the pilot: which team works without the feature for comparison, and for how long?
• What does a wrong proposal cost in this process, and where must a person review before anything is posted?
• Which planned features in our roadmap depend on a date SAP hasn't confirmed as GA?
• After each release, who checks that the features we rely on still behave the same?

#Common misconceptions

• "Embedded means free." Base AI is included; Premium AI consumes AI Units. Check each feature.
• "It's switched on, so it's working." Activation is the start. Without measuring acceptance and time saved, you don't know.
• "Embedded AI replaces the custom build." It covers standard work. Company-specific exceptions often still need a side-by-side extension.
• "SAP trains other vendors' models on our data." SAP says it doesn't. Using your data to improve SAP's own features is a separate question, governed by your contract, with an opt-out.
• "Planned at Sapphire means available." Planned dates aren't commitments. Plan on what is GA in your system.
• "One switch turns on AI everywhere." Each application has its own activation, roles and settings.

#Key terms

All course terms, A to Z, in the glossary

• Embedded AI: AI features SAP builds into its applications and maintains for you.
• Base AI: AI capabilities included in standard SAP cloud subscriptions.
• Premium AI: advanced AI capabilities paid for in AI Units, per use or per user.
• AI Units: SAP's prepaid AI currency, bought annually, pooled across solutions, expiring after 12 months.
• AI Services Administration: the SuccessFactors admin tool where AI features are switched on.
• IAM app / business catalog: S/4HANA Cloud authorization objects that give users access to an app or feature.
• Pilot with a comparison group: some users work with the feature, some without, so the difference shows the effect.
• Acceptance rate: the share of AI proposals users keep unchanged.

#Check yourself

#Mental model: you own the switch, the threshold and the proof

With a custom build you own everything: data, model, prompt, code, hosting. With embedded AI, SAP owns the model and the code. You can't retrain it or rewrite its prompt.

What you still own is everything around it:

• The switch: which users get the feature, through which authorization or admin setting.
• The threshold: where the feature may act on its own and where a person must review. Some features expose a confidence value you can use for that; others only propose.
• The proof: whether it saves time and how often people accept what it proposes, on your data.
• The bill: Base or Premium, and AI Units per item.

An FDE's job with embedded AI is therefore not modelling. It is configuration, measurement and extension. You switch it on carefully, measure it honestly, and build only around its gaps.

#How it works

#Three delivery patterns

SAP doesn't publish the internals of every feature. From SAP's own descriptions, embedded AI reaches users in three patterns.

Whatever the pattern, the user sees the same thing: a proposal on a screen they already use.

flowchart LR
  U[User in SAP app] --> F[AI feature]
  F --> M[Model: ML, LLM or agent]
  M --> P[Proposal and confidence]
  P --> R{User decides}
  R -->|accept| S[Saved in SAP]
  R -->|edit| S
  R -->|reject| W[Manual work]
  F -.-> B[AI Units metered if Premium]

#The control points

Each step in that diagram has a control you can set or a signal you can measure.

#The three numbers that decide a pilot

You can't see inside a vendor model. You can see what users do with its proposals. Three numbers come out of that.

1. Acceptance rate: of all proposals, how many were kept unchanged. Edits and rejections count as misses. For drafting features, edits are normal, so read this one with care.
2. Time saved per item: average handling time without the feature minus average time with it. This needs a comparison group: people doing the same work without the feature during the same weeks. Before-and-after comparisons mix in seasonality and learning effects.
3. Confidence band: if the feature shows a confidence value, the lowest value above which proposals were almost always accepted. That band is your candidate for lighter review. You met thresholds in classification and the metrics that matter.

The time saving needs an error bar. With 100 items per group, a 30-second "saving" can be noise. A rough 95% interval for the difference of two means is the difference plus or minus 1.96 standard errors. If the interval includes zero, the pilot hasn't proved a saving yet.

#Why a comparison group, not a survey

Users like or dislike AI features for reasons beyond speed. A survey tells you about trust, which matters, but not time. Logs tell you time. Use both: logs for the business case, a few interviews to explain the edits.

#Build it yourself: a pilot scorecard for an embedded feature

You'll write a small tool that reads a pilot log and answers three questions per feature: how often users accepted the proposals, how much time the feature saved against people working without it, and above which confidence value proposals were safe. It writes a short report you can attach to a go or no-go decision.

You don't need an SAP system. The script makes up a realistic pilot log for three features. When you run a real pilot, you export the same columns from your own logs or a timing study and run the same script.

Before you start: complete Set up your computer for this course and Set up for Unit 12: local models. This walkthrough uses only Python's built-in modules, so there's nothing new to install, and it needs no account or key.

flowchart LR
  L[Pilot log CSV] --> S[embedded_pilot.py]
  S --> A[Acceptance rate]
  S --> T[Time saved with error bar]
  S --> C[Confidence band]
  A --> V[Verdict and report]
  T --> V
  C --> V

#What you need

• Your course folder orchestrate-course with its .venv, from the setup topics.
• 20 to 30 minutes.
• Cost: free. Everything runs on your computer with made-up data.

#Step 1: Open your course folder

1. Open VS Code, choose File > Open Folder, and open orchestrate-course.

2. Open a terminal with Terminal > New Terminal. Turn on the virtual environment if the prompt doesn't start with (.venv):

   Windows (PowerShell):

   Copy

   .venv\Scripts\Activate.ps1

   macOS or Linux:

   Copy

   source .venv/bin/activate

3. Check that the unit12 folder exists. If it doesn't, create it:

   Copy

   mkdir unit12

Run every command in this topic from the course folder, not from inside unit12.

#Step 2: Save the script

1. In VS Code, choose File > New File, and save it as unit12/embedded_pilot.py.
2. Paste this code and save again.

"""Pilot scorecard for an embedded AI feature you switched on, not built.

You can't retrain a vendor's model. What you can do is measure it on your
own work: how often users accept its proposals, how much time it saves
compared with people working without it, and (where it shows a confidence
value) above which value its proposals were almost always right.

Input: a CSV with one row per work item handled during the pilot.
  item_id     any id
  feature     name of the AI feature, e.g. cash_matching
  group       ai      = handled with the feature switched on
              manual  = handled the old way (the comparison group)
  confidence  0 to 1, if the feature shows one; leave empty otherwise
  outcome     for group ai: accepted | edited | rejected | no_proposal
              for group manual: leave empty
  seconds     handling time for the item

Run:
  python unit12/embedded_pilot.py --sample
  python unit12/embedded_pilot.py --csv my_pilot.csv
Options:
  --target-precision 0.98    precision a confidence band must reach
  --min-acceptance 0.6       acceptance rate you need to scale
  --ai-units FEATURE=VALUE   AI Units per item from your own estimate
  --report FILE              also write a Markdown report
Uses only the Python standard library.
"""

import argparse
import csv
import math
import random
import statistics
import sys
from pathlib import Path

OUTCOMES = {"accepted", "edited", "rejected", "no_proposal"}
MIN_BAND_ITEMS = 30  # don't trust a confidence band with fewer items


# ---------------------------------------------------------------- sample data
def make_sample(path, seed=12):
    """Write a made-up pilot log for three embedded features.

    Feature names describe the kind of task. Times and rates are invented
    for teaching; they are not SAP figures.
    """
    rng = random.Random(seed)
    rows = []

    def add(feature, group, seconds, confidence="", outcome=""):
        rows.append({
            "item_id": f"{feature[:3].upper()}-{len(rows) + 1:05d}",
            "feature": feature, "group": group,
            "confidence": confidence, "outcome": outcome,
            "seconds": max(5, round(seconds)),
        })

    # 1. Payment matching proposals with a confidence value (order-to-cash)
    for _ in range(600):
        if rng.random() < 0.08:
            add("cash_matching", "ai", rng.gauss(230, 60), "", "no_proposal")
            continue
        conf = min(0.999, max(0.30, rng.betavariate(6, 1.6)))
        p_right = 1 / (1 + math.exp(-18 * (conf - 0.7)))  # higher conf, more often right
        right = rng.random() < p_right
        if right:
            add("cash_matching", "ai", rng.gauss(25, 8), f"{conf:.3f}", "accepted")
        elif rng.random() < 0.6:
            add("cash_matching", "ai", rng.gauss(150, 40), f"{conf:.3f}", "edited")
        else:
            add("cash_matching", "ai", rng.gauss(240, 60), f"{conf:.3f}", "rejected")
    for _ in range(200):
        add("cash_matching", "manual", rng.gauss(220, 60))

    # 2. Purchase order PDF to sales order draft, no confidence shown
    for _ in range(300):
        r = rng.random()
        if r < 0.55:
            add("po_extraction", "ai", rng.gauss(90, 25), "", "accepted")
        elif r < 0.90:
            add("po_extraction", "ai", rng.gauss(200, 50), "", "edited")
        else:
            add("po_extraction", "ai", rng.gauss(420, 90), "", "rejected")
    for _ in range(100):
        add("po_extraction", "manual", rng.gauss(360, 80))

    # 3. Drafting performance goals from a short description (hire-to-retire)
    for _ in range(200):
        r = rng.random()
        if r < 0.30:
            add("goal_drafting", "ai", rng.gauss(300, 90), "", "accepted")
        elif r < 0.80:
            add("goal_drafting", "ai", rng.gauss(650, 160), "", "edited")
        else:
            add("goal_drafting", "ai", rng.gauss(1000, 220), "", "rejected")
    for _ in range(80):
        add("goal_drafting", "manual", rng.gauss(760, 200))

    path.parent.mkdir(parents=True, exist_ok=True)
    with path.open("w", newline="", encoding="utf-8") as f:
        writer = csv.DictWriter(f, fieldnames=list(rows[0]))
        writer.writeheader()
        writer.writerows(rows)
    return path


# ---------------------------------------------------------------- reading
def read_log(path):
    """Read and check the pilot CSV. Stops with a clear message on bad rows."""
    needed = {"item_id", "feature", "group", "confidence", "outcome", "seconds"}
    with open(path, newline="", encoding="utf-8-sig") as f:
        reader = csv.DictReader(f)
        missing = needed - set(reader.fieldnames or [])
        if missing:
            sys.exit(f"Missing columns in {path}: {', '.join(sorted(missing))}")
        rows = []
        for line, row in enumerate(reader, start=2):
            group = row["group"].strip().lower()
            outcome = row["outcome"].strip().lower()
            if group not in {"ai", "manual"}:
                sys.exit(f"Line {line}: group must be ai or manual, got {row['group']!r}")
            if group == "ai" and outcome not in OUTCOMES:
                sys.exit(f"Line {line}: outcome must be one of {sorted(OUTCOMES)}")
            try:
                seconds = float(row["seconds"])
                conf = float(row["confidence"]) if row["confidence"].strip() else None
            except ValueError:
                sys.exit(f"Line {line}: seconds and confidence must be numbers")
            rows.append({"feature": row["feature"].strip(), "group": group,
                         "outcome": outcome, "seconds": seconds,
                         "confidence": conf})
    if not rows:
        sys.exit(f"{path} has a header but no rows.")
    return rows


# ---------------------------------------------------------------- measuring
def time_saving(ai_secs, manual_secs):
    """Mean seconds saved per item, with a rough 95% interval (Welch)."""
    if len(ai_secs) < 2 or len(manual_secs) < 2:
        return None
    diff = statistics.mean(manual_secs) - statistics.mean(ai_secs)
    se = math.sqrt(statistics.variance(ai_secs) / len(ai_secs)
                   + statistics.variance(manual_secs) / len(manual_secs))
    return diff, diff - 1.96 * se, diff + 1.96 * se


def confidence_band(ai_rows, target):
    """Lowest confidence value whose proposals reach the target precision.

    "Right" means the user accepted the proposal unchanged. Edited and
    rejected proposals count as wrong.
    """
    scored = [r for r in ai_rows if r["confidence"] is not None
              and r["outcome"] != "no_proposal"]
    if len(scored) < MIN_BAND_ITEMS:
        return None
    for step in range(50, 100):
        t = step / 100
        band = [r for r in scored if r["confidence"] >= t]
        if len(band) < MIN_BAND_ITEMS:
            break
        precision = sum(r["outcome"] == "accepted" for r in band) / len(band)
        if precision >= target:
            return t, precision, len(band) / len(scored), len(band)
    return "none"


def score_feature(name, rows, args):
    ai = [r for r in rows if r["group"] == "ai"]
    manual = [r for r in rows if r["group"] == "manual"]
    counts = {o: sum(r["outcome"] == o for r in ai) for o in sorted(OUTCOMES)}
    proposals = len(ai) - counts["no_proposal"]
    result = {
        "feature": name, "ai_items": len(ai), "manual_items": len(manual),
        "counts": counts,
        "coverage": proposals / len(ai) if ai else 0.0,
        "acceptance": counts["accepted"] / proposals if proposals else 0.0,
        "ai_mean": statistics.mean(r["seconds"] for r in ai) if ai else None,
        "manual_mean": statistics.mean(r["seconds"] for r in manual) if manual else None,
        "saving": time_saving([r["seconds"] for r in ai],
                              [r["seconds"] for r in manual]),
        "band": confidence_band(ai, args.target_precision),
        "ai_units": args.ai_units.get(name),
    }
    result["verdict"], result["reason"] = verdict(result, args)
    return result


def verdict(r, args):
    if r["saving"] is None:
        return "NO VERDICT", "need at least 2 ai and 2 manual items"
    diff, low, high = r["saving"]
    if high < 0:
        return "STOP", "people are slower with the feature than without it"
    if r["acceptance"] < args.min_acceptance / 2:
        return "STOP", "users throw away most proposals"
    if r["acceptance"] >= args.min_acceptance and low > 0:
        return "SCALE", "accepted often enough and the time saving is clear"
    if low <= 0:
        return "KEEP PILOTING", "time saving not proven yet; collect more items"
    return "KEEP PILOTING", "time saved, but most proposals get changed; check why"


# ---------------------------------------------------------------- reporting
def describe(r, args):
    c = r["counts"]
    lines = [
        f"== {r['feature']} ==",
        f"Items with AI: {r['ai_items']}   without AI: {r['manual_items']}",
        f"Proposals made: {r['coverage']:.0%} of items "
        f"({c['no_proposal']} items got no proposal)",
        f"Of the proposals: accepted {c['accepted']}, edited {c['edited']}, "
        f"rejected {c['rejected']}  -> acceptance {r['acceptance']:.0%}",
    ]
    if r["saving"]:
        diff, low, high = r["saving"]
        lines.append(f"Seconds per item: {r['ai_mean']:.0f} with AI vs "
                     f"{r['manual_mean']:.0f} without")
        lines.append(f"Saved per item: {diff:.0f} s (95% range {low:.0f} to "
                     f"{high:.0f} s) = {diff * 1000 / 3600:.1f} hours per 1,000 items")
    band = r["band"]
    if band is None:
        lines.append("Confidence band: no confidence values (or too few)")
    elif band == "none":
        lines.append(f"Confidence band: no value reaches {args.target_precision:.1%} "
                     f"precision with at least {MIN_BAND_ITEMS} items")
    else:
        t, precision, share, n = band
        lines.append(f"Confidence band: at {t:.2f} and above, {precision:.1%} of "
                     f"{n} proposals were accepted unchanged ({share:.0%} of proposals)")
    if r["ai_units"] is not None and r["saving"]:
        per_1000 = r["ai_units"] * 1000
        hours = r["saving"][0] * 1000 / 3600
        per_hour = f"{per_1000 / hours:.2f}" if hours > 0 else "n/a"
        lines.append(f"AI Units: {per_1000:.1f} per 1,000 items, "
                     f"{per_hour} per hour saved (your estimate)")
    lines.append(f"Verdict: {r['verdict']} ({r['reason']})")
    return lines


def parse_units(values):
    units = {}
    for item in values or []:
        name, _, value = item.partition("=")
        try:
            units[name.strip()] = float(value)
        except ValueError:
            sys.exit(f"--ai-units needs FEATURE=NUMBER, got {item!r}")
    return units


def main():
    parser = argparse.ArgumentParser(description=__doc__.splitlines()[0])
    source = parser.add_mutually_exclusive_group(required=True)
    source.add_argument("--sample", action="store_true",
                        help="write and score a made-up pilot log")
    source.add_argument("--csv", help="score your own pilot log")
    parser.add_argument("--target-precision", type=float, default=0.98)
    parser.add_argument("--min-acceptance", type=float, default=0.6)
    parser.add_argument("--ai-units", action="append", metavar="FEATURE=VALUE")
    parser.add_argument("--report", help="write a Markdown report to this file")
    args = parser.parse_args()
    args.ai_units = parse_units(args.ai_units)

    if args.sample:
        path = make_sample(Path(__file__).parent / "pilot_log_sample.csv")
        try:
            path = path.resolve().relative_to(Path.cwd().resolve())
        except ValueError:
            pass  # script run from another folder: keep the full path
        print(f"Wrote made-up pilot log: {path}\n")
    else:
        path = args.csv
    rows = read_log(path)

    output = []
    for name in sorted({r["feature"] for r in rows}):
        result = score_feature(name, [r for r in rows if r["feature"] == name], args)
        output.extend(describe(result, args) + [""])
    print("\n".join(output))

    if args.report:
        fence = "`" * 3  # a Markdown code fence around the plain-text results
        text = ["# Embedded AI pilot report", "",
                f"Source: `{path}`  ",
                f"Target precision: {args.target_precision:.1%}  ",
                f"Minimum acceptance: {args.min_acceptance:.0%}", "", fence + "text"]
        Path(args.report).write_text("\n".join(text + output + [fence, ""]),
                                     encoding="utf-8")
        print(f"Report written to {args.report}")


if __name__ == "__main__":
    main()

#Step 3: Run it on the sample pilot

1. Run the script with made-up data:

   Windows (PowerShell):

   Copy

   python unit12\embedded_pilot.py --sample

   macOS or Linux:

   Copy

   python unit12/embedded_pilot.py --sample

2. You should see one block per feature. The first lines look like this:

Wrote made-up pilot log: unit12/pilot_log_sample.csv

== cash_matching ==
Items with AI: 600   without AI: 200
Proposals made: 92% of items (48 items got no proposal)
Of the proposals: accepted 391, edited 105, rejected 56  -> acceptance 71%
Seconds per item: 86 with AI vs 214 without
Saved per item: 128 s (95% range 117 to 139 s) = 35.6 hours per 1,000 items
Confidence band: at 0.83 and above, 98.0% of 255 proposals were accepted unchanged (46% of proposals)
Verdict: SCALE (accepted often enough and the time saving is clear)

== goal_drafting ==
Items with AI: 200   without AI: 80
Proposals made: 100% of items (0 items got no proposal)
Of the proposals: accepted 60, edited 101, rejected 39  -> acceptance 30%
Seconds per item: 625 with AI vs 794 without
Saved per item: 169 s (95% range 109 to 229 s) = 46.9 hours per 1,000 items
Confidence band: no confidence values (or too few)
Verdict: KEEP PILOTING (time saved, but most proposals get changed; check why)

3. Read the three features side by side:
   • cash_matching (payment matching in order-to-cash) shows a confidence value. Above 0.83, 98% of proposals were kept unchanged. That band is your candidate for lighter review.
   • po_extraction (purchase order PDF to sales order draft) saves time, but users change about half the drafts. Find out which fields they fix.
   • goal_drafting (hire-to-retire) saves time even though users edit most drafts. For a drafting feature, an edited draft can still be useful, so acceptance alone would mislead you here.

A valid "empty" result: Confidence band: no confidence values (or too few) means the feature didn't log a confidence, or fewer than 30 items had one. That is normal for drafting features.

#Step 4: Change the targets

The verdict depends on targets you choose with the business, not on the script.

1. Ask for a stricter band, as you might for anything that clears money:

   Copy

   python unit12/embedded_pilot.py --sample --target-precision 0.995

2. Check the cash matching line. You should see something like:

Confidence band: at 0.86 and above, 99.5% of 205 proposals were accepted unchanged (37% of proposals)

3. Notice the trade-off: a stricter target leaves fewer proposals in the band. That is the same precision-versus-volume choice as in classification and the metrics that matter.
4. Try --min-acceptance 0.4 and see which verdicts change.

#Step 5: Add cost and write a report

1. Add your own AI Unit estimate per item. The number below is made up; use the figure from your SAP estimate or account team:

   Copy

   python unit12/embedded_pilot.py --sample --ai-units cash_matching=0.01 --report unit12/pilot_report.md

2. The cash matching block now has a cost line:

AI Units: 10.0 per 1,000 items, 0.28 per hour saved (your estimate)

3. Open unit12/pilot_report.md in VS Code. It holds the same results with the targets you used. This is the file you'd attach to a go or no-go decision.

#Step 6: Score your own pilot log

1. Make a CSV with these columns, in any order: item_id, feature, group, confidence, outcome, seconds.

2. Use ai or manual in group. Use accepted, edited, rejected or no_proposal in outcome for ai rows, and leave it empty for manual rows. Leave confidence empty if the feature shows none.

3. Run it:

   Copy

   python unit12/embedded_pilot.py --csv my_pilot.csv

Where do real numbers come from? Some features log proposals and decisions; others don't. If yours doesn't, a timing study works: for two weeks, a few users note start and end times and what they did with the proposal. That is slower, but honest.

#Step 7: Save your work in Git

git add unit12/embedded_pilot.py unit12/pilot_report.md
git commit -m "Add embedded AI pilot scorecard"

The sample CSV can be recreated at any time, so you don't need to commit it.

#What each part of the script does

#If something goes wrong

#The SAP way

#S/4HANA Cloud Public Edition: features by role

SAP Learning describes five AI-assisted capabilities in the SAP Fiori launchpad, as of October 2026: Smart Summarization, Easy Filter, Error Explanation, Smart Personalization of My Home insights cards and the Smart App Finder. They are enabled per user through authorizations. For each one, SAP names a recommended IAM app and an alternative business catalog.

So rollout is a role design task. Add the catalog to the business roles of your pilot team, not to everyone at once. That gives you the comparison group for free.

#SuccessFactors: AI Services Administration

For Goal Management, SAP Learning lists three prerequisites: the latest Goal Management, an SAP AI Units licence, and the RBP permission Manage AI Capabilities > AI Services Administration. The administrator then:

1. Opens AI Services Administration through Action Search.
2. Under Global Features, turns on Assisted Writing, with its sub-options Translation and Text Analyzer.
3. Under Talent, turns on Assisted Performance Goals.

Other SuccessFactors features SAP names include applicant screening, interview questions generation, job description enhancement, AI-assisted people insights and AI-assisted skills architecture creation. Check each one's activation in its own administration guide.

#IBP: algorithms you choose

In SAP Integrated Business Planning, the embedded AI is closer to classic machine learning. SAP Learning lists about 20 forecasting algorithms, including Gradient Boosting, XGBoost and ARIMAX/MLR. You can put several algorithms in one forecast model and let the system pick the best fit. Demand sensing produces short-term daily or weekly forecasts from signals such as orders and deliveries. You can also bring your own models.

Here you have more control than with a generative feature: you choose algorithms and compare forecast error. The pilot logic is the same, though. Compare against the old forecast on the same products and weeks.

#Extending S/4HANA AI with ISLM

When standard features don't cover a case, S/4HANA offers its own framework: Intelligent Scenario Lifecycle Management (ISLM). You met it for predictive scenarios in machine learning in plain terms. SAP's developer tutorials also show it for generative AI. This is the bridge from "switch on" to "extend".

The setup, per SAP's tutorials:

1. SAP BTP: create an SAP AI Core instance with plan extended and a service key. Subscribe to SAP AI Launchpad and add an AI API connection with that key.
2. S/4HANA trust: import the AI Core root certificate into the SSL client PSE in STRUST.
3. OAuth client: in OA2C_CONFIG, create a client with profile ISLM_SAPGENAI_OAUTH_PRF_HCP, client credentials grant, using the key's client ID and secret.
4. Destination: in SM59, create the HTTP destination ISLM_REUSE_CONNECTION to the AI API host, using that OAuth client.
5. Usage type: in ISLM_REUSE_CFGV ("Maintain Intelligent Scenario Usage"), add a usage type with that connection and resource group default, then run Check Connection until it shows READY.
6. Scenario: in the Intelligent Scenarios app (F4469), create a side-by-side scenario of type Generative AI, add a model with a supported provider and LLM, and publish it.
7. Deploy: in Intelligent Scenario Management (F4470), deploy it, which creates the deployment on SAP AI Core, then activate it.

ABAP code then calls the scenario through a factory class rather than raw HTTP. In outline, from the tutorial:

The design point matters more than the syntax. The scenario, model and deployment are managed in ISLM, so operations teams see custom generative scenarios next to SAP's shipped ones. For side-by-side apps outside ABAP, use the generative AI hub and CAP extensions instead.

#Licensing in one place

As of October 2026, per SAP's pricing page and SAP Learning:

• Base AI is included in standard cloud subscriptions. It covers Joule Base and embedded AI that is "included in specific SAP cloud subscriptions", depending on the solution.
• Premium AI draws on AI Units: agents, document processing, developer capabilities and some per-user packages.
• AI Units are bought annually under SKU 8019164, pooled across SAP solutions and expire after 12 months. Usage and balance show in SAP for Me.
• SAP Learning says most generative AI capabilities start moving from Premium to Base AI from Q3 2026.

The AI business case shows how to put AI Units next to hours saved.

#Build vs. SAP

#Production concerns

• Authorizations. Treat AI feature catalogs like any other authorization. Assign them through business roles in S/4HANA, or RBP permissions in SuccessFactors, and review them in your normal access reviews. An AI feature shows what the user may see, so the role design matters as much as ever. See agent permissions and SAP authorizations.
• Data terms. Check your contract for whether SAP may use your data to improve its features, and decide on the opt-out deliberately. Personal data in HR features needs your data protection officer's sign-off. See data security and PII.
• Evaluation. Pilot with a comparison group. Record acceptance, edits and time. Define the success metric with the business before go-live, as in defining success metrics with the business.
• Release drift. SAP updates cloud features through releases. A feature that scored well in March may behave differently after an upgrade. Re-run the scorecard on a sample after each release.
• Cost. Track AI Units in SAP for Me per feature, monthly. AI Units expire after 12 months, so both overbuying and running out are real risks.
• User notice. SAP shows AI notices in its interfaces. Train users to read generated text as a draft. Smart Summarization's own notice says summaries can vary between runs.
• Clean core. Extend with ISLM scenarios or side-by-side apps on released APIs. Don't modify SAP code to change how a feature behaves.
• Works council. Logging handling times measures employees. Agree the pilot design, aggregation and retention before you collect anything.

#Pitfalls

• Reading acceptance as quality for drafting features. Edited drafts can still save time. Use time saved, not just acceptance.
• Before-and-after instead of a comparison group. Month-end, holidays and learning effects swamp the signal.
• Too few items. A saving whose error bar crosses zero isn't a saving yet.
• Assigning the catalog to everyone on day one. You lose your comparison group and your rollback path.
• Budgeting from announcements. Plan from features that are GA in your system, not from planned dates.
• Building before checking. A custom build of a feature SAP ships next quarter is money spent twice.
• Ignoring the rejected proposals. The rejections show where the feature doesn't fit your process. They're also where your extension, if any, belongs.

#Exercise: a pilot design for one embedded feature

You'll design a real pilot for one embedded feature your company could switch on, and test the design with the scorecard. Your design feeds the buy-vs-build topic next in this unit.

1. Pick one embedded feature from this topic's tables that fits a process you know. Write its name, application and whether it is Base or Premium in unit12/pilot-design.md.
2. Under a heading ## Comparison group, write who uses the feature, who doesn't, and for how many weeks.
3. Under ## Targets, write the minimum acceptance and, if the feature shows a confidence value, the precision target. Write one sentence on why, based on what a wrong proposal costs.
4. Under ## Data, list how you will get each column of the pilot log: from system logs or a timing study.
5. Make a small test CSV, unit12/my_pilot.csv, with at least 40 ai rows and 20 manual rows of plausible values for your feature.
6. Run python unit12/embedded_pilot.py --csv unit12/my_pilot.csv --report unit12/my_pilot_report.md with your targets.
7. Under ## Decision rule, write what result would make you scale, keep piloting or stop.
8. Commit the three files with Git.

Done when unit12/pilot-design.md names the feature, comparison group, targets, data sources and decision rule, and unit12/my_pilot_report.md shows a verdict for your test data.

#Check yourself