Die Frankenstein-Architektur: Cross-Vendor-Agenten und die Lücke, die Klein in Orlando nicht geschlossen hat

1. Saueressigs Begriff und seine Erweiterung im DACH-Diskurs

Frankenstein-Architektur ist eine Begriffsprägung des SAP-Vorstandsmitglieds Thomas Saueressig, ursprünglich verwendet in einem Computerwoche-Interview vom 10. November 2025. Saueressig beschrieb damit on-premise betriebene KI-Agenten-Architekturen, die über „Tunnel und Gateways" zusammengeschaltet werden: teuer, schwer zu warten, schnell veraltet. Das Bild wurde anschließend in der DACH-Analystenkommentierung zur DSAG Investment Report 2026 (e3mag.com März 2026, it-daily.net März 2026) auf einen breiteren Sachverhalt ausgeweitet: KI-Agenten von SAP, Salesforce, Workday und Microsoft, die parallel auf denselben Unternehmenssystemen operieren, ohne eine übergeordnete Governance-Instanz.

Die Definition im weiteren Sinn lautet damit: Frankenstein-Architektur ist eine Konstellation, in der mehrere KI-Agenten unterschiedlicher Anbieter gleichzeitig produktive Geschäftsdaten und Geschäftsprozesse berühren, ohne dass eine gemeinsame Identitätspropagation, ein einheitlicher Audit Trail auf Tool-Call-Granularität und ein einheitlicher Eskalationspfad zwischen den Vendor-Welten existiert.

2. Drei Datenpunkte, die die Lücke konkret machen

Drei unabhängig dokumentierte Datenpunkte machen die Lage konkret.

Erstens: Die Inventur der Community. Die marianfoo-Registry auf github.com/marianfoo/sap-ai-mcp-servers listet mit Stand April 2026 mehr als 30 unabhängige MCP-Server-Projekte für SAP-Systeme. Kategorien: ADT-Bridges (Lese- und Schreibzugriff), Transport-Orchestrierung, BW/4HANA-Modellierung, SuccessFactors-HR-Operationen, SAP Cloud ALM ITSM-API, Sicherheits- und Compliance-Auditierung, SAP Cloud Integration, BTP-Destinations, AI Core Lifecycle, HANA Cloud, Datasphere, Analytics Cloud, Knowledge Graph. Ein einheitliches Audit Trail über diese Server existiert nicht.

Zweitens: Der Shadow-AI-Befund. Die Digital-Chiefs-Analyse „Chief AI Officer 2026" vom April 2026 berichtet, dass 78 Prozent der Beschäftigten KI-Werkzeuge ohne IT-Genehmigung nutzen, während nur 14 Prozent der Unternehmen die KI-Verantwortlichkeit auf Vorstandsebene geklärt haben. Bei einem AI-Budgetwachstum von 87 Prozent zeigt sich, dass Investition und Governance entkoppelt sind.

Drittens: Die SAP-eigene Position. Christian Klein, CEO der SAP SE, äußerte sich in seinem Q1/2026-Earnings-Call (April 2026) und bestätigte die Aussage live auf der Sapphire-Keynote 2026 in Orlando am 11. Mai 2026: „We plan to announce some fundamental changes to our portfolio to infuse this deep domain know-how into SAP's AI agents, and we will govern the agentic AI layer for our customers." (Quelle: Constellation Research April 2026, Diginomica April 2026, IgniteSAP April 2026, SAVIC Technologies 11. Mai 2026 Post-Keynote-Analyse).

Diese drei Datenpunkte zusammen rahmen das Problem. Zwischen 30+ Community-MCP-Servern, 78 Prozent Shadow-AI und einer SAP-Ansage zur Governance der eigenen Agentenebene liegt eine strukturelle Lücke. Die Frage lautet: Wer kontrolliert das, was über diese Lücke hinweg geschieht.

3. Drei Lösungsansätze mit unterschiedlicher Reichweite

Drei Lösungsansätze sind im Markt verfolgbar, mit unterschiedlicher Reichweite.

Ansatz 1: Plattform-Governance durch den dominanten Vendor. Kleins Sapphire-Statement ist die Ankündigung, dass SAP für SAP-eigene Agenten in SAP-Systemen die Governance-Rolle übernimmt. Das LeanIX AI Agent Hub (Q1/2026 eingeführt) ist das dafür vorgesehene Inventar-Dashboard. Das Joule Studio Agent Builder (GA Q1/2026) liefert eingebaute Audit-Trails für die in ihm gebauten Agenten. Die SAVIC-Technologies-Analyse vom 11. Mai 2026 beschreibt drei strukturelle Entscheidungen der Keynote: domain-aware Joule-Agenten, SAP Sovereign Cloud Expansion Indien, Business Data Cloud Expansion (durch die abgeschlossene Reltio-Akquisition vom 7. Mai 2026 als Kerngeschäft positioniert).

Ansatz 2: Community-Evolution zu Enterprise-MCP. ARC-1 (ABAP Relay Connector, „arc one"), von Marian Zeis am 27. April 2026 veröffentlicht, positioniert sich als „Secure ADT MCP Server for Enterprise SAP Development". Fünf Unterscheidungsmerkmale gegenüber früheren Community-Projekten: zentrales Deployment, sichere Defaults, schichtweise Sicherheit, nutzerbezogene Identität, Auditierbarkeit. ARC-1 ist nicht das Ende dieser Bewegung, aber ein deutlicher Schritt von der experimentellen Phase zu enterprise-tauglicher Infrastruktur.

Ansatz 3: Übergreifende Change-Governance auf der SAP-Seite. Der Solutive-AG-Ansatz mit der Enterprise-Change-Control-Tower-Kategorie (Q2/2026 Anbieter-Framing) verortet sich oberhalb der ALM-Schicht. Die Entscheidung über Produktivänderungen wird in einer eigenen Schicht getroffen, unabhängig davon, ob die Änderung von einem menschlichen Entwickler, einem Joule-Agenten oder einem Community-MCP-Server initiiert wurde. Das ist eine Anbieter-Kategorisierung, kein etabliertes Analyst-Kategorie-Label. Die zugrunde liegende Problemstellung (Cross-Vendor-Governance-Lücke, regulatorische Überlappung, Plattform-Konsolidierungsdruck) ist hingegen unabhängig belegt.

4. Fünf Risiken jenseits der SAP-Governance-Grenze

Risiko 1: Begrenzte Reichweite der SAP-Governance. Kleins Statement bezieht sich explizit auf „SAP's AI agents". Die Scope-Boundary ist klar: SAP regelt SAP-Agenten in SAP-Systemen. Was passiert, wenn Microsoft Copilot, Salesforce Agentforce oder ein Workday-Agent über eine API in ein SAP-System schreibt, ist nicht in dieser Zusage enthalten. Die Frankenstein-Frage wird durch Kleins Aussage geschärft, nicht geschlossen.

Risiko 2: Identitätsverlust am Tool-Call. Wenn ein KI-Agent über einen MCP-Server eine ABAP-Änderung schreibt, landet im SAP-Transport-Log typischerweise ein Service-User. Die Identität des originating Agents (welches Modell, welche Konversation, welcher Mensch hat den Prompt geschickt) geht verloren, sofern keine zusätzliche Schicht diese Information persistiert. Die DX-Heroes-Analyse vom April 2026 dokumentiert dies als strukturelle Lücke des MCP-Enterprise-Landscape.

Risiko 3: Audit-Trail-Fragmentierung über Vendor-Grenzen. Jeder Vendor produziert seinen eigenen Audit-Trail. AWS Bedrock AgentCore mit Cedar-Policies, Atlassian Rovo mit OAuth 2.1 plus Domain-Allowlist, SAP Joule Studio mit eingebautem Trail. Die Konsolidierung dieser Trails auf einer einheitlichen Granularität (Tool-Call mit Identität, Zeitstempel, Ergebnis, Eskalation) ist Stand Mai 2026 nicht produktreif gelöst.

Risiko 4: Die irreversible Natur des SAP-Transports verschärft die Lücke. SAP-Hinweis 11599 dokumentiert, dass produktive ABAP-Transporte technisch irreversibel sind. Es gibt keinen nativen Rollback. Eine falsche Entscheidung, getroffen von einem nicht-identifizierten Agenten in einer nicht-konsolidierten Audit-Welt, lässt sich nachträglich nicht systembereinigt zurücknehmen. Die entscheidende Frage ist nicht, ob das System funktioniert, sondern ob der Mensch noch die Wahl hat, es abzulehnen.

Risiko 5: Persönliche Haftung trifft auf strukturelles Defizit. Im Schnittpunkt von NIS2 (persönliche Haftung der Geschäftsleitung nach § 38 BSIG, seit 6. Dezember 2025 in Kraft) und EU AI Act (Artikel 26 Betreiberpflichten ab 2. August 2026, nicht durch den Digital Omnibus verschoben) trägt der Betreiber die Verantwortung für Vorgänge, die er in der aktuellen Architektur strukturell nicht vollständig nachvollziehen kann.

5. Fünf operative Konsequenzen für Betreiber

Erstens: Agenten-Inventar führen. Welche KI-Agenten haben heute Lese- oder Schreibzugriff auf welche SAP-Systeme. Eine Cross-Vendor-Liste mit Quelle (SAP-eigen, Community-MCP, Drittanbieter), Berechtigungsumfang, Verantwortlichem, letztem Audit. Das LeanIX AI Agent Hub deckt die SAP-eigene Sicht ab; eine vollständige Sicht braucht zusätzliche Werkzeuge oder manuelle Pflege.

Zweitens: Identität bei jedem Tool-Call propagieren. Der zentrale technische Hebel ist die Frage: Wer hat den ursprünglichen Prompt geschickt, und ist diese Person im Audit-Eintrag erkennbar. Für ABAP-Schreibzugriffe über MCP-Server bedeutet das, dass nutzerbezogene Identitäten genutzt werden, nicht generische Service-Accounts. ARC-1 implementiert dieses Prinzip; ältere Community-Server tun es nicht durchgängig.

Drittens: Eskalationspfad definieren. Bei Mehrdeutigkeit in der Deployment-Entscheidung (Quality-Gate teilweise grün, teilweise gelb) braucht es einen klar definierten menschlichen Entscheider mit lesbarer Briefing-Vorlage. 30-Sekunden-Format mit Risikoaussage, betroffenem Geschäftsprozess, Testabdeckung, Empfehlung. Diese Schicht ist es, an der sich entscheidet, ob die Architektur trotz unterschiedlicher Vendor-Agenten konsolidiert handelt oder fragmentiert bleibt.

Viertens: Vendor-Boundary explizit machen. In Vertragsverhandlungen mit SAP, Microsoft und Salesforce sollten konkrete Fragen gestellt werden: Welcher Audit-Trail wird produziert, in welchem Format ist er exportierbar, welche Identitätsinformation enthält er, wie erreicht der Auditor diese Information im Notfall. Pauschale „we govern our agents"-Zusagen reichen für eine NIS2- oder EU-AI-Act-Verteidigung nicht aus.

Fünftens: CAIO-Rolle besetzen oder funktional zuordnen. Digital Chiefs identifiziert die EU-AI-Act- und ISO-42001-Governance als das verteidigbarste CAIO-Mandat. Die operative Konsequenz: eine namentlich benannte Person mit Verantwortung für Risikobeurteilung, Vorfallmanagement und Rechenschaft. Beispiele aus 2026: Jonathan von Rueden als CAIO der SAP SE.

6. Werkzeug-Landschaft: Cross-Vendor-Governance im Mai 2026

Werkzeuge, die einzelne Teile der Cross-Vendor-Agenten-Governance abdecken, gruppieren sich in drei Schichten.

¹ Solutive AG ist Initiator des Change Orchestration Institute. ESM Suite ist ein Produkt der Solutive AG.

Solutive AG ist Initiator des Change Orchestration Institute. ESM Suite ist ein Produkt der Solutive AG. Die Aussagen zur ESM Suite sind Anbieterangaben.

Lesart der Tabelle: Kein Werkzeug deckt alle vier Funktionsbereiche ab. Cross-Vendor-Audit-Konsolidierung ist Stand Mai 2026 schlicht nicht produktreif gelöst. Was existiert, sind partielle Lösungen in der eigenen Plattform-Welt jedes Anbieters. Die operative Konsequenz: Wer eine ganzheitliche Frankenstein-Antwort verlangt, muss Werkzeuge kombinieren.

7. Was Klein in Orlando offen gelassen hat

Die Frankenstein-Architektur beschreibt eine Konstellation, in der mehrere KI-Agenten unterschiedlicher Anbieter gleichzeitig auf produktive Geschäftssysteme einwirken, ohne dass eine übergeordnete Governance-Schicht existiert. Saueressig hat den Begriff im November 2025 in den Diskurs eingeführt, Klein hat in der Sapphire-Keynote vom 11. Mai 2026 die SAP-eigene Antwort positioniert: „We will govern the agentic AI layer for our customers." Diese Antwort ist im Geltungsbereich klar (SAP-Agenten, SAP-Systeme) und in dem, was sie offen lässt, ebenso klar (Cross-Vendor-Identität, Cross-Vendor-Audit).

Für SAP-Anwenderunternehmen lautet die operative Konsequenz: Inventar, Identitätspropagation, Eskalationspfad, vertragliche Vendor-Boundary-Klarheit, CAIO-Verantwortung. Reine Plattform-Governance eines einzelnen Anbieters ist nicht das ganze Bild. Das gilt unabhängig davon, welcher Anbieter den Anspruch erhebt.