KI im Workflow des Data Analyst: Wo sie hilft, wo sie scheitert

Ein VP of Sales schreibt Ihnen um 8:47 Uhr auf Slack. Die Nachricht besteht aus einem Satz: „Die KI sagt, der Umsatz ist um 14 % gestiegen. Können Sie das prüfen?"

Sie öffnen den Copilot des BI-Tools, fügen denselben Prompt ein, den der VP verwendet hat, und erhalten eine Abfrage zurück, die in 1,2 Sekunden ausgeführt wird. Die zurückgegebene Zahl lautet 14 %. Die Abfrage ist trotzdem falsch. Sie verknüpft orders mit customers über email statt über customer_id und zählt damit jeden doppelt, der jemals seine E-Mail-Adresse geändert hat. Sie behandelt status = 'completed' als Umsatz, ohne Rücksendungen herauszufiltern. Die 14 % sind korrekte Arithmetik auf dem falschen Datensatz.

Der VP weiß das nicht. Der Copilot weiß das nicht. Sie wissen es, weil Sie seit neun Monaten in diesem Data Warehouse arbeiten und von beiden Verknüpfungsfehlern bereits Mal gebrannt worden sind.

Das ist der eigentliche Job im Jahr 2026. Nicht SQL schneller schreiben. SQL verifizieren, das bereits von etwas geschrieben wurde, das plausibel klingt, aber das Unternehmen nicht versteht.

Warum das jetzt wichtig ist

Jeder BI-Anbieter und jede IDE hat ein Feature für „Abfragen in einfachen Worten" veröffentlicht. Die Führungsebene hat das bemerkt. Der CFO hat einen McKinsey-Artikel über KI-Produktivität gelesen und erwartet nun, dass die Analyseabteilung mit demselben Headcount mehr liefert. Wer KI ablehnt, wirkt rückständig. Wer ihr blind vertraut, wird zum menschlichen Stempel auf halluzinierten Zahlen, die es bis ins Board-Deck schaffen.

Die einzige tragfähige Position ist die dritte: KI als Kraftmultiplikator für die mechanischen Teile der Arbeit einsetzen und selbst zur Governance-Schicht für den Rest werden. Der Analyst, der überzeugend erklären kann, warum eine KI-erstellte Abfrage falsch ist, sie in zwei Minuten korrigiert und die richtige Antwort liefert, ist im Jahr 2026 wertvoller, nicht weniger. Wer Copilot-Output in ein Dashboard einfügt und dabei bleibt, ist ein Junior mit einem zusätzlichen Schritt.

Wo KI wirklich hilft

Konkret benennen. „KI hilft bei der Produktivität" ist genau die Art von Satz, den ich aus diesem Artikel streichen möchte. Hier sind die Bereiche, in denen KI ihren Einsatz rechtfertigt, beim Namen genannt.

SQL-Entwürfe zum Überarbeiten

Cursor mit Claude als Modell ist derzeit die sichere Standardwahl für arbeitende Analysten. Besonders stark ist das Tool beim zweiten Entwurf, nicht beim ersten. Sie haben eine 200-zeilige Abfrage mit fünf CTEs geschrieben, um die Kohortenbindung von Monat zu Monat zu berechnen. Sie funktioniert. Sie ist aber auch unleserlich. Fügen Sie sie in Cursor ein, bitten Sie um eine Überarbeitung, die die CTEs konsolidiert und Kommentare hinzufügt, und erhalten Sie in 30 Sekunden etwas Saubereres zurück. Sie lesen es, lehnen zwei Änderungen ab, die die Logik gebrochen haben, akzeptieren den Rest und haben sich einen Nachmittag Bereinigung gespart.

Dasselbe gilt für Fensterfunktionen, die Sie zweimal im Jahr schreiben, komplizierte Self-Joins für hierarchische Daten und Pivot-Logik. Behandeln Sie das Ergebnis als ersten Entwurf eines klugen Juniors, der Ihr Data Warehouse noch nie gesehen hat. Nützlich, aber nicht fertig.

Dokumentation des Dashboard-Schemas

Geben Sie Claude Ihre dbt-Modelldatei, Ihr LookML oder das Dashboard-JSON und bitten Sie darum, den Datenkatalog-Eintrag zu verfassen. Das Ergebnis ist ein überprüfbarer Fließtext, der zu 80 % korrekt ist. Sie korrigieren die 20 %, bei denen die KI geraten hat. Gesamtaufwand: 10 Minuten pro Dashboard statt zwei Stunden. Der mögliche Fehler ist eine falsche Beschreibung, keine falsche Zahl. Das ist in der Überprüfung viel leichter zu erkennen.

Das ist der wirksamste KI-Einsatz, den ich gefunden habe. Dokumentation ist das, was jedes Analytics-Team „nächstes Quartal" erledigen will und nie tut. KI senkt die Hemmschwelle.

Vorbereitung auf Anforderungsgespräche

Bevor Sie sich mit einem Stakeholder über ein neues Dashboard treffen, fügen Sie seinen Slack-Thread, die E-Mail-Kette und die grobe Anfrage in Claude ein. Prompt: „Was sind die fünf Fragen, die ich klären sollte, bevor ich SQL für diese Anfrage schreibe?" Sie erhalten eine Liste. Die Hälfte der Fragen ist offensichtlich. Zwei werden Unklarheiten aufdecken, die Sie übersehen haben. Eine ist nutzlos. Netto positiv in 90 Sekunden.

Der Punkt ist nicht, dass KI Ihr Unternehmen kennt. KI ist eine kompetente Entscheidungshilfe, die bessere Folgefragen stellt, als Sie es um 9 Uhr morgens an einem Dienstag tun.

Beschreibung erkannter Anomalien

Sie haben den Ausreißer entdeckt. Die Conversion-Rate ist in der Südostregion im Wochenvergleich um 23 % gesunken. Sie wissen, dass es am neuen Preistest liegt. Jetzt müssen Sie die Slack-Nachricht im Ton Ihres Teams verfassen, mit der richtigen Einschränkungssprache, den richtigen nächsten Schritten und einem Hinweis an die betroffenen Stakeholder. KI entwirft diese Nachricht in 15 Sekunden. Sie passen den Ton an, senden sie ab und machen weiter.

Beachten Sie die Reihenfolge. Sie haben die Analyse durchgeführt. KI hat den Text verfasst. Drehen Sie die Reihenfolge um, und Sie landen wieder bei „Die KI sagt, der Umsatz ist um 14 % gestiegen."

Pflege des Datenkatalogs

Die meisten Teams haben keine Spaltenbeschreibungen in ihrem Data Warehouse. Null. Leere Zeichenketten. Beschreibungen automatisch aus Spaltenname, Beispielwerten und übergeordneter Tabelle zu generieren ist nicht perfekt, aber „unvollkommene Beschreibung" ist besser als „keine Beschreibung". Führen Sie das als Batch-Job einmal im Quartal aus, bearbeiten Sie die offensichtlich falschen manuell nach und veröffentlichen Sie das Ergebnis.

Wo KI scheitert

Das sind die Fehlerquellen, die falsche Zahlen an Führungskräfte liefern. Prägen Sie sie sich ein.

Datensemantik

orders.status = 'completed' bedeutet in Ihrem Data Warehouse nicht „Umsatz". Es schließt möglicherweise zurückgesendete Bestellungen aus oder auch nicht. Es könnte Abonnementverlängerungen als separate Bestellungen zählen oder sie zusammenfassen. Es könnte gross_amount, net_amount oder amount_after_tax_and_discount verwenden. KI weiß das nicht. KI rät. Die Schätzung klingt plausibel. Sie ist häufig falsch, und zwar auf eine Weise, die allein anhand der Abfrage kaum zu erkennen ist. Das SQL ist syntaktisch einwandfrei, die Verknüpfung kompiliert, die Zahl kommt zurück. Sie müssen das Data Warehouse kennen, um den Fehler zu erkennen.

NULL-Behandlung

COUNT(column) schließt NULLs aus. COUNT(*) nicht. SUM über eine Spalte mit NULLs gibt NULL zurück, wenn alle Werte NULL sind, und eine Zahl, wenn irgendeiner nicht NULL ist. LEFT JOIN bei einer Eins-zu-viele-Beziehung verdoppelt Ihre Zeilenanzahl, wenn Sie vergessen zu aggregieren. KI macht diese Fehler bei echten Schemas in etwa der Hälfte der Fälle, weil die öffentlichen Trainingsdaten ebenfalls häufig den Fehler enthalten. Wenn Ihr Dashboard plötzlich viermal so viele Kunden wie gestern zeigt, prüfen Sie die Verknüpfungen.

Geschäftslogik

„Aktiver Kunde" bedeutet bei jedem Unternehmen etwas anderes. Bei einem B2B-SaaS-Unternehmen könnte es „innerhalb der letzten 30 Tage eingeloggt" heißen. Bei einem Marktplatz „innerhalb der letzten 90 Tage eine Transaktion abgeschlossen". Bei einem Fintech „Guthaben über 0 € und kein Betrugsmerkmal". KI greift auf die gängigste Definition in ihren Trainingsdaten zurück, die mit ziemlicher Sicherheit nicht die Ihre ist. Dasselbe gilt für „MRR", „Abwanderung", „Engagement", „Bindung". Jede Kennzahl hat fünf plausible Definitionen. Ihr Team verwendet eine davon. KI weiß nicht, welche.

Data Governance und Datenherkunft

KI schreibt ohne Weiteres eine Abfrage gegen customers_legacy_v2, eine veraltete Tabelle, die seit November nicht mehr aktualisiert wurde. KI kennt Ihr dbt-Freshness-SLA nicht. KI weiß nicht, dass das Marketing-Team die Kundentabelle dienstags für einen Kampagnenexport verzweigt und diese Verzweigung eine leicht abweichende Logik hat. KI weiß nicht, dass Sie die Umsatzverfolgung vor sechs Wochen auf eine neue Tabelle migriert haben und die alte schreibgeschützt ist.

Das ist die am schwersten skalierbare Fehlerquelle. Je mehr sich Ihr Data Warehouse weiterentwickelt, desto weiter hinkt KIs Vorstellung davon hinterher, und die entworfenen Abfragen werden mit zunehmender Zeit überzeugter falsch.

Die Falle „KI hat diese Abfrage generiert"

Hier ist die klare Grenze. Fügen Sie niemals eine KI-generierte Abfrage in ein Dashboard, einen Stakeholder-Bericht oder eine Executive-Präsentation ein, ohne diese vier Prüfungen durchzuführen:

1. Gegen ein bekanntes Ergebnis testen. Wählen Sie einen Ausschnitt, den Sie bereits validiert haben (die Vormonatszahl, die der CFO bereits abgesegnet hat), und prüfen Sie, ob die KI-Abfrage diesen reproduziert.
2. Zeilenanzahl prüfen. Wenn Sie rund 10.000 Kunden erwarten und die Abfrage 47.000 zurückgibt, liegt eine Zeilenvervielfachung vor. Gibt sie 12 zurück, ist ein Filter zu restriktiv.
3. Verknüpfungen auf Zeilenvervielfachung prüfen. Betrachten Sie jedes JOIN. Ist die rechte Seite beim Verknüpfungsschlüssel garantiert eindeutig? Falls nicht, benötigen Sie DISTINCT oder Aggregation.
4. Datumsfilter auf korrekte Funktion prüfen. „Letzter Monat" in BI-Tool A kann „letzte 30 Tage" bedeuten. In Tool B kann es „vorheriger Kalendermonat" sein. In SQL, das KI geschrieben hat, könnte es beides sein, plus ein Off-by-one-Fehler.

Das zu verinnerlichende Muster lautet: KI hat es geschrieben, ich habe es verifiziert, ich verantworte es. Nicht: KI sagt, die Zahl ist X. Wenn Sie die Abfrage Zeile für Zeile vor dem VP of Finance nicht verteidigen können, dürfen Sie die Antwort nicht liefern. Wenn Sie sie trotzdem liefern und sie falsch ist, ist „die KI hat es geschrieben" keine Verteidigung. Sie haben es geschrieben, indem Sie es akzeptiert haben.

Data Governance und Versionskontrolle

Behandeln Sie KI-gestütztes SQL wie jeden anderen Code. Committen Sie es in Ihr dbt-Repository oder Ihr Analytics-GitHub. Nutzen Sie Pull-Request-Prüfungen, auch wenn der einzige Prüfer Sie selbst 24 Stunden später mit frischem Blick sind. Vermerken Sie Modell und Prompt in der Commit-Nachricht, wenn sie die Logik maßgeblich beeinflusst haben, damit Sie künftig wissen, woher die ungewöhnliche CTE-Struktur stammt.

Legen Sie eine kleine Datei forbidden_patterns.md im Repository Ihres Teams an. Zehn bis zwanzig Einträge, jeder ein Fehler, den Sie persönlich gemacht haben:

• Verknüpfungen, die richtig aussehen, es aber nicht sind (das Beispiel mit email statt customer_id)
• Spalten, deren Bedeutung sich geändert hat (status schloss früher „shipped" ein, jetzt nicht mehr)
• Tabellen, die nicht direkt abgefragt werden sollen (raw.events ist ein Daten-Feuerschlauch, nutzen Sie analytics.sessions)
• Kennzahlendefinitionen, die von der öffentlichen Standarddefinition abweichen (Ihre Definition von „aktivem Nutzer")
• SLA-relevante Tabellen (diese hat 24 Stunden Verzögerung, jene ist in Echtzeit)

Fügen Sie diese Datei für jede SQL-Sitzung in den Kontext von Cursor ein. Das ist das günstigste und wirksamste Governance-Tool, das ich gefunden habe. KI tappt deutlich seltener in bekannte Fallen, wenn Sie ihr gesagt haben, wo die Fallen sind.

Der 30-Tage-Plan zur KI-Integration ohne Qualitätsverlust

Versuchen Sie nicht, Ihren gesamten Workflow am ersten Tag auf KI umzustellen. Gehen Sie schrittweise vor.

Woche 1, Kalibrierung. Wählen Sie ein Tool. Cursor plus Claude ist die sichere Standardwahl; falls Ihr Unternehmen Copilot eingeführt hat, nutzen Sie das. Verwenden Sie es ausschließlich für die SQL-Überarbeitung bei Abfragen, die Sie bereits verstehen und validiert haben. Vergleichen Sie jedes Ergebnis mit dem, was Sie selbst geschrieben hätten. Entwickeln Sie ein Gefühl dafür, wo das Tool zuverlässig ist und wo es halluziniert. Das Ziel ist Kalibrierung, nicht Produktivität.

Woche 2, Dokumentation. Fügen Sie risikoarme, aber wirkungsstarke Aufgaben hinzu. Datenkatalog-Einträge automatisch entwerfen. Dashboard-READMEs erstellen. Runbook-Entwürfe für wiederkehrende Anfragen Ihres Teams schreiben. Fehlerquelle hier ist ein Satz, den Sie umschreiben müssen, keine falsche Zahl auf dem Schreibtisch des CFO.

Woche 3, Anforderungsvorbereitung. Lassen Sie KI vor jedem Stakeholder-Meeting zuerst den Thread auswerten. Bitten Sie um die fünf Klärungsfragen. Protokollieren Sie, welche davon tatsächlich eine Überarbeitung erspart haben. Nach zwei Wochen erkennen Sie ein Muster dafür, was KI erkennt und was sie übersieht.

Woche 4, kodifizieren. Verfassen Sie die ai-usage.md Ihres Teams. Drei Abschnitte: was KI eigenständig entwerfen darf, was Menschen vor dem Merge prüfen müssen und was verboten ist. Ein vernünftiger Ausgangspunkt:

• Erlaubt: Dokumentationsentwürfe, Überarbeitungsvorschläge, Entwürfe für Anomalie-Beschreibungen nach menschlicher Analyse, klärende Fragen für Anforderungen.
• Vor Merge prüfen: jegliches SQL, das Produktions-Dashboards berührt, jede Änderung an Kennzahlendefinitionen, jedes neue dbt-Modell.
• Verboten: KI-erstelltes SQL ohne LIMIT 100 und menschliche Prüfung automatisch gegen Prod ausführen; Spalten mit PII in ein Drittanbieter-KI-Tool einfügen, das keinen unterzeichneten DPA hat; KI nutzen, um SQL in Dialekten zu schreiben, die Sie nicht flüssig lesen.

Der letzte Punkt ist der, den die meisten überspringen. Wenn Sie Snowflake-spezifische Fensterfunktions-Syntax nicht lesen können, können Sie auch nicht prüfen, was Cursor geschrieben hat. Sie vertrauen auf Treu und Glauben. Tun Sie das nicht.

Optional: Die Perspektive des ACE Frameworks

Wenn Ihr Unternehmen ein KI-Betriebsmodell auf Basis des ACE Frameworks einführt, lässt sich der Analyst-Workflow sauber darauf abbilden. KI übernimmt Generate (SQL-Entwürfe, Dokumentationsentwürfe, Slack-Updates) und unterstützt Analyze (Zusammenfassungen von Anomalien, Überarbeitungsvorschläge). Menschen verantworten Ingest (Datensemantik: was jede Spalte in diesem Unternehmen tatsächlich bedeutet), Predict (kausale Interpretation, warum sich eine Kennzahl bewegt hat) und Execute (die Antwort mit Überzeugung und einer nachvollziehbaren Logik an einen Stakeholder liefern).

Das ist die Kurzversion. Der Kern: Die vertrauensintensiven, geschäftskontextabhängigen Teile des Jobs bleiben noch lange beim Menschen. Die mechanischen Teile gehen an KI. Ihre Karriere baut auf der ersten Hälfte auf.

Häufige Fehler

Einige Fallen, in die ich Analysten häufig tappen sehe, grob nach Häufigkeit geordnet:

• Stakeholders erlauben, den BI-Copilot eigenständig zu nutzen, und die Analyst-Prüfung als optional zu behandeln. Der Copilot liefert falsche Zahlen; der Analyst wird trotzdem verantwortlich gemacht.
• Produktionsschema mit PII in ein Drittanbieter-KI-Tool einfügen, das keinen DPA hat. Das ist bei den meisten Unternehmen ein Kündigungsgrund. Prüfen Sie das, bevor Sie einfügen.
• KI nutzen, um SQL in Dialekten zu schreiben, die Sie nicht flüssig lesen. BigQuery's ARRAY_AGG entspricht nicht dem von Postgres, Snowflakes QUALIFY nicht dem von Redshift. Was man nicht lesen kann, kann man nicht prüfen.
• Den Schritt „gegen bekanntes Ergebnis testen" überspringen, weil die Abfrage „richtig aussieht". So landen 14 % Umsatzwachstum im Dashboard, wenn das tatsächliche Wachstum 3 % beträgt.
• Die Überzeugung des BI-Copilots als Beweis für Korrektheit werten. Er sagt „Umsatz ist um 14 % gestiegen" mit demselben Tonfall, egal ob die Abfrage korrekt oder katastrophal falsch ist.

Vorlagen und Tools

Drei Artefakte, die Sie in Ihren ersten 30 Tagen erstellen sollten. Bewahren Sie sie im Analytics-Repository Ihres Teams auf.

1. forbidden_patterns.md: Beginnen Sie mit zehn Einträgen aus Ihrem Data Warehouse. Echte Verknüpfungen, die jemanden bereits gebrannt haben. Ergänzen Sie monatlich einen weiteren, sobald Sie ihn entdecken.
2. SQL-Prüfcheckliste: Acht Punkte, die Sie bei jeder KI-erstellten Abfrage vor dem Merge durchgehen: Bekanntes-Ergebnis-Prüfung, Plausibilitätsprüfung der Zeilenanzahl, Prüfung auf Zeilenvervielfachung, Datumsfilterprüfung, NULL-Behandlungsprüfung, Geschäftslogik-Prüfung (bedeutet „aktiv" das, was wir meinen?), Governance-Prüfung (ist diese Tabelle aktuell?), Lesbarkeits-Prüfung.
3. Prompt zur Vorbereitung von Stakeholder-Gesprächen: Ein gespeicherter Claude-Prompt, in den Sie einen Slack-Thread einfügen und fünf klärende Fragen zurückerhalten. Monatlich verfeinern.
4. ai-usage.md: Die Richtlinie Ihres Teams. Lebendes Dokument. Quartalsweise überprüfen.

Erfolgsmessung

Sie werden wissen, dass es funktioniert, wenn drei Dinge zutreffen. Sie liefern schneller bei Dokumentation und Überarbeitung, und Sie können auf konkrete Ergebnisse verweisen, die es vorher nicht gab. Stakeholder vertrauen Ihren Zahlen mehr, nicht weniger, weil Sie die Fehler des BI-Copilots routinemäßig abfangen, bevor sie in Slack landen. Und Sie können in einem Satz pro Abfrage erklären, warum der erste KI-Entwurf falsch war.

Dieser letzte Satz macht Sie 2026 erfahrener, nicht ersetzbarer. „Er hat auf email statt customer_id verknüpft." „Der Rückgabefilter fehlt." „Er hat die veraltete Umsatztabelle verwendet." Jeder Satz ist ein Stück warehouse-spezifisches Urteilsvermögen, das KI nicht hat und ohne Sie nicht haben kann. Das ist der Schutzwall. Bauen Sie ihn auf.

Der Job ist nicht mehr das Tippen der Abfrage. Der Job ist das Verantworten der Antwort. KI hat sie geschrieben, Sie haben sie geprüft, Sie verantworten sie. Das ist die Grenze. Das ist der ganze Artikel.

Weiterführende Artikel

• Ein Tag im Leben eines Data Analyst
• Die ersten 30/60/90 Tage als neuer Data Analyst
• Data Analyst Stellenbeschreibungsvorlage
• ACE Framework