SAP hat mit der „AI-Native North Star Architecture" (Mai 2026, öffentlich) einen Bauplan veröffentlicht, wie KI Unternehmenssoftware umgestaltet. Die Botschaft: SAP fragt nicht mehr, ob agentische KI die Unternehmenssoftware verändert — es beschreibt, wie. Diese Architekturrichtung bestätigt den Weg, den wir für unsere eigene Verrechnungspreis-Plattform gewählt haben, und zeigt mit ungewöhnlicher Präzision, wohin die agentische Dokumentengenerierung als Nächstes geht.
Quelle: SAP AI-Native North Star Architecture (Mai 2026, öffentlich).
SAPs zentrale Aussage ist trügerisch einfach: „Daten waren der Burggraben des letzten Jahrzehnts. Kontext ist der Burggraben des nächsten." Frontier-Modelle werden zur Ware; jeder Anbieter kann auf dieselben führenden LLMs zugreifen. Was sich nicht kopieren lässt, ist der Kontext, über den diese Modelle schlussfolgern — die Entscheidungshistorie, die Geschäftssemantik, die governierten Daten, auf denen jede Ausgabe gründet.
Das ist keine abstrakte Theorie. Es ist genau das Problem, mit dem die Verrechnungspreisdokumentation seit BEPS Action 13 ringt: wie man fünf Jahre Finanzdaten, konzerninterne Vereinbarungen und Funktionsanalysen in eine belastbare, prüfbare Darstellung verwandelt — ohne das „Warum" hinter den Zahlen zu verlieren.
Von AI-First zu AI-Native: Die vier Schichten
SAP beschreibt vier Architekturschichten, jede im Übergang von einer starren Vergangenheit zu einer anpassungsfähigen Zukunft:
- User-Experience-Schicht — von statischen Apps zu absichtsgesteuerter Interaktion. Joule wird zum zentralen Einstiegspunkt; Nutzer navigieren nicht mehr, sondern formulieren ihre Absicht.
- Prozess-Schicht — von vordefinierten Workflows zu agentischer Orchestrierung. Anwendungen werden zu Capability-Providern, die Agenten über ein governiertes Gateway entdecken und aufrufen.
- Foundation-Schicht — vom System of Record zum System of Context. SAP Business Data Cloud und SAP Knowledge Graph liefern semantisch fundierte Daten; Context Engineering stellt für jede Interaktion den richtigen Ausschnitt der Unternehmensinformationen zusammen.
- Plattform-Schicht — vom Hosten von Anwendungen zum Betrieb governierter Unternehmensagenten, mit Identität, Sandboxing, Observability und Mandantentrennung ab dem ersten Tag.
Zwei offene Protokolle leisten die Hauptarbeit: MCP (Model Context Protocol) für die Tool-Integration — Agenten entdecken und rufen Fähigkeiten systemübergreifend auf — und A2A (Agent2Agent) für die Koordination mehrerer Agenten. Security behandelt Agenten als erstklassige Principals mit begrenzten Berechtigungen; eine dreistufige KI-Verteidigung (Zero-Trust-Fundament, Security-Agenten, deterministische Aufsichtsagenten) umschließt das Ganze.
Dieselben Prinzipien im Produktivbetrieb
SAPs Architekturpapier ist eine Vision. Glaubwürdig wird sie, wenn man dieselben Prinzipien im Produktivbetrieb sieht — und genau das zeigen aktuelle SAP-Implementierungen:
- Production Intelligence Cockpit: Ein deutschsprachiger KI-Assistent für Schichtleiter auf S/4HANA on-premise — kein RAG, kein ETL, keine Vektordatenbank. Der Agent ruft veröffentlichte OData-APIs auf, SAPs eigenes Berechtigungsmodell erzwingt bei fehlender Berechtigung einen 403, und das LLM berührt das Backend nie: Es ist eine Reasoning-Schicht, kein Backend-Aufrufer. Das ist SAP API Policy v4 §2.2.2 in der Praxis — agentischer Zugriff läuft über das governierte Agent Gateway.
- ABAP-Modernisierung mit einem MCP-Server: Drei Schichten — eine schreibgeschützte Fiori-Analyse-App, eine Eclipse-Erweiterung für Entwickler und ein richtliniengetriebener MCP-Server als kontrollierte Schnittstelle für jede Systemänderung. „Co-pilot, not autopilot": Jeder Schreibvorgang erfordert eine Freigabe, alles ist auditierbar.
- SAP Company Memory (GA Q2/2026): eine systemagnostische (markdown-basierte) Single Source of Truth, die Geschäftskontext für alle Agenten bereitstellt und governiert — die operationalisierte Variante des System of Context.
- SAP × Anthropic: Claude-Modelle sind über den SAP Generative AI Hub verfügbar, und Claude Code kommt in Joule Studio 2.0 — aber immer hinter dem Agent Gateway, nie als direkter Modellzugriff auf SAP-Systeme.
Für eine Plattform zur Dokumentenautomatisierung ist das die stärkstmögliche externe Bestätigung: Dasselbe Governance-by-Design-Muster, das wir gebaut haben (JWT-Vertrauenskette, Mandantentrennung, MCP-Tools, auditierbare Prompt-Kette), ist nun SAPs befürwortete Architektur — durch API-Policy erzwungen, nicht bloß empfohlen.
Was das in unserer Plattform bestätigt
Wir haben unsere Verrechnungspreis-Master-File-Plattform (tp.finestselection.net) genau um diese Prinzipien herum gebaut — bevor das SAP-Papier sie salonfähig gemacht hat:
| SAP-North-Star-Konzept | Unsere Umsetzung |
|---|---|
| MCP als Tool-Integration | Ein eigener MCP-Server mit fünf JWT-geschützten Tools: Section-Context-Hydration, System-Prompt-Auflösung, semantische Wissenssuche, Revisions-Persistenz und Usage-Logging |
| Agenten-Orchestrierung | Ein ADK-Agent (FastAPI), der Identität verifiziert, MCP-Tools aufruft und LLM-Ausgaben streamt — mit Modell-/Provider-Wechsel über Umgebungskonfiguration, ohne Redeploy |
| Governiertes Gateway / Vertrauenskette | Eine JWT-Bridge: Clerk-Session → Prüfung der Mandantenzuordnung → kurzlebiges signiertes Token → Agent. Mandantentrennung auf jeder Stufe erzwungen |
| Semantische Fundierung (RAG) | Hochgeladene PDF/DOCX/TXT-Wissensbasis, gechunkt und eingebettet, gerankt nach Kosinus-Distanz über pgvector |
| Datenprodukte / Stammdaten | Projekte pro Mandant modelliert, mit Zielwirtschaftsjahr und Lookback-Zeitraum; Master File → Kapitel → Abschnitte mit vollständiger Revisions-Historie |
| Geschäftskontext / Prompt-Governance | Eine Fallback-Prompt-Kette (Projekt-Override → Agent-Konfiguration → SOUL.md → hardcodiert) mit expliziten Quellenangaben für das Audit |
| Entscheidungsspuren | Jede Persistenz des Agenten schreibt eine Revision — ein Audit-Trail darüber, was wann auf welcher Grundlage erzeugt wurde |
Die Architektur ist im Sinne SAPs bereits AI-native: Das Modell denkt, das Harness governiert.
Wohin SAP uns als Nächstes weist
Das North-Star-Papier ist auch eine Roadmap für das, was wir noch nicht gebaut haben:
1. Entscheidungsspuren als erstklassige Assets. SAPs „Context Graph" hält fest, was bekannt, erwogen und gewählt wurde und was daraus folgte — jede menschliche Korrektur wird zu einer strukturierten Entscheidungsspur. Für die Verrechnungspreisdokumentation ist das Gold: ein Audit-Trail, der erklärt, warum eine Funktionsanalyse eine bestimmte Position eingenommen hat, nicht nur, dass sie gespeichert wurde. Unser Revisionssystem ist das Fundament; der Export von Spuren als strukturierte, abfragbare Nachweise ist der nächste Schritt.
2. Local File als gleichrangiger Workflow. Master File und Local File teilen Kontext, verlangen aber unterschiedliche Nachweisbasen. Das MCP-Tool-Modell macht die Erweiterung trivial — ein get_local_file_context-Tool, eine eigene Wissensbasis, eine eigene Prompt-Kette — ohne die Agent-Runtime anzutasten.
3. Multi-Agenten-Orchestrierung. SAPs A2A-Muster legt nahe, einen Recherche-Agenten (Wissensabruf, Präzedenzfallsuche) von einem Textentwurfs-Agenten (Abschnittsgenerierung) zu trennen — jeder mit eigener Identität, begrenzten Berechtigungen und eigener Evaluierung. Einzelagenten-Systeme stoßen an Qualitätsgrenzen; governierte Multi-Agenten-Systeme verstärken sich kumulativ.
4. Agenten-Evaluierung als Feedback-Schleife. SAP warnt (Goodharts Gesetz) davor, eine einzelne Kennzahl zu optimieren. Das Evaluierungsziel für die Verrechnungspreis-Dokumentengenerierung sollte multikriteriell sein: technische Vollständigkeit, Review-Durchlaufquote, Revisionshäufigkeit, Kundenakzeptanz. Diese Messungen werden zum Lernsignal.
5. Wirtschaftsjahr-native Datenmodellierung. SAPs Datenprodukt-Denken lässt sich direkt anwenden: Finanzdaten sind kein Schnappschuss, sondern eine Zeitreihe. Unsere Plattform modelliert Projekte bereits nach Zieljahr mit Lookback-Zeiträumen; die nächste Iteration behandelt Wirtschaftsjahre als erstklassige Datendimension — damit Agenten über fünf Jahre Trend schlussfolgern, nicht über ein Jahr Zahlen.
Das Fazit
SAPs North Star ist keine Produkt-Roadmap; er ist die Bestätigung einer Architekturrichtung. Das Papier bestätigt, was wir in der Praxis gesehen haben: Context Engineering, governierte Agenten-Runtimes und MCP-basierte Integration sind das tragfähige Fundament für Dokumentenautomatisierung — und für die Verrechnungspreisdokumentation im Besonderen verwandeln sie das „System of Record" (Zahlen) in ein „System of Context" (Zahlen plus die Überlegungen dahinter).
Das ist der Unterschied zwischen Dokumentation, die eine Prüfung übersteht, und Dokumentation, die lediglich existiert.
Finest Selection GmbH — KI-getriebene Verrechnungspreisdokumentation. Automatisierung von Master File und Local File, Governance by Design, fundiert in Ihren Daten.