Als SAP die Übernahme von Prior Labs ankündigte und zusagte, über die nächsten vier Jahre mehr als eine Milliarde Euro zu investieren, um daraus ein führendes Frontier-KI-Labor in Europa aufzubauen, war die Reaktion in der Technologiepresse vorhersehbar: noch eine große KI-Akquisition, noch eine Pressemitteilung über die transformative Kraft künstlicher Intelligenz. Das eigentliche Signal — dasjenige, das für Ihre KI-Architektur tatsächlich zählt — ging in der Schlagzeile unter. Es lautet: Der Wettlauf um Enterprise-KI verschiebt sich von der Sprache zu den Zahlen.

SAP bringt es selbst auf den Punkt. Large Language Models, so die Begründung der Übernahme, haben „nur ein rudimentäres Verständnis von Tabellen, Zahlen und Statistik" — und genau auf solchen Daten laufen die Geschäftsprozesse der Welt. Prior Labs gilt als Pionier einer eigenen Modellklasse für strukturierte Daten: Tabular Foundation Models. Wenn der Anbieter, der das operative Rückgrat eines Großteils des DACH-Mittelstands betreibt, eine Milliarde Euro auf diese These setzt, ist das kein Randthema für die KI-Roadmap. Es ist eine Annahme, die Sie überprüfen sollten, bevor Sie das nächste Budget freigeben.

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.

Diese Diagnose stammt nicht von einem Kritiker, sondern aus SAPs eigener Begründung für die Übernahme: Sprachmodelle hätten „nur ein rudimentäres Verständnis von Tabellen, Zahlen und Statistik". Jeder, der versucht hat, ein LLM dazu zu bringen, zuverlässig Kundenabwanderung aus einer Transaktionstabelle vorherzusagen oder Anomalien in einem Finanzdatensatz zu erkennen, kennt das Ergebnis. 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 in den 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 und in Freiburg ansässig, hat eine Modellklasse entwickelt, die speziell für tabellarische Daten konzipiert ist. Die TabPFN-Modellreihe wurde in Nature publiziert und laut SAP in Hunderten unabhängiger akademischer Studien validiert. Das Forschungsteam wurde unter anderem von Google, Apple, Amazon, Microsoft, Jane Street und CERN rekrutiert — eine ungewöhnlich tiefe Konzentration tabellarischer ML-Expertise, und bemerkenswert für ein europäisches Labor.

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 darauf trainiert, 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 Vortraining 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. Oft Hunderttausende von Zeilen, bevor das Modell zuverlässig wird. Ein TFM bringt strukturelle Intuitionen bereits mit. Das im Nature-Paper beschriebene Ergebnis ist drastisch: TabPFN schlägt auf Datensätzen mit bis zu 10.000 Zeilen ein über vier Stunden optimiertes Ensemble der stärksten klassischen Verfahren — in unter drei Sekunden und ohne aufgabenspezifisches Training. SAPs eigenes Modell SAP-RPT-1, das auf derselben Architekturlinie aufsetzt, löst Klassifikations- und Regressionsaufgaben sogar per In-Context-Learning, also ganz ohne Fine-Tuning: Man gibt dem Modell die Tabelle und die zu prognostizierende Spalte, und es liefert die Vorhersage.

Für Unternehmenskontexte, in denen gelabelte Daten rar sind — eine neue Produktlinie mit drei Monaten Verkaufshistorie, ein gerade erst eingebundener Lieferant, ein Marktsegment, in das Sie eben erst eintreten — verschiebt das, was überhaupt möglich ist. Genau die Situationen, in denen klassisches ML mangels Datenbasis kapituliert, sind die natürliche Stärke eines TFM.

Warum SAP diese Wette jetzt eingeht

Die Übernahme geschieht nicht isoliert. SAP hat fast zeitgleich die Absicht erklärt, Dremio zu übernehmen, eine offene, Iceberg-native Data-Lakehouse-Plattform, die SAP- und Nicht-SAP-Daten ohne Datenbewegung zusammenführen soll. Das kombinierte Signal ist eindeutig: SAP baut einen vertikal integrierten Stack, in dem die Datenschicht (Dremio in der Business Data Cloud), die KI-Schicht (Prior Labs und das bereits verfügbare SAP-RPT-1) und die Applikationsschicht (S/4HANA, Joule, die SAP Business Technology Platform) so konzipiert sind, dass sie zusammenarbeiten. SAPs CTO formuliert die Datenseite dieser Wette bemerkenswert offen: „Enterprise-KI scheitert nicht daran, dass die Modelle nicht gut genug sind; sie scheitert daran, dass die Daten nicht KI-bereit sind."

Das ist architektonisch bedeutsam, weil es die Integrationslücke adressiert, die die Enterprise-KI-Adoption seit Jahren bremst. Heute muss ein DACH-Hersteller, der Lieferverzögerungen vorhersagen will, Daten aus SAP extrahieren, in ein Format für eine externe ML-Plattform transformieren, ein Modell trainieren, es irgendwo deployen und die Vorhersagen zurück in SAP leiten. Jeder dieser Schritte bringt Latenz, Komplexität und Fehlerquellen mit sich — und in der Praxis eine Übergabe zwischen IT, Data Science und Fachabteilung, an der viele Pilotprojekte hängenbleiben. Sitzt die Prognosefähigkeit eingebettet dort, wo die Daten ohnehin liegen, fällt diese Kette weg.

Inhaltlich positioniert SAP das als Gegenentwurf zum reinen Conversational-AI-Trend. Joule — der konversationelle Assistent — übernimmt die textbasierte, fragebeantwortende Schicht. Vorhersagen auf strukturierten Daten dagegen erfordern zweckgebaute Modelle, keine Chatbots, die als Analysten umfunktioniert werden. Zahlungsverzugsprognose, Churn-Scoring, Bedarfsvorhersage, Lieferantenrisikobewertung, Anomalieerkennung in Finanzdaten, Identifikation von Upsell-Chancen — das sind tabellarische Vorhersageprobleme, und SAP wettet darauf, dass deren native Lösung für die Kundenbasis mehr Wert schafft als jede weitere konversationelle Funktion.

Auch wettbewerblich ist der Schritt aufschlussreich. Microsoft hat Copilot über den gesamten Stack verteilt, aber kein vergleichbares Investment in tabellarische KI. Salesforce hat Einstein, das jedoch auf CRM-Daten operiert, nicht auf dem gesamten ERP-Footprint. Oracle verfolgt eigene KI-Ambitionen ohne einen vergleichbar tabellarisch-spezifischen Schritt. SAP beansprucht damit eine Position, die bislang niemand klar besetzt: der Enterprise-Anbieter, der Vorhersage auf strukturierten Daten zur Kernfähigkeit der Plattform macht. Für Unternehmen, deren wertschöpfende Transaktionen ohnehin durch ein SAP-System laufen, ist das keine akademische Unterscheidung.

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 eigene KI-Fähigkeiten neben Drittanbieter-Optionen abwägen. Sich heute langfristig auf eine separate tabellarische ML-Plattform festzulegen, kann Redundanz erzeugen, wenn SAP vergleichbare Fähigkeiten nativ in den Stack zieht. Umgekehrt heißt blindes Warten auf SAP, Quartale an Vorhersagewert zu verschenken, den Sie mit bereits verfügbaren Werkzeugen heben könnten. Der tragfähige Mittelweg ist, auf Portierbarkeit zu bauen — saubere Daten, klar definierte Prognoseaufgaben, dokumentierte Feature-Pipelines —, die sich plattformübergreifend übertragen, unabhängig davon, welcher Anbieter am Ende das Modell betreibt.

Was jetzt zu tun ist

Die Übernahme soll laut SAP in Q2 oder Q3 2026 abgeschlossen werden, vorbehaltlich der üblichen Freigaben. Prior Labs wird weiterhin eigenständig operieren, und die tiefe Integration in S/4HANA und die Business Technology Platform wird Zeit brauchen. Wichtig ist aber: SAP-RPT-1 ist bereits heute über SAP AI Core verfügbar — Sie müssen nicht auf den Abschluss der Akquisition warten, um die Kategorie zu erproben. Das ergibt ein Zeitfenster, das nicht zum Abwarten einlädt, 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 — Ergebnisse 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; Pressemitteilungen sind keine Roadmaps. Aber die These selbst ist fundiert, und DACH-Unternehmen, die sie früh verstehen, treffen bessere KI-Architekturentscheidungen — unabhängig davon, welcher Anbieter am Ende 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 to Establish a Globally Leading Frontier AI Lab in Europe", Pressemitteilung, Mai 2026; Hollmann et al., „Accurate predictions on small data with a tabular foundation model", Nature, Januar 2025; SAP SE, „SAP to Acquire Dremio to Unify SAP and Non-SAP Data to Power Agentic AI", Pressemitteilung, Mai 2026; SAP SE, „SAP-RPT-1", SAP Help Portal, 2026.