Warum 'Nimm doch einfach einen Code-Interpreter' KI nicht finance-safe macht

Jedes Mal, wenn jemand darauf hinweist, dass große Sprachmodelle schlecht rechnen, kommt von einem selbstbewussten Entwickler derselbe Satz: “Gib ihm doch einfach einen Code-Interpreter.” Das Modell schreibt Python, das Python läuft, die Rechnung stimmt auf den Cent. Problem gelöst.

Ist es nicht.

Der Code-Interpreter löst ein reales, aber eng begrenztes Problem. Er beseitigt den einen Fehler, den jeder sieht, und lässt die vier übrig, von denen niemand einen Screenshot macht. Ihre KI behauptet nicht länger, dass 8,4 mal 12 gleich 99,2 sei. Gut. Aber die Zahl, die sie mit 12 multipliziert hat, stammte nach wie vor aus der falschen Spalte, aus der falschen Periode, ohne nachvollziehbare Quelle. Das Ergebnis ist jetzt präzise falsch statt ungefähr falsch, und ein CFO erkennt den Unterschied auf den ersten Blick nicht.

Was ein Code-Interpreter tatsächlich behebt

Wenn ein Modell die Berechnung an ein abgeschottetes Python (oder ein beliebiges Function-Calling-Tool) auslagert, rechnet es nicht mehr im Kopf. Das ist wichtig. LLMs zerlegen Zahlen in Token wie Text und reproduzieren das Ergebnis per Mustererkennung – deshalb bricht die Rechengenauigkeit mit steigender Stellenzahl regelrecht ein. Übergeben Sie die Berechnung an numpy, erhalten Sie ein deterministisches, reproduzierbares Ergebnis. Summieren Sie eine Spalte mit 4.000 Transaktionen, stimmt das Ergebnis jedes Mal.

Wenn die Frage also lautet “Kann die KI eine Liste von Zahlen korrekt addieren?”, dann ist die Antwort mit Code-Interpreter: ja. Das bestreiten wir nicht. Wir setzen selbst auf deterministische Ausführung, denn das LLM darf niemals der Taschenrechner sein.

Das Problem ist nur: “Addiere diese Zahlen” ist so gut wie nie die eigentliche Aufgabe. Die Aufgabe lautet: “Wie hoch war die Net Revenue Retention im dritten Quartal, und ist das dieselbe Zahl, die wir dem Aufsichtsrat zeigen werden?” Diese Frage kann auf mindestens vier Arten schiefgehen, bevor überhaupt multipliziert wird.

Die vier Fehlerquellen, die der Interpreter nie berührt

1. Falsche Eingaben

Ein Code-Interpreter rechnet fehlerfrei – mit allem, was Sie ihm vorsetzen. Geben Sie ihm den Bruttoumsatz, obwohl Sie den Nettoumsatz meinten, abgegrenzte Erlöse als bereits realisiert verbucht oder eine doppelt erfasste Rechnungsposition, dann liefert er eine exakte Antwort auf die falsche Frage. Müll rein, perfekt berechneter Müll raus. Die Sandbox hat keine Meinung dazu, ob die Eingaben die richtigen Eingaben sind. Sie kann es nicht haben, denn sie weiß nicht, was “richtig” in Ihrem Kontenplan bedeutet.

Das ist der Fehler, der Sie in einer Aufsichtsratspräsentation in den Abgrund reißt, weil die Rechnung ja aufgeht. Niemand hinterfragt eine Zahl, die schlüssig addiert ist.

2. Nicht abgestimmte Daten

Die meisten Unternehmen haben nicht einen Datenstand. Sie haben QuickBooks, ein Abrechnungssystem, ein CRM mit ARR-Feldern, die jemand von Hand pflegt, und dazu drei Tabellen. Ziehen Sie “Umsatz” aus dem Abrechnungstool und “Umsatz” aus dem Hauptbuch, erhalten Sie zwei verschiedene Werte – beide vertretbar, keiner mit dem anderen abgestimmt.

Eine KI mit Code-Interpreter rechnet bereitwillig mit dem einen wie dem anderen. Sie merkt nicht, dass beide voneinander abweichen. Sie hat kein Konzept einer einzigen verlässlichen Wahrheit, die zum Hauptbuch durchstimmt, denn Abstimmung ist ein vorgelagertes Datenproblem, kein Rechenproblem zur Laufzeit. Genau diese Lücke ist der Grund, warum autonome Finanz-Agenten zuerst eine verlässliche Zahlenebene brauchen. Diesen Punkt unterschätzen Teams am stärksten. Umfragen finden immer wieder Datenqualität und Integration als das größte Hindernis dafür, Wert aus KI im Finanzbereich zu ziehen – nicht die Modellgenauigkeit. Das Modell war nie der Engpass.

3. Fehlende Herkunft

Bitten Sie einen CFO, eine Zahl vor einem Wirtschaftsprüfer, einem Investor oder einer Aufsichtsbehörde zu vertreten, lautet die erste Frage: “Woher kommt die?” Ein Code-Interpreter liefert Ihnen ein Ergebnis und ein Protokoll des Python-Codes, der es erzeugt hat. Er liefert Ihnen keine Linie zurück zum Quelldokument, zum Buchungssatz, zur Periode, zur Modellversion. Wenn Sie eine Zahl nicht anklicken und bis zu ihrem Ursprung zurückverfolgen können, ist sie nicht prüfungssicher – ganz gleich, wie sauber die Rechnung ist. Genau deshalb zählen Audit-Trails mehr als Genauigkeit allein, sobald echtes Geld auf dem Spiel steht.

4. Mehrdeutigkeit bei Gebietsschema und Format

Hier die leise Fehlerquelle. Ist 12,345 zwölftausenddreihundertfünfundvierzig oder zwölf Komma drei vier fünf? In den USA sind es rund zwölftausend. In Deutschland sind es etwa zwölf. Mischen Sie noch ostarabische Ziffern in dasselbe Dokument, wird das Parsing noch schlechter. Ein Code-Interpreter führt aus, wofür das Modell die Zahl gehalten hat. Hat das Modell das Trennzeichen falsch gelesen, rechnet die Sandbox brav mit einem Wert, der um drei Größenordnungen daneben liegt. Es wird kein Fehler geworfen. Das Python lief einwandfrei.

Währung, Grenzen des Geschäftsjahres, Prozent vs. Basispunkte, Skalierung von Tausend vs. Million in einer ausgewiesenen Tabelle: Jede dieser Größen ist eine Interpretation, die vor der Berechnung stattfindet – und der Rechner kann eine Fehlinterpretation nicht abfangen, die er nie zu Gesicht bekommt.

Das Muster: Die Berechnung sind die einfachen 20 Prozent

Beachten Sie, was alle vier gemeinsam haben. Sie passieren vor oder nach der Rechnung, nicht während ihr. Ein Code-Interpreter ist eine Korrektur auf der falschen Ebene. Es ist, als stellten Sie einen brillanten Buchhalter ein und drückten ihm einen Schuhkarton voller unsortierter, falsch beschrifteter, womöglich doppelter Belege in die Hand. Seine Rechnung wird perfekt sein. Der Abschluss wird trotzdem falsch sein.

Im Finanzbereich die Zahlen richtig hinzubekommen, ist überwiegend ein Datenproblem und ein Herkunftsproblem. Die Mathematik ist der leichte Teil – und der einzige, den der Interpreter überhaupt anfasst.

Was KI wirklich finance-safe macht

Die Lösung ist kein klügeres Modell und keine schnellere Sandbox. Es ist eine abgestimmte Modellebene zwischen Ihren Rohdaten und der KI, und sie muss drei Dinge leisten, die der Interpreter nicht leistet.

• Zuerst abstimmen. Verbinden Sie die Buchhaltungs- und Finanzquellen, lösen Sie die Konflikte auf und bauen Sie ein Modell, das zum Hauptbuch durchstimmt, bevor die KI überhaupt eine Frage stellt. Die KI ruft aus geprüften Werten ab, nicht aus dem System, das zufällig zuerst antwortet. Tiefer gehen wir darauf ein unter warum abgestimmte Daten der eigentliche Schlüssel sind.
• Deterministisch rechnen – mit den richtigen Eingaben. Ja, setzen Sie eine deterministische Engine ein. Aber richten Sie sie auf abgestimmte, korrekt geparste, periodengerecht zugeordnete Zahlen, mit vorab geklärtem Gebietsschema und vorab geklärter Skalierung. Dass die Engine exakt ist, hilft nur, wenn die Eingaben stimmen.
• Jede Zahl bis zur Quelle nachverfolgen. Jede Zahl, die die KI ausweist, sollte ihre Herkunft mitführen: den Quelldatensatz, den Berechnungsweg, die Periode, die Version. Genau das macht aus einer Antwort etwas, das Sie auch vertreten können.

Das ist die neuro-symbolische Aufteilung, richtig gemacht. Das LLM tut, worin es gut ist: die Frage verstehen, die Methode wählen, das Ergebnis in verständlicher Sprache erläutern. Die deterministische Engine übernimmt die Mathematik. Und ein abgestimmtes, herkunftsverfolgtes Modell darunter sorgt dafür, dass gerechnet wird auf Zahlen, die tatsächlich Ihre sind. Sie können sich ansehen, wie die deterministische Engine arbeitet und wie sie sich an Ihre bestehenden Systeme anbindet, ohne dass Sie irgendetwas neu erfassen müssen.

Ein Code-Interpreter ist notwendig. Hinreichend ist er bei Weitem nicht. Auf die Nase fallen die Unternehmen, die sahen, wie die Rechnung in Ordnung gebracht wurde, und annahmen, damit sei auch das Vertrauensproblem gelöst.

Wenn KI Ihre echten Zahlen anfassen soll, beginnen Sie auf der Ebene, die der Interpreter überspringt. Buchen Sie eine Demo, und wir zeigen Ihnen eine Zahl, die von einem aufsichtsratsreifen Ergebnis bis zum Buchungssatz zurückverfolgt ist, aus dem sie stammt.