
Klarna ersetzte 700 Mitarbeiter durch KI. Dann stellte das Unternehmen sie alle wieder ein. Was jedes Unternehmen daraus lernen sollte.
Ich war gerade in einem Gespräch mit einem potenziellen Kunden aus dem Bankensektor, als die Klarna-Nachricht bekannt wurde. Mitte 2025. Mein Telefon vibrierte — ein Kollege hatte mir den Artikel weitergeleitet, mit einer einzigen Zeile: "Das ist buchstäblich das, was du die ganze Zeit sagst."
Der Kunde war mitten im Satz und erklärte, wie sie einen Kundenservice-Chatbot auf Basis von GPT-4 gebaut hätten und wie "großartig" der laufe. Ich fragte ihn, wie seine CSAT-Werte aussähen. Lange Pause. "Das erfassen wir noch nicht."
Diese Pause sagte mir alles. Denn Klarna hatte es erfasst. Und was sie dabei herausfanden, war verheerend genug, um eine der medienwirksamsten KI-Einführungen in der Geschichte der Fintech-Branche rückgängig zu machen.
Hier die Kurzfassung: Klarna, der 14,6 Milliarden US-Dollar schwere schwedische Buy-now-pay-later-Riese, ersetzte rund 700 Kundenservice-Mitarbeiter durch einen KI-Assistenten auf Basis von OpenAI. Man verkündete es wie eine Ehrenrunde — die KI wickelte 75 % aller Kundenchats in 35 Sprachen ab. Die Kosten pro Transaktion sanken um 40 %. Die Wall Street war begeistert. Dann fielen die Kundenzufriedenheitswerte um 22 %. Das Unternehmen wies im ersten Quartal 2025 einen Nettoverlust von 99 Millionen US-Dollar aus. Und CEO Sebastian Siemiatkowski räumte öffentlich ein, dass das Streben nach Effizienz die Servicequalität ausgehöhlt hatte und Ergebnisse hervorbrachte, die er als "generisch" bezeichnete und die mit allem überfordert waren, was echtes Urteilsvermögen erforderte.
Sie begannen, wieder einzustellen. Sie versetzten sogar Softwareentwickler und Marketingleute an die Telefone.
Ich baue nun seit Jahren neuro-symbolische KI-Systeme bei Veriprajna, und ich habe zugesehen, wie ein Unternehmen nach dem anderen in dieselbe Falle getappt ist. Nicht weil die Technologie schlecht wäre — große Sprachmodelle sind wirklich bemerkenswert. Sondern weil es eine grundlegende Verwechslung gibt zwischen richtig klingen und richtig sein, und in regulierten Branchen wird Sie diese Verwechslung am Ende alles kosten.
Die Nacht, in der mir klar wurde, dass "gut genug" nicht genügt
Bevor ich zur Architektur komme, möchte ich Ihnen von einem Moment erzählen, der verändert hat, wie ich über dieses Problem denke.
Wir führten ein Pilotprojekt für ein System zur Einhaltung rechtlicher Vorgaben durch — kein Kundenservice, sondern Dokumentenanalyse. Die Art von Arbeit, bei der man aufsichtsrechtliche Einreichungen auswertet und interne Richtlinien mit externen Vorgaben abgleicht. Wir hatten einen Prototyp mit einem Standard-Setup für Retrieval-Augmented Generation. Vektorsuche, Top-k-Retrieval, GPT erzeugte die Zusammenfassung. Es war schnell. Die Ausgaben lasen sich wunderbar.
Eine unserer Ingenieurinnen — Priya — blieb länger und ließ Grenzfälle durchlaufen. Gegen 23 Uhr meldete sie sich in unserem Slack-Kanal mit einem Screenshot. Das System hatte einen perfekt flüssigen Absatz erzeugt, der eine bestimmte aufsichtsrechtliche Klausel zitierte. Die Klausel existierte nicht. Kein Falschzitat, keine Umschreibung — eine vollständige Erfindung. Und sie las sich so überzeugend, dass man sie ohne Expertenwissen zu genau dieser Vorschrift niemals bemerkt hätte.
Ich erinnere mich, wie ich an meinem Schreibtisch saß, auf diesen Screenshot starrte und dachte: Das ist das Produkt, das wir gerade ausliefern wollen. Ein System, das mit der Selbstsicherheit eines Seniorpartners in einer Anwaltskanzlei lügt.
Wir stoppten das Pilotprojekt. Bauten die Architektur von Grund auf neu. Verloren drei Monate. Es war die beste Entscheidung, die wir je getroffen haben.
Wenn ein KI-System mit vollkommener Selbstsicherheit eine juristische Fundstelle erfindet, ist das Problem kein Bug — es ist die Architektur. Aus einem grundlegend probabilistischen Fundament kann man sich nicht per Prompt Engineering herausmanövrieren.
Was ist die "Wrapper-Falle" und warum tappen kluge Unternehmen immer wieder hinein?
Lassen Sie mich in technischen Begriffen erklären, was bei Klarna tatsächlich passiert ist, denn die Wirtschaftspresse hat es weitgehend falsch dargestellt. Sie hat es als "Die KI ist noch nicht so weit" gerahmt. Das ist nicht das Problem. Das Problem ist, welche Art von KI und wie sie eingesetzt wurde.
Ein "Wrapper" ist eine dünne Softwareschicht, die auf einem großen Sprachmodell eines Drittanbieters aufsitzt. Sie kümmert sich um die Formatierung, verwaltet API-Aufrufe, ergänzt vielleicht etwas strukturiertes Parsen der Ausgabe. Aber das eigentliche Denken — das Schlussfolgern, das Urteilen, das Entscheiden — wird vollständig an das LLM ausgelagert. Ihr Wrapper schickt einen Prompt, das Modell sagt die wahrscheinlichsten nächsten Token voraus, und zurück kommt etwas, das wie eine Antwort klingt.
Für eine Demo funktioniert das wunderbar. Für Aufgaben mit geringem Risiko funktioniert es passabel. Und es scheitert katastrophal bei allem, was eines erfordert: Gewissheit.
Die Transformer-Architektur, die diese Modelle antreibt, nutzt einen Self-Attention-Mechanismus, um die Relevanz von Token in einer Sequenz zu gewichten und vorherzusagen, was als Nächstes kommt. Das ist Mustererkennung — außerordentlich ausgefeilte Mustererkennung, aber eben doch Mustererkennung. Es gibt keinen internen Mechanismus, um Fakten gegen eine externe Quelle der Wahrheit zu prüfen. Das Modell weiß nichts. Es sagt voraus, wie eine sachkundige Antwort aussehen würde.
Klarnas KI konnte Passwörter fehlerfrei zurücksetzen. Aber wenn ein Kunde einen komplexen Streitfall hatte, bei dem es um eine Teilrückerstattung, eine Meinungsverschiedenheit mit einem Händler und Verbraucherschutzvorschriften in zwei Rechtsräumen ging? Dann fiel das Modell in etwas zurück, das ich Slop-Spinning nenne — es erzeugte plausibel klingende Antworten, die sich im Kreis drehten, nie etwas lösten und Kunden in das trieben, was ein Analyst als "kafkaeske Schleife" beschrieb.
Und hier ist der Teil, der jede Führungskraft in Unternehmen erschrecken sollte: Die Kostenkennzahlen sahen großartig aus — und zwar die ganze Zeit, während sich das Kundenerlebnis verschlechterte. Die Kosten pro Transaktion fielen von 0,32 auf 0,19 US-Dollar. Die Lösungszeit pro Chat sank von 11 Minuten auf unter 2. Wer nur auf das Dashboard schaute, hätte gedacht, er gewinne — bis zu dem Moment, in dem die Kunden anfingen zu gehen.
Warum kann man einem LLM nicht einfach bessere Guardrails hinzufügen?
Das ist die Frage, die ich am häufigsten höre, und sie offenbart das zentrale Missverständnis. Die Leute glauben, die Lösung seien bessere Prompts, mehr Few-Shot-Beispiele, strengere Systemanweisungen. "Sagen Sie dem Modell einfach, es soll nicht halluzinieren."
Das ist, als würde man einem Wettervorhersagemodell sagen, es solle sich nicht irren. Die probabilistische Natur ist kein Fehler, den man flicken könnte — sie ist der grundlegende Mechanismus, nach dem das System funktioniert.
Ein Investor sagte mir einmal ganz unverblümt: "Nutzen Sie doch einfach GPT und legen Sie ein paar Regeln darüber." Ich fragte ihn, ob er einem Taschenrechner vertrauen würde, der in 95 % der Fälle richtig liegt. Er lachte. Ich sagte: "Genau das schlagen Sie für die Compliance im Bankwesen vor." Er hörte auf zu lachen.
Die technischen Fehlermodi reichen tiefer als Halluzinationen. Wrappern fehlt, was ich State-Schema-Persistenz nennen würde. Im Verlauf eines Gesprächs füllt sich das Kontextfenster. Informationen vom Anfang des Gesprächs werden komprimiert oder fallen weg. Das Modell kann sich innerhalb einer einzigen Sitzung selbst widersprechen, ohne zu merken, dass es das tut. Im Kundenservice heißt das: Der Agent verifiziert Ihre Identität vielleicht in Runde 3 und bittet Sie dann in Runde 15 erneut um eine Verifizierung — oder schlimmer noch, er überspringt die Verifizierung ganz, weil der Gesprächsverlauf ihn "überzeugt" hat, dass sie bereits stattgefunden habe.
Das ist die Schwachstelle, die ich die Infinite Freedom Fallacy nenne. Weil das LLM keine harten strukturellen Beschränkungen dafür hat, was es sagen oder tun kann, kann ein hinreichend cleverer Nutzer — oder eine hinreichend komplexe Situation — es in Zustände treiben, die Geschäftsregeln, regulatorische Anforderungen oder schlichte Logik verletzen. Mit Prompting lässt sich das nicht lösen. Man braucht eine grundlegend andere Architektur.
Ausführlich über dieses Problem habe ich in der interaktiven Version unserer Forschungsarbeit geschrieben, aber die Kernerkenntnis ist einfach: Man muss die Stimme vom Gehirn trennen.
Die 20 %, an denen alles scheitert

Es gibt ein Muster, das ich in jeder Branche gesehen habe, in der wir arbeiten, und ich glaube, es erklärt, warum so viele KI-Einführungen dem Klarna-Verlauf folgen.
KI kann 2025 rund 80 % der routinemäßigen, häufig auftretenden Interaktionen kompetent bewältigen. Passwort-Resets, Bestellstatusabfragen, einfache FAQ-Antworten — das sind gelöste Probleme. Die verbleibenden 20 % der Interaktionen sind die, auf die es wirklich ankommt. Es sind die komplexen Streitfälle, die Grenzfälle, die Momente, in denen ein Kunde frustriert, verwirrt oder verängstigt ist. Und sie sind die wichtigsten Treiber von Markenreputation und finanzieller Haftung.
Klarna hat für die 80 % optimiert und die 20 % ignoriert. Die Rechnung schien offensichtlich: Automatisiere das Einfache, spare Millionen. Aber in den 20 % wird Vertrauen aufgebaut oder zerstört. Ein Kunde, dessen Passwort-Reset reibungslos läuft, erzählt es niemandem. Ein Kunde, der 45 Minuten in einer KI-Schleife feststeckt und versucht, einen Abrechnungsfehler zu klären, erzählt es allen.
Die 80 % der Interaktionen, die KI gut bewältigt, sind für Ihre Marke unsichtbar. Die 20 %, die sie schlecht bewältigt, sind die einzigen, an die sich irgendjemand erinnert.
Die Ironie ist, dass Klarnas anfängliche Einsparung von 10 Millionen US-Dollar durch den Personalabbau mit ziemlicher Sicherheit von dem Customer Lifetime Value in den Schatten gestellt wurde, den sie durch verschlechterte Erlebnisse zerstört haben. Wenn man ein 14,6 Milliarden US-Dollar schweres Unternehmen ist, das sich auf einen Börsengang vorbereitet, ist ein Rückgang der Kundenzufriedenheit um 22 % kein Kennzahlenproblem — es ist ein existenzielles.
Was bedeutet "deterministische KI" eigentlich?

Wenn also Wrapper das Problem sind, was ist dann die Lösung? Hier muss ich etwas technischer werden, aber ich verspreche, es greifbar zu halten.
Bei Veriprajna bauen wir das, was man neuro-symbolische KI nennt. Der Name klingt akademisch, aber das Konzept ist eingängig: Man nimmt die sprachliche Gewandtheit eines neuronalen Netzes und zwingt sie in die starre Logik einer symbolischen Inferenzmaschine. Das neuronale Netz übernimmt die "weiche" Arbeit — natürliche Sprache verstehen, für Menschen lesbare Antworten erzeugen, mehrdeutige Anfragen interpretieren. Die symbolische Engine übernimmt die "harte" Arbeit — Regeln durchsetzen, Logik validieren, sicherstellen, dass jede Ausgabe auf eine verifizierte Quelle zurückführbar ist.
Wir nennen das das Neuro-Symbolic Sandwich. Bevor eine Anfrage das LLM erreicht, prüft eine Intent-Validierungsschicht sie gegen Richtlinienvorgaben und untersucht sie auf adversariale Eingaben. Nachdem das LLM eine Antwort erzeugt hat, prüft eine Validierungs-Engine — typischerweise ein endlicher Automat oder ein Logik-Solver — jede Behauptung gegen den Knowledge Graph und jede Aktion gegen die Geschäftsregeln. Verletzt die Antwort irgendeine Vorgabe, kommt sie nicht durch. Punkt.
Es gibt eine Technik, die wir einsetzen und die Constrained Decoding heißt — auch bekannt als Token Masking — und die ich besonders elegant finde. Statt das Modell frei generieren zu lassen und die Ausgabe anschließend zu prüfen, verhindern wir physisch, dass bestimmte Token überhaupt erzeugt werden. Erstellt das Modell einen Steuer-Compliance-Bericht, stellt die symbolische Schicht sicher, dass jede Zahl einer verifizierten Berechnung entspricht. Das Modell ist buchstäblich außerstande, eine Zahl zu halluzinieren, weil die halluzinierten Token vor der Generierung aus der Wahrscheinlichkeitsverteilung ausmaskiert werden.
Das ist kein "Hinzufügen von Guardrails". Das ist eine grundlegend andere Architektur, in der das LLM die Stimme ist und die symbolische Engine das Gehirn — und die Stimme darf niemals ohne die Zustimmung des Gehirns sprechen.
Als der Knowledge Graph uns vor einem 2-Millionen-Dollar-Fehler bewahrte

Standard-RAG — Retrieval-Augmented Generation — hat ein Problem, über das die wenigsten sprechen. Es stützt sich auf Vektorähnlichkeit, um relevante Dokumente zu finden. Aber Vektorähnlichkeit versteht keine Richtung. "Unternehmen A verklagte Unternehmen B" und "Unternehmen B verklagte Unternehmen A" haben womöglich nahezu identische Vektor-Embeddings, beschreiben aber völlig entgegengesetzte Rechtslagen.
Wir haben das auf die harte Tour in einem juristischen Pilotprojekt gelernt. Unser System analysierte die Prozesshistorie eines Unternehmenskunden, und das Standard-RAG-Setup verwechselte immer wieder die Rollen von Kläger und Beklagtem. Die Ausgaben waren flüssig, gut strukturiert und gefährlich falsch.
Da sind wir zu dem übergegangen, was wir Citation-Enforced GraphRAG nennen. Statt Dokumente in einen Vektorspeicher zu kippen, parsen wir sie in einen Knowledge Graph — Entitäten, die durch typisierte, gerichtete Beziehungen verbunden sind. Wenn das System eine Behauptung aufstellt, muss es diese Behauptung auf konkrete Knoten und Kanten im Graphen zurückführen. Kann der Graph die Behauptung nicht stützen, stellt das System sie nicht auf.
Der Genauigkeitsgewinn war dramatisch — 30-35 % höher als Standard-RAG bei komplexen Multi-Hop-Reasoning-Aufgaben. Wichtiger noch: Es gab uns etwas, das kein noch so ausgefeiltes Prompt Engineering leisten könnte: einen Audit-Trail. Jede Ausgabe lässt sich über den exakten Argumentationspfad zurückverfolgen, von Entität zu Entität, von Beziehung zu Beziehung. Ein Compliance-Verantwortlicher kann sehen, warum das System zu einem Schluss gekommen ist, nicht nur, was es geschlossen hat.
Die vollständige technische Aufschlüsselung, wie diese Architektur in verschiedenen Domänen funktioniert — Bankwesen, Recht, Fertigung —, finden Sie in unserer technischen Tiefenanalyse.
Der Streit, der mein Team fast gespalten hätte
Ich möchte bei etwas ehrlich sein. So zu bauen ist schwerer. Deutlich schwerer. Und es gab einen Punkt, vielleicht vor achtzehn Monaten, an dem mein Team ernsthaft darüber stritt, ob wir es mit dem Engineering übertrieben.
Wir saßen in einem Konferenzraum — die Whiteboards voller Architekturdiagramme — und einer unserer Senior-Ingenieure argumentierte, wir sollten für einen Fertigungskunden ein Wrapper-basiertes MVP ausliefern. "Umsatz reinholen, das Konzept beweisen, die Architektur später härten." Das war ein vernünftiges Argument. Der Kunde war ungeduldig. Der Zeitplan war eng. Und jeder Wettbewerber in unserem Umfeld lieferte Wrapper-Produkte aus und gewann Aufträge.
Ich erinnere mich an die Stille, nachdem er geendet hatte. Dann rief Priya — dieselbe Ingenieurin, die die Phantom-Fundstelle entdeckt hatte — eine Folie auf, die sie schon eine Weile zurückgehalten hatte. Sie zeigte drei reale Fälle aus dem Vorquartal, in denen Wrapper-basierte KI-Systeme Ausgaben erzeugt hatten, die, hätte man danach gehandelt, regulatorische Anforderungen verletzt hätten. Keine hypothetischen Verstöße. Echte — und nur deshalb entdeckt, weil zufällig Menschen im Loop waren.
Ich entschied, Kurs zu halten. Wir verloren diesen Auftrag an einen Wettbewerber, der schneller lieferte. Sechs Monate später produzierte das System dieses Wettbewerbers einen Compliance-Verstoß, der dessen Kunden eine siebenstellige Nachbesserung kostete. Der Kunde kam zu uns.
Geschwindigkeit ohne Korrektheit ist kein Wettbewerbsvorteil. Sie ist eine Haftung mit Zeitzünder.
Ich erzähle diese Geschichte nicht, um vorausschauend zu wirken. Ich erzähle sie, weil der Druck, schnell zu liefern und später zu iterieren, enorm ist — und in den meisten Softwarekontexten ist das der richtige Instinkt. Aber in regulierten Branchen — Bankwesen, Gesundheitswesen, Recht, Fertigung — heißt "später iterieren" nichts anderes als "nach dem Verstoß reparieren". Und Verstöße in diesen Domänen kommen ohne Schonfrist.
Warum 2026 das Jahr ist, in dem die Rechnung fällig wird
Hier das große Bild. McKinsey hat festgestellt: Während 88 % der Organisationen KI einsetzen, können nur 39 % auf einen positiven Ergebniseffekt auf Unternehmensebene verweisen. Diese Lücke wird bald unhaltbar.
Die "Investieren-und-Lernen"-Phase der KI-Einführung ist vorbei. CFOs fragen nicht mehr: "Setzen wir KI ein?" Sie fragen: "Wie ist der EBIT-Effekt?" Und für die meisten Organisationen lautet die ehrliche Antwort: "Wir haben bei administrativen Aufgaben etwas Zeit gespart."
Das reicht nicht. Zeit bei E-Mails und Foliensätzen zu sparen, ist "Produktivitäts-KI" — nützlich, aber inkrementell. Was Unternehmen wirklich brauchen, ist "operative KI" — Systeme, die in der physischen Wirtschaft Reibungsverluste beseitigen, die real Geld kosten. Fehlbestände verhindern. Compliance-Verstöße abfangen, bevor sie passieren. Die jährlichen Kosten von 890 Milliarden US-Dollar für Retouren im Einzelhandel senken, indem man eine akkurate virtuelle Anprobe bietet statt KI-generierter Fantasiebilder, die großartig aussehen, aber nicht abbilden, wie Stoff tatsächlich an einem menschlichen Körper fällt.
Die Klarna-Geschichte ist hier lehrreich, weil ihre Kennzahlen aussahen wie ein ROI. Kosten pro Transaktion 40 % runter! Aber sie haben das Falsche gemessen. Sie maßen gesparte Zeit und abgebauten Personalbestand. Sie maßen nicht das erodierte Vertrauen und die verlorenen Kunden. Rechnet man die Wiedereinstellungskosten, den Markenschaden und den Verlust von 99 Millionen US-Dollar im ersten Quartal ein, verpufft die "Ersparnis".
Die Unternehmen, die 2026 gewinnen werden, sind die, die verhinderte operative Verluste messen, nicht gesparte Stunden. Die, die KI einsetzen, die über Nacht 10.000 Störungsszenarien in der Lieferkette simulieren und Krisenbewältigungspläne erstellen kann, die kein menschliches Team in einem Jahrzehnt hervorbringen könnte. Die, deren KI-Systeme ihre Argumentation gegenüber einer Aufsichtsbehörde beweisen können, statt nur einen überzeugenden Absatz zu produzieren.
Und was ist mit den Menschen?
Gegen diese Sichtweise kommt immer Widerspruch. "Wenn KI so gut wird, was passiert dann mit den Menschen?"
Ich glaube, die Antwort ist das Gegenteil dessen, was die meisten erwarten. Organisationen, die tiefe, architektonisch solide KI einsetzen, brauchen nicht weniger Menschen — sie brauchen andere Menschen. Die klassische Beratungspyramide mit ihrer breiten Basis aus Junior-Analysten, die Daten zusammenfassen und Präsentationen erstellen, bricht zusammen. KI erledigt diese Arbeit schneller und besser. Aber der Bedarf an erfahrenem Urteilsvermögen, strategischem Denken, ethischer Aufsicht und echter menschlicher Empathie überlebt nicht nur — er verstärkt sich.
Was entsteht, nennt die Branche das "Obelisk"-Modell: schlankere, expertenlastigere Teams, in denen Berufseinsteiger "KI-Facilitators" sind, die KI-Workflows entwerfen und steuern, Fachkräfte mit mittlerer Erfahrung "Engagement-Architekten" sind, die definieren, welche Probleme es wert sind, gelöst zu werden, und Führungskräfte sich auf die zutiefst menschliche Arbeit konzentrieren, Vertrauen aufzubauen und Mehrdeutigkeit zu navigieren.
McKinseys interner KI-Assistent "Lilli" wird von 72 % der Belegschaft genutzt und hat die Recherchezeit um 30 % verkürzt. BCGs "Deckster" automatisiert die Erstellung von Präsentationen. Aber keine der beiden Firmen schrumpft. Sie strukturieren um — sie ersetzen Menge durch Präzision, abgerechnete Stunden durch gelieferte Ergebnisse.
Der Fehler von Klarna war nicht, KI einzusetzen. Der Fehler war, KI als Ersatz für Menschen einzusetzen statt als Verstärker menschlicher Fähigkeiten. Diese Unterscheidung klingt fein. Ist sie nicht. Sie ist der Unterschied zwischen einer Ersparnis von 10 Millionen US-Dollar und einem Verlust von 99 Millionen US-Dollar.
Die Architektur des Vertrauens
Ich möchte mit etwas schließen, das mir seit jener späten Nacht nicht aus dem Kopf geht, in der Priya die Phantom-Fundstelle fand.
Wir erleben einen Moment, in dem KI-Systeme Ausgaben produzieren können, die von der Arbeit menschlicher Experten nicht zu unterscheiden sind — und die dennoch vollkommen und selbstsicher falsch sind. Das ist keine vorübergehende Beschränkung, die GPT-6 oder GPT-7 lösen werden. Es ist eine inhärente Eigenschaft der Funktionsweise probabilistischer Sprachmodelle. Sie optimieren auf Plausibilität, nicht auf Wahrheit. Und in Domänen, in denen Wahrheit zählt — wo eine falsche Antwort einen Compliance-Verstoß, eine Fehldiagnose oder einen erfundenen juristischen Präzedenzfall bedeutet —, ist Plausibilität das Gefährlichste überhaupt.
Die Lösung ist nicht, KI aufzugeben. Die Lösung ist, KI-Systeme zu bauen, in denen Wahrheit architektonisch erzwungen und nicht probabilistisch erhofft wird. In denen jede Behauptung auf eine verifizierte Quelle zurückführt. In denen das System buchstäblich keine Ausgabe erzeugen kann, die die Regeln seiner Domäne verletzt. In denen der Audit-Trail kein Feature ist — sondern das Fundament.
Das ist es, was wir bei Veriprajna bauen. Nicht weil deterministische KI einfacher wäre — sie ist erheblich schwerer. Nicht weil sie sich besser demonstrieren ließe — Wrapper machen wunderbare Demos. Sondern weil in Branchen, die sich Raten nicht leisten können, die einzige tragfähige Architektur die ist, die Raten unmöglich macht.
Klarna hat diese Lektion zum Preis von 700 Arbeitsplätzen, eines CSAT-Rückgangs um 22 % und eines Quartalsverlusts von 99 Millionen US-Dollar gelernt. Die Frage an jede Führungskraft in Unternehmen, die das hier liest, ist einfach: Wollen Sie sie aus deren Geschichte lernen — oder aus Ihrer eigenen?
Bei der Zukunft der Unternehmens-KI geht es nicht darum, Sprachmodelle klüger zu machen. Es geht darum, sie rechenschaftspflichtig zu machen — architektonisch, beweisbar, unveränderlich rechenschaftspflichtig.
Die Wrapper-Ära ist vorbei. Was als Nächstes kommt, wird schwerer zu bauen und langsamer auszuliefern sein — und jeden zusätzlichen Monat Engineering wert. Denn am Ende ist das einzige KI-System, dessen Einsatz sich lohnt, eines, auf das Sie Ihr Unternehmen wetten würden. Und Sie sollten Ihr Unternehmen niemals auf ein System wetten, das seinen Rechenweg nicht zeigen kann.