# Klarna kündigt Salesforce und Workday für interne KI-Systeme

# Klarna kündigt Salesforce und Workday für interne KI-Systeme Klarna hat seine Enterprise-Verträge mit Salesforce und Workday gekündigt. Das war kein simpler Vertragsstreit und kein Anbieterwechsel. Das Unternehmen hat seine Abhängigkeit von klassischer kommerzieller Software systematisch abgebaut. Betriebsabläufe laufen stattdessen auf proprietären, internen Modellen. CEO Sebastian Siemiatkowski bestätigte den Schritt nach internen Tool-Audits. Klarna strich über 1.200 eigenständige Drittanbieter-SaaS-Apps und Workflow-Integrationen. Das Ziel war simpel: wiederkehrende Seat-Lizenzen streichen und alle internen Workflows in eine konsolidierte Datenumgebung zwingen. ### Die Architektur: Neo4j und Ontologien Viele dachten, Klarna hätte einfach ein paar Prompts an interne Dashboards gehängt. Das ist falsch. Ein CRM oder HRIS selbst zu ersetzen, braucht weit mehr als einfache API-Aufrufe an Foundation Models. Klarna setzte Neo4j-Graphdatenbanken ein, um eine zentrale semantische Ontologie über das gesamte Unternehmen aufzubauen. > Unstrukturierte Datensätze ohne strikte Ontologie führen dazu, dass Large Language Models (LLMs) bei kritischen Kunden- und Mitarbeiterbeziehungen halluzinieren. So funktioniert die Pipeline im Detail: * **Ingestion und Normalisierung:** Rohe Kundeninteraktionen, Transaktionsprotokolle und interne Tickets fließen direkt in Neo4j-Graph-Cluster. * **Ontologisches Mapping:** Der Graph weist feste Entity-Beziehungen zwischen Kunden, Händlern, Streitfällen und Compliance-Status zu. * **LLM-Orchestrierung:** Foundation Models von OpenAI fragen diesen vorstrukturierten Graphen ab, um Workflows auszuführen, Case-Updates zu verfassen und Aufgaben zu verteilen. Ohne diesen Zwischenschritt über den Graphen können LLMs keinen deterministischen Kontext über Millionen von Buy-Now-Pay-Later-Konten (BNPL) halten. Neo4j dient als Leitplanke, die den Ersatz klassischer Enterprise-Datenbanken technisch überhaupt erst machbar macht. ### Die direkten Folgen für das Unternehmen Das direkte Ergebnis ist eine vollständige Entkopplung von der typischen Pro-Nutzer-SaaS-Ökonomie. Klarna zahlt keine Standard-Software-Rechnungen mehr für tausende interne Nutzer. Stattdessen fließen diese Budgets direkt in Compute-Instanzen, Model-Tokens und die interne Plattform-Wartung. Die Konsolidierung von 1.200 Tools in ein einziges internes Framework beseitigt Datensilos. Sie konzentriert das operative Risiko aber auch komplett auf das interne Infrastruktur-Team. --- ## Börsensignale versus Realität im Produktivbetrieb Die Finanzmärkte bewerten Narrative genauso wie den Cashflow. Bei radikalen Umbauten des Tech-Stacks liefert der finanzielle Kontext die wahren Hintergründe. ### Das Spiel mit dem Bewertungsmultiplikator Die Wall Street bewertet Kreditgeschäfte und Software-Plattformen völlig unterschiedlich. Klassische BNPL-Anbieter werden oft mit niedrigen Umsatz-Multiples bewertet, wie sie für Konsumentenkredite üblich sind. Reine KI-Infrastruktur-Unternehmen erzielen deutlich höhere Multiplikatoren. > Vermarkte dich als Zahlungsabwickler, und man bewertet dich nach Kreditausfällen. Vermarkte dich als KI-native Plattform, und dein Börsengang (IPO) erzielt Tech-Multiples. Fallen die Posten für Enterprise-Software weg, sinken die Vertriebs- und Verwaltungskosten (SG&A) sofort. Auf den Folien für die Pre-IPO-Roadshow sieht dieser operative Hebel sauber aus. Er signalisiert maximale Effizienz. In der Praxis tauscht man planbare SaaS-Abonnements gegen interne Engineering-Kosten ein. Und die tauchen in den ersten Margenberechnungen selten auf. ### Die Umbuchung von operativen Kernkosten Ein Enterprise-CRM oder eine HR-Suite bringt beträchtlichen operativen Wartungsaufwand mit sich. Wenn ein Unternehmen behauptet, Millionen an Lizenzgebühren eingespart zu haben, fehlen in der Rechnung meist die Entwicklerkapazitäten für die Eigenentwicklungen. * Software-Lizenzkosten wandern von den operativen Betriebskosten direkt in die Budgets für F&E und Plattform-Wartung. * Spezialisierte ML-Engineers pflegen am Ende Standard-UIs, Webhook-Handler und Token-Quoten. * Produkt-Roadmaps geraten ins Stocken, weil Kernteams Sprint-Kapazitäten dafür aufwenden, Standardfunktionen für interne Admin-Tools nachzubauen. Diese Systeme ins eigene Haus zu holen, verbessert die Margen für Investoren rein optisch. Die realen Kosten stehen am Ende einfach an anderer Stelle in der Bilanz. --- ## Operative Belastung und technische Schulden Standardlizenzen zu streichen, sieht in der Quartalsbilanz stark aus. Kostenpunkte verschwinden. Die Betriebsausgaben sinken. Danach kommt die echte operative Rechnung. Wer ausgereifte Plattformen entfernt, streicht nicht die zugrundeliegenden Geschäftsanforderungen. Man überträgt sie lediglich auf die eigenen Entwicklerteams. ### Die versteckten Kosten eigener Codebasen Jedes Enterprise-Tool bietet zwei Dinge: eine Benutzeroberfläche und einen unsichtbaren Wartungsapparat im Hintergrund. Ersetzt man ein etabliertes CRM durch einen internen LLM-Layer, übernimmt man die dauerhafte Wartung. Routine-Updates von APIs, Datenbank-Indizierung und Berechtigungsmodelle binden plötzlich eigene Software-Entwickler. > Die Gesamtkostenrechnung (TCO) spricht selten für Eigenentwicklungen, sobald man die laufende Wartung einpreist. Ein Blick auf die reine Stückkostenrechnung: * **Lizenz versus Infrastruktur:** Das Streichen von Pro-Nutzer-Lizenzen tauscht fixe Monatskosten gegen variable Ausgaben für Compute, Vektorspeicher und dauerhaften Token-Verbrauch. * **Opportunitätskosten:** Senior Engineers patchen Datenpipelines, anstatt umsatzrelevante Features für Kunden zu bauen. * **Modell-Drift:** Modelle halluzinieren und Schema-Zuordnungen brechen ab, sobald sich nachgelagerte Datenstrukturen ändern. Das erfordert ständige Eingriffe. Maßgeschneiderte Ontologien brauchen permanente menschliche Pflege. Technische Schulden wachsen in diesen internen Systemen unbemerkt an, bis Workflows quer durch alle Abteilungen ausfallen. ### Compliance-Risiken in regulierten Märkten Neben der technischen Wartung gibt es rechtliche Risiken. Standardplattformen für HR und Finanzen beschäftigen Heere von Regulierungsexperten. Ändern sich Steuergesetze, Arbeitsrecht oder Standards für Finanzberichte, liefern diese Anbieter sofort Compliance-Updates aus. Bei Eigenbauten liegt diese Verantwortung komplett beim internen Team. * Gesetzliche Steuererklärungen in dutzenden Ländern verlangen starre, fehlerfreie Regelsysteme statt Wahrscheinlichkeiten. * Granulare Zugriffskontrollen und unveränderliche Audit-Logs müssen strengen Prüfungen nach SOX und Finanzaufsichtsrecht standhalten. * Komplexe Gehaltsabrechnungen mit mehreren Währungen und Tarifvorgaben verzeihen keine Parsing-Fehler. Wenn undokumentierte Pipelines während einer behördlichen Prüfung scheitern, kann niemand warten, bis Produktteams Graph-Knoten debuggen. Man holt externe Systemintegratoren zu teuren Notfallstundensätzen. Die anfänglichen Einsparungen gehen direkt für Fehlerbehebungen drauf. --- ## Leitfaden für Enterprise-SaaS-Audits Zentrale Enterprise-Tools ohne klares System herauszureißen, führt direkt ins Chaos. Für mehr Effizienz braucht es keinen kompletten Kahlschlag. Man benötigt ein strukturiertes Audit, das aufgeblähte Lizenzen von unersetzlichen Basissystemen trennt. So lässt sich die Software-Architektur prüfen, ohne Compliance zu gefährden oder im Wartungsaufwand zu versinken. ### Schritt 1: Das Drei-Stufen-Audit Teilen Sie alle Software-Abos mit vielen Lizenzen in drei Kategorien ein: * **Stufe 1: Einzellösungen & CRUD-Wrapper.** Formular-Builder, interne Projektportale und Notiz-Tools, die hohe Lizenzgebühren für einfache Datenbankspeicherung verlangen. Das sind die ersten Kandidaten für Konsolidierungen. * **Stufe 2: Workflow-Beschleuniger & Analysetools.** Branchenspezifische Datenanreicherung, Ticket-Routing und Texterstellung, bei denen externe APIs echten Nutzen bringen, ohne die primäre Datenquelle zu sein. * **Stufe 3: Gesetzliche Systems of Record & Finanzbücher.** Plattformen für Lohnabrechnung, unveränderliche Audit-Logs und behördliche Hauptbücher. Speichert ein Tool nur Zeilen und sendet Benachrichtigungen, kündigen Sie überflüssige Lizenzen. Trägt es regulatorische Risiken, fassen Sie es zuletzt an. ### Schritt 2: Fragmentierte Datenspeicher zusammenführen Verbinden Sie OpenAI-Endpunkte oder eigene Agenten niemals direkt mit fragmentierten relationalen Tabellen. Das führt zu Halluzinationen und lückenhaften Kontextfenstern in der Geschäftslogik. Bündeln Sie Ihre Metadaten, indem Sie zuerst Knowledge Graphs über Ihre bestehenden Datenbestände legen. > Saubere Ontologien müssen vor der Automatisierung stehen. Ein LLM kann in Schema-Chaos keine Logik finden. Bilden Sie Beziehungen zwischen Kunden, Verträgen und internen Prozessen in einem klaren Graph-Schema ab. Diese Struktur gibt Modellen feste Leitplanken für verlässliche Ergebnisse. ### Schritt 3: Wettbewerbsvorteile ausbauen statt Monolithen nachbauen Behalten Sie etablierte System-of-Record-Plattformen für die gesetzliche Compliance. Nutzen Sie diese rein als Backend-Engines. Bauen Sie kein eigenes CRM von Grund auf neu. Setzen Sie stattdessen schlanke Modelle auf Ihre bestehenden CRM-Datenfeeds, um Lead-Anreicherung, Routing und Ticket-Prüfung zu automatisieren. * Nutzen Sie den Anbieter für Compliance, Audit-Logs und Sicherheitskontrollen. * Entwickeln Sie interne Agenten nur dort, wo spezifische Workflows einen echten Wettbewerbsvorteil bringen. Bis 2027 werden nicht die Unternehmen die KI-Transformation anführen, die jede Zeile Infrastruktur selbst schreiben. Es werden die sein, die Foundation Models als Orchestratoren nutzen, anstatt regulierte Kernsysteme komplett neu zu erfinden.