Fundamental stellt erstes großskaliges Foundation Model nur für Tabellendaten vor – was das für Unternehmensdaten bedeutet

Die tabellarischen Kerndaten vieler Unternehmen – ERP-Buchungen, CRM-Opportunities, Logistik- und Sensordaten – rücken in den Fokus der Foundation-Model-Revolution. Das US-Startup Fundamental ist am 5. Februar 2026 aus dem Stealth-Modus gekommen und hat mit NEXUS ein Foundation Model vorgestellt, das ausschließlich für strukturierte Tabellendaten trainiert ist und dafür 255 Mio. US‑Dollar Finanzierung erhält. Im Gegensatz zu LLMs, die Text verstehen und generieren, zielt NEXUS direkt auf numerische und kategoriale Spalten, Zeitreihen und Relationen in Unternehmensdaten.

Der Artikel ordnet den Launch von Fundamental ein, erklärt die Besonderheiten tabellarischer Foundation Models und analysiert, welche neuen Möglichkeiten – aber auch Risiken – sich für Unternehmen in den Bereichen Forecasting, Pricing, Betrugserkennung und Governance ergeben.

1. Kontext: Was genau hat Fundamental heute angekündigt?

1.1 Das Startup Fundamental und sein Produkt NEXUS

Fundamental ist ein US‑Startup, das sich auf KI für strukturierte Unternehmensdaten spezialisiert und sich bisher im Stealth-Modus befand. Am 5. Februar 2026 hat das Unternehmen:

• eine Finanzierung von 255 Mio. US‑Dollar bekanntgegeben,

• sowie den öffentlichen Launch von NEXUS, einem „Large Tabular Model“ (LTM), das als Foundation Model speziell für Tabellen- und BI-Daten konzipiert ist.

Kernversprechen von NEXUS:

• Eingangsdaten: Tabellen aus ERP-, CRM-, Finanz- und operativen Systemen, Data Warehouses und Data Lakes.

• Aufgaben: Vorhersage (z. B. Umsatz, Nachfrage, Ausfallwahrscheinlichkeit), Risiko-Scoring, Anomalieerkennung, Klassifikation, Ranking, teilweise auch Generierung synthetischer Daten.

• Betriebsmodell: Das Modell soll sowohl als Cloud-Service (API) als auch – zumindest perspektivisch – in kundennahen Deployments laufen, um sensible Daten nicht zwangsläufig in eine Public Cloud transferieren zu müssen.

Fundamental positioniert NEXUS explizit als Foundation Model für Tabellen, analog zu LLMs im Textbereich, aber mit einem anderen Pretraining-Setup und Datenfokus.

1.2 Warum „nur für Tabellendaten“ relevant ist

Im Gegensatz zu textzentrierten LLMs, die Tabellen höchstens „als Text“ sehen (CSV, Markdown, JSON), adressiert ein spezialisiertes Tabular Model strukturelle Eigenschaften direkt:

• Spalten- und Zeilenstruktur: Beziehungen zwischen Features (Spalten) und einzelnen Beobachtungen (Zeilen) werden explizit modelliert.

• Numerische Skalen und Verteilungen: Umgang mit schiefen Verteilungen, Ausreißern, fehlenden Werten.

• Relationale Informationen: Primär- und Fremdschlüssel, Hierarchien (z. B. Kunde → Vertrag → Transaktion).

• Zeitbezug: Zeitreihen, saisonale Muster, Verzögerungen.

Dadurch sollen Modelle wie NEXUS dort performen, wo klassische Deep-Learning-Modelle bisher schwach waren und wo Gradient-Boosting-Modelle (XGBoost, LightGBM, CatBoost) noch dominieren.

2. Technischer und strategischer Hintergrund: Tabular Foundation Models

2.1 Bisherige Landschaft: Von TabPFN bis zu ersten Enterprise-Modellen

In den letzten Jahren sind mehrere Forschungs- und Produktinitiativen rund um tabellarische Foundation Models entstanden:

• TabPFN (Tabular Prior-data Fitted Network) als eines der ersten breit rezipierten tabularen Foundation Models aus der Forschung, vortrainiert auf Millionen synthetischer Datensätze.

• Nachfolger wie TabPFN‑2.5 erweitern Skalierung und Anwendungsbreite und zeigen, dass Tabular Foundation Models in Benchmarks klassische tree‑basierte Methoden übertreffen können.

• Zudem gibt es erste Enterprise-Ansätze großer Anbieter, die tabellenzentrierte Modelle für Geschäftsapplikationen ankündigen.

Fundamental positioniert sich jetzt im gleichen grundlegenden Paradigma, aber mit einem klaren Fokus auf:

• sehr große, echte Unternehmensdatensätze (nicht nur synthetisch generierte Daten),

• End‑to‑End-Produkte für Data-Science- und Analytics-Teams,

• Produktionsreife (Sicherheit, Monitoring, Governance).

2.2 Wie unterscheidet sich ein Large Tabular Model von einem LLM?

Wesentliche Unterschiede – vereinfacht dargestellt:

1. Datenbasis

- LLMs: Milliarden Token an natürlicher Sprache, Code, teils Bilder.

- LTM wie NEXUS: Milliarden Zeilen tabellarischer Daten aus unterschiedlichen Domänen, ergänzt um synthetische Daten und möglicherweise Metadaten.

1. Architektur

- LLMs: Sequenz-Transformer mit Fokus auf Token-Reihenfolge.

- LTMs: Varianten von Transformern, die Reihen (Samples) und Spalten (Features) getrennt bzw. kombiniert betrachten und auf statistische Abhängigkeiten in Tabellen spezialisiert sind.

1. Inferenz & Aufgaben

- LLMs: Next-Token-Prediction, Text-Generierung, semantische Suche.

- LTMs: Wahrscheinlichkeiten und numerische Zielgrößen, Risiko-Scoring, Anomaliescores, Empfehlungen, Forecasts.

1. Evaluierung

- LLMs: Benchmarks wie MMLU, Textverständnis, Codetests.

- LTMs: Klassifikations- und Regressionsbenchmarks auf Tabellendaten, z. B. TabArena, interne Unternehmensbenchmarks.

Für Entscheider wichtig: Während LLMs vor allem die Interaktion mit Wissen verändern (Chatbots, Wissenssuche), zielen LTMs auf den Kern der operativen Steuerung: Entscheidungen auf Basis von Kennzahlen und Ereignissen in Tabellen.

3. Was ist an Fundamentals Ansatz neu oder anders?

3.1 Fokus auf Enterprise-Tabellen als „First-Class Citizen“

Fundamental stellt Tabellen explizit in den Mittelpunkt seiner Produktstrategie:

• Das Modell soll direkt auf strukturierten Enterprise-Schemata arbeiten, ohne dass diese zuvor in Text konvertiert und via Prompting beschrieben werden müssen.

• Features wie Kunden-ID, Produktkategorie, Zahlungskanal oder Kampagnen-ID werden als strukturierte, teils kategoriale Variablen verstanden.

• Zeitliche und relationale Kontexte (z. B. die letzten N Transaktionen eines Kunden) werden als Sequenzen innerhalb der Tabellenrepräsentation modelliert.

Damit wird vermieden, dass kritische Informationen in einer Textrepräsentation „verwaschen“ werden.

3.2 Pretraining auf realen Unternehmensdomänen

Während frühe tabulare Foundation Models primär auf synthetischen Datensätzen vortrainiert wurden, setzt Fundamental – nach eigenen Angaben – stark auf:

• Domänenvielfalt (Finanzdaten, E‑Commerce, SaaS-Metriken, Industrie, Gesundheitsdaten – soweit zulässig),

• Qualitäts- und Fehlerprofile, wie sie in echten Systemen vorkommen (fehlende Werte, inkonsistente Codierungen, saisonale Effekte),

• Multi-Task-Learning, also gleichzeitiges Lernen über viele unterschiedliche Zielgrößen und Tasks hinweg.

Das Ziel: Ein Modell, das übertragbares Wissen über typische Muster in Unternehmensdaten aufgebaut hat und deshalb schneller und robuster auf neue Datensätze adaptiert werden kann.

3.3 Foundation Model statt klassischem AutoML

Viele Unternehmen setzen heute auf AutoML-Frameworks, die verschiedene Standard-Modelle (XGBoost, Random Forests, neuronale Netze) automatisiert testen und optimieren. Fundamental geht einen anderen Weg:

• Ein großes, vortrainiertes Basismodell (NEXUS) bildet den Ausgangspunkt.

• Neue Unternehmensaufgaben werden per Fine-Tuning oder Prompting im Featureraum gelöst, nicht per erneuter Modellkonstruktion von Null.

• Modelle können mehrere Aufgaben gleichzeitig bedienen – z. B. Churn, Upsell-Wahrscheinlichkeit, Betrugsrisiko – anstatt für jedes Ziel ein eigenes Modell aufzusetzen.

Das senkt potenziell die Komplexität im MLOps-Betrieb, erhöht aber die Abhängigkeit von einem zentralen Modell.

4. Konkrete Anwendungsfälle in Unternehmen

4.1 Risiko- und Kredit-Scoring

Beispielszenario: Eine Bank nutzt heute für Kreditentscheidungen Gradient-Boosting-Modelle auf Daten wie Einkommen, Zahlungshistorie, Auslastung des Kreditrahmens, Branche, Region.

Mit einem Foundation Model wie NEXUS könnte sie:

• historische Kreditportfolios, Transaktionsdaten und Makroindikatoren als einheitlichen tabellarischen Raum modellieren,

• neue Scoring-Varianten (z. B. ESG-Risiko, Frühwarnindikatoren) schneller definieren,

• Sensitivitätsanalysen („Was passiert mit dem Ausfallrisiko, wenn Zinssätze X % steigen?“) systematisch aus dem Modell ableiten.

Wichtig: Strenge Erklärbarkeits- und Regulierungsanforderungen (z. B. in der EU) müssen weiterhin erfüllt werden. Unternehmen sollten prüfen, welche Explainability-Tools und Dokumentationsfunktionen Fundamental anbietet.

4.2 Forecasting in Supply Chain und Vertrieb

Unternehmen mit Tausenden Produkten und komplexen Lieferketten kämpfen mit:

• volatilen Nachfrageprognosen,

• Störungen in der Lieferkette,

• saisonalen und regionalen Effekten.

Ein tabulares Foundation Model kann:

• mehrdimensionale Zeitreihen (z. B. Absatz pro Produkt, Region, Kanal, Woche) gemeinsam modellieren,

• exogene Variablen wie Promotionen, Preisänderungen, Feiertage einbeziehen,

• Forecasts für viele Granularitäten gleichzeitig erzeugen (SKU-, Kategorien-, Länder-Ebene),

• Unsicherheiten (Konfidenzintervalle) ausgeben, die für Bestands- und Kapazitätsplanung genutzt werden können.

4.3 Pricing und Revenue Management

Im Handel, in der Reisebranche oder im SaaS-Bereich können LTMs Muster in Preis‑, Rabatt- und Nachfragedaten erkennen:

• Dynamische Preisgestaltung: Ableitung optimaler Preisempfehlungen je Produkt, Kunde, Kanal.

• Kampagnenevaluation: Wirkungsanalysen von Aktionen auf Umsatz und Marge.

• Personalisierte Angebote: Kombination historischer Kaufdaten, Klickstreams (sofern tabellarisiert) und Kundensegmente.

Die Besonderheit: NEXUS lernt generische Muster, wie Preiselastizitäten typischerweise aussehen, und kann dieses Wissen auf neue Produkte übertragen, bei denen noch wenig Historie vorliegt.

4.4 Betrugserkennung und Anomalieerkennung

Transaktionsdaten, Claims im Versicherungsbereich oder Login-Events lassen sich tabellarisch darstellen. Hier bieten sich LTMs für:

• Anomalie-Scoring über verschiedene Featurekombinationen,

• Erkennung komplexer Muster (z. B. zeitliche Häufungen, ungewöhnliche Kombinationen von Kanal, Gerät, Standort),

• Schnellere Anpassung an neue Betrugsmuster ohne komplettes Re‑Training klassischer Modelle.

4.5 Churn- und NRR-Analysen in SaaS und Subscription-Modellen

SaaS-Anbieter und Subscription-Geschäftsmodelle stützen sich massiv auf tabellarische KPIs: Nutzungshäufigkeit, Seats, Feature-Adoption, Support-Tickets, Zahlungsverspätungen.

Ein Large Tabular Model kann:

• Churn-Risiken auf Kunden- oder User-Level modellieren,

• Net Revenue Retention (NRR) und Expansion-Wahrscheinlichkeiten prognostizieren,

• Segment-spezifische Treiber identifizieren (z. B. welche Feature-Adoption besonders churn-relevant ist).

Damit werden präzisere Priorisierungen für Customer-Success-Teams möglich.

5. Technische und organisatorische Implikationen für Unternehmen

5.1 Data Governance und Feature-Zugriff

Da NEXUS direkt auf Kernsystemdaten aufsetzt, verschärfen sich Governance-Anforderungen:

• Datenzugriff: Wer darf welche Tabellen bzw. Spalten für das Modell freigeben? Müssen Views oder Data Products definiert werden, um sensible Informationen auszublenden?

• Datenschutz & Compliance: Bei personenbezogenen Daten (Kunden, Patienten, Mitarbeitende) müssen DSGVO, Branchengesetze und interne Policies eingehalten werden. Pseudonymisierung, Anonymisierung und Zweckbindung sind zentral.

• Feature-Kataloge: Unternehmen sollten klare Prozesse etablieren, welche Features in das Model-Ökosystem aufgenommen und dokumentiert werden.

Empfehlung: Vor Implementierung eines solchen Modells sollte ein Data-Governance-Assessment speziell auf tabellarische Foundation Models zugeschnitten durchgeführt werden.

5.2 MLOps: Von vielen Modellen zu einem zentralen Foundation Model

Der Wechsel hin zu einem zentralen LTM verändert MLOps-Strukturen:

• Modelllebenszyklus: Anstelle vieler einzelner Modelle (pro Use Case) wird ein zentrales Modell mit mehreren Heads / Tasks betrieben.

• Monitoring: Drift-, Bias- und Performance-Monitoring müssen auf Modell‑, Task‑ und Datenebene etabliert werden.

• Rollout & Rollback: Änderungen am Foundation Model können Auswirkungen auf viele Prozesse haben. Unternehmen brauchen klare Deployment- und Freigabeprozesse (z. B. Canary Releases, Staging-Umgebungen, Backups früherer Modellstände).

5.3 Architekturfragen: Wo „lebt“ das Modell?

Entscheidende Architekturthemen:

• Daten-Lokation: On-Premises, Private Cloud, Public Cloud – und wo wird NEXUS betrieben?

• Latenzanforderungen: Für Batch-Forecasting ist Cloud-Inferenz unkritisch, für Echtzeit-Scoring (Betrugsprüfung, Kreditentscheidungen) können Latenzen von unter 100 ms erforderlich sein.

• Integration in bestehende Tools: BI-Systeme, Data-Warehouses, Feature Stores, Workflow-Orchestratoren (z. B. Airflow, Dagster) sollten angebunden werden.

5.4 Fachliche Verantwortung und Explainability

Gerade wenn ein Modell quer über viele Fachbereiche wirkt, ist klar zu regeln:

• Wer ist fachlich verantwortlich für Entscheidungen, die auf Modelloutputs beruhen?

• Welche Erklärungsmöglichkeiten bietet Fundamental (z. B. globale und lokale Feature-Importance, Counterfactuals, Dokumentation von Trainingsdaten und Modellversionen)?

• Wie werden Modelle auditiert? – insbesondere bei regulierten Branchen oder internen Kontrollanforderungen.

6. Was Unternehmen jetzt konkret tun sollten

6.1 Kurzfristige Schritte (0–6 Monate)

1. Use-Case-Inventur

- Liste aller use cases, bei denen heute tabellarische Modelle eingesetzt werden (Scoring, Forecasting, Anomalieerkennung etc.).

- Bewertung nach Business-Impact, Datenverfügbarkeit und Regulierungsgrad.

1. Datenlandkarte aktualisieren

- Übersicht, welche Kernsysteme (ERP, CRM, Billing, Data Warehouse, Data Lake) die relevanten Tabellen bereitstellen.

- Prüfen, ob Datenqualität, Historie und Governance ausreichen, um sie einem zentralen Foundation Model zugänglich zu machen.

1. Pilotprojekte definieren

- 1–2 Pilotfälle mit hohem Wert, überschaubarem Risiko und gut verstandenen Daten auswählen – etwa Churn-Prediction oder Nachfrage-Forecasting.

1. Anbieterbewertung starten

- Fundamental als neuen Player gemeinsam mit bestehenden Alternativen (eigene Tabular-Model-Stacks, andere Foundation-Model-Anbieter) evaluieren.

6.2 Mittelfristige Schritte (6–24 Monate)

1. Architektur-Blueprint für Tabular Foundation Models

- Zielbild zeichnen: Wo läuft das Foundation Model? Wie werden Daten angebunden? Welche Systeme konsumieren die Outputs?

1. Governance- und MLOps-Richtlinien anpassen

- Policies für zentrale Foundation Models formulieren (Freigabeprozesse, Monitoring, Retraining-/Fine-Tuning-Strategien, Audit-Fähigkeit).

1. Kompetenzaufbau im Data- und Analytics-Team

- Schulungen zu tabularen Foundation Models, Feature Engineering in diesem neuen Paradigma, Interpretation der Modelloutputs.

1. Portfolio-Ansatz

- Evaluieren, welche bestehenden Einzellösungen (z. B. spezifische Fraud-Modelle) langfristig durch ein zentrales LTM ersetzt, ergänzt oder bewusst separat weiterbetrieben werden sollen.

7. Fazit: Tabellen rücken ins Zentrum der Foundation-Model-Strategie

Mit dem heutigen Launch von Fundamental und seinem Large Tabular Model NEXUS wird deutlich: Die Foundation-Model-Welle erreicht nun konsequent die strukturierten Kerndaten von Unternehmen. Während LLMs vor allem kommunikative und wissensorientierte Prozesse transformieren, könnten LTMs wie NEXUS die Art verändern, wie operative Entscheidungen auf Basis von ERP-, CRM- und Finanzdaten getroffen werden.

Ob Fundamental sich als führender Anbieter in diesem Segment etabliert, hängt von technologischer Substanz, Integrationsfähigkeit und Governance-Maturität ab. Für Unternehmen ist jedoch schon heute klar: Wer eine KI-Strategie für die nächsten Jahre formuliert, kommt an tabellarischen Foundation Models nicht mehr vorbei.

Wichtigste Takeaways für Entscheider

• Tabular Foundation Models werden zum neuen Standard für datengetriebene Entscheidungen auf ERP-, CRM- und Finanzdaten und ergänzen klassische LLM-Strategien.

• Fundamental positioniert sich mit NEXUS als spezialisierter Anbieter für Large Tabular Models und zielt direkt auf Enterprise-Szenarien wie Risk Scoring, Forecasting, Pricing und Betrugserkennung.

• Der Einsatz solcher Modelle erhöht die Anforderungen an Data Governance, insbesondere beim Zugriff auf sensible Tabellen und bei der Dokumentation von Features, Trainingsdaten und Entscheidungen.

• MLOps-Strukturen müssen angepasst werden, da ein zentrales Foundation Model mehrere bisher getrennte Modelle ersetzt und somit neue Monitoring- und Rollout-Prozesse erfordert.

• Unternehmen sollten jetzt Use Cases und Datenlandschaft systematisch erfassen, Pilotprojekte definieren und Architektur-Blueprints für den Betrieb tabellarischer Foundation Models entwickeln.

• Langfristig werden LTMs zu einem Kernbaustein moderner Datenplattformen, die nicht nur berichten, sondern prädiktiv und handlungsleitend auf Basis der vorhandenen Tabellenbestände agieren.

Häufig gestellte Fragen (FAQ)

Was ist NEXUS von Fundamental und worin unterscheidet es sich von klassischen KI-Modellen?

NEXUS ist ein großskalig vortrainiertes Foundation Model, das ausschließlich für strukturierte Tabellendaten wie ERP-, CRM-, Finanz- und Transaktionsdaten entwickelt wurde. Im Gegensatz zu textbasierten LLMs oder klassischen Machine-Learning-Modellen arbeitet es direkt auf Spalten, Zeilen, Zeitreihen und Relationen von Unternehmensdaten und ist auf Aufgaben wie Scoring, Forecasting und Anomalieerkennung spezialisiert.

Wie funktionieren Large Tabular Models (LTMs) wie NEXUS technisch?

Large Tabular Models nutzen spezialisierte Transformer-Architekturen, die Reihen (Samples) und Spalten (Features) getrennt und gemeinsam betrachten, um Abhängigkeiten in Tabellen zu lernen. Sie werden auf Milliarden Zeilen aus unterschiedlichen Unternehmensdomänen vortrainiert und anschließend über Fine-Tuning oder Aufgaben-spezifische Heads für konkrete Business-Cases wie Churn, Pricing oder Betrugserkennung angepasst.

Welche Vorteile bieten tabellarische Foundation Models gegenüber klassischen AutoML- oder Gradient-Boosting-Ansätzen?

Tabellarische Foundation Models starten von einem großen, vortrainierten Basismodell und können viele verschiedene Use Cases gleichzeitig bedienen, statt für jeden Anwendungsfall ein eigenes Modell von Grund auf zu trainieren. Das beschleunigt die Modellentwicklung, kann die Prognosequalität erhöhen und vereinfacht MLOps, führt aber auch zu einer stärkeren Abhängigkeit von einem zentralen Modell und erfordert robuste Governance.

Welche konkreten Anwendungsfälle können Unternehmen mit NEXUS abdecken?

Typische Anwendungsfälle sind Risiko- und Kredit-Scoring, Nachfrage- und Absatzprognosen in Supply Chains, dynamisches Pricing und Revenue Management sowie Betrugs- und Anomalieerkennung in Transaktionsdaten. Darüber hinaus können SaaS- und Subscription-Anbieter Churn-Risiken, Net Revenue Retention (NRR) und Upsell-Wahrscheinlichkeiten auf Basis tabellarischer Nutzungs- und Abrechnungsdaten modellieren.

Welche Auswirkungen hat der Einsatz von NEXUS auf Data Governance und Compliance?

Da NEXUS direkt auf sensiblen Kernsystemtabellen wie Kunden-, Finanz- oder Logdaten arbeitet, steigen die Anforderungen an Zugriffssteuerung, Datenschutz und Dokumentation. Unternehmen müssen klar regeln, welche Tabellen und Spalten für das Modell freigegeben werden, wie Pseudonymisierung und Zweckbindung umgesetzt werden und wie Feature-Kataloge, Trainingsdaten und Modellentscheidungen revisionssicher dokumentiert werden.

Was sollten Unternehmen jetzt konkret tun, um sich auf tabellarische Foundation Models vorzubereiten?

Kurzfristig sollten Unternehmen ihre bestehenden tabellarischen Use Cases inventarisieren, eine aktuelle Datenlandkarte über ERP-, CRM-, Billing- und Warehouse-Systeme erstellen und 1–2 Pilotprojekte mit hohem Business-Impact definieren. Mittelfristig geht es darum, Architektur-Blueprints für den Betrieb solcher Modelle zu entwickeln, Governance- und MLOps-Richtlinien anzupassen und Data- sowie Analytics-Teams gezielt im Umgang mit tabellarischen Foundation Models zu schulen.

Wie fügt sich ein Large Tabular Model in bestehende Daten- und Analytics-Architekturen ein?

NEXUS wird typischerweise als zentraler Scoring- und Forecasting-Baustein zwischen Data Warehouse/Data Lake und konsumierenden Systemen wie BI-Tools, operativen Applikationen oder Workflow-Orchestratoren integriert. Unternehmen müssen entscheiden, ob das Modell in der Cloud, in einer Private Cloud oder on-premises betrieben wird, Latenzanforderungen für Echtzeit-Use-Cases berücksichtigen und geeignete Schnittstellen sowie Monitoring-Mechanismen etablieren.