KI-AkademieModul 5 — Daten, Office und Excel/CSV-Integration

Wissensbasis · UE 59 von 120

Grenzen statistischer Zuverlässigkeit von LLM-Analysen

Modul 5 — Daten, Office und Excel/CSV-Integration ca. 36 Min. Lesezeit

Lernziele

Sie können die vier Klassen von Zuverlässigkeitsproblemen bei LLM-Datenanalysen (Rechenfehler, statistische Fehlinterpretationen, konfabulierte Statistiken, Datums-/Zeitreihenfehler) erklären und an konkreten Beispielen aus dem eigenen Arbeitsbereich identifizieren.

Sie können den Unterschied zwischen Code-Interpreter-basierten Berechnungen (zuverlässig) und rein textbasierter KI-Berechnung (unzuverlässig) erläutern und im praktischen Einsatz unterscheiden.

Sie können die Stichproben-Prüfmethode anwenden: mindestens fünf zufällige Datenpunkte einer KI-Analyse gegen die Originalquelle verifizieren und das Ergebnis dokumentieren.

Sie können für geschäftskritische Analysen ein vierstufiges Validierungsprotokoll (Plausibilitäts-Check, Stichprobe, unabhängige Berechnung, Fachexperten-Review) benennen und anwenden.

Sie können den „Confidence-Überschuss”-Effekt von LLMs beschreiben und konkrete Rückfrage-Techniken einsetzen, um zwischen berechneten und geschätzten KI-Ausgaben zu unterscheiden.

Sie können statistische Grundkonzepte (Mittelwert vs. Median, Stichprobengröße, Konfundierungsvariablen, Simpson’s Paradox) nutzen, um KI-Analyseergebnisse kritisch zu beurteilen.

Auf einen Blick

Dauer45 Min
MethodikInput + Diskussion + Fehler-Analyse-Übung
VorwissenUE 49–58 abgeschlossen; Erfahrung mit Code Interpreter (UE 53)
AI-Act-KompetenzRisiko-Bewusstsein · Grundverständnis (Art. 4 EU AI Act)
QuerverweiseUE 53 (Code Interpreter — zuverlässige Berechnungen), UE 56 (Varianzanalysen — Validierungspflicht), UE 60 (Abschlussübung mit Validierungsstichprobe)

Worum geht es? — Der didaktische Einstieg

Stellen Sie sich vor: Ein Mitarbeiter im Controlling hat mit ChatGPT Advanced Data Analysis eine Varianzanalyse des Quartalsabschlusses erstellt. Die Analyse sieht professionell aus — sauber formatierte Tabellen, ein Wasserfalldiagramm, sachliche Kommentare. Er leitet sie an die Geschäftsführung weiter. Zwei Tage später fällt auf: Der ausgewiesene Gesamtumsatz weicht um 12 % vom tatsächlichen Wert ab. Die KI hatte einen Aggregationsfehler erzeugt — sie hatte bei einer CSV-Datei mit 80.000 Zeilen nur die ersten 40.000 verarbeitet (Silent Truncation) und den Rest ohne Warnung ignoriert. Das professionelle Erscheinungsbild des Outputs hatte den Fehler vollständig verdeckt.

Dieses Szenario ist kein Extremfall. Es illustriert das zentrale Problem dieser UE: LLMs sind keine Statistik-Engines. Sie erzeugen plausibel klingende Outputs — auch wenn die zugrundeliegende Berechnung fehlerhaft ist. Der Unterschied zu einem klassischen Rechenfehler in Excel ist fundamental: In Excel sieht man die Formel, den Zellbezug, den Zwischenwert — und kann jeden Schritt nachvollziehen. Bei einer KI-Analyse ist die „Formel” unsichtbar. Es sei denn, man nutzt den Code Interpreter, dessen Python-Code einsehbar und prüfbar ist.

Diese UE gibt Ihnen die Werkzeuge, um KI-Analysen systematisch zu validieren, die riskantesten Situationen zu erkennen und ein persönliches Validierungs-Protokoll zu entwickeln, das in der täglichen Praxis handhabbar ist.

Lerntext — Theorie und Konzepte

LLMs sind keine Statistik-Engines — der grundlegende Unterschied

Große Sprachmodelle wurden auf Text trainiert — nicht auf Zahlen als mathematische Objekte. Wenn ein LLM eine Berechnung durchführt, geschieht das auf zwei grundlegend verschiedene Weisen:

Weg 1 — Code Interpreter (zuverlässig): Das Modell generiert Python-Code (z. B. mit pandas oder numpy), der in einer isolierten Sandbox-Umgebung tatsächlich ausgeführt wird. Das Ergebnis ist der Output des Python-Codes — nicht des Sprachmodells selbst. Dieser Weg ist für Berechnungen zuverlässig, weil Python mathematisch exakt rechnet. Die Fehlerquellen liegen hier beim generierten Code (falsche Logik) und bei der Interpretation der Ergebnisse — nicht bei der numerischen Berechnung selbst.

Weg 2 — Textwahrscheinlichkeits-Logik (unzuverlässig): Ohne Code-Ausführung verarbeitet das Modell Zahlen als Tokens — ähnlich wie Silben eines Wortes. Die Wahrscheinlichkeit, das „richtige” Token zu erzeugen (also die korrekte nächste Ziffer), sinkt bei komplexen Berechnungen erheblich. Mehrstellige Multiplikationen, Summen über viele Positionen, Prozentberechnungen mit mehreren Nachkommastellen — all das kann ohne Code-Ausführung fehlerhaft sein.

Das kritische Problem: Für Nutzende ist oft nicht erkennbar, ob die KI gerade Code ausführt oder „schätzt”. Das Ergebnis sieht in beiden Fällen gleich aus — formatiert, in einer Tabelle, mit zwei Nachkommastellen. Nur der aufmerksame Blick auf das Code-Interpreter-Symbol (das Python-Logo in ChatGPT) zeigt, ob tatsächlich Code ausgeführt wurde.

Merksatz

Code Interpreter rechnet mit Python — mathematisch exakt, nachvollziehbar, der Code ist sichtbar und prüfbar. LLM-Textmodus „schätzt” Zahlen auf Basis von Sprachwahrscheinlichkeiten — unzuverlässig bei komplexen Berechnungen. Regel für quantitative Analysen: Immer Code Interpreter einschalten und zu Beginn die Zeilenanzahl des Datensatzes bestätigen lassen.

Die vier Klassen von Zuverlässigkeitsproblemen

Klasse 1 — Rechenfehler bei komplexen numerischen Operationen:

Ohne Code Interpreter kann ChatGPT bei mehrstelligen Berechnungen Fehler machen. Erkennbar an: ungewöhnlich runden Zwischenergebnissen (z. B. exakt 15.000 statt 15.984), Abweichungen beim manuellen Nachrechnen einer einzelnen Position, fehlender Konsistenz zwischen Teilsummen und der Gesamtsumme.

Konkretes Beispiel: „Was ist 87.345 × 0,183?” — Ohne Code-Ausführung kann das Ergebnis leicht 15.000 statt 15.984,135 lauten. Mit Code Interpreter: exakt 15.984,135.

Typisches Risikoszenario: Ein Analyst fragt ChatGPT im Textmodus nach der Gesamt-Marge über 50 Projekte — ohne Code Interpreter. Die KI summiert die Margen-Werte als Text-Tokens und kann dabei Fehler machen, die die Gesamtsumme um 5–15 % verfälschen. Bei einem Report mit 50 Projekten ist das nicht manuell nachrechenbar — die Stichprobenprüfung deckt es auf.

Klasse 2 — Statistische Fehlinterpretationen:

LLMs können Korrelation und Kausalität verwechseln, Stichprobenprobleme ignorieren oder Aggregations-Ebenen durcheinanderbringen. Das bekannteste Beispiel ist Simpson’s Paradox — wenn eine Teilgruppe einen Trend zeigt, der sich in der Gesamtgruppe umkehrt. KI erkennt dieses Muster nicht automatisch und berichtet den Teilgruppen-Trend als eindeutige Erkenntnis.

Weiteres Beispiel: „Der Umsatz in Region Nord ist in allen drei Quartalen gestiegen” — stimmt für die Aggregation, aber Region Nord hat gleichzeitig drei neue Großkunden gewonnen. Der Vergleich mit dem Vorjahr ist ohne diese Information verzerrt. Die KI kommentiert den Trend, ohne auf den Strukturwechsel hinzuweisen — weil sie ihn nicht kennt.

Klasse 3 — Konfabulierte Statistiken (Halluzinationen):

Wenn nach Benchmarks, Branchenwerten oder historischen Daten gefragt wird und kein Datenmaterial hochgeladen wurde, kann die KI plausibel klingende, aber falsche Zahlen „erfinden”. Diese Konfabulationen klingen überzeugend, weil sie das Format valider Statistiken imitieren — mit Jahreszahl, Quelle, prozentualen Angaben.

Typisches Szenario: „Wie ist die durchschnittliche Projektmarge im IT-Consulting in Deutschland 2024?” — Ohne Quelldaten liefert die KI eine Schätzung, die sie als Faktum formuliert: „IT-Consulting-Unternehmen in Deutschland weisen typischerweise Projektmargen zwischen 18 und 28 % aus.” Diese Zahl ist nicht verifiziert — sie ist eine Extrapolation aus Trainingstexten. Schutzregel: Niemals KI-generierte Benchmarks ohne verifizierte Quellenangabe verwenden.

Klasse 4 — Datums- und Zeitreihenfehler:

Sortierung, Monatsgrenzen, Schalttage, Kalenderwochen, Zeitzonendifferenzen — bei komplexen Datumsbedingungen in CSV-Analysen treten regelmäßig Fehler auf. Das häufigste Problem: Das Datumsformat im CSV-Datensatz (DD.MM.JJJJ) wird vom Code Interpreter als MM/DD/YYYY interpretiert, was zu Datumsverwechslungen führt (der 03.04.2025 wird als 3. April statt 4. März eingelesen). Die Auswirkung: Eine Q1-Analyse schließt fälschlicherweise Märzdaten ein oder aus.

Schutzregel: Immer das erkannte Datumsformat bestätigen lassen. Prompt nach dem Upload: „Wie hat Python das Datumsformat in der Spalte ‘Datum’ interpretiert? Zeige mir drei Beispiel-Datumswerte und das erkannte Format.”

Diagramm aus der KI-Wissensbasis

Abb. 59.1 — Validierungs-Workflow für KI-Datenanalysen

Die Stichproben-Prüfmethode — der praktische Mindeststandard

Die effektivste und schnellste Validierungsmethode für KI-Analysen ist die Stichprobenprüfung:

Wählen Sie fünf zufällige Datensätze aus dem Originaldatensatz. Wichtig: Wirklich zufällig — nicht die „schönen” Normalfälle, sondern auch Projekte mit fehlenden Werten, ungewöhnlich hohen oder niedrigen Werten, oder Datensätze am Rand des Datumsbereichs.

Berechnen Sie für diese fünf Datensätze das Ergebnis manuell (oder mit einer einfachen Excel-Formel direkt aus dem Original-CSV).

Vergleichen Sie Ihr Ergebnis mit dem KI-Output für dieselben fünf Datensätze (Zeilennummern explizit anfragen: „Zeige mir die Berechnung für die Zeilen 47, 112, 289, 503, 781”).

Wenn alle fünf übereinstimmen: hohe Wahrscheinlichkeit, dass die Logik korrekt ist. Kein 100 %-Beweis, aber ausreichender Mindeststandard.

Wenn eine oder mehr abweichen: Fehlerklasse identifizieren (welche der vier Klassen?), Prompt korrigieren, Neuanalyse anfordern und erneut stichprobenprüfen.

Diese Methode dauert 5–10 Minuten und identifiziert die meisten systematischen Fehler. Sie ist kein Ersatz für die vollständige Validierung bei sehr kritischen Analysen — aber ein praktischer Mindeststandard für alle KI-Analysen, die in Berichte oder Entscheidungen einfließen.

Der „Confidence-Überschuss”-Effekt — und wie man damit umgeht

LLMs tendieren dazu, Aussagen mit hoher Gewissheit zu formulieren — auch wenn die Datenlage unsicher ist. Eine KI schreibt selten „ich bin mir nicht sicher, ob diese Zahl stimmt” — sie schreibt einfach die Zahl, im selben Ton wie eine sichere Aussage. Dieser Effekt ist ein bekanntes Charakteristikum großer Sprachmodelle und hat seinen Ursprung in der Art des Trainings: Texte, die für Training genutzt wurden, enthalten überwiegend Aussagen, die jemand mit Überzeugung formuliert hat.

Konkrete Rückfrage-Techniken:

Technik 1 — Code-Bestätigung anfragen: „Hast du für diese Berechnung Python-Code ausgeführt oder die Zahl direkt berechnet? Zeige mir den Python-Code, den du für diese Berechnung verwendet hast.”

Technik 2 — Quellenbeleg für einzelne Zahlen: „Welche Zeile im Originaldatensatz belegt diesen Wert von [Zahl]? Zeige mir den entsprechenden Zeilenwert aus dem hochgeladenen Datensatz.”

Technik 3 — Unsicherheitsgrade anfragen: „Für welche der ausgewiesenen Kennzahlen bist du dir sicher, und für welche könntest du Fehler gemacht haben? Klassifiziere jede Kennzahl in: (a) berechnet mit Python-Code — verlässlich, (b) berechnet ohne Python — mögliche Fehler.”

Diese Rückfragen klingen aufwändig — sind es aber nicht. Sie dauern je ca. 30 Sekunden und liefern in vielen Fällen unmittelbar Klarheit, ob ein Ergebnis sicher oder unsicher ist.

Merksatz

KI klingt immer sicher — auch wenn sie falsch liegt. Die drei Rückfrage-Techniken (Code-Bestätigung, Quellenbeleg, Unsicherheitsgrad) sind einfache, schnelle Schutzmaßnahmen gegen den Confidence-Überschuss-Effekt. Sie kosten 30 Sekunden und können einen gravierenden Fehler in einem Management-Report verhindern.

Zuverlässige vs. unzuverlässige Szenarien

SzenarioZuverlässigkeitEmpfehlung
Code Interpreter: Summe, Mittelwert, ZählungHochStichprobenprüfung ausreichend
Code Interpreter: Pivot-AggregationHochStichprobenprüfung + Datumsformat prüfen
Code Interpreter: Lineare RegressionMittelMethoden-Plausibilität + Code-Logik prüfen
Code Interpreter: >50.000 Zeilen DateiMittelZeilenanzahl nach Upload bestätigen
Rein textbasiert: einfache MultiplikationMittelManuell nachrechnen
Rein textbasiert: komplexe BerechnungenNiedrigNiemals ohne Code Interpreter
KI-Benchmarks ohne hochgeladene DatenSehr niedrigNie ohne verifizierte Quelle verwenden
Statistische SignifikanzaussagenNiedrigFachexperten-Review obligatorisch

Statistische Grundlagen für kritisches KI-Denken

Mittelwert vs. Median: Der Mittelwert ist anfällig für Ausreißer. Wenn 9 Projekte eine Marge von 15 % haben und ein Projekt eine Marge von 85 % (Ausreißer), liegt der Mittelwert bei ca. 22 %, der Median aber bei 15 %. Die KI verwendet standardmäßig den Mittelwert — ohne zu prüfen, ob er bei der vorliegenden Verteilung aussagekräftiger ist als der Median. Kritische Rückfrage: „Zeige mir sowohl Mittelwert als auch Median für [Metrik]. Gibt es Ausreißer, die den Mittelwert stark beeinflussen?”

Stichprobengröße und statistische Signifikanz: Eine KI kann schnell Aussagen wie „Region Nord hat die höchste Marge” generieren. Wenn Region Nord aber nur drei Projekte umfasst, ist dieser Unterschied möglicherweise statistisch nicht signifikant — ein Zufallsergebnis bei kleiner Stichprobe. Kritische Rückfrage: „Wie viele Datenpunkte liegen der Aussage für jede Gruppe zugrunde? Ab welcher Stichprobengröße wäre der Unterschied statistisch signifikant?”

Konfundierungsvariablen: Ein scheinbarer Zusammenhang zwischen zwei Variablen kann durch eine dritte, unbeobachtete Variable vollständig erklärt werden. Beispiel: KI analysiert, dass Projekte mit mehr als 5 Teammitgliedern eine niedrigere Marge haben. Mögliche Konfundierungsvariable: Große Teams werden für komplexere Projekte eingesetzt — und Komplexität, nicht Teamgröße, erklärt die niedrigere Marge. Kritische Rückfrage: „Gibt es andere Variablen im Datensatz, die sowohl mit Teamgröße als auch mit Marge korrelieren könnten?”

Simpson’s Paradox: Wenn aggregierte Trends einzelnen Teilgruppen widersprechen. Bekanntes Beispiel: In einem Datensatz sind Männer im Durchschnitt häufiger befördert worden als Frauen — aber in jeder einzelnen Abteilung wurden Frauen häufiger befördert als Männer. Der paradoxe Effekt entsteht durch unterschiedliche Gruppengrößen. KI berichtet das Aggregat, nicht den Widerspruch. Schutzregel: Immer nach Teilgruppen-Aufteilung fragen, bevor Aggregatwerte interpretiert werden.

Vertiefung — Das Validierungs-Ökosystem

Keine einzelne Validierungsmethode ist allein ausreichend für geschäftskritische Analysen. Ein robustes Validierungs-Ökosystem kombiniert vier Ebenen:

Ebene 1 — Plausibilitäts-Check (30 Sekunden): Ergibt das Ergebnis auf den ersten Blick Sinn? Liegt es in einem erwarteten Bereich? Ein ausgewiesener Jahresumsatz von 500 Mio. € für ein 100-Personen-Unternehmen ist sofort unplausibel. Ein Gesamtumsatz, der niedriger ist als der Umsatz der umsatzstärksten einzelnen Region, ist ein Signal für einen Aggregationsfehler. Dieser Check ist schnell und filtert offensichtliche Fehler.

Ebene 2 — Stichprobenprüfung (5–10 Min): Fünf bis zehn zufällige Datenpunkte gegen das Original prüfen — wie oben beschrieben. Identifiziert systematische Fehler in der Berechnungslogik.

Ebene 3 — Unabhängige Berechnung (10–15 Min): Dieselbe Kerngröße (z. B. Gesamtumsatz) auf einem alternativen Weg berechnen — z. B. in Excel mit einer SUMME-Formel direkt aus dem Original-CSV. Wenn beide Werte übereinstimmen, steigt die Sicherheit erheblich.

Ebene 4 — Fachexperten-Review (variabel): Für Analysen, die in strategische Entscheidungen oder externe Berichte einfließen, ist ein Review durch eine Person mit fachlichem Verständnis des Datenkontexts unverzichtbar. Diese Person prüft nicht die Mathematik, sondern die inhaltliche Plausibilität: Macht der Kommentar Sinn? Fehlt ein wichtiger Kontext? Wurde eine relevante Teilgruppe nicht berücksichtigt?

Prompt-Bibliothek — Validierung

Zeilenzahl bestätigen (immer allererster Prompt nach Upload): „Wie viele Zeilen und Spalten enthält dieser Datensatz? Zeige mir die ersten 5 Zeilen und die letzten 5 Zeilen, damit ich die Vollständigkeit des Imports prüfen kann.”

Datumsformat bestätigen: „Wie hat Python das Datumsformat in der Spalte ‘[Spaltenname]’ interpretiert? Zeige mir drei Beispiel-Datumswerte: den kleinsten, den größten und einen mittleren Wert. In welchem Format wurden sie erkannt?”

Code-Ausführung bestätigen: „Hast du für diese letzte Berechnung Python-Code ausgeführt? Zeige mir den vollständigen Python-Code, den du verwendet hast. Wenn kein Code ausgeführt wurde, wiederhole die Berechnung mit Code Interpreter.”

Stichproben-Validierung: „Zeige mir die detaillierte Berechnung (Schritt für Schritt) für die Zeilen mit den Indizes [Zahl 1, Zahl 2, Zahl 3, Zahl 4, Zahl 5] aus dem hochgeladenen Datensatz. Ich möchte diese Ergebnisse manuell prüfen können.”

Benchmark-Quelle anfragen: „Auf welche Quelle stützt du dich für die Zahl [Zahl]? Stammt sie aus den hochgeladenen Daten oder ist es eine allgemeine Schätzung auf Basis deines Trainingsdatensatzes?”

Unsicherheitsgrad anfragen: „Für welche der ausgewiesenen Kennzahlen bist du sicher (berechnet mit Python-Code), und für welche könnten Fehler vorliegen (ohne Code, oder bei komplexen Bedingungen)? Klassifiziere jede Kennzahl explizit.”

Branchen-Anwendungen

IT-Dienstleistung & Beratung

Bei Kunden-Reporting und internem Controlling sind Zahlenfehler besonders kritisch: Ein falscher Umsatzwert im Kunden-Report beschädigt das Vertrauen in die Projektarbeit. Ein fehlerhafter Forecast führt zu falschen Ressourcenentscheidungen, die monatlich lange Korrekturen nach sich ziehen.

Die empfehlenswerte Praxis: Definieren Sie für jeden regelmäßigen Report drei „kritische Zahlen” — die Werte, bei denen ein Fehler die größten Konsequenzen hätte. Für einen Kunden-Report sind das typischerweise: der ausgewiesene Gesamtumsatz je Abrechnungsperiode, die dargestellte Marge je Projekt, der ausgewiesene Ressourcenaufwand (Stunden). Diese drei Zahlen werden bei jedem Report manuell gegen die Originalquelle verifiziert — unabhängig davon, ob KI oder Excel für die Analyse genutzt wurde.

Besonderer Fallstrick im Consulting: Der „Silent Truncation Error” — bei Datensätzen über 50.000 Zeilen kann ein LLM ohne Code Interpreter den Datensatz im Hintergrund abschneiden, ohne Warnung. Die Gesamtsumme ist dann nur ein Teilwert. Schutzmaßnahme: Immer mit Zeilenzahl-Bestätigung beginnen. Wenn die bestätigte Zeilenzahl nicht mit der bekannten Dateigröße übereinstimmt: Datei erneut hochladen oder in kleinere Chunks aufteilen.

Industrie & Fertigung

In der Qualitätssicherung ist die Fehlerquoten-Analyse eine zentrale KI-Anwendung. Typischer Validierungsfall: Bei einer automatisierten Analyse der Ausschussquoten nach Fertigungslinie muss sichergestellt werden, dass die Aggregation korrekt ist — insbesondere wenn verschiedene Produkte unterschiedliche Ziel-Ausschussquoten haben (kein einheitlicher Benchmark).

Klasse-2-Fehler (statistische Fehlinterpretation) ist im Fertigungsumfeld besonders relevant: Wenn Linie A in einem Monat 10 % der Gesamtproduktion verantwortet, aber 60 % der Ausschussmenge — ist das ein systemisches Linienproblem oder ein Zufallsbefund bei kleiner Stichprobe in diesem Monat? Die KI zeigt die Abweichung, aber die Interpretation erfordert Fertigungs-Fachwissen und Zeitreihen-Kontext (War Linie A auch in den Vormonaten auffällig?).

Klasse-4-Fehler (Zeitreihenfehler) ist im Fertigungsumfeld ebenfalls häufig: MES-Exporte enthalten oft Timestamps mit Millisekunden oder andere spezielle Datumsformate, die Python beim CSV-Import falsch interpretiert. Datumsformat immer explizit bestätigen lassen.

Finanzdienstleistung & Versicherung

Im Finanzsektor ist die Qualität von Analyseergebnissen direkt regulatorisch relevant: Fehlerhafte Zahlen in Risiko-Reports oder Aufsichtsmeldungen können zu aufsichtsrechtlichen Maßnahmen und Bußgeldern führen. Daher gilt hier das strengste Validierungsregime: Immer Code Interpreter, immer Stichprobenprüfung, immer unabhängige Berechnung der Kerngröße, und für externe Berichte immer Fachexperten-Review (Ebene 4).

Besonders kritisch ist Klasse 3 (konfabulierte Statistiken) bei Markt-Benchmarks: Wenn KI-generierte Branchenzahlen ohne verifizierte Quellenangabe in Aufsichtsdokumenten erscheinen, ist das ein erhebliches Compliance-Risiko. Internes Protokoll empfehlenswert: Jede Zahl in einem externen Bericht muss eine verifizierte Quellenangabe haben — KI darf als Analysewerkzeug, nicht als Quellenersatz eingesetzt werden.

Für regulatorische Berichte: Eine explizite Notation empfehlenswert, welche Berechnungen KI-gestützt und welche manuell durchgeführt wurden — für interne Revisionen und mögliche Rückfragen der Aufsichtsbehörde.

Öffentliche Verwaltung

In der öffentlichen Verwaltung sind Zahlen in offiziellen Berichten häufig öffentlich einsehbar und politisch sensitiv. Ein fehlerhafter Wert in einem statistischen Jahresbericht oder einem Haushaltsplan kann zu parlamentarischen Anfragen führen und das Vertrauen in die Behörde beeinträchtigen.

Validierungspflicht: Alle Zahlen, die in offizielle Berichte einfließen, müssen mit den entsprechenden Amtsstatistiken (Statistisches Bundesamt, Statistische Landesämter) oder den Quellsystemen abgeglichen werden. KI-generierte Benchmarks (z. B. „der Bundesdurchschnitt für diese Kennzahl beträgt…“) müssen durch verifizierte Destatis- oder Eurostat-Daten ersetzt werden.

Vorteil: Destatis und Eurostat bieten API-Zugänge (GENESIS-Online, Eurostat REST API), über die offizielle Vergleichsdaten direkt in Code-Interpreter-Workflows eingebunden werden können — ohne manuelle Abschrift und damit ohne Abschreibfehler.

Übung 1 — Fehler finden: KI-Analyse mit eingebautem Fehler

Übung 1

Aufgabe: Sie erhalten eine beschriebene KI-generierte Analyse mit zwei eingebauten Fehlern. Identifizieren Sie die Fehler durch systematische Stichprobenprüfung und benennen Sie die Fehlerklasse.

Material: Handout mit der fehlerhaften KI-Analyse und fünf Originaldatenpunkten zur Prüfung, Taschenrechner oder Excel.

KI-Analyse (fehlerhaft): „Die Gesamtauslastung für Q3 beträgt 87 %. Die durchschnittliche Projektlaufzeit liegt bei 42 Tagen. Das Segment ‘Enterprise’ weist die höchste Marge mit 28 % aus. Die Ressourcenauslastung wurde auf Basis aller 45 Mitarbeitenden berechnet.”

Originaldaten (Auszug aus 5 Datenpunkten für Stichprobe): - Mitarbeitender 1: 152 gebuchte Stunden von 168 verfügbaren = 90,5 % - Mitarbeitender 2: 0 gebuchte Stunden (krank / kein Projekt) — aus Analyse ausgeschlossen? - Mitarbeitender 7: 88 gebuchte Stunden von 168 = 52,4 % - Segment Enterprise: Projekt A (Marge 32 %), Projekt B (Marge 18 %), Projekt C (Marge 34 %) — Stundensatz 80 €/h im Datensatz - Korrekte Stundensatz-Information: 95 €/h (aktueller Rahmenvertrag seit Q2)

Schritt-für-Schritt: 1. Berechnen Sie die Auslastungsquote für die drei Mitarbeitenden manuell. 2. Was passiert, wenn Mitarbeitende mit 0 Stunden (krank, kein Projekt) ausgeschlossen werden? Vergleichen Sie mit der KI-Aussage von 87 %. 3. Berechnen Sie die Marge für Segment Enterprise mit dem korrekten Stundensatz von 95 €/h. 4. Vergleichen Sie mit dem KI-Ergebnis von 28 %. 5. Benennen Sie für jeden Fehler: Fehlerklasse (1–4), mögliche Ursache, korrekter Wert.

Musterlösung: - Fehler 1 (Auslastungsquote): KI hat Mitarbeitende mit 0-Stunden-Buchungen aus der Berechnung ausgeschlossen (statt als 0 zu behandeln). Mit allen 45 Mitarbeitenden inklusive der 0-Stunden-Fälle: tatsächliche Gesamtauslastung ca. 79 %. Fehlerklasse 2 (statistische Fehlinterpretation — falsche Behandlung fehlender Werte). - Fehler 2 (Segment-Marge): KI hat den veralteten Stundensatz von 80 €/h aus dem Datensatz verwendet statt des aktuellen Satzes von 95 €/h. Korrekter Enterprise-Marge-Wert: ca. 24 % statt 28 %. Fehlerklasse 1 (Rechenfehler durch falsche Datenannahme). Hinweis: Dieser Fehler hätte durch Datenvorbereitung (aktuellen Stundensatz im Datensatz hinterlegen) verhindert werden können.

Übung 2 — Persönliches Validierungs-Protokoll entwickeln

Übung 2

Aufgabe: Entwickeln Sie ein persönliches Validierungs-Protokoll für KI-Datenanalysen in Ihrem eigenen Arbeitsbereich. Das Protokoll besteht aus: Analyse-Typ, kritische Zahlen (max. 3), Validierungsmethode pro Zahl, akzeptable Abweichungstoleranz, fünf-Punkte-Checkliste.

Schritt-für-Schritt: 1. Wählen Sie eine KI-Analyse-Aufgabe, die Sie in den nächsten Wochen umsetzen möchten oder die in Ihrem Arbeitsbereich regelmäßig vorkommt. 2. Identifizieren Sie drei „kritische Zahlen” für diese Aufgabe — die Werte, bei denen ein Fehler die größten Konsequenzen hätte (falscher Report an Kunden, falsche Entscheidungsgrundlage). 3. Legen Sie für jede kritische Zahl die passende Validierungsmethode fest (Stichprobenprüfung, manuelle Berechnung, zweites Tool, Fachexperten-Review). 4. Definieren Sie eine akzeptable Abweichungstoleranz: Wie viel Prozent Abweichung ist noch tolerierbar, bevor der Report nicht versandt wird? 5. Schreiben Sie das Protokoll als Checkliste mit fünf Punkten. 6. Tauschen Sie Ihr Protokoll in Zweier-Teams aus. Ist die Abweichungstoleranz realistisch und ausreichend streng? Fehlt ein kritischer Prüfpunkt?

Musterlösung (Monatlicher Plan-Ist-Vergleich für Projektmargen): Kritische Zahlen: (1) Gesamtmarge Monat (aggregiert), (2) Marge des umsatzstärksten Projekts, (3) Ressourcenauslastung gesamt. Validierungsmethode: (1) Stichprobenprüfung (5 Projekte) + manuelle Excel-Pivotprüfung, (2) Vollständige manuelle Berechnung (ein Projekt), (3) Stichprobenprüfung (5 Mitarbeitende). Abweichungstoleranz: ≤ 0,5 % bei Margen (externer Bericht), ≤ 2 % bei Auslastungsquoten (interner Bericht). Checkliste: (1) Code Interpreter verwendet (nicht Textmodus)? (2) Zeilenanzahl nach Upload bestätigt? (3) Fünf zufällige Datenpunkte gegen Original geprüft? (4) Gesamtmarge manuell verifiziert (Excel-Summe aus Original-CSV)? (5) Datumsbereich korrekt (Q1 = 01.01.–31.03.)?

Cheat-Sheet — UE 59

PunktMerksatz
Code Interpreter = zuverlässigPython-Ausführung rechnet exakt — LLM-Textmodus rechnet nicht zuverlässig
Zeilenzahl immer bestätigenErster Prompt nach jedem Upload: Wie viele Zeilen?
5 Stichproben nach jeder AnalyseEinfachste und schnellste Validierungsmethode — obligatorisch
Konfabulierte BenchmarksNie KI-generierte Branchenzahlen ohne verifizierte Quellenangabe verwenden
Confidence-ÜberschussKI klingt immer sicher — fragen: „Code oder Schätzung?”
Kritische Zahlen definierenMaximal 3 Zahlen pro Report, die immer manuell verifiziert werden
Simpson’s ParadoxAggregate können Teilgruppen-Trends verschleiern — immer segmentieren
Datumsfehler sehr häufigDatumsformat immer explizit nach Upload bestätigen lassen

Reflexionsfragen

Haben Sie in der Vergangenheit KI-Analyseergebnisse ohne systematische Validierung verwendet? Was hätte passieren können — und was war Ihr größtes Glück?

Wie unterscheidet sich die Validierungspflicht für eine interne Schätzung, die nur für Ihre eigene Planung genutzt wird, von einer Zahl, die in einen Kunden-Report oder eine Aufsichtsmeldung einfließt?

Der Code Interpreter führt Python-Code aus — das Ergebnis ist rechnerisch korrekt. Aber die Logik des Codes kann trotzdem falsch sein (z. B. falsche Aggregations-Ebene, falsches Datumsformat). Wie erkennen Sie Code-Logik-Fehler, ohne Python zu beherrschen?

Welche der vier Fehlerklassen ist in Ihrem Arbeitsbereich am wahrscheinlichsten — und warum? Welche Schutzmaßnahme adressiert genau diese Klasse?

Wie verändert das Wissen über die vier Fehlerklassen Ihren Umgang mit KI-Analysen in der täglichen Praxis — konkret: Was machen Sie ab morgen anders?

Vertiefung — Der Validierungs-Werkzeugkasten: Fünf Methoden für unterschiedliche Analysezwecke

Nicht jede Analyse braucht dieselbe Validierungsmethode. Hier fünf Methoden, abgestimmt auf häufige Anwendungsfälle:

Methode 1 — Stichprobenprüfung (universell): 5 zufällige Datenpunkte manuell gegen Original prüfen. Zeitaufwand: 5–10 Minuten. Eignet sich für: alle Analysen, immer als Basisvalidierung.

Methode 2 — Plausibilitäts-Benchmarking: Analyseergebnis mit bekannten Benchmark-Werten vergleichen (z. B. Branchendurchschnitt, Vorjahreswert, eigene Erwartung). Zeitaufwand: 2 Minuten. Eignet sich für: Kennzahlen-Berechnungen, Forecast-Ergebnisse.

Methode 3 — Kreuz-Validierung mit zweitem Tool: Dieselbe Analyse mit einem anderen Tool durchführen (z. B. Code Interpreter + Excel-Pivot) und Ergebnisse vergleichen. Zeitaufwand: 15–30 Minuten. Eignet sich für: kritische Zahlen in externen Reports.

Methode 4 — Unit-Test-Ansatz: Bekannte Testdatensätze mit bekanntem Ergebnis verwenden, um den Analyse-Prompt zu testen. Zeitaufwand: 20–30 Minuten einmalig (Setup), dann sekunden-schnell. Eignet sich für: wiederkehrende standardisierte Analysen.

Methode 5 — Peer-Review: Ein Kollege prüft die Analyse-Ergebnisse mit frischem Blick, ohne die KI-Prompts zu kennen. Zeitaufwand: 15–20 Minuten. Eignet sich für: hochkritische Management-Entscheidungen.

Vertiefung — Statistische Fehler in KI-Analysen kommunizieren: Wie Sie Unsicherheit transparent machen

Das größte Problem bei KI-Analysen in Unternehmenskontexten ist nicht die Analyse selbst — es ist die Kommunikation ihrer Unsicherheit. „Die Analyse zeigt 23 %” klingt präziser als „Die Analyse schätzt 23 %, Konfidenzintervall 19–27 %“. Aber die erste Aussage ist irreführend, wenn die Unsicherheit tatsächlich hoch ist.

Unsicherheits-Kommunikationsstandards für KI-Analysen:

Für Punkt-Schätzungen: Immer Konfidenzbereich angeben oder explizit die Annahmen nennen, unter denen die Schätzung gilt.

Für Forecasts: Drei-Szenario-Darstellung (Base/Best/Worst Case) plus eine explizite Liste der wichtigsten Annahmen.

Für Korrelationsanalysen: Immer angeben: Stichprobengröße, Konfidenzintervall des Korrelationskoeffizienten, Kausalitäts-Hinweis.

Für Gruppenvergleiche: Immer angeben: Stichprobengrößen beider Gruppen, statistisches Testverfahren, p-Wert oder Konfidenzintervall der Differenz.

Erweiterte Reflexionsfragen — UE 59

Welchen Validierungsstandard werden Sie für Ihren häufigsten Analyse-Typ festlegen — und wie werden Sie sicherstellen, dass Sie diesen Standard auch unter Zeitdruck einhalten?

Wie würden Sie erklären, warum auch ein rechnerisch korrektes Code-Interpreter-Ergebnis falsch sein kann?

Was wäre die eine Maßnahme, die die statistische Zuverlässigkeit Ihrer KI-Analysen am stärksten verbessern würde — und warum setzen Sie sie noch nicht um?

Prompt-Vorlage — Validierungs-Zusammenfassung für den Analyse-Brief

Prompt: Validierungs-Abschnitt für den Analyse-Brief

„Ich habe eine Datenanalyse mit Code Interpreter durchgeführt. Erstelle mir den Validierungs-Abschnitt für meinen Analyse-Brief, basierend auf folgenden Validierungsschritten:

Durchgeführte Validierungen: - Stichprobenprüfung: [Anzahl geprüfter Datenpunkte, Ergebnis: korrekt/Abweichungen gefunden] - Plausibilitätsprüfung: [Vergleich mit Benchmarks, Ergebnis] - Aggregationsprüfung: [Summen-Check, Ergebnis]

Bekannte Einschränkungen: - [z. B. Fehlende Werte in X % der Zeilen, Zeitraum nur 12 Monate, Stichprobengröße bei Subgruppenanalysen]

Formuliere einen Validierungs-Abschnitt (max. 80 Wörter) für einen Management-Report: Was wurde validiert? Was wurde nicht validiert? Welche Schlussfolgerungen sind mit hoher Sicherheit belegt, welche sind Schätzungen?”

Vertiefung — Statistische Signifikanz für Nicht-Statistiker

KI-Analysen berechnen Mittelwerte und Trends — aber liefern selten automatisch Hinweise auf statistische Signifikanz.

Das Problem: Wenn der Analyse-Bericht sagt „Region Nord hat 12 % mehr Umsatz als Region Süd” — ist dieser Unterschied statistisch belastbar oder zufallsbedingt?

Einfache Faustregeln für die Praxis: - Stichprobengröße < 30: Keine verlässlichen statistischen Aussagen — Trend, keine Tatsache. - Stichprobengröße 30–100: Moderate Belastbarkeit — Formulierung: „Tendenz erkennbar, noch nicht statistisch gesichert.” - Stichprobengröße > 100: Erste statistische Belastbarkeit — aber Ausreißer-Check immer noch nötig.

KI-Prompt für Signifikanz-Check: „Ich habe folgendes Analyseergebnis: [Ergebnis]. Meine Stichprobengröße beträgt [N]. Ist dieser Unterschied statistisch signifikant? Führe einen geeigneten Test durch und erkläre das Ergebnis in nicht-statistischer Sprache für ein Management-Publikum.”

Übung 6 — Fehlerklassen in der Praxis: Analyse-Audit durchführen

Aufgabe: Führen Sie ein systematisches Audit einer eigenen oder Kurs-Analyse durch.

Audit-Checkliste (vier Fehlerklassen): 1. Klasse 1 (Rechenfehler): Prüfen Sie 3 Zahlenwerte manuell nach. 2. Klasse 2 (Logikfehler): Ergibt die Interpretationsrichtung Sinn? 3. Klasse 3 (Halluzination): Gibt es Aussagen ohne Datengrundlage? 4. Klasse 4 (Stichprobenproblem): Wie groß ist die Stichprobe? Welche Subgruppen sind unterrepräsentiert?

Ergebnis: Für jede gefundene Abweichung: Fehlerklasse benennen, Korrekturprompt formulieren, Ergebnis nach Korrektur notieren.

Zeit: 25 Minuten

Erweiterte Reflexionsfragen — UE 59 (Fortsetzung)

Wie würden Sie in einem Unternehmen ohne dediziertes Data-Science-Team sicherstellen, dass KI-Analysen regelmäßig auf statistische Belastbarkeit geprüft werden?

Vertiefung — Simpson’s Paradox: Wenn Aggregation täuscht

Das Simpson’s Paradox ist eines der kontraintivsten statistischen Phänomene — und taucht in realen Datensätzen häufiger auf als erwartet:

Beispiel: Eine Analyse zeigt, dass Kunden aus Region A durchschnittlich mehr kaufen als Kunden aus Region B. Wenn man jedoch nach Kundensegment aufteilt, kaufen Kunden aus Region B in jedem Segment mehr. Der scheinbare Vorteil von Region A entsteht nur durch eine ungleiche Verteilung der Segmente.

Wann ist Simpson’s Paradox wahrscheinlich? Immer dann, wenn: - Verschiedene Gruppen unterschiedlich groß sind - Die Gruppen unterschiedliche Basis-Charakteristika haben - Eine Aggregation über diese Gruppen hinweg vorgenommen wird

KI-Prompt zur Erkennung: „Ich habe folgendes Analyse-Ergebnis: [Ergebnis]. Könnte hier ein Simpson’s Paradox vorliegen? Welche Subgruppen-Analysen sollte ich durchführen um das zu prüfen?”

Merksatz

Aggregierte Statistiken können täuschen. Bevor Sie auf Basis von Durchschnittswerten Entscheidungen treffen: Immer nach relevanten Subgruppen aufteilen und prüfen, ob das Muster konsistent bleibt.

Praxis-Tipp — Validierungsprotokoll führen

Führen Sie für jede wesentliche KI-Analyse ein kurzes Validierungsprotokoll:

AnalysePrüfmethodeGeprüfte WerteErgebnisStatus
Umsatz Q15 StichprobenZeilen 12, 45, 78, 102, 156Alle korrekt
Wachstum YoYManuelle BerechnungGesamtsummenKI-Wert: +12,3 %, manuell: +12,1 %✓ (Rundung)

Dieses Protokoll kostet 5 Minuten — und gibt Ihnen die Gewissheit, korrekte Ergebnisse zu kommunizieren.

Quellen

QuelleTypURL
OpenAI: ChatGPT Code Interpreter DokumentationProduktdokuhttps://openai.com/index/chatgpt-plugins/
Towards Data Science: LLM Hallucinations in Data AnalysisFachbeitraghttps://towardsdatascience.com
Destatis — Qualitätsstandards für statistische AnalysenMethodikhttps://www.destatis.de/DE/Methoden/Qualitaet/
EU AI Act Art. 13 — TransparenzanforderungenRechtsquellehttps://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R1689
IBM Research: Measuring Reliability of LLM OutputsForschunghttps://research.ibm.com
Statistisches Bundesamt GENESIS-Online APIDatenquellehttps://www.destatis.de/DE/Service/OpenData/api-webservice.html
Eurostat REST APIDatenquellehttps://ec.europa.eu/eurostat/web/user-guides/data-browser/api-data-access/api-introduction

Vertiefung — Statistische Grundkonzepte für den kritischen KI-Nutzer

Das Verständnis statistischer Grundkonzepte ist für den kritischen Umgang mit KI-Analysen unverzichtbar. Sie müssen kein Statistiker sein — aber einige Konzepte kennen, um KI-Ergebnisse richtig einzuordnen.

Konfidenzintervall vs. Punktschätzung: Ein Konfidenzintervall gibt nicht nur einen Wert, sondern einen Bereich an, in dem der wahre Wert mit einer bestimmten Wahrscheinlichkeit liegt. Statt „Der durchschnittliche Projektumsatz beträgt 85.000 €” bedeutet ein 95 %-Konfidenzintervall: „Mit 95 % Wahrscheinlichkeit liegt der wahre durchschnittliche Projektumsatz zwischen 78.000 € und 92.000 €.” Dieser Bereich ist die ehrlichere Kommunikation von Unsicherheit. Code Interpreter kann Konfidenzintervalle auf Prompt hin berechnen.

P-Wert und statistische Signifikanz: Der P-Wert gibt an, mit welcher Wahrscheinlichkeit das beobachtete Ergebnis rein zufällig entstanden sein könnte, wenn es keinen echten Unterschied gäbe. P < 0,05 gilt konventionell als „statistisch signifikant” — es ist unwahrscheinlich, dass das Ergebnis zufällig ist. Aber: Statistisch signifikant bedeutet nicht unbedingt praktisch bedeutsam (→ UE 53 Vertiefung). Und bei großen Stichproben können extrem kleine, praktisch irrelevante Unterschiede statistisch signifikant werden.

Stichprobengröße und Teststärke: Eine Analyse auf Basis von 20 Datenpunkten ist statistisch viel weniger zuverlässig als eine auf Basis von 2.000 Datenpunkten — aber KI kommuniziert das nicht automatisch. Wenn ein Code-Interpreter-Ergebnis auf einem kleinen Datensatz basiert, sollte immer gefragt werden: „Ist die Stichprobengröße ausreichend, um diesen Unterschied zuverlässig zu erkennen? Führe eine Power-Analyse durch.”

Multikollinearität in Regressionsanalysen: Wenn zwei unabhängige Variablen in einer Regressionsanalyse stark miteinander korreliert sind (Multikollinearität), können die Koeffizienten der Regression instabil und schwer interpretierbar werden. Bei KI-generierten Regressionsanalysen: Immer fragen, ob Multikollinearität geprüft wurde — und wenn ja, mit welchem Ergebnis.

Kausalität vs. Korrelation — der ewige Fehler: KI kann Korrelationen präzise berechnen. Was KI strukturell nicht kann: Kausalität feststellen. Die Aussage „Projekte mit höherem Budget haben höhere Abweichungen — also verursacht ein höheres Budget höhere Abweichungen” ist ein Kausalitätsschluss aus Korrelationsdaten. Es könnte genauso sein, dass komplexere Projekte sowohl höhere Budgets als auch höhere Abweichungen haben, und Komplexität der eigentliche Treiber ist. Für Kausalitätsaussagen braucht man kontrollierte Experimente (Randomized Controlled Trials) oder spezifische ökonometrische Methoden — die nicht aus einer einfachen Korrelationsanalyse folgen.

Vertiefung — Aufbau einer Fehlerkultur für KI-Analysen

Fehler in KI-Analysen zu erkennen und offen zu kommunizieren, erfordert eine Fehlerkultur — eine Organisationskultur, in der Fehler als Lernmöglichkeit betrachtet werden und das Melden eines Fehlers keine negativen Konsequenzen hat.

Incident-Reporting für KI-Analysefehler: Jeder KI-Analysefehler, der in einem Report entdeckt wird, sollte in einem einfachen Incident-Log dokumentiert werden: Datum, Report-Typ, Fehlerklasse (→ vier Fehlerklassen aus UE 59), wie der Fehler entdeckt wurde, welche Auswirkungen er hatte, welche Korrekturmaßnahme eingeleitet wurde. Dieses Log hat drei Vorteile: Es ermöglicht die Mustererkennung (welche Fehlerklasse tritt am häufigsten auf?), es zeigt die Wirksamkeit der Validierungsmaßnahmen (werden Fehler früher entdeckt?), und es ist ein organisatorisches Lernwerkzeug.

Root-Cause-Analyse für wiederholte Fehler: Wenn dieselbe Fehlerklasse regelmäßig auftritt, lohnt eine strukturierte Root-Cause-Analyse: Warum passiert dieser Fehler immer wieder? Ist es fehlende Schulung, ein unklarer Prozess, ein Tool-Problem oder ein Datenproblem? Die 5-Why-Methode (Warum ist das passiert? → Antwort. Warum? → Antwort. Warum? → Antwort. Warum? → Antwort. Warum? → Ursache.) führt systematisch zur Grundursache.

KI-Qualitätssicherungs-Reifegrad: Organisationen entwickeln ihre KI-Qualitätssicherung über Zeit in Stufen: - Stufe 1 (ad hoc): Keine systematische Validierung, Fehler werden zufällig entdeckt. - Stufe 2 (definiert): Stichprobenprüfung als Standard, keine Dokumentation. - Stufe 3 (gemessen): Validierungsprotokoll mit Dokumentation, Fehler-Log. - Stufe 4 (optimiert): Automatisierte Validierungsroutinen, kontinuierliche Verbesserung auf Basis des Fehler-Logs, Fehlerkultur im Team etabliert.

Das Ziel ist Stufe 3 oder 4 für alle Reports, die externe Entscheidungen beeinflussen. Für interne Planungszwecke ist Stufe 2 oft ausreichend.

Merksatz

LLMs sind keine statistischen Berechnungsmaschinen — sie sind Sprachmodelle, die statistische Aussagen in Text übersetzen. Numerische Berechnungen sollten immer durch Code Interpreter (Python/R) oder durch Tabellenkalkulationen gegengeprüft werden. Der Text einer KI-Interpretation kann präzise sein, auch wenn eine eingebettete Zahl falsch ist.

Hinweise für AI Champions — So vermitteln Sie das Thema — UE 59

Zeitplanung (45 Min): - 0–5 Min: Einstieg mit dem konkreten Szenario „Varianzanalyse mit 12 % Fehler durch Silent Truncation” — Frage an Plenum: Wie hätte man das erkennen können? (Keine Auflösung geben — erst nach dem Input.) - 5–18 Min: Input zu den vier Fehlerklassen, Stichproben-Prüfmethode und Confidence-Überschuss-Effekt. Live-Demo: ChatGPT eine einfache Rechenaufgabe ohne Code Interpreter und mit Code Interpreter stellen — Ergebnisvergleich zeigt den Unterschied sofort. - 18–30 Min: Übung 1 — Fehler-Analyse (Einzelarbeit 8 Min, Auflösung in der Gruppe oder allein 4 Min). - 30–42 Min: Übung 2 — Validierungs-Protokoll (Einzelarbeit 8 Min, Zweier-Austausch 4 Min). - 42–45 Min: Zusammenfassung und Ausblick auf UE 60.

Methodische Empfehlung: Die Live-Demo am Anfang (Rechenfehler-Demonstration ohne vs. mit Code Interpreter) ist der didaktisch wirksamste Moment dieser UE. Den Fehler live geschehen lassen — kein vorbereiteter Screenshot, sondern echte Interaktion. Das macht den abstrakten Effekt unmittelbar erlebbar. Anschließend: Code Interpreter aktivieren und denselben Prompt wiederholen — das korrekte Ergebnis erscheint sofort.

Stolpersteine: - Teilnehmende nehmen das Einstiegsszenario als unrealistisch wahr — konkrete eigene oder bekannte Beispiele aus der Praxis ergänzen. Der Silent Truncation Error bei großen Dateien ist besonders real und wenig bekannt. - Die Unterscheidung Code Interpreter vs. Textmodus ist für manche nicht intuitiv — visuell verdeutlichen: Das Python-Symbol in ChatGPT ist das Zeichen, dass Code ausgeführt wird. - Das Validierungs-Protokoll in Übung 2 wird manchmal zu generisch formuliert — auf spezifische Zahlen und konkrete Methoden drängen.

Differenzierung: - Einsteiger: Fokus auf Stichprobenprüfung und die Regel „immer Code Interpreter für Berechnungen”. Fehlerklassen 1 und 3 als wichtigste Beispiele. - Power-User: Statistische Signifikanz, Konfidenzintervalle, Simpson’s Paradox, Differential Privacy als fortgeschrittene Themen.

Vertiefung — Fortgeschrittene Fehlerklassen: Simpson’s Paradox und Aggregations-Fehler

Neben den vier Basisklassen (Halluzination, Silent Truncation, Kontextfenster-Verlust, Code-Logik-Fehler) gibt es zwei fortgeschrittene Fehlerklassen, die besonders tückisch sind, weil sie im Ergebnis plausibel erscheinen:

Simpson’s Paradox: Eine Korrelation, die in der Gesamtgruppe besteht, kann sich in Untergruppen umkehren. Klassisches Beispiel: In einer Beratung scheint KI-Tool A insgesamt besser als Tool B — aber wenn man nach Projekttypen aufschlüsselt, ist Tool B in jedem Projekttyp besser. Das Paradox entsteht, weil Tool A hauptsächlich bei einfachen Projekten eingesetzt wird.

Wenn KI eine Aggregatstatistik präsentiert, die zu gut klingt: Prompt nachfragen — „Zeige diese Analyse aufgeschlüsselt nach [relevante Subgruppe]. Gibt es Untergruppen, in denen das Bild anders ist als im Gesamtergebnis?”

Aggregations-Ebenen-Fehler: KI aggregiert manchmal auf der falschen Ebene. Wenn eine Analyse den „durchschnittlichen Projektumsatz” berechnet, aber manche Projekte mehrere Transaktionen haben, kann KI den Durchschnitt über Transaktionen statt über Projekte berechnen — ein systematischer Fehler, der zu falschen Ergebnissen führt. Prüfung: „Auf welcher Ebene hast du aggregiert? Zeige mir die Anzahl der einzigartigen Projekte vs. die Anzahl der Datenzeilen.”

Prompt-Vorlage — Validierungsprotokoll für KI-Analysen

Prompt: Strukturiertes Validierungsprotokoll

„Ich möchte die Ergebnisse dieser KI-Analyse validieren. Unterstütze mich bei der Validierung mit folgendem Protokoll:

Schritt 1 — Stichprobenprüfung: Wähle 5 zufällige Datenpunkte aus dem Originaloder Ergebnis-Datensatz. Zeige für jeden: den Eingabewert aus dem Original, den berechneten Wert in der Analyse, und eine manuelle Kontrollrechnung.

Schritt 2 — Grenzfall-Prüfung: Prüfe den höchsten Wert, den niedrigsten Wert und mindestens einen Wert mit fehlenden Daten in der Analyse auf Korrektheit.

Schritt 3 — Aggregations-Prüfung: Stimmt die Gesamt-Summe / der Gesamtdurchschnitt in der Analyse mit einer manuellen Berechnung überein? Zeige die Berechnung Schritt für Schritt.

Schritt 4 — Konsistenz-Prüfung: Gibt es Zahlen in der Analyse, die logisch inkonsistent sind (z. B. Summe der Teile ≠ Gesamtwert, Prozentwerte die nicht auf 100 % summieren)?

Erstelle nach der Validierung ein Ergebnis-Protokoll: Wie viele Prüfpunkte wurden korrekt bestanden — und was wurde gefunden?”

Vertiefung — Der Confidence-Überschuss im Praxis-Kontext: Erkennungszeichen

Der Confidence-Überschuss-Effekt beschreibt das Phänomen, dass KI-Antworten oft mit demselben Selbstbewusstsein formuliert werden, egal ob sie richtig oder falsch sind. Erkennen Sie diesen Effekt an folgenden Signalen:

Signal 1 — Runde Zahlen: KI neigt bei ungenauen Daten zu „Schätzungsrunden” (z. B. „ca. 1.000” statt „927”). Wenn Sie runde Zahlen sehen, nachfragen: „Aus welchem Datenpunkt leitet sich dieser Wert genau ab?”

Signal 2 — Fehlendes Konfidenzintervall: Eine Punkt-Schätzung ohne Konfidenzintervall ist bei unsicheren Daten ein Warnsignal. Prompt: „Gib für diese Schätzung auch das 90%-Konfidenzintervall an.”

Signal 3 — Keine Einschränkungen: Wenn KI ein Analyseergebnis präsentiert, ohne Einschränkungen, Datenlücken oder Unsicherheiten zu nennen, ist das ein Warnsignal — nicht weil das Ergebnis falsch sein muss, sondern weil jede ehrliche Analyse Einschränkungen hat.

Signal 4 — Widerspruch zum gesunden Menschenverstand: Wenn ein KI-Ergebnis Ihrer Praxiserfahrung fundamental widerspricht, sollten Sie nachfragen — nicht weil KI immer falsch ist, sondern weil der Widerspruch entweder ein Fehler in der Analyse oder eine echte überraschende Erkenntnis ist, die beide eine Prüfung verdienen.

Zusatzübung — Fehler gezielt einbauen und finden

Zusatzübung — Der Saboteur: Fehler absichtlich einbauen und erkennen

Aufgabe: Bauen Sie in einen Datensatz absichtlich drei typische Fehler ein (falsches Datumsformat, einen Ausreißer, eine fehlerhafte Aggregation) und lassen Sie eine KI die Fehler finden — testen Sie deren Zuverlässigkeit als Qualitätsprüfer.

Schritt-für-Schritt: 1. Nehmen Sie den Übungsdatensatz aus UE 53. 2. Bauen Sie drei Fehler ein: (a) Ein Datum im Format JJJJ-MM-TT statt TT.MM.JJJJ in einer Spalte, die sonst TT.MM.JJJJ verwendet. (b) Einen Umsatzwert, der 10× höher ist als alle anderen (Ausreißer). (c) Eine doppelte Projektnummer (Duplikat). 3. Laden Sie den modifizierten Datensatz in Code Interpreter hoch. 4. Prompt: „Analysiere diesen Datensatz auf Qualitätsprobleme. Identifiziere: (a) Datumsformat-Inkonsistenzen, (b) numerische Ausreißer (mehr als 3 Standardabweichungen), (c) Duplikate in der Projektnummern-Spalte. Für jedes gefundene Problem: Zeile, Spalte, Art des Problems.” 5. Prüfen Sie: Hat KI alle drei Fehler gefunden? Hat sie Fehler gefunden, die Sie nicht eingebaut haben (mögliche echte Qualitätsprobleme)? 6. Reflexion: Wie zuverlässig ist KI als Qualitätsprüfer für Datensätze dieser Art?

Erwartetes Ergebnis: KI-Qualitätsprüfbericht, persönliche Einschätzung der Zuverlässigkeit.

Quelle: KI-Wissensbasis von MindsMachines, Edition Juni 2026. Vollständige Fassung mit Anhängen und Musterlösungen: als PDF anfordern.

Zurück zur Modul-Übersicht

Nächster Schritt

Vom Selbststudium zur Schulung im Team.

Diese Einheit stammt aus unserer Wissensbasis mit 120 Unterrichtseinheiten. Als KI-Schulung vermitteln wir die Inhalte praxisnah an Ihren eigenen Use Cases, EU-AI-Act-konform dokumentiert.

Die Plattform

OneMachine: Ihre KI, in Ihrem System.

Produktive KI, die sicher in Ihrer Organisation läuft: mit eigenen Daten, Rechten und Freigaben. Aus echter Projektpraxis zum lizenzierbaren Produkt verdichtet.

OneMachine ansehen