Als SAP die Übernahme von Prior Labs ankündigte und mehr als eine Milliarde Euro über vier Jahre zusagte, um daraus ein Frontier-KI-Labor aufzubauen, war die sofortige Reaktion in der DACH-Technologiepresse vorhersehbar: eine weitere große KI-Akquisition, eine weitere Pressemitteilung über die transformative Kraft künstlicher Intelligenz. Das tiefere Signal — dasjenige, das für Enterprise-KI-Architektur tatsächlich zählt — ging unter der Schlagzeilensumme unter.

SAPs CTO formulierte es unverblümt: Die größte ungenutzte Chance in Enterprise-KI seien nicht Large Language Models. Es sei KI, die für die strukturierten Daten gebaut wird, auf denen die Geschäftsprozesse der Welt laufen. Dieser Satz sollte verändern, wie jedes SAP-zentrische Unternehmen in der DACH-Region über seine KI-Roadmap nachdenkt.

Das Problem, das die meiste Enterprise-KI ignoriert

Die KI-Diskussion der vergangenen drei Jahre wurde von Large Language Models dominiert. GPT, Claude, Gemini, Llama — die Frontier-Modelle, die Text generieren, Dokumente zusammenfassen, Fragen beantworten und Konversationen führen. Diese Modelle sind außergewöhnlich gut in der Verarbeitung natürlicher Sprache. Sie sind aber auch, ganz bewusst, für sequenzielle Token-Vorhersage auf unstrukturierten Daten gebaut. Gibt man ihnen einen gut formulierten Absatz, liefern sie bemerkenswerte Ergebnisse. Gibt man ihnen eine Tabelle mit 40 Spalten und 100.000 Zeilen Finanztransaktionen, liefern sie etwas deutlich weniger Brauchbares.

Das ist keine Kritik an LLMs. Es ist eine architektonische Feststellung. Sprachmodelle verarbeiten Text als Sequenz von Token. Eine Tabelle ist keine Sequenz — sie ist eine Matrix aus typisierten Werten, bei der die Beziehung zwischen Spalte 3 und Spalte 27 wichtiger sein kann als die Beziehung zwischen benachbarten Zellen. Die statistischen Muster in einer Zahlungstabelle — welche Kunden verspätet zahlen, welche Lieferanten Risiken bergen, welche Produktlinien einen Aufwärtstrend zeigen — unterscheiden sich fundamental von den Mustern in einem Absatz englischer Prosa.

SAPs eigene interne Bewertung war unmissverständlich: Large Language Models besäßen nur ein rudimentäres Verständnis von Tabellen, Zahlen und Statistik. Jeder, der versucht hat, ein Sprachmodell dazu zu bringen, zuverlässig Abwanderung aus einer Kundentransaktionstabelle vorherzusagen oder Anomalien in einem Finanzdatensatz zu erkennen, weiß, dass das zutreffend ist. Die Modelle können die Tabelle beschreiben. Sie können SQL schreiben, um sie abzufragen. Aber sie können nicht nativ die prädiktiven Muster innerhalb der Daten erlernen, wie es ein zweckgebautes Modell kann.

Das ist deshalb wichtig, weil die überwältigende Mehrheit der Unternehmensdaten tabellarisch ist. ERP-Systeme, CRM-Datenbanken, Finanzbuchhaltung, Supply-Chain-Datensätze, Produktionsprotokolle, HR-Systeme — das operative Rückgrat jedes DACH-Unternehmens besteht aus strukturierten Daten in Zeilen und Spalten. Und die KI-Modelle, die den letzten Zyklus dominierten, waren nicht dafür gebaut.

Was Tabular Foundation Models tatsächlich sind

Prior Labs, gegründet von Frank Hutter, Noah Hollmann und Sauraj Gambhir, hat eine Modellklasse entwickelt, die speziell für tabellarische Daten konzipiert ist. Ihre TabPFN-Modellreihe, publiziert in Nature und validiert in Hunderten unabhängiger akademischer Studien, setzte den State of the Art bei Benchmarks für tabellarische Vorhersagen. Das Team — rekrutiert von Google, Apple, Amazon, Microsoft und Jane Street — repräsentiert eine der tiefsten Konzentrationen tabellarischer ML-Expertise, die je an einem Ort versammelt wurde.

Ein Tabular Foundation Model (TFM) funktioniert anders als ein Sprachmodell. Während ein LLM auf umfangreichen Textkorpora vortrainiert wird und lernt, das nächste Token vorherzusagen, wird ein TFM auf Millionen diverser tabellarischer Datensätze vortrainiert und lernt, die strukturellen Muster zu erkennen, die sich über Tabellen hinweg wiederholen: Korrelationen zwischen Features, nichtlineare Zusammenhänge, Muster fehlender Werte, Verteilungsverschiebungen. Das Modell lernt, wie tabellarische Daten im Allgemeinen aussehen, bevor es jemals die spezifischen Geschäftsdaten eines Unternehmens sieht.

Dieses Pre-Training auf diversen Tabellen verleiht TFMs eine Eigenschaft, die traditionellem maschinellem Lernen fehlt und die LLMs nicht replizieren können: starke Performance bei kleinen Datensätzen. Eine klassische ML-Pipeline — Gradient-Boosted Trees, Random Forests, neuronale Netze — benötigt substanzielle Trainingsdaten, um domänenspezifische Muster von Grund auf zu erlernen. Hunderttausende von Zeilen, manchmal Millionen, bevor das Modell zuverlässig wird. Ein TFM bringt strukturelle Intuitionen bereits mit. Es hat genug Tabellen gesehen, um zu wissen, dass eine Spalte mit hoher Kardinalität und niedriger Varianz sich wahrscheinlich anders verhält als eine mit niedriger Kardinalität und hoher Varianz. Fine-Tuning auf wenigen hundert Zeilen der spezifischen Unternehmensdaten reicht oft aus, um akkurate Vorhersagen zu erzeugen.

Für Unternehmenskontexte, in denen gelabelte Daten rar sind — eine neue Produktlinie mit drei Monaten Verkaufshistorie, ein kürzlich eingebundener Lieferant mit begrenzten Leistungsdaten, ein Marktsegment, in das man gerade erst eintritt — verändert das, was möglich ist.

Warum SAP diese Wette jetzt eingeht

Die Übernahme geschieht nicht isoliert. SAP hat im selben Zeitraum auch Dremio übernommen, eine Data-Lakehouse-Plattform. Das kombinierte Signal ist eindeutig: SAP baut einen vertikal integrierten Stack, in dem die Datenschicht (Dremio und SAP Datasphere), die KI-Schicht (Prior Labs und das bestehende tabellarische Modell SAP-RPT-1) und die Applikationsschicht (S/4HANA, Joule und die SAP Business Technology Platform) so konzipiert sind, dass sie nahtlos zusammenarbeiten.

Das ist architektonisch bedeutsam, weil es die Integrationslücke adressiert, die die Enterprise-KI-Adoption seit Jahren behindert. Heute muss ein DACH-Hersteller, der Lieferverzögerungen vorhersagen will, Daten aus SAP extrahieren, sie in ein Format transformieren, das für eine externe ML-Plattform geeignet ist, ein Modell trainieren, es irgendwo deployen und dann Vorhersagen zurück in SAP leiten. Jeder Schritt bringt Latenz, Komplexität und Fehlerquellen mit sich. Wenn TFMs eingebettet im SAP-Stack ausgeliefert werden, sitzt die Prognosefähigkeit dort, wo die Daten bereits liegen.

SAPs CTO positionierte dies explizit als Gegenentwurf zum Trend der Conversational AI. Joule — SAPs konversationeller Assistent — übernimmt die textbasierte, fragebeantwortende Schicht. Aber Vorhersagen auf strukturierten Daten erfordern zweckgebaute Modelle, keine Chatbots, die als Analysten umfunktioniert werden. Zahlungsverzugsprognose, Churn-Scoring, Bedarfsvorhersage, Lieferantenrisikobewertung, Kreditscoring, Anomalieerkennung in Finanzdaten, Identifikation von Upsell-Chancen — das sind tabellarische Vorhersageprobleme, und SAP wettet darauf, dass deren native Lösung für die Kundenbasis wertvoller sein wird als jede Zahl konversationeller Features.

Das Timing spiegelt auch die Wettbewerbspositionierung wider. Microsoft hat Copilot über seinen gesamten Stack verteilt, aber kein vergleichbares Investment in tabellarische KI. Salesforce hat Einstein, doch das operiert auf CRM-Daten, nicht auf dem gesamten ERP-Footprint. Oracle verfolgt eigene KI-Ambitionen, hat aber keinen vergleichbaren tabellarisch-spezifischen Schritt gemacht. SAP beansprucht die Position als der Enterprise-Anbieter, der strukturierte Datenvorhersage ernst nimmt — und für die 77 Prozent des globalen Transaktionsvolumens, die ein SAP-System berühren, hat diese Position erhebliches Gewicht.

Was sich für DACH-Unternehmen ändert

Für Unternehmen, die SAP als operatives Rückgrat betreiben — was auf die meisten großen und viele mittelständische DACH-Unternehmen zutrifft — sind die Implikationen sowohl strategischer als auch architektonischer Natur.

Die Frage der KI-Architektur verschiebt sich. Das vorherrschende Muster, um KI auf strukturierte Unternehmensdaten anzuwenden, bestand darin, RAG-Pipelines aufzubauen — Daten aus SAP extrahieren, einbetten, in einer Vektordatenbank speichern und ein LLM darauf abfragen lassen. Das funktioniert, um Fragen über die Daten zu beantworten. Es funktioniert nicht, um Vorhersagen aus den Daten zu treffen. Eine RAG-Pipeline kann sagen, wie die Zahlungsmuster des letzten Quartals aussahen. Ein TFM kann vorhersagen, welche Rechnungen im nächsten Quartal verspätet bezahlt werden. Das sind fundamental unterschiedliche Fähigkeiten, und die architektonischen Entscheidungen, die ein Unternehmen heute trifft — welche Systeme integriert, welche Datenpipelines aufgebaut, welche Modellinfrastruktur investiert werden soll — sollten beide berücksichtigen.

Die Build-versus-Buy-Kalkulation verschiebt sich. Wenn SAP TFM-Fähigkeiten direkt in S/4HANA und die Business Technology Platform einbettet, schwächt sich der Fall für den Aufbau eigener tabellarischer ML-Pipelines bei Use Cases ab, die SAPs Modelle gut abdecken. Die Build-versus-Buy-Entscheidung wird dann: Wo brauchen wir maßgeschneiderte Prognosemodelle, die auf unseren spezifischen Wettbewerbsvorteil zugeschnitten sind, und wo können wir auf SAPs eingebettete Fähigkeiten für operative Standardvorhersagen vertrauen? Das ist dieselbe Logik, die für jede Plattformfähigkeit gilt — man baut, wo Differenzierung zählt, und kauft, wo Standardisierung akzeptabel ist.

Die Modellauswahl wird differenzierter. Die Enterprise-KI-Landschaft dreht sich nicht mehr nur um die Wahl zwischen LLM-Anbietern. Wie wir im Framework zum Modellvergleich dargelegt haben, dienen verschiedene Modellkategorien verschiedenen Zwecken. LLMs bearbeiten Text und Konversation. Kleine Sprachmodelle erledigen eng definierte NLP-Aufgaben effizient. TFMs übernehmen tabellarische Vorhersagen. Die richtige Architektur setzt jedes dort ein, wo es exzelliert — nicht einen einzigen Modelltyp für alles. Unternehmen, die sämtliche KI als Sprachmodellproblem behandeln, werden zu wenig in die Vorhersagefähigkeiten für strukturierte Daten investieren, die oft den höchsten operativen ROI liefern.

Datenqualität wird noch kritischer. TFMs sind vortrainiert, um mit verrauschten tabellarischen Daten besser umzugehen als traditionelles ML — sie haben fehlende Werte, inkonsistente Formate und verrauschte Labels über Millionen von Trainingstabellen gesehen. Aber „besser als traditionelles ML" bedeutet nicht „immun gegen Datenmüll". Die Dimensionen der Datenqualität, die über KI-Erfolg entscheiden — Vollständigkeit, Konsistenz, Aktualität, Genauigkeit und Struktur — gelten weiterhin. Ein TFM wird kein Stammdatenproblem lösen, bei dem „Siemens AG" als fünf verschiedene Entitäten über die SAP-Module verteilt erscheint. Es wird einfach fünf separate Vorhersagen für etwas treffen, das ein einziger Kunde sein sollte.

Die Vendor-Auswahl für den KI-Stack erfordert Neubewertung. Für SAP-zentrische Organisationen muss der Prozess der Vendor-Auswahl nun SAPs aufkommende KI-Fähigkeiten neben Drittanbieter-Optionen berücksichtigen. Sich heute auf eine separate tabellarische ML-Plattform festzulegen, kann Redundanz erzeugen, falls SAP innerhalb von 18 Monaten vergleichbare Fähigkeiten nativ liefert. Umgekehrt kann das Warten auf SAP bedeuten, 18 Monate Wettbewerbsvorteil durch Vorhersagen zu verlieren, die man bereits jetzt treffen könnte. Der richtige Ansatz ist, auf Standards zu bauen — saubere Daten, klar definierte Prognoseaufgaben, dokumentierte Feature-Pipelines — die sich plattformübergreifend übertragen, unabhängig davon, welcher Anbieter letztlich das Modell betreibt.

Was jetzt zu tun ist

Die Übernahme soll voraussichtlich in Q2 oder Q3 2026 abgeschlossen werden. Prior Labs wird weiterhin eigenständig operieren, und die Integration in SAPs Produktsuite wird Zeit brauchen. Produktionsreife TFM-Fähigkeiten, eingebettet in S/4HANA, sind vor Ende 2027 unwahrscheinlich. Das gibt Unternehmen ein Zeitfenster — nicht zum Abwarten, sondern zur Vorbereitung.

Den Unterschied zwischen LLMs und TFMs verstehen. Das sind keine konkurrierenden Ansätze. Sie lösen unterschiedliche Probleme. Wenn die aktuelle KI-Roadmap sämtliche KI als Sprachmodellproblem behandelt, hat sie eine Lücke. Use Cases explizit zuordnen: Welche erfordern Textverarbeitung (LLM-Territorium), welche erfordern Vorhersagen aus strukturierten Daten (TFM-Territorium), und welche erfordern beides?

Die Datenschicht bewerten. TFMs brauchen saubere, zugängliche tabellarische Daten. Derselbe Kontext-Layer, der jeden KI-Workflow speist — zugängliche Daten, konsistente Formate, ausreichende Aktualität, kodiertes Domänenwissen — ist die Grundlage für TFM-Adoption. Wenn die SAP-Daten hinter manuellen Exporten und ABAP-Reports verschlossen sind, wird kein noch so ausgereiftes Modell helfen. Jetzt in Datenzugänglichkeit und -qualität investieren, damit bei Verfügbarkeit der TFM-Fähigkeiten die Adoption möglich ist, ohne dass ein sechsmonatiges Datenbereinigungsprojekt den Weg versperrt.

Mit hochwertigsten tabellarischen Vorhersage-Use-Cases beginnen. Man muss nicht auf SAPs TFM-Integration warten, um mit der Vorhersage aus strukturierten Daten zu beginnen. Die drei bis fünf tabellarischen Vorhersageprobleme identifizieren, die den größten operativen Wert schaffen würden — Lieferantenrisiko-Scoring, Zahlungsverzugsprognose, Bedarfsvorhersage, Churn-Erkennung — und damit beginnen, die Datenpipelines, das Feature Engineering und die Evaluierungsframeworks dafür aufzubauen. Wer heute traditionelle Gradient-Boosted Trees oder bestehende AutoML-Werkzeuge nutzt, kann diese Arbeit direkt auf TFMs übertragen. Das Feature Engineering, die Evaluierungsmetriken und die operativen Workflows rund um die Vorhersagen bleiben gleich, unabhängig vom zugrunde liegenden Modell.

Keine architektonischen Festlegungen treffen, die SAPs Richtung widersprechen. Den Aufbau einer großen, eigenen tabellarischen ML-Plattform auf einem Nicht-SAP-Stack zu betreiben, ist riskant, wenn die operativen Daten in SAP liegen und SAP im Begriff ist, native Prognosefähigkeiten anzubieten. Modular bauen. Feature-Pipelines portabel halten. Prognoseaufgaben herstellerneutral definieren. Das ist gute Engineering-Praxis unabhängig von SAPs Roadmap, aber es wird besonders wichtig, wenn der primäre Datenplattform-Anbieter eine Milliarden-Wette darauf eingeht, diese Fähigkeit selbst zu besitzen.

Das strategische Signal

SAPs Übernahme von Prior Labs ist nicht primär eine Technologiegeschichte. Es ist ein strategisches Signal darüber, wo sich Enterprise-KI-Wertschöpfung konzentriert. Der KI-Hype-Zyklus von 2023 bis 2025 fixierte sich auf Conversational AI — Chatbots, Copilots, generative Inhalte. Diese Fähigkeiten sind real und wertvoll, aber sie adressieren nur einen Teil der Enterprise-KI-Chance.

Der größere Gewinn — Outcomes aus den strukturierten Daten vorherzusagen, die den operativen Betrieb tatsächlich steuern — erfordert andere Modelle, andere Architekturen und andere Datenaufbereitung. SAP ist der erste große Enterprise-Anbieter, der eine Milliarden-Wette auf diese These platziert. Ob die Umsetzung gelingt, bleibt abzuwarten. Aber die These selbst ist fundiert, und DACH-Unternehmen, die sie verstehen, werden bessere KI-Architekturentscheidungen treffen — unabhängig davon, welcher Anbieter letztlich die Modelle liefert.

Die Unternehmen, die Tabular Foundation Models als neue Kategorie begreifen — distinkt von LLMs, komplementär zu Conversational AI und abhängig von Datenbereitschaft — werden positioniert sein, um Wert aus SAPs Roadmap zu schöpfen. Diejenigen, die weiterhin sämtliche KI als Sprachmodellproblem behandeln, werden in zwei Jahren ihre Architektur nachrüsten müssen, wenn SAP native Prognosefähigkeiten ausliefert, die ihre Daten nicht unterstützen können.

Buchen Sie einen Fit Call, um zu bewerten, wie SAPs TFM-Roadmap Ihre KI-Architektur beeinflusst. Wir helfen DACH-Unternehmen dabei, ihre tabellarischen Vorhersage-Use-Cases zu kartieren, die Datenbereitschaft für TFM-Adoption zu evaluieren und KI-Architekturen zu entwerfen, die von SAPs Richtung profitieren, ohne Vendor-Lock-in zu erzeugen. Fit Call buchen →

References: SAP SE, "SAP to Acquire Prior Labs," press release, May 2026; Hollmann, Müller, and Hutter, "TabPFN: A Transformer That Solves Small Tabular Classification Problems in a Second," Nature, 2025; SAP SE, "SAP Announces SAP-RPT-1 Tabular Foundation Model," SAP TechEd keynote, 2025; SAP SE, "SAP to Acquire Dremio," press release, May 2026; Gartner, "Magic Quadrant for Cloud ERP for Product-Centric Enterprises," 2025 (77 percent of transaction revenue touching SAP systems).