Die neuen Enterprise-Datensilos: Wenn die Systeme, für die Sie bezahlen, die KI vorschreiben, die Sie nicht gewählt haben

In den vergangenen sechs Wochen haben vier der größten Enterprise-Softwareanbieter der Welt architektonische Entscheidungen getroffen, die alle dieselbe Grundstruktur teilen. SAP hat Ende April die API Policy v4/2026 veröffentlicht, die Drittanbieter-KI-Agenten den Zugriff auf SAP-Systeme außerhalb von SAP-zertifizierten Pfaden untersagt; die Durchsetzung beginnt am 9. Juni 2026 mit einem Security Patch, der technisch nicht-konformen Zugriff blockiert. Microsoft hat Agent 365 und die Work IQ MCP-Server formalisiert und leitet jeden Drittanbieter-Agenten, der auf SharePoint, OneDrive, Teams, Outlook, Word, Excel oder Dynamics zugreifen will, über ein von Microsoft betriebenes Tooling-Gateway. ServiceNow hat auf der Knowledge 2026 Action Fabric gestartet – eine Integrationsschicht, die externe KI-Agenten passieren müssen, um auf ServiceNow-Daten zuzugreifen – und die pro Aktion gemessen und abgerechnet wird, mit Anthropic Claude als Launch-Partner. Salesforce hat die Slack-API-Bedingungen verschärft und verbietet Drittparteien, Slack-Daten zu speichern, zu indexieren oder zum Training zu nutzen. Unterschiedliche Anbieter. Unterschiedliche Mechanismen. Unterschiedliche juristische Begründungen. Ein architektonischer Move: ein vom Anbieter kontrolliertes KI-Gateway zwischen den unternehmenseigenen Daten des Kunden und jedem Agenten, der sie nutzen will. Das ist das Datensilo-Problem der Agenten-Ära – genau in dem Moment, in dem europäische Unternehmen endlich beginnen, Klarheit über KI-Architekturen zu gewinnen. Und es ist die wichtigste Enterprise-KI-Entwicklung dieses Quartals.

Dies ist der achte Beitrag in einer Serie, die ich für neuland.ai schreibe. Der rote Faden durch alle Beiträge ist derselbe: Wert, Risiko und „Moat“ von Enterprise-KI liegen in der Schicht über und um das Modell herum – nicht im Modell selbst. [¹] Frühere Beiträge haben dieses Argument aus unterschiedlichen Blickwinkeln betrachtet – Control Plane, Model Drift, Modell-Topologie, Compliance als Systemeigenschaft, Agentensicherheit, MCP-Governance und zuletzt die strategische Begründung für Fast-Follower-Deployments mit robusten Open-Weight-Modellen auf souveräner Infrastruktur. [²]

Dieser Beitrag führt das Argument eine Schicht weiter nach unten im Stack. Ingestion ist ebenfalls eine Systemeigenschaft. Dasselbe gilt für Retrieval. Und beides steht kurz davor, die teuerste Schicht in jeder Enterprise-KI-Architektur zu werden, die nicht bewusst so gebaut ist, dass sie genau das verhindert.

Vier Anbieter, ein architektonischer Move
Der einfachste Weg, das Muster zu erkennen, ist, die vier Ankündigungen nebeneinander zu legen.

SAP hat im April die API Policy v4/2026 veröffentlicht; Abschnitt 2.2.2 untersagt die Nutzung von SAP-APIs für „Interaktion oder Integration mit (semi-)autonomen oder generativen KI-Systemen, die Sequenzen von API-Aufrufen planen, auswählen oder ausführen“, sofern dies nicht innerhalb von SAP-zertifizierten Architekturen geschieht. [³] Der zertifizierte Pfad sind Joule Agents, SAP Business Data Cloud und das Agent Gateway – alles SAP-Produkte. CEO Christian Klein hat die Policy im Q1-2026-Investor-Call in zwei Registern eingeordnet: Plattformstabilität („wenn massenhaft Datenanfragen oder Millionen von Calls auf eine API einprasseln, müssen wir anfangen, diese APIs zu drosseln“) und IP-Schutz („die IP von SAP, das Domänen-Know-how ist etwas, das wir unseren Kunden zur Verfügung stellen werden… aber [auch] ein großes Schutzgut“). [⁴] Die Durchsetzung beginnt am 9. Juni 2026 mit einem Security Patch, der technisch nicht-konforme ODP-via-RFC-Calls blockiert. Die DSAG, die Deutschsprachige SAP-Anwendergruppe, hat die Policy öffentlich als widersprüchlich zu SAPs proklamierten Open-Platform-Verpflichtungen kritisiert. [⁵] Branchenanalysten haben auf eine „Pricing-Klippe 2027“ hingewiesen – den Teil der Policy, über den SAP öffentlich noch nicht spricht. [⁶]

Microsoft hat einen anderen Mechanismus gewählt, um am selben Ziel zu landen. Agent 365 und die Work IQ MCP-Server, im Mai 2026 über Microsoft Learn dokumentiert, exponieren Copilot, Calendar, Mail, SharePoint, OneDrive, Teams, Word, Excel, Dataverse und Dynamics 365 als MCP-Tools – aber ausschließlich über von Microsoft betriebene Endpunkte unter agent365.svc.cloud.microsoft/agents/tenants/{tenant_id}/servers/. [⁷] Jeder externe Agent, der Microsoft-365-Enterprise-Daten lesen oder schreiben will, wird durch Microsofts Tooling-Gateway geroutet, wo Governance, Policy Enforcement und Observability ebenso bei Microsoft liegen. Das Protokoll ist offen. Die Control Plane ist es nicht.

ServiceNow hat dasselbe Muster explizit monetarisiert. Auf der Knowledge 2026 in Las Vegas wurde Action Fabric als Integrationsschicht vorgestellt, die externe KI-Agenten passieren müssen, um auf Daten zuzugreifen und Workflows innerhalb der ServiceNow-Plattform auszuführen. ServiceNows COO Amit Zavery bestätigte, dass diese Schicht gemessen wird und Kunden pro abgeschlossener Aktion eines externen Agenten bezahlen. JPMorgan-Analyst Mark Murphy beschrieb diese Gebühr unverblümt als eine Steuer für Kunden, die externe KI-Agenten einsetzen, um mit den Daten zu interagieren, die sie bereits in ServiceNow-Anwendungen speichern. Anthropic Claude ist Launch-Partner. [⁸]

Salesforce hat sich gleichzeitig in zwei Richtungen bewegt. Auf Slack-Seite wurde verschärft – Dritte dürfen Slack-Daten nicht länger speichern, indexieren oder zum Training von KI-Modellen nutzen, womit eine kritische Input-Quelle für jeden Agenten abgeschnitten wird, der Slack als persistentes Organisationsgedächtnis genutzt hat. Auf der breiteren Salesforce-Plattform hingegen hat das Unternehmen Headless 360 ausgeliefert – mit mehr als 60 neuen MCP-Tools, die aus Claude Code, Cursor oder jeder MCP-kompatiblen Runtime nutzbar sind, ohne proprietäre KI-Schnittstelle. [⁹] Ein Unternehmen, zwei entgegengesetzte Haltungen zur gleichen Architekturfrage – offenbar abhängig davon, auf welche Akquisition sich die Policy bezieht.

Die Mechanismen unterscheiden sich. SAP schränkt vollständig ein. Microsoft routet durch sein Gateway. ServiceNow rechnet pro Aktion ab. Salesforce schränkt bei Slack ein und öffnet auf der breiteren Plattform. Aus Sicht des europäischen Enterprise-Einkäufers ist die praktische Folge von drei der vier jedoch dieselbe: Die Datenquellen, für die das Unternehmen bezahlt, werden strukturell an eine vom Anbieter kontrollierte KI-Control-Plane gebunden. Die Architektur jedes bisherigen „AI Workspace“-Demos – Agent ruft Vendor-API, Vendor liefert Daten, Agent schließt daraus – unterliegt jetzt den Bedingungen, der Bepreisung, den Throughput-Limits und der Audit-Haltung des Anbieters, dem diese API gehört.

Warum Anbieter das tun
Es lohnt sich, die rationale Argumentation ehrlich zu würdigen, bevor man zur strukturellen Kritik ansetzt – denn die rationale Argumentation hat Substanz.

SAPs Plattformstabilitäts-Argument ist legitim. ERP-Systeme wurden für menschliche Transaktionsvolumina gebaut – Payroll, Financial Close, Supply-Chain-Execution –, bei denen 85 oder 90 Prozent Genauigkeit nicht ausreichend sind und in denen eine ungebremste Agentenschleife kritische Workloads tatsächlich destabilisieren könnte. [¹⁰] Kein seriöses Unternehmen will, dass sein Hauptbuch durch einen schlecht begrenzten autonomen Agenten beschädigt wird. Microsofts Argument für das Routing durch ein Tooling-Gateway ist auf technischer Ebene ebenfalls legitim: Ein einziger Governance-, Audit- und Policy-Enforcement-Punkt ist einfacher zu betreiben als 200 individuelle Integrationen. Die IP-Schutz-Argumente sind ebenfalls real – SAPs Domänenwissen repräsentiert jahrzehntelange Prozessexpertise, die man nicht kostenlos aus der Hand gibt.

Ebenso ehrlich ist es aber festzustellen, dass keines dieser Argumente Timing und Asymmetrie vollständig erklärt. KI ist die margenstärkste Umsatzlinie, die die großen SaaS-Anbieter jemals monetarisieren werden. Agentischen Zugriff durch die eigene KI des Anbieters zu routen, ist der strukturelle Move, den sie machen müssen, wenn sie diese Marge einfangen wollen – und das Plattformstabilitäts-Argument ist die öffentlich verträgliche Version einer kommerziellen Entscheidung, die bereits aus dem darunterliegenden Produktportfolio ablesbar ist. SAPs eigene KI-Produkte (Joule, Business Data Cloud, das Agent Gateway) stehen auf der erlaubten Seite der Policy-Linie. Microsofts eigener Copilot zahlt nichts dafür, Agent 365 zu durchqueren. ServiceNows eigene KI-Agenten zahlen keine Action-Fabric-Pro-Action-Gebühr, die externe Agenten trifft. Die Asymmetrie ist kein Nebeneffekt der Architektur; sie ist die Architektur.

Die Forrester-Analyse zur SAP-Policy kommt zum gleichen Ergebnis in komprimierter Form: Dies ist ein Move, um zum Gatekeeper von Enterprise-KI zu werden, und CIOs sollten gegensteuern. [⁶] Die DSAG-Kritik kommt im höflicheren Deutsch zum gleichen Schluss. Die strukturelle Lesart ist nicht strittig; die einzige strittige Frage ist, wie Unternehmen darauf reagieren.

Was das speziell für europäische Unternehmen bedeutet
Für das Publikum, für das diese Serie primär geschrieben ist – CIOs, CISOs, Heads of Architecture und Heads of AI in regulierten DACH- und europäischen Unternehmen – sind die Implikationen direkt und greifen in jede Dimension hinein, die ich in den vergangenen sieben Beiträgen beschrieben habe.

Sie können DSGVO-Konformität nicht auf einer Tool-Call-Schicht erzwingen, die Sie nicht kontrollieren. [¹¹] Sie können Datenflüsse, die durch ein KI-Gateway eines Anbieters laufen, nicht ohne Kooperation des Anbieters auditieren. Sie können Datenresidenz nicht garantieren, wenn das Gateway auf Infrastruktur läuft, die Ihnen nicht gehört. Sie können nicht auf Ihren eigenen Daten feinjustieren, wenn diese Daten nur hinter einem Vendor-AI-Gate hervorkommen. Sie können Kosten nicht vorhersagen, wenn der Zugriff pro Agentenaktion von einem Anbieter abgerechnet wird, dessen Pricing-Modell, wie Forrester bemerkt, „der Teil ist, über den SAP noch nicht spricht“. Sie können die Capability-Dekomposition der „lethalen Trifecta“, die ich im Beitrag vom 18. Mai entwickelt habe, nicht anwenden, wenn Ihr Data-Ingestion-Pfad selbst die Trifecta ist. [¹²] Und die Workhorse-Strategie, die ich im Beitrag der vergangenen Woche argumentiert habe – Open-Weight-Modelle auf souveräner Infrastruktur für die 70–90 % des Enterprise-Inferenz-Traffics zu fine-tunen, die nicht das Frontier-Level benötigen – funktioniert nur, wenn Sie Ihre Trainings- und Retrieval-Daten tatsächlich unabhängig aus diesen Quellsystemen herausbekommen. [¹³]

Kurz gesagt: Die elegante europäische KI-Architektur, die ich in den vergangenen sieben Beiträgen beschrieben habe, ruht auf einer fundamentalen Annahme – dass das Unternehmen seine eigenen Daten ingestieren, indexieren und retrieven kann, ohne dafür eine pro Aktion zu zahlende Miete an den Anbieter zu entrichten, dessen Produkt diese Daten zufällig hostet. Die Vendor-Moves von April bis Mai 2026 sind genau der Angriff auf diese Annahme, auf den diese Serie implizit hingearbeitet hat.

Die architektonische Antwort folgt direkt aus der Diagnose: Die Ingestion- und Retrieval-Schicht muss auf souveränen Fundamenten gebaut werden – im Terabyte- bis Petabyte-Maßstab – mit dem Kunden in der Kontrolle über Pipeline und Index. Ohne diese Schicht werden alle anderen architektonischen Argumente dieser Serie akademisch.

Warum die meisten „RAG-Plattformen“ dieses Problem nicht lösen können
Eine kurze strukturelle Beobachtung, die erklärt, warum dieses Problem schwieriger ist, als es aussieht. Die meisten Produkte, die im europäischen Markt aktuell als „AI Workspaces“, „Agentenplattformen“ oder „RAG-Plattformen“ vermarktet werden, basieren selbst auf Hyperscaler-APIs für die schweren Schichten von Retrieval-Augmented Generation. Embeddings werden von einer Vendor-API gekauft, abgerechnet pro Million Input-Tokens. Reranking wird von einer Vendor-API gekauft, abgerechnet pro Call. OCR wird von einer Vendor-API gekauft, abgerechnet pro Seite. Vektorspeicher kommt von einem Managed Service des Anbieters, abgerechnet pro GB-Monat plus pro Query. Die Integration in Ihre Enterprise-Quellsysteme ist in der Praxis eine dünne Schicht über denselben Vendor-Connectors, die durch die Gateways geführt werden, über die wir gerade gesprochen haben.

Dieser ökonomische Stack funktioniert hervorragend für einen Chat-Demo-Case auf ein paar hundert Megabyte Dokumentation. Bei der Skalierung und Ökonomie, die zählen, bricht er zusammen. Ein mittelgroßes europäisches Industrieunternehmen mit einem ernstzunehmenden Dokumentencorpus – ein Hersteller mit jahrzehntelangen CAD-Daten, technischer Dokumentation, Lieferantenverträgen und Qualitätsaufzeichnungen; ein Finanzinstitut mit Prospekten, KYC-Dossiers, Audit-Reports und Transaktionsdaten; eine Gesundheitseinrichtung mit Patientenakten, klinischer Literatur und regulatorischen Einreichungen – arbeitet am Tag eins einer ernsthaften KI-Initiative im Bereich von zig Terabytes bis in niedrige Petabytes an gemischtmodalen Daten. In dieser Größenordnung kostet das Embedding-per-Token-Billing allein für den Ingestion-Pass bereits mehr als der Rest des Projekts zusammen. Vector-Store-per-Query-Billing auf einem Corpus, der reale parallele Retrieval-Last tragen soll, kostet mehr als das. Und die gesamte Architektur reproduziert qua Konstruktion genau die Vendor-Control-Plane-Abhängigkeit, aus der der Kunde sich durch den Kauf einer „europäischen KI-Plattform“ eigentlich befreien wollte.

Die architektonische Alternative besteht darin, die Ingestion- und Retrieval-Schicht als erstklassige, kundengeführte Infrastrukturkomponente zu bauen und nicht als Integrationsschicht über Vendor-APIs. Genau dafür wurde der neuland.ai HUB von Beginn an konstruiert – und genau diese Schicht ist es, die durch die jüngsten Vendor-Moves zur wichtigsten Schicht im Stack geworden ist, die man richtig bauen muss.

Was wir gebaut haben – und warum
Ich möchte beim Detailgrad vorsichtig sein, da nicht alles, was den neuland.ai HUB architektonisch besonders macht, in einem Blog vollständig offengelegt werden sollte. Die öffentlich sichtbare Form des Designs lohnt sich jedoch, präzise beschrieben zu werden, denn sie ist das Fundament, auf dem der Rest dieser Serie steht.

Die Ingestion-Pipeline des HUB basiert nativ auf einem verteilten Compute-Substrat, das horizontal auf einem einzelnen Cluster skaliert – mit multimodaler Verarbeitung als erstklassiger Eigenschaft und nicht als nachträgliche Sammlung separater Connectoren: PDF (nativ und OCR-basiert), Bilder, Audio, Video und strukturierte tabellarische Daten. Das nichtfunktionale Ziel ist Petabyte-Ingestion – nicht als Marketingversprechen, sondern als engineered Property der Pipeline-Architektur selbst. OCR, Embedding-Generierung und Reranking laufen auf der GPU-Infrastruktur des Kunden innerhalb von dessen Cluster, bereitgestellt über einen internen High-Throughput-Inference-Stack. Die Kosten für diese Schicht sind die Kosten der GPU-Minuten, die die Hardware des Kunden tatsächlich verbraucht – nicht ein Vendor-Markup pro Token, pro Call oder pro Seite. Embeddings und Reranks verlassen die Umgebung des Kunden nicht, außer der Kunde entscheidet sich explizit, ein Frontier-LLM über die Routing-Schicht des HUB anzusprechen – und diese Entscheidung ist dann eine Policy-Entscheidung, keine architektonische Zwangsläufigkeit.

Die Retrieval-Schicht sitzt auf einem einzigen spaltenorientierten Storage-Backend, das Vektorindizes, Fulltext-Suchstrukturen und spaltenorientierte Metadaten an einem Ort hält. Ein Write erzeugt drei abfragbare Repräsentationen. Ein Storage-Account skaliert in den Petabyte-Bereich. Hybrides Retrieval, das semantische und lexikalische Signale kombiniert, ist Default-Verhalten, kein Add-on. Der Reranker – der teuerste einzelne Inferenzschritt in einer typischen RAG-Query – läuft lokal auf den GPUs des Kunden. Nichts davon ist neuartige Forschung; alles hängt von bewusst getroffenen Entscheidungen ab, die unter operativer Disziplin gehalten werden, statt bei jeder günstigen Gelegenheit wieder als Vendor-API einzukaufen. [¹⁴]

Was der Kunde dadurch in Klartext erhält, ist ein souveränes Ingestion- und Retrieval-Substrat, das Daten aus zertifizierten Vendor-Pfaden ingestiert (einschließlich SAPs BTP- und Joule-Integrationspunkten, Microsofts Work IQ MCP-Servern, den veröffentlichten ServiceNow-APIs, Salesforce Headless 360 MCP und den eigenen Dokumentenrepositories, Fileshares, Datenbanken und EU-souveränen Cloud-Object-Stores des Kunden) – das aber, entscheidend, diese Daten in einem Corpus materialisiert, den der Kunde besitzt, mit Indizes, die der Kunde kontrolliert, und einer Retrieval-Oberfläche, die der Kunde governet. Das Vendor-MCP-Gateway wird zum eingehenden Integrationspunkt. Es wird nicht zur operativen Control Plane für die KI-Strategie des Kunden.

Die darüberliegende Orchestrierungsebene – Identity, RBAC, Audit, Capability-Abstraktion, MCP-Server-Allowlisting, Tool-Call-Governance, jurisdiktionales Routing, Multi-LLM-Model-Routing – ist das, was ich in den vorangegangenen sieben Beiträgen beschrieben habe. Die Ingestion- und Retrieval-Schicht ist das Fundament, das dieser Orchestrierungsebene eine eigene Basis gibt – statt sie auf der Basis eines Dritten aufzusetzen. [¹⁵]

Persönliche Einordnung
Ich möchte mit der strategischen Beobachtung schließen, die diese Serie zusammenführt – eine Beobachtung, die durch die Vendor-Moves der vergangenen sechs Wochen schärfer geworden ist, als ich sie vor drei Monaten formuliert hätte.

Der Differenzierungsfaktor in europäischer Enterprise-KI im Jahr 2026 ist nicht länger das Modell, die Chat-Oberfläche oder selbst die Integrationsbreite. Es ist die Antwort auf eine einfache Architekturfrage: Besitzt Ihre KI-Strategie das Substrat, auf dem sie läuft – oder mieten Sie dieses Substrat von Unternehmen, deren Preismodelle Sie nicht kennen und deren Produkt-Roadmaps mit Ihrer eigenen nicht übereinstimmen? Jede Schicht, die wir in dieser Serie betrachtet haben – Modell-Topologie, Tool-Call-Souveränität, Agent-Capability-Dekomposition, Protokoll-Governance, Deployment-Ökonomie und jetzt Ingestion und Retrieval im großen Maßstab – zeigt auf dieselbe Antwort. Souveränes Substrat oder gemietetes Substrat. Es gibt keine dritte Option, die die nächsten zwölf Monate Vendor-Konsolidierung, regulatorische Klarstellung und Procurement-Prüfung überlebt.

Ein Frontier-Modell, das in einem Wettbewerbsprodukt zwei Wochen früher landet als in unserem HUB, ist eine Verzögerung, die wir bewusst akzeptieren – weil wir diese zwei Wochen nutzen, um die Tool-Call-Oberfläche, die Datenfluss-Pfade, das jurisdiktionale Verhalten und die operativen Eigenschaften gegen denselben DSGVO-100%-Standard zu verifizieren, den wir auf jede andere Capability anwenden, die der HUB für regulierte Workloads bereitstellt. Ein SaaS-Vendor-MCP-Server, der morgen live geht, durchläuft denselben Prozess – zertifizierte eingehende Integration, kundeneigener ausgehender Corpus, kein Transfer der Control Plane an einen Anbieter, dessen KI-Roadmap nicht zur Roadmap des Kunden passt. So muss eine ernstzunehmende europäische Enterprise-KI-Plattform Mitte 2026 aussehen – und genau an dieser Architektur haben wir in den vergangenen zwei Jahren Plattformarbeit gebaut.

Der Kunde ist der Operator. Die Vendor-Datenquellen sind Inputs. Die Control Plane bleibt beim Kunden. Das Substrat ist souverän. Alles andere ist Implementierungsdetail.

Ein kurzer Blick auf den regulatorischen Hintergrund, der sich weiterentwickelt. Die EU-Digital-Omnibus-Einigung vom 7. Mai 2026 hat die Hochrisiko-Verpflichtungen nach Anhang III vom 2. August 2026 auf den 2. Dezember 2027 verschoben, und die Pflichten aus Anhang I auf den 2. August 2028. [¹⁶] Die Durchsetzungsbefugnisse für GPAI nach Kapitel V bleiben beim ursprünglichen Termin 2. August 2026. Die strategische Implikation ist unverändert gegenüber den vorangegangenen Beiträgen: Der unmittelbare regulatorische Deadline-Druck hat leicht nachgelassen, die Käuferscrutiny hat zugenommen, Vendor-Konsolidierung hat sich beschleunigt – und die Architekturentscheidungen in Q3 2026 sind diejenigen, die bestimmen, ob Ihr KI-Stack die Procurement-Zyklen 2027 unbeschadet übersteht.

Die neuen Silos sind real. Die Architektur, um ihnen zu entkommen, ist es ebenfalls. Die nächsten zwölf Monate entscheiden, wo der Unterschied sichtbar wird.

¹ Serienartikel unter neuland.ai/insights. Frühere Beiträge: „Control Panels, Execution Surfaces…“ (Feb 2026); „Wenn KI-Systeme plötzlich schlechter werden“ (Apr 2026); „Open weights took the top spot. Meta walked away.“ (Apr/Mai 2026); „Compliance is a system property, not a checkbox“ (Mai 2026); „The lethal trifecta is not a vulnerability. It is a property of the system.“ (Mai 2026); „MCP solved the integration problem. It just made the governance problem bigger.“ (Mai 2026); „Let the racehorses run. Your enterprise needs workhorses.“ (Mai 2026).
² Siehe Fußnote 1 und die dort genannten Beiträge für die im Text referenzierten Architekturargumente.
³ SAP API Policy v4/2026, veröffentlicht April 2026, aktualisiert am 27. April 2026. Abschnitt 2.2.2: APIs dürfen nicht genutzt werden für „interaction or integration with (semi-)autonomous or generative AI systems that plan, select or execute sequences of API calls“. Beschränkungen betreffen ebenfalls großvolumige Datenextraktion außerhalb zertifizierter Pfade sowie Workarounds über Proxies, Gateways, Custom Code oder Impersonation. Siehe The Register, „AI clause in new SAP API policy provokes lock-in concern“, 29. April 2026.
⁴ Christian Klein, SAP CEO, Q1-2026-Investor-Call, Ende April 2026. Direkte Zitate nach The Register und CIO.com.
⁵ DSAG (Deutschsprachige SAP-Anwendergruppe), öffentliche Stellungnahme zur API Policy v4/2026. Siehe CIO.com, „SAP's new API policy restricts AI access, draws customer criticism“, April 2026.
⁶ Forrester, „SAP Is Attempting To Become The Gatekeeper Of Enterprise AI — CIOs Should Push Back“, Mai 2026. Durchsetzungszeitplan: Security Patch ab 9. Juni 2026 blockiert technisch nichtkonforme ODP-via-RFC-Calls. Die Bezeichnung „2027 pricing cliff“ stammt von Forrester; die vollständige Preisstruktur für zertifizierte Pfade ist von SAP noch nicht öffentlich offengelegt.
⁷ Microsoft Learn: „Overview of Microsoft MCP Server for Enterprise — Microsoft Graph“; „Work IQ MCP overview (preview)“; Agent-365-Tooling-Server-Übersicht. Endpoint-Muster: agent365.svc.cloud.microsoft. Abgedeckte Services umfassen Copilot, Calendar, Mail, SharePoint, OneDrive, Teams, Word, Excel, Dataverse, Dynamics 365 und Microsoft Graph Identity APIs.
⁸ ServiceNow Knowledge 2026, Action-Fabric-Ankündigung, Mai 2026. Amit Zavery (COO) zur aktionsbasierten Bepreisung. JPMorgan-Analystenkommentar (Mark Murphy) laut PYMNTS-Bericht „ServiceNow, SAP and Workday Make AI Agents Pay to Play“, Mai 2026. Anthropic-Claude-Launch-Partner via Claude-Cowork-Integration.
⁹ Salesforce-Slack-API-Beschränkungen, April 2026, die Drittparteien das Speichern, Indexieren oder Trainieren auf Slack-Daten für KI-Zwecke untersagen. Salesforce Headless 360 (April 2026): >60 neue MCP-Tools für die breitere Salesforce-Plattform, nutzbar aus jeder MCP-kompatiblen Runtime, ohne proprietäre KI-Schnittstelle. Siehe Techzine, „SAP blocks external AI agents. Salesforce and ServiceNow don't“, Mai 2026.
¹⁰ Siehe Kai Waehner, „Data Ownership in the Age of Agentic AI: Why SAP's API Policy Forces a Data Integration Reckoning for Every Enterprise“, 2. Mai 2026, zur Plattformstabilitäts-Argumentation, die auf ihren eigenen Meriten neben der strukturellen Kritik akzeptiert wird.
¹¹ Zur zugrunde liegenden Compliance-Argumentation siehe den früheren Beitrag „Compliance is a system property, not a checkbox“ (Mai 2026). Das Kernargument – dass DSGVO-Konformität eine Eigenschaft des gesamten Datenfluss-Pfads ist, nicht einer einzelnen Schicht – gilt direkt für das Vendor-AI-Gateway-Muster, das im aktuellen Beitrag beschrieben wird.
¹² Siehe früheren Beitrag „The lethal trifecta is not a vulnerability. It is a property of the system.“ (Mai 2026). Wenn Data Ingestion durch eine Third-Party-AI-Control-Plane läuft, die gleichzeitig Private-Data-Zugriff, Exponierung zu untrusted Content und externe Kommunikationsfähigkeit hält, ist die Trifecta nicht länger eine Eigenschaft eines Agenten, den der Kunde gebaut hat – sondern eine Eigenschaft einer Integration, die der Kunde nicht inspizieren kann.
¹³ Siehe früheren Beitrag „Let the racehorses run. Your enterprise needs workhorses.“ (Mai 2026). Die Fast-Follower-Strategie mit feinjustierten Open-Weight-Workhorse-Modellen auf souveräner Infrastruktur setzt voraus, dass Trainings- und Retrieval-Daten in einem souveränen Substrat materialisiert werden können – genau darum geht es in der Architekturargumentation des aktuellen Stücks.
¹⁴ neuland.ai HUB Ingestion- und Retrieval-Layer: multimodale Pipeline (PDF, Bild, Audio, Video, strukturierte Daten), verteiltes Compute-Substrat, spaltenorientiertes Storage-Backend, das Vektor-, Fulltext- und spaltenorientierte Repräsentationen vereint, hybrides Retrieval (semantisch + lexikalisch) als Default, GPU-basierte Embedding-/Reranking-/OCR-Serving im Cluster des Kunden. Petabyte-Ingestion als engineered Non-Functional Target. Hyperscaler-unabhängige Deployments auf Azure, On-Premises-Kubernetes oder EU-jurisdiktionaler Sovereign Cloud.
¹⁵ neuland.ai AG trägt in allen Kundenprojekten Verantwortung für Inhaltsqualität und saubere Auslieferung der Ergebnisse.
¹⁶ Provisorische politische Einigung von Rat der EU und Europäischem Parlament zum Digital Omnibus on AI, 7. Mai 2026. Hochrisiko-Verpflichtungen nach Anhang III verschoben vom 2. August 2026 auf den 2. Dezember 2027 (16 Monate); Pflichten aus Anhang I verschoben auf den 2. August 2028 (12 Monate); Artikel 50(2) Watermarking verschoben auf den 2. Dezember 2026. GPAI-Durchsetzungsbefugnisse gemäß Kapitel V bleiben beim ursprünglichen Termin 2. August 2026.

Bild generiert mit dem neuland.ai HUB.