Federated Learning in SAP

What you will learn

• Design a federated learning architecture across multiple SAP legal entities using SAP AI Core and BTP Argo Workflows, specifying the round-orchestration pipeline, gradient aggregation strategy, and model artefact versioning to handle non-IID data distributions across subsidiaries.
• Evaluate the privacy guarantees of federated learning with and without differential privacy and secure aggregation, applying the ε-privacy budget trade-off to realistic SAP dataset sizes and advising legal and compliance stakeholders on residual risks.
• Select and configure the appropriate FL algorithm — FedAvg, FedProx, SCAFFOLD, or personalised FL — for a given EMEA multi-entity SAP landscape based on data heterogeneity, network topology, and model quality requirements, justifying the choice against centralised alternatives.
• Identify the conditions under which federated learning is not warranted — including anonymisable datasets, single-instance SAP landscapes, and tiny per-client datasets — and correctly propose simpler alternatives such as Datasphere data federation or differential privacy on aggregated exports.

The Problem Federated Learning Solves in SAP Landscapes

Federated learning (FL) is a distributed machine learning paradigm in which a model is trained across multiple data sources without the raw data ever leaving its origin. The model — or more precisely, gradient updates — travels; the data does not. This distinction is not merely technical. In multi-entity SAP landscapes, it is the difference between a project that proceeds and one that is killed by legal review.

Consider the scenarios a senior consultant encounters regularly. A multinational with SAP S/4HANA instances in Germany, France, and Poland wants to build a cross-border churn prediction model on ACDOCA and CRM data. Under GDPR, the personal data of French customers cannot be transferred to a central server in Germany without either explicit consent or an adequacy mechanism. A hospital network using SAP for procurement wants to pool purchasing pattern data with other hospitals to improve demand forecasting — but patient-adjacent procurement data is governed by sector-specific privacy rules in each member state. A financial services group with ring-fenced legal entities cannot share raw trading data across entities due to regulatory firewalls, but wants a unified fraud detection model.

Prerequisites

• Intermediate hands-on experience on SAP analytics projects
• Review core concepts first: C087, C083, C047

Outcomes

• Work through a realistic scenario: A pan-European financial-services group with ring-fenced legal entities in three countries wants a shared fraud-detection model but cannot legally pool raw trading data.
• Recognize and avoid the anti-pattern: Selling FL as an automatic GDPR compliance mechanism — Legal treats the gradient payloads as personal data anyway, and the project stalls in review.
• Apply the module's core decision: Federated learning vs. centralised training — choose Default to centralised (anonymised/aggregated) training.
• Track mastery with the KPI: Per-client loss divergence (target: Stable or converging within 20 rounds; red flag: Loss oscillates or keeps diverging past round 20).