In Stellenanzeigen für Datenrollen steht inzwischen fast überall etwas von KI. Gemeint ist selten ein eigenes Modell, das du trainierst, und meistens etwas viel Banaleres: dass du Sprachmodelle als Werkzeug in deiner täglichen Analysearbeit benutzt. Das ist eine sinnvolle Erwartung. Sie wird nur oft falsch verstanden - von Bewerbern, die glauben, damit wäre die Arbeit erledigt, und von Teams, die glauben, damit wäre die Prüfung erledigt.
Was sich tatsächlich geändert hat
Geändert hat sich die Zeit, die zwischen einer Idee und einem ersten lauffähigen Ergebnis liegt. Eine Abfrage, für die du früher zwanzig Minuten in der Dokumentation einer Fensterfunktion verbracht hast, steht heute in zwei Minuten als Entwurf da. Ein fremdes Skript, das du früher Zeile für Zeile gelesen hast, bekommst du in einer verständlichen Zusammenfassung. Der erste Blick in einen unbekannten Datensatz ist billiger geworden.
Nicht geändert hat sich alles, was danach kommt. Ob die Zahl stimmt, ob die Verknüpfung fachlich zulässig war, ob der Datensatz überhaupt das misst, was der Spaltenname behauptet, und ob aus dem Zusammenhang eine Ursache folgt - all das steht genau da, wo es vorher stand. Die Werkzeuge haben den handwerklichen Teil verbilligt und den urteilenden Teil unangetastet gelassen.
Das ist die eigentliche Nachricht, und sie ist unbequemer als die üblichen Versprechen. Wer den Beruf über die Werkzeugbedienung definiert hat, verliert. Wer ihn über das Urteil definiert, gewinnt. Was ein Data Analyst im Alltag konkret tut, steht ausführlicher im Überblick über die Aufgaben eines Data Analyst.
Wo Sprachmodelle in der Analysearbeit helfen
SQL-Entwürfe. Der stärkste Anwendungsfall. Du beschreibst, welche Tabellen es gibt und was du zählen willst, und bekommst eine Abfrage, die in der Struktur meist passt. Besonders nützlich bei Dingen, die man selten braucht und deshalb nie im Kopf hat: verschachtelte Aggregationen, Datumsarithmetik, Pivotieren. Der Entwurf ist ein Startpunkt, kein Ergebnis.
Fremden Code erklären. Du kommst in ein Team und findest ein Skript aus dem Jahr davor, ohne Kommentare, geschrieben von jemandem, der nicht mehr da ist. Ein Modell fasst zusammen, was der Code der Reihe nach tut. Das ersetzt kein eigenes Lesen, aber es verkürzt den Einstieg von Stunden auf Minuten.
Dokumentation. Der Teil der Arbeit, der am häufigsten liegen bleibt, weil er ungeliebt ist. Aus einem fertigen Notebook eine lesbare Beschreibung zu machen, aus einer Abfrage einen erklärenden Absatz, aus einer Analyse eine kurze Zusammenfassung für die Fachabteilung - das funktioniert gut und spart real Zeit.
Erste Explorationsschritte. Welche Verteilungen sollte man sich ansehen, welche Kennzahlen sind bei dieser Art von Daten üblich, welche Auffälligkeiten wären typisch. Als Ideengeber taugt das. Als Ersatz für den eigenen Blick in die Daten nicht.
Textdaten vorsortieren. Freitext in grobe Kategorien einteilen - Support-Anfragen nach Thema, Kommentare nach Tonlage, Freitextfelder nach Art des Anliegens. Für eine erste Sortierung, die anschließend stichprobenartig geprüft wird, ist das brauchbar und oft besser als die Regelwerke, die vorher dafür herhalten mussten.
Wo sie zuverlässig scheitern
Nachrechnen. Ein Sprachmodell erzeugt plausible Zeichenfolgen, keine Rechenergebnisse. Zahlen, die es selbst ausrechnet, sind ungeprüfte Behauptungen. Rechnen lässt du die Datenbank oder den Code, den du gelesen hast.
Kausalität. Modelle greifen Formulierungsmuster auf, und in Texten wird ständig Zusammenhang mit Ursache verwechselt. Genau diese Verwechslung bekommst du zurück, oft in sehr überzeugendem Ton. Die Frage, ob eine Kennzahl gestiegen ist, weil sich etwas geändert hat, oder ob beides derselben dritten Ursache folgt, kann dir niemand abnehmen.
Datenqualität beurteilen. Ob die Werte in einer Spalte seit einem Systemwechsel anders erhoben werden, ob doppelte Zeilen aus einem fehlerhaften Import stammen, ob ein Nullwert "unbekannt" oder "nicht zutreffend" bedeutet - das steht nicht in den Daten, sondern in den Köpfen der Leute, die das System betreiben.
Fachlicher Kontext. Was in eurem Haus als aktiver Kunde zählt, welche Aufträge zu Testzwecken angelegt wurden, welche Region zwischenzeitlich anders zugeschnitten war. Das ist der Teil, der eine Analyse richtig oder falsch macht, und er ist nirgends abrufbar.
| Aufgabe | Taugt das Werkzeug? | Was du prüfen musst |
|---|---|---|
| SQL-Entwurf | ja, als Entwurf | Verknüpfungen, Filter, Ergebnisgröße |
| Code erklären | ja | Stellen, an denen es auf Details ankommt |
| Dokumentation schreiben | ja | Fachbegriffe und Zahlenangaben |
| Text grob kategorisieren | eingeschränkt | Stichprobe von Hand |
| Zahlen ausrechnen | nein | ohnehin selbst rechnen |
| Ursachen erklären | nein | eigene Argumentation |
| Datenqualität einschätzen | nein | Rücksprache im Fachbereich |
Warum die Prüfpflicht vollständig bei dir bleibt
Wenn eine Auswertung in eine Entscheidung eingeht und die Zahl falsch war, fragt niemand, welches Werkzeug sie erzeugt hat. Gefragt wird, wer sie geliefert hat. Diese Zuordnung ändert sich nicht dadurch, dass ein Modell im Spiel war - sie ist der Grund, warum es die Rolle überhaupt gibt.
Praktisch heißt das: Jede erzeugte Abfrage liest du, bevor du sie ausführst. Besonders auf Verknüpfungen achten, weil ein falscher Join-Typ Zeilen vervielfacht, ohne dass es auffällt. Danach ein Gegencheck, der unabhängig ist: eine einfachere Abfrage auf denselben Ausschnitt, eine bekannte Summe aus einem Bericht, eine Handvoll Datensätze, die du einzeln nachsiehst. Erst wenn zwei Wege dasselbe sagen, gibst du die Zahl weiter.
Dazu kommen betriebliche Regeln. Ob du Daten aus dem Unternehmen in ein extern betriebenes Werkzeug eingeben darfst, entscheidet nicht dein Gefühl, sondern eine interne Richtlinie. Frag danach in der ersten Woche, statt es später zu erklären. Die Grundlagen, die dabei vorausgesetzt werden, findest du in der Übersicht der Kenntnisse für ein KI-Praktikum.
Eine Arbeitsweise, mit der das funktioniert
Sinnvoll ist eine klare Reihenfolge. Erst die Frage schärfen: Was genau soll beantwortet werden, für wen, und welche Entscheidung hängt daran. Dann selbst in die Daten sehen - Zeilenzahl, Zeitraum, offensichtliche Lücken. Erst danach das Werkzeug einsetzen, um schneller zu einem Entwurf zu kommen. Dann prüfen. Dann dokumentieren, was du getan hast, einschließlich der Stellen, an denen du dir unsicher warst.
Wer diese Reihenfolge umdreht und mit dem Werkzeug anfängt, bekommt eine Antwort auf eine Frage, die er nicht gestellt hat. Das ist der häufigste Fehler und der teuerste, weil er erst spät auffällt.
Was das für den Berufseinstieg bedeutet
Die Werkzeugbedienung wird billiger, das Urteil wird teurer. Wer sich früher damit abgehoben hat, dass er SQL beherrscht, hat heute einen kleineren Vorsprung. Wer eine Zahl gegen eine zweite Quelle prüft, bevor er sie weitergibt, hat einen größeren.
Für dich als Einsteiger folgt daraus dreierlei. Erstens: Die Grundlagen bleiben Pflicht, gerade weil du das Ergebnis beurteilen musst. Man kann keinen Entwurf prüfen, den man selbst nicht schreiben könnte. Zweitens: Übe das Gegenrechnen, nicht das Formulieren von Anweisungen. Drittens: Sprich im Gespräch über deine Prüfschritte. Der Satz "Ich nutze das für erste Entwürfe und rechne die Kennzahl anschließend über einen zweiten Weg nach" sagt mehr über dich aus als jede Werkzeugliste.
In der Vorbereitung auf das technische Gespräch ist das inzwischen ein eigenes Thema: Es wird gefragt, wie du mit erzeugtem Code umgehst. Eine ehrliche, differenzierte Antwort ist dort mehr wert als Begeisterung.
Welche Fähigkeiten dadurch wichtiger werden
Vier Dinge gewinnen an Gewicht. Fragen schärfen - aus einem vagen Wunsch der Fachabteilung eine beantwortbare Frage machen. Daten beurteilen - erkennen, wann ein Datensatz die Frage gar nicht hergibt. Ergebnisse erklären - eine Zahl so darstellen, dass die Unsicherheit mitkommt. Sauber arbeiten - nachvollziehbare Abfragen, versionierter Code, dokumentierte Annahmen.
Alle vier sind altmodisch, und keine davon wird gerade billiger. Sie unterscheiden die Rolle des Data Analyst von der Bedienung eines Werkzeugs, und sie sind auch das, was den Übergang in Richtung Data Scientist oder in andere Rollen im Berufsfeld Daten und Analytics offen hält. Was dort jeweils erwartet wird, unterscheidet sich stärker, als die Stellentitel vermuten lassen - der Vergleich der Aufgaben eines Data Scientist macht den Unterschied deutlich.
Wenn du das üben willst, ohne auf ein Praktikum zu warten: Nimm einen offenen Datensatz, lass dir eine Auswertung entwerfen, und schreib anschließend auf, wie du jede einzelne Zahl darin überprüft hast. Dieses zweite Dokument ist das, was du später vorzeigst. Weitere Beiträge zu Werkzeugen und Grundlagen sammelt die Kategorie Skills, passende ausgeschriebene Stellen findest du in der Übersicht der KI-Praktika.
Kurz gefasst
Die Werkzeuge nehmen dir das Tippen ab, nicht das Denken. Wer sie so einsetzt - Entwurf schnell, Prüfung gründlich, Verantwortung ungeteilt - arbeitet spürbar schneller. Wer sie als Ersatz für das eigene Urteil benutzt, produziert Zahlen, die niemand halten kann.
Bereit für den nächsten Schritt?
Setz dein Wissen direkt ein und finde einen freien KI-Praktikum in deiner Nähe – kostenlos und ohne Anmeldung.
KI-Praktika finden
