When SAP announced it would acquire Prior Labs and invest more than one billion euros over four years to scale it into a frontier AI lab in Europe, the immediate reaction across the DACH technology press was predictable: another large-scale AI acquisition, another release about the transformative power of artificial intelligence. The deeper signal — the one that matters for how you architect enterprise AI — sat beneath the headline number.
SAP's chief technology officer, Philipp Herzig, put it plainly in the announcement: "Early on, SAP recognized that the greatest untapped opportunity in enterprise AI wasn't large language models; it was AI built for the structured data that runs the world's businesses." That sentence should change how every SAP-centric company in the DACH region thinks about its AI roadmap — and it is unusually candid, because it concedes that the technology the market has spent three years celebrating is the wrong tool for the data most enterprises actually run on.
The problem that most enterprise AI ignores
The AI conversation since 2023 has been dominated by large language models. GPT, Claude, Gemini, Llama — the frontier models that generate text, summarise documents, answer questions, and hold conversations. These models are extraordinary at processing natural language. They are also, by design, built for sequential token prediction on unstructured data. Feed them a well-written paragraph and they produce remarkable results. Feed them a table with forty columns and a hundred thousand rows of financial transactions and they produce something far less useful.
This is not a criticism of LLMs. It is a statement of architecture. Language models process text as a sequence of tokens. A table is not a sequence — it is a matrix of typed values where the relationship between column 3 and column 27 may matter more than the relationship between adjacent cells. The statistical patterns in a payments table — which customers pay late, which suppliers carry risk, which product lines are trending upward — are categorically different from the patterns in a paragraph of English prose.
SAP's own assessment is blunt. Its announcement states that large language models "struggle to make accurate predictions on structured business data because they have only a rudimentary understanding of tables, numbers and statistics." Anyone who has tried to get a language model to reliably predict churn from a customer transaction table, or to flag anomalies in a financial ledger, recognises this. The model can describe the table. It can write SQL to query it. It can even reason about it in prose. But it cannot natively learn the predictive patterns inside it the way a purpose-built model can.
This matters because the overwhelming majority of enterprise data is tabular. ERP systems, CRM databases, financial ledgers, supply chain records, production logs, HR systems — the operational backbone of every DACH enterprise is structured data in rows and columns. And the model class that dominated the last cycle was not built for it.
What tabular foundation models actually are
Prior Labs — founded in 2024 by Frank Hutter, Noah Hollmann, and Sauraj Gambhir, and headquartered in Freiburg with offices in Berlin and New York — built a class of models designed specifically for tabular data. Its TabPFN model, published in Nature in January 2025, set a new state of the art on small-data tabular prediction. The headline result from that paper is worth sitting with: on classification tasks with up to roughly ten thousand samples, TabPFN matched or beat an ensemble of the strongest tuned baselines — and did so in seconds rather than the hours those baselines needed for tuning. Frank Hutter is one of the most cited researchers in automated machine learning, and the team's body of work is among the deepest concentrations of tabular ML expertise in Europe.
A tabular foundation model (TFM) works differently from a language model. Where an LLM is pre-trained on text corpora to predict the next token, a TFM is pre-trained on a vast number of diverse, mostly synthetic tabular datasets to recognise the structural patterns that recur across tables: correlations between features, non-linear relationships, missing-value patterns, distributional shifts. The model learns what tabular data looks like in general before it ever sees your specific business data.
That pre-training gives TFMs a property classical machine learning lacks and LLMs cannot replicate: strong performance on small datasets. A classical pipeline — gradient-boosted trees, random forests, bespoke neural networks — has to learn domain-specific patterns from scratch, which usually means tens or hundreds of thousands of rows before it becomes reliable. A TFM arrives with structural intuitions already in place; in TabPFN's case, predictions come from a single forward pass with no per-task training at all. For many tasks, a few hundred rows of your own data are enough to produce accurate predictions.
For enterprise contexts where labelled data is scarce — a new product line with three months of sales history, a recently onboarded supplier with thin performance data, a market segment you are only now entering — this changes what is possible.
Why SAP is making this bet now
The acquisition is not happening in isolation. Days earlier, SAP agreed to acquire Dremio, an Apache Iceberg-native data lakehouse platform, to fold into SAP Business Data Cloud. The combined signal is clear: SAP is building a vertically integrated stack where the data layer (Dremio and Business Data Cloud), the AI layer (Prior Labs alongside SAP's own SAP-RPT-1 relational foundation model), and the application layer (S/4HANA, Joule, and the Business Technology Platform) are designed to work together. Herzig framed the Dremio deal in the same terms: "Enterprise AI doesn't stall because the models aren't good enough; it stalls because the data isn't ready."
This is architecturally significant because it attacks the integration gap that has throttled enterprise AI. Today, a DACH manufacturer that wants to predict supplier delays has to extract data from SAP, transform it for a third-party ML platform, train a model, deploy it somewhere, then pipe predictions back into SAP. Each hop adds latency, complexity, and a new failure mode. If TFMs ship embedded in the SAP stack, the prediction sits where the data already lives — and SAP has named the productisation path: SAP AI Core, SAP Business Data Cloud, and the agentic Joule layer.
It is worth being precise about where these models fit. Joule handles the conversational, question-answering layer. Predictions on structured data require purpose-built models, not a chatbot repurposed as an analyst. Payment delay prediction, churn scoring, demand forecasting, supplier risk, anomaly detection in financial data, upsell identification — these are tabular prediction problems, and SAP is betting that solving them natively is worth more to its base than another tier of conversational features. SAP claims its own RPT-1 model delivers materially higher prediction quality than general-purpose LLMs on these tasks; treat the specific multiple as a vendor figure, but the direction is consistent with the independent TabPFN results.
The timing also reflects competitive and sovereignty positioning. Microsoft has Copilot across its stack but no comparable tabular-AI investment; Salesforce has Einstein, but it lives on CRM data rather than the full ERP footprint; Oracle has AI ambitions but no equivalent tabular-specific move. SAP is staking out a position as the enterprise vendor that takes structured-data prediction seriously — and as a European-headquartered frontier lab, which carries weight for DACH boards now weighing digital sovereignty alongside capability.
What this changes for DACH enterprises
For companies running SAP as their operational backbone — which describes most large and many mid-sized DACH enterprises — the implications are both strategic and architectural.
The AI architecture question shifts. The prevailing pattern for applying AI to structured enterprise data has been to build RAG pipelines — extract data from SAP, embed it, store it in a vector database, and let an LLM query it. This works for answering questions about the data. It does not work for making predictions from the data. A RAG pipeline can tell you what last quarter's payment patterns looked like. A TFM can predict which invoices will be paid late next quarter. These are fundamentally different capabilities, and the architectural decisions an enterprise makes today — which systems to integrate, which data pipelines to build, which model infrastructure to invest in — should account for both.
The build-versus-buy calculus shifts. If SAP embeds TFM capabilities directly into S/4HANA and the Business Technology Platform, the case for building custom tabular ML pipelines weakens for use cases that SAP's models cover well. The build-versus-buy decision becomes: where do we need custom prediction models tailored to our specific competitive advantage, and where can we rely on SAP's embedded capabilities for standard operational predictions? This is the same logic that applies to any platform capability — you build where differentiation matters and buy where standardisation is acceptable.
Model selection becomes more nuanced. The enterprise AI landscape is no longer just about choosing between LLM providers. As we outlined in the model comparison framework, different model categories serve different purposes. LLMs handle text and conversation. Small language models handle narrow NLP tasks efficiently. TFMs handle tabular prediction. The right architecture uses each where it excels — not a single model type for everything. Enterprises that treat all AI as a language model problem will underinvest in the structured-data prediction capabilities that often deliver the highest operational ROI.
Data quality becomes even more critical. TFMs are pre-trained to handle messy tabular data better than traditional ML — they have seen missing values, inconsistent formats, and noisy labels across millions of training tables. But "better than traditional ML" does not mean "immune to garbage." The data quality dimensions that determine AI success — completeness, consistency, currency, accuracy, and structure — still apply. A TFM will not fix a master data problem where "Siemens AG" appears as five different entities across your SAP modules. It will simply make five separate predictions for what should be one customer.
Vendor selection for the AI stack requires re-evaluation. For SAP-centric organisations, the vendor selection process must now account for SAP's emerging AI capabilities alongside third-party options. Committing to a separate tabular ML platform today may create redundancy if SAP delivers equivalent capabilities natively within 18 months. Conversely, waiting for SAP may mean losing 18 months of competitive advantage from predictions you could be making now. The right approach is to build on standards — clean data, well-defined prediction tasks, documented feature pipelines — that transfer across platforms regardless of which vendor ultimately runs the model.
What to do now
The acquisition is expected to close in Q2 or Q3 2026, subject to regulatory approval, and Prior Labs will keep operating as an independent entity inside SAP. Productisation through SAP AI Core, Business Data Cloud, and Joule will take time after that — embedding research-grade models into shipping enterprise software is rarely a matter of months. SAP has not committed to a general-availability date, and you should not plan around one. That uncertainty is the window: not a reason to wait, but time to prepare.
Understand the distinction between LLMs and TFMs. These are not competing approaches. They solve different problems. If your current AI roadmap treats all AI as a language model problem, it has a gap. Map your use cases explicitly: which ones require text processing (LLM territory), which ones require prediction from structured data (TFM territory), and which ones require both?
Assess your data layer. TFMs need clean, accessible tabular data. The same context layer that feeds any AI workflow — accessible data, consistent formats, sufficient freshness, encoded domain knowledge — is the foundation for TFM adoption. If your SAP data is locked behind manual exports and ABAP reports, no model, however sophisticated, will help. Invest in the data accessibility and quality work now so that when TFM capabilities arrive, you can adopt them without a six-month data remediation project blocking the way.
Start with high-value tabular prediction use cases. You do not need to wait for SAP's TFM integration to begin predicting from structured data. Identify the three to five tabular prediction problems that would create the most operational value — supplier risk scoring, payment delay prediction, demand forecasting, churn detection — and begin building the data pipelines, feature engineering, and evaluation frameworks for them. If you use traditional gradient-boosted trees or existing AutoML tools today, that work transfers directly to TFMs later. The feature engineering, the evaluation metrics, and the operational workflows around the predictions remain the same regardless of the underlying model.
Do not over-commit to architecture that conflicts with SAP's direction. Building a large, custom tabular ML platform on a non-SAP stack is risky if your operational data lives in SAP and SAP is about to offer native prediction capabilities. Build modular. Keep your feature pipelines portable. Define your prediction tasks in a vendor-neutral way. This is good engineering practice regardless of SAP's roadmap, but it becomes especially important when your primary data platform vendor is making a billion-euro bet on owning this capability.
The strategic signal
SAP's acquisition of Prior Labs is not primarily a technology story. It is a strategic signal about where enterprise AI value concentrates. The AI hype cycle of 2023 to 2025 fixated on conversational AI — chatbots, copilots, generative content. Those capabilities are real and valuable, but they address only part of the enterprise AI opportunity.
The larger prize — predicting outcomes from the structured data that actually runs operations — requires different models, different architectures, and different data preparation. SAP is the first major enterprise vendor to place a billion-euro bet on this thesis. Whether they execute well remains to be seen. But the thesis itself is sound, and DACH enterprises that understand it will make better AI architecture decisions regardless of which vendor delivers the models.
The companies that treat tabular foundation models as a new category — distinct from LLMs, complementary to conversational AI, and dependent on data readiness — will be positioned to capture value from SAP's roadmap. The ones that continue to treat all AI as a language model problem will find themselves retrofitting their architecture in two years when SAP ships native prediction capabilities that their data cannot support.
A Fit Call maps your tabular prediction use cases and pressure-tests your SAP data layer against the TFM shift — before the architecture you commit to this year becomes the one you have to retrofit in two. We help DACH enterprises decide where to build, where to wait for SAP's native capabilities, and how to keep feature pipelines portable so your direction benefits from SAP's without locking you in.
References: SAP SE, "SAP to Acquire Prior Labs to Establish a Globally Leading Frontier AI Lab in Europe," press release, May 2026; Hollmann, Müller, Purucker, Krishnakumar, Körfer, Hoo, Schirrmeister, and Hutter, "Accurate predictions on small data with a tabular foundation model," Nature, January 2025; SAP SE, "SAP to Acquire Dremio to Unify SAP and Non-SAP Data to Power Agentic AI," press release, May 2026; SAP SE, "SAP-RPT-1 — Relational Pretrained Transformer," product page, 2026.