KI auf Tabellen loslassen Fragen an Excel-Daten in Klartext.

Die Vorstellung ist verlockend: Ein Mitarbeiter tippt „Welche fünf Kunden hatten im letzten Quartal den höchsten Deckungsbeitrag?“ in ein Chatfenster, und die KI liefert die Antwort direkt aus der Excel-Tabelle — ohne Pivot-Tabelle, ohne SVERWEIS, ohne Controlling-Anfrage. Genau das ist heute technisch möglich, aber nur, wenn man versteht, warum ein Sprachmodell allein dafür der falsche Weg ist. Reine Sprachmodelle rechnen nicht zuverlässig; sie erzeugen plausibel klingende Zahlen, die schlicht falsch sein können. Der verlässliche Ansatz lässt das Modell nicht selbst rechnen, sondern Code oder eine Datenbankabfrage schreiben, die auf der echten Tabelle ausgeführt wird — und gibt nur das Ergebnis zurück. Dieser Beitrag erklärt, warum LLMs bei Mathematik systematisch danebengreifen, wie Text-to-SQL und Code-Ausführung das Problem lösen, welche Datenmengen und Datenqualität dafür nötig sind und wo die Grenzen liegen, denn auch der beste Ansatz scheitert an unsauberen Tabellen und mehrdeutigen Fragen.

Warum reine Sprachmodelle bei Zahlen scheitern.

Ein großes Sprachmodell ist kein Taschenrechner. Es sagt das nächste wahrscheinliche Wort voraus — und bei einer Rechenaufgabe ist das nächste „Wort“ eben eine Ziffer, die statistisch plausibel wirkt, aber nicht aus einer tatsächlichen Berechnung stammt. Bei kleinen, oft gesehenen Rechnungen geht das gut; bei der Summe über tausend Tabellenzeilen oder einem mehrstufigen Filter wird es unzuverlässig.

Das Tückische ist, dass die Fehler nicht offensichtlich sind. Das Modell liefert eine Zahl mit derselben Selbstsicherheit, ob sie stimmt oder nicht. Es gibt keine Fehlermeldung, kein Warnsignal — nur eine falsche Zahl, die richtig aussieht. Im Geschäftskontext ist das gefährlicher als ein offensichtlicher Aussetzer, weil niemand stutzig wird.

Hinzu kommt das Kontext-Problem: Eine große Tabelle passt oft gar nicht vollständig in die Anfrage an das Modell. Schickt man nur einen Ausschnitt, rechnet das Modell auf unvollständigen Daten. Schickt man alles, wird es teuer und unzuverlässig zugleich. Für ernsthafte Datenauswertung ist der direkte Weg „Tabelle plus Frage ins Sprachmodell“ deshalb keine tragfähige Lösung.

Der richtige Ansatz: das Modell schreibt Code, nicht die Antwort.

Die verlässliche Architektur dreht die Aufgabe um. Das Sprachmodell rechnet nicht selbst, sondern übersetzt die Frage in eine präzise, ausführbare Anweisung — eine Datenbankabfrage oder ein kurzes Stück Auswertungscode. Diese Anweisung wird dann von einer echten Rechenmaschine auf der vollständigen Tabelle ausgeführt. Das Ergebnis ist mathematisch korrekt, weil eine deterministische Engine gerechnet hat, nicht das Modell.

Konkret läuft das in drei Schritten ab. Erstens versteht das Modell die natürlichsprachige Frage und das Schema der Tabelle — welche Spalten gibt es, was bedeuten sie. Zweitens erzeugt es daraus eine Abfrage, etwa in SQL, oder ein Stück Auswertungscode. Drittens wird diese Abfrage ausgeführt, und nur das Zahlenergebnis — oder eine kurze Erläuterung dazu — geht an den Nutzer zurück.

Der entscheidende Punkt: Die Sprachfähigkeit des Modells wird dort genutzt, wo sie stark ist — beim Verstehen der Frage und beim Formulieren der Logik — und nicht dort, wo sie schwach ist, beim eigentlichen Rechnen. Diese Arbeitsteilung ist der Kern jeder verlässlichen KI-gestützten Tabellenanalyse.

Text-to-SQL und Code-Ausführung im Vergleich.

Für die ausführbare Anweisung gibt es zwei gängige Wege, die sich je nach Datenlage anbieten:

Text-to-SQL ist der reifere und besser kontrollierbare Weg, wenn die Daten ohnehin in einer Datenbank liegen. Die erzeugte Abfrage lässt sich anzeigen, prüfen und einschränken — man kann etwa erzwingen, dass nur lesende Abfragen erlaubt sind. Code-Ausführung ist flexibler und passt besser zu lose vorliegenden Excel- oder CSV-Dateien und zu Auswertungen, die über reines SQL hinausgehen, etwa Trendberechnungen. Sie verlangt aber mehr Sorgfalt bei der Absicherung, weil ausgeführter Code prinzipiell mehr Schaden anrichten kann.

In der Praxis kombinieren viele Lösungen beides: SQL für die strukturierte Standardabfrage, Code für die anspruchsvollere Analyse. Welcher Weg passt, hängt davon ab, wo die Daten liegen und wie tief die Fragen gehen sollen.

Datenqualität entscheidet über das Ergebnis.

Der beste Ansatz scheitert an einer schlechten Tabelle. Wer KI auf seine Daten loslässt, merkt schnell, dass das eigentliche Hindernis selten die KI ist, sondern der Zustand der Tabellen. Drei Probleme tauchen immer wieder auf.

Erstens unklare Struktur: verbundene Zellen, mehrere Tabellen auf einem Blatt, Überschriften in der Mitte, leere Zeilen als optische Trenner. Was ein Mensch intuitiv liest, verwirrt eine maschinelle Auswertung. Saubere, einheitliche Tabellen mit einer Kopfzeile und einer Zeile pro Datensatz sind die Voraussetzung, nicht der Luxus.

Zweitens uneinheitliche Werte: Derselbe Kunde heißt mal „Müller GmbH“, mal „Mueller GmbH“, mal „Fa. Müller“. Für die KI sind das drei verschiedene Kunden, und jede Summierung danach ist falsch. Solche Inkonsistenzen muss man kennen und bereinigen, bevor man den Auswertungen traut.

Drittens fehlende Bedeutung: Eine Spalte heißt „DB2“ — meint das Deckungsbeitrag Stufe 2 oder etwas anderes? Ohne Erklärung der Spalten rät das Modell, und Raten ist im Controlling keine gute Grundlage. Ein kurzes Daten-Glossar, das jede Spalte erklärt, verbessert die Trefferquote spürbar.

Wer es nutzt und welchen Nutzen es bringt.

Der größte Wert entsteht dort, wo viele Menschen einfache bis mittlere Datenfragen haben, aber nicht alle die Werkzeuge dafür beherrschen. Der Vertriebsmitarbeiter, der wissen will, wie sich sein Gebiet entwickelt; die Geschäftsführung, die schnell eine Kennzahl braucht; der Einkäufer, der Lieferantenausgaben vergleichen will — sie alle müssten sonst entweder selbst Pivot-Tabellen bauen oder das Controlling anfragen und warten.

KI-gestützte Tabellenanalyse verkürzt diese Wege erheblich. Statt einer Anfrage, die einen halben Tag liegt, gibt es eine Antwort in Sekunden. Das entlastet die Datenspezialisten von Routine-Auswertungen und gibt den Fachabteilungen mehr Selbstständigkeit. Realistisch ist, dass ein erheblicher Teil der wiederkehrenden, einfachen Auswertungsanfragen so direkt beantwortet werden kann — die komplexen, mehrdeutigen Fälle bleiben beim Menschen.

Wichtig ist die richtige Erwartung: Das Werkzeug ersetzt keine durchdachte Analyse und keinen erfahrenen Controller. Es macht die einfachen Fragen schnell und senkt die Hürde, überhaupt in die Daten zu schauen. Schon das ist in vielen Unternehmen ein spürbarer Gewinn, weil Entscheidungen häufiger auf einem kurzen Datenblick beruhen statt auf dem Bauchgefühl.

Grenzen, Risiken und der nötige Prüfschritt.

Auch der saubere Ansatz hat Grenzen, die man kennen muss. Die erste ist die Mehrdeutigkeit der Frage. „Umsatz im letzten Monat“ — Kalendermonat oder Geschäftsmonat, brutto oder netto, gebucht oder fakturiert? Das Modell trifft eine Annahme, und wenn sie falsch ist, stimmt die Zahl nicht, obwohl die Rechnung korrekt war. Gute Systeme machen ihre Annahmen sichtbar oder fragen bei Unklarheit nach, statt stillschweigend zu raten.

Die zweite Grenze ist die fehlerhafte Abfrage. Auch wenn das Modell Code statt Zahlen erzeugt, kann dieser Code logisch falsch sein — ein falscher Filter, eine falsche Verknüpfung. Das Ergebnis ist dann sauber gerechnet, aber auf der falschen Grundlage. Deshalb gehört zur seriösen Lösung, dass die erzeugte Abfrage einsehbar ist und sich bei wichtigen Auswertungen prüfen lässt.

Die dritte ist die Sicherheit. Ausgeführter Code und Datenbankzugriff müssen streng eingegrenzt sein: nur lesend, nur auf die freigegebenen Daten, in einer abgeschotteten Umgebung. Sonst öffnet man eine ernste Lücke. Mein ehrlicher Rat: Für verbindliche Zahlen — Bilanz, Reporting, Außenkommunikation — bleibt ein menschlicher Prüfschritt Pflicht. Für die schnelle Orientierung im Alltag ist die Technik dagegen schon heute ein echter Gewinn.

Sie wollen Ihren Mitarbeitern erlauben, Fragen an Ihre Tabellen-Daten in Klartext zu stellen — mit verlässlichen Zahlen? Unverbindlich anfragen — wir prüfen gemeinsam, wie sauber Ihre Daten aufgestellt sind, welcher Ansatz aus Text-to-SQL und Code-Ausführung passt und wie ein sicherer, geprüfter Auswertungs-Workflow für Ihren Anwendungsfall aussieht.