Diesen aiMOOC als Battle spielen: Deutsch, Klasse 9-10, G-Niveau

Fehler systematisch zurückverfolgen

Zielgruppe: Klasse 10, fächerübergreifend mit Schwerpunkten in Informatik, Mathematik, Technik, Deutsch, Wirtschaft, Geschichte, Ethik und Gemeinschaftskunde. Der Kurs ist für etwa 1–2 Unterrichtsstunden angelegt. Du lernst nicht nur, einen Fehler zu finden, sondern ein ganzes System so zu untersuchen, dass Deine Diagnose nachvollziehbar, fair und verantwortbar wird.

Ein Fehler zeigt sich oft nur als Symptom: ein falscher Wert, ein Absturz, eine ungerechte Empfehlung, ein unerwarteter Messwert oder eine fehlerhafte Entscheidung. Systematische Fehlerrückverfolgung bedeutet deshalb: Du beschreibst zuerst, was passiert, sammelst Belege, bildest prüfbare Hypothesen, testest sie und suchst anschließend nach der Ursache, die das Problem tatsächlich hervorbringt. Erst danach entscheidest Du über eine Korrektur und prüfst ihre Folgen.

Ein sichtbarer Fehler ist noch keine Erklärung. Das Bild zeigt einen Softwarefehler auf Anzeigetafeln. Für eine gute Diagnose müsste zusätzlich geklärt werden, welche Daten, Programme, Schnittstellen und menschlichen Entscheidungen zu dieser Anzeige geführt haben.

Lernziele

Nach dem Kurs kannst Du:

Kompetenz	Was Du am Ende leisten kannst	Fächerübergreifender Bezug
Diagnose	Soll- und Ist-Zustand trennen, Symptome präzise beschreiben und einen Fehler reproduzierbar machen.	Informatik, Technik, Deutsch
Ursachenanalyse	Hypothesen entwickeln, Belege sammeln und mit Ishikawa-Diagramm, Fehlerbaum oder Warum-Fragen Ursache-Wirkungs-Ketten untersuchen.	Technik, Informatik, Wirtschaft
Evaluation	Testfälle planen, Fehlerarten unterscheiden und einfache Kennzahlen wie Treffer- und Auffindungsquote deuten.	Mathematik, Informatik
Systemdesign	Eingaben, Verarbeitung, Ausgaben, Schnittstellen, menschliche Entscheidungen und Rückkopplungen als Teile eines Systems analysieren.	Informatik, Technik, Wirtschaft
Governance	Zuständigkeiten, Freigaben, Dokumentation, Eskalation und menschliche Kontrolle für riskante Systeme begründet gestalten.	Gemeinschaftskunde, Wirtschaft, Ethik
Folgenabschätzung	Auswirkungen auf Sicherheit, Fairness, Datenschutz, Grundrechte, Ressourcen und Betroffene gegeneinander abwägen.	Ethik, Gemeinschaftskunde, Geschichte
Human Agency	Automatische Vorschläge kritisch prüfen, widersprechen, eine menschliche Überprüfung einfordern und Entscheidungen begründen.	Ethik, Gemeinschaftskunde, Deutsch
Transfer	Die Methode selbstständig auf einen neuen technischen oder gesellschaftlichen Fall übertragen.	alle genannten Lernbereiche

Unterrichtsplan für 1–2 Unterrichtsstunden

Phase	Richtzeit	Lernaktivität	Ergebnis
Aktivierung	5–8 Minuten	Du unterscheidest spontan Symptom, Vermutung und Beleg.	Erste Diagnose
Einführung	10–15 Minuten	Du lernst die Rückverfolgungskette und das Denken in Systemschichten kennen.	Gemeinsames Vorgehensmodell
Werkzeugphase	15–20 Minuten	Du erprobst Warum-Fragen, Ishikawa-Diagramm, Fehlerbaum und Testlogik.	Ursachenhypothesen
Anwendungssituation	20–30 Minuten	Du analysierst einen realistischen Schulfall mit mehreren Stakeholdern.	Begründete Ursachen- und Risikoanalyse
Entscheidung	10–15 Minuten	Du wägest Sicherheit, Fairness, Nutzen, Datenschutz und Aufwand ab.	Nachvollziehbares Urteil
Selbstkontrolle und Reflexion	10 Minuten	Du prüfst Dein Verständnis und hinterfragst Deinen Diagnoseweg.	Feedback zum eigenen Vorgehen
Transfer	10–20 Minuten	Du überträgst die Methode auf einen neuen Fall.	Eigenständige begründete Entscheidung

Für eine einzelne 45-Minuten-Stunde kannst Du die Abschnitte Aktivierung, Einführung und Anwendungssituation bearbeiten. Für 90 Minuten kommt die vollständige Entscheidung mit Transfer hinzu. Für 120 Minuten kannst Du zusätzlich eine offene Aufgabe als Gruppenprojekt ausarbeiten.

Aktivierung und Diagnose

Kurzdiagnose: Stell Dir vor, eine digitale Anzeige meldet: „Temperatur 71 °C“. Im Raum fühlt es sich normal an. Formuliere in drei Sätzen:

Symptom: Was ist tatsächlich beobachtbar, ohne bereits eine Ursache zu behaupten?
Hypothese: Welche eine mögliche Erklärung würdest Du zuerst testen?
Beleg: Welche Messung oder Beobachtung könnte Deine Hypothese bestätigen oder widerlegen?

Vergleiche anschließend diese Aussagen: „Der Sensor ist kaputt“, „Die Anzeige zeigt 71 °C“ und „Ein Vergleichsthermometer zeigt 22 °C“. Nur die zweite Aussage beschreibt zunächst das Symptom. Die erste ist bereits eine Hypothese. Die dritte liefert einen zusätzlichen Beleg. Diese Trennung schützt Dich vor vorschnellen Schuldzuweisungen.

Einleitung

Ein Programmfehler oder technischer Fehler ist eine Abweichung von einem erwarteten oder geforderten Zustand. Beim Debugging wird versucht, Fehler zu diagnostizieren und zu lokalisieren. In komplexen Systemen genügt es aber nicht, nur eine einzelne fehlerhafte Codezeile zu suchen. Probleme können durch Daten, Hardware, Schnittstellen, Bedienung, Organisation, unklare Regeln oder Wechselwirkungen mehrerer Faktoren entstehen.

Das berühmte Logbuch mit einer Motte aus dem Jahr 1947 ist eine anschauliche Episode der Computergeschichte. Der Ausdruck „bug“ für technische Fehlfunktionen existierte jedoch schon vorher. Die Geschichte eignet sich daher vor allem als Erinnerung daran, dass ein sichtbarer Fund nicht automatisch die ganze Geschichte eines Fehlers erklärt.

Vom Symptom zur Ursache

Begriff	Leitfrage	Beispiel
Sollzustand	Was sollte geschehen?	Ein Warnsystem soll nur dann einen Hinweis geben, wenn die festgelegten Kriterien erfüllt sind.
Istzustand	Was geschieht tatsächlich?	Nach einem Update werden plötzlich sehr viele Hinweise erzeugt.
Symptom	Welche beobachtbare Abweichung liegt vor?	Die Zahl der Warnungen steigt stark an.
Hypothese	Welche prüfbare Erklärung könnte das Symptom verursachen?	Fehlende Werte werden nach dem Update anders codiert.
Test	Welche Beobachtung würde die Hypothese stützen oder schwächen?	Alte und neue Rohdaten werden bei identischen Fällen verglichen.
Ursache	Welcher Faktor trägt nachweisbar zum Fehler bei?	Die Datenschnittstelle übergibt einen geänderten Wert.
Grundursache	Welcher tieferliegende Systemfaktor machte den Fehler möglich?	Für Schnittstellenänderungen fehlte ein automatischer Kompatibilitätstest.
Korrektur	Welche Maßnahme behebt die Ursache, nicht nur das Symptom?	Datenabbildung korrigieren und einen Regressionstest ergänzen.
Verifikation	Funktioniert die Korrektur auch bei Gegenbeispielen?	Alte, neue und absichtlich schwierige Testfälle werden erneut ausgeführt.

Ein häufiger Denkfehler lautet: „Nach der Änderung trat das Problem auf, also ist die Änderung die Ursache.“ Zeitliche Nähe ist ein wichtiger Hinweis, aber noch kein Beweis. Du brauchst einen Test, der alternative Erklärungen möglichst gut unterscheidet.

Systemdesign: Denk in Schichten statt in Einzelteilen

Wenn Du nur Eingabe und Ausgabe siehst, wirkt ein System wie eine „Black Box“. Für die Fehlerrückverfolgung zerlegst Du es gedanklich in Schichten:

Schicht	Typische Fehlerquelle	Prüffrage
Eingabe	falsche, fehlende, veraltete oder verzerrte Daten	Sind die Eingangsdaten vollständig, gültig und passend zum Zweck?
Vorverarbeitung	Einheitenfehler, falsche Codierung, Rundung, Filterung	Wurde ein Wert auf dem Weg verändert?
Regel oder Modell	Logikfehler, ungeeignete Annahmen, unpassende Schwellenwerte	Liefert die Verarbeitung bei kontrollierten Testfällen das erwartete Ergebnis?
Schnittstelle	Versionskonflikt oder falsch zugeordnetes Datenfeld	Stimmen Format und Bedeutung auf beiden Seiten überein?
Ausgabe	missverständliche Darstellung oder falsche Priorisierung	Kann ein Mensch erkennen, wie sicher und wofür die Ausgabe gedacht ist?
Menschliche Entscheidung	Automationsbias, Zeitdruck, fehlende Prüfung	Darf und kann ein Mensch widersprechen oder nachfragen?
Organisation	unklare Zuständigkeit, fehlende Freigabe, kein Monitoring	Wer bemerkt, meldet, stoppt, prüft und dokumentiert einen Fehler?
Folgen	Benachteiligung, Sicherheitsrisiko, Kosten, Vertrauensverlust	Wer ist betroffen und wie schwer wiegt der mögliche Schaden?

Gerade bei KI-Systemen ist diese Sicht wichtig: Ein falsches Ergebnis kann aus den Trainingsdaten, den aktuellen Eingaben, dem Modell, einer Schnittstelle oder aus einer falschen Nutzung der Ausgabe entstehen. Die Diagnose darf deshalb nicht vorschnell „die KI“ oder „den Menschen“ als einzige Ursache festlegen.

Die Rückverfolgungskette

Eine robuste Untersuchung folgt keinem starren Rezept, aber dieser Ablauf hilft Dir, nachvollziehbar zu arbeiten:

Schritt	Handlung	Qualitätsfrage
1. Problem abgrenzen	Soll, Ist, Zeitpunkt, Ort und betroffene Fälle beschreiben.	Ist die Beschreibung beobachtbar und frei von Schuldzuweisung?
2. Reproduzieren	Bedingungen sammeln, unter denen das Problem wieder auftritt.	Kann eine andere Person den Fehler unter denselben Bedingungen sehen?
3. Spuren sichern	Logs, Versionen, Messwerte, Eingaben und Änderungen dokumentieren.	Ist erkennbar, welche Daten aus welcher Quelle stammen?
4. Hypothesen bilden	Mehrere plausible Ursachen formulieren.	Sind die Hypothesen prüfbar und unterscheiden sie sich?
5. Tests entwerfen	Mit möglichst kleinen, kontrollierten Änderungen testen.	Kann der Test eine Hypothese widerlegen?
6. Ursache belegen	Ergebnisse vergleichen und Gegenbeispiele suchen.	Passt die Erklärung auch zu Fällen, in denen der Fehler nicht auftritt?
7. Maßnahme gestalten	Ursache beheben, Risiken begrenzen und Verantwortliche festlegen.	Behebt die Maßnahme die Ursache oder versteckt sie nur das Symptom?
8. Verifizieren und überwachen	Regressionstests, Monitoring und Nachkontrolle durchführen.	Entstehen neue Fehler oder unbeabsichtigte Folgen?

Diese Kette fördert Human Agency: Du behandelst eine automatische Ausgabe als Hinweis, nicht als unanfechtbare Wahrheit.

Werkzeug 1: Warum-Fragen und Ursachenketten

Bei der Methode der wiederholten Warum-Fragen fragst Du nicht mechanisch genau fünfmal. Du fragst so lange weiter, bis Du zu einer überprüfbaren und handlungsrelevanten Ursache gelangst. Jede Antwort muss durch Daten oder Beobachtungen prüfbar bleiben.

Beispiel: „Warum wurde ein falscher Warnhinweis erzeugt?“ – „Weil ein fehlender Wert als Null interpretiert wurde.“ – „Warum wurde er als Null interpretiert?“ – „Weil die Schnittstelle nach einem Update die Codierung änderte.“ – „Warum fiel das nicht auf?“ – „Weil kein Test für fehlende Werte vorgesehen war.“ Die letzte Antwort verweist nicht nur auf den unmittelbaren Datenfehler, sondern auf eine Schwäche im Systemdesign.

Das Video zeigt die Grundidee der 5-Why-Methode. Nutze die Methode kritisch: Mehrfaches Fragen ersetzt keinen Beleg, und komplexe Probleme können mehrere Ursachen haben.

Werkzeug 2: Ishikawa-Diagramm

Ein Ursache-Wirkungs-Diagramm sammelt mögliche Ursachen in Kategorien. Für digitale Schulsysteme kannst Du statt starrer Standardkategorien zum Beispiel Mensch, Methode, Daten, Technik, Umgebung und Organisation verwenden. Das Diagramm ist ein Werkzeug zum Strukturieren von Hypothesen, kein Beweis für eine Ursache.

Eine gute Gruppenregel lautet: Erst Ursachen sammeln, dann für jede wichtige Vermutung einen prüfbaren Beleg oder Test formulieren.

Werkzeug 3: Fehlerbaum

Bei einer Fehlerbaumanalyse startest Du mit einem unerwünschten Ereignis und zerlegst es in mögliche Teilursachen. Ein Fehlerbaum ist besonders nützlich, wenn mehrere Ereignisse gemeinsam nötig sind oder wenn verschiedene unabhängige Wege zum selben Problem führen können.

Beispiel: „Ungerechtfertigter Warnhinweis“ könnte entstehen, wenn falsche Eingabedaten ODER falsche Regelanwendung ODER falsche Zuordnung zur Person vorliegt. Ein schwerer Folgeschaden könnte zusätzlich davon abhängen, dass keine menschliche Prüfung UND keine Widerspruchsmöglichkeit vorhanden sind.

Werkzeug 4: Debugger, Logs und kontrollierte Tests

Ein Debugger kann ein Programm schrittweise ausführen, Variablen beobachten und Haltepunkte setzen. Ein Log protokolliert Ereignisse und Zustände. Beides ist nur hilfreich, wenn Du vorher weißt, welche Hypothese Du prüfen willst. Ungezieltes Durchklicken erzeugt viele Daten, aber wenig Erkenntnis.

Ein kontrollierter Test verändert möglichst nur einen relevanten Faktor. Wenn ein Fehler nur bei einem bestimmten Dateiformat auftritt, hältst Du Programmversion, Benutzerkonto und Inhalt möglichst konstant und änderst zunächst nur das Format. So wird der Zusammenhang prüfbarer.

Werkzeug 5: Root-Cause-Dokumentation und kontinuierliche Verbesserung

Eine gute Ursachenanalyse hält Problem, Auswirkung, zeitlichen Verlauf, Maßnahme und Vorbeugung fest. Dokumentation ist kein Selbstzweck: Sie ermöglicht, dass andere den Diagnoseweg prüfen, später ähnliche Fehler erkennen und aus dem Ereignis lernen können.

Der PDCA-Gedanke – Plan, Do, Check, Act – erinnert daran, dass eine Korrektur nicht mit dem Einspielen eines Fixes endet. Du planst eine Änderung, führst sie kontrolliert aus, überprüfst ihre Wirkung und verbesserst anschließend Verfahren oder Standards.

Mathematische Evaluation: Welche Fehler macht das System?

Bei automatischen Hinweisen reicht die Frage „Wie oft liegt das System richtig?“ oft nicht aus. Du musst unterscheiden, welche Art von Fehler entsteht.

Angenommen, bei 40 Fällen benötigen 8 tatsächlich zusätzliche Unterstützung. Das System markiert 10 Fälle. Von diesen 10 sind 6 wirklich unterstützungsbedürftig. Damit ergibt sich:

	Unterstützung tatsächlich nötig	Unterstützung tatsächlich nicht nötig
System markiert	6 richtige Treffer	4 Fehlalarme
System markiert nicht	2 übersehene Fälle	28 richtige Nicht-Markierungen

Die Trefferquote unter den Markierten beträgt 6 von 10, also 60 Prozent. Die Auffindungsquote beträgt 6 von 8, also 75 Prozent. Beide Werte beantworten unterschiedliche Fragen. Welche Kennzahl wichtiger ist, hängt von den Folgen der beiden Fehlerarten ab.

Ein Fehlalarm kann zu unnötiger Stigmatisierung, zusätzlicher Arbeit oder unfairer Behandlung führen. Ein übersehener Fall kann bedeuten, dass notwendige Unterstützung ausbleibt. Deshalb ist Evaluation immer auch eine Wertefrage: Welche Fehlerfolgen sind wie schwer? Wer darf darüber entscheiden? Welche Mindestanforderungen gelten?

Fairness prüfen, ohne Menschen auf Zahlen zu reduzieren

Fairness bedeutet nicht automatisch, dass jede Gruppe exakt dieselbe Kennzahl haben muss. Du solltest aber prüfen, ob bestimmte Gruppen oder Nutzungssituationen systematisch schlechtere Ergebnisse erhalten. Unterschiede können zum Beispiel aus ungleich verteilten Trainingsdaten, ungeeigneten Messgrößen, Barrieren bei der Datenerfassung oder einer falschen Anwendung des Systems entstehen.

Für eine faire Evaluation brauchst Du genügend Fälle, einen sinnvollen Vergleich und eine Begründung, warum die betrachtete Gruppe relevant ist. Einzelne Prozentwerte ohne Kontext können in die Irre führen. Besonders bei Grundrechten oder wichtigen Lebenschancen darf eine Kennzahl die menschliche Abwägung nicht ersetzen.

KI, Verantwortung und menschliche Kontrolle

KI-Systeme können Muster erkennen und Vorschläge erzeugen, aber sie tragen keine menschliche Verantwortung. Internationale Ethikrahmen und die europäische KI-Regulierung betonen deshalb unter anderem Transparenz, Risikomanagement, Fairness, Nachvollziehbarkeit und menschliche Aufsicht. Für Dich heißt das im Unterricht: Je größer die möglichen Folgen einer automatischen Entscheidung, desto wichtiger sind Prüfung, Dokumentation, Widerspruchsmöglichkeit und klar benannte Verantwortliche.

Human Agency heißt, dass Menschen handlungsfähig bleiben. Eine Schülerin oder ein Schüler sollte einen automatischen Hinweis nicht nur hinnehmen müssen, sondern verstehen können, wofür er verwendet wird, eine Überprüfung anstoßen und eine Entscheidung anfechten können. Eine Lehrkraft sollte erkennen können, wann das System unsicher ist und wann menschliche Fachkenntnis Vorrang hat.

Grundrechte und Werteabwägung

Bei schulischen oder öffentlichen Systemen können mehrere Werte gleichzeitig berührt sein:

Wert oder Recht	Mögliche Leitfrage
Menschenwürde	Wird eine Person auf einen Score reduziert oder respektvoll als handelndes Subjekt behandelt?
Gleichbehandlung	Werden vergleichbare Fälle nach nachvollziehbaren Kriterien behandelt?
Privatsphäre und Datenschutz	Werden nur Daten genutzt, die für den Zweck notwendig und zulässig sind?
Sicherheit	Können Fehlentscheidungen körperliche, psychische oder materielle Schäden verursachen?
Transparenz	Können Betroffene und Verantwortliche die entscheidenden Gründe nachvollziehen?
Autonomie	Gibt es echte Möglichkeiten zum Widerspruch und zur menschlichen Entscheidung?
Effizienz	Spart das System Zeit oder Ressourcen, ohne wichtigere Werte unangemessen zu verdrängen?

Werte können in Konflikt geraten. Mehr Transparenz kann etwa hilfreich sein, darf aber nicht dazu führen, dass personenbezogene Daten unnötig offengelegt werden. Mehr Automatisierung kann Arbeit sparen, darf aber keine unbegründete automatische Autorität erzeugen. Deine Aufgabe ist nicht, einen Wert immer gewinnen zu lassen, sondern einen begründeten Ausgleich zu gestalten.

Governance: Wer trägt welche Verantwortung?

Governance bedeutet, Regeln, Zuständigkeiten und Kontrollwege so zu gestalten, dass ein System verantwortbar betrieben werden kann.

Rolle	Verantwortung im Fehlerfall	Kontrollfrage
Entwicklung	technische Ursache untersuchen und Korrektur nachvollziehbar dokumentieren	Wurde die Änderung getestet und versioniert?
Fachverantwortliche	prüfen, ob die Ausgabe im Anwendungskontext sinnvoll ist	Passt die technische Kennzahl zur pädagogischen Aufgabe?
Betroffene	Erfahrungen, Widerspruch und Folgen sichtbar machen	Können Betroffene Fehler melden und eine Überprüfung verlangen?
Datenschutz oder Aufsicht	Rechtmäßigkeit, Datensparsamkeit und Schutzmaßnahmen prüfen	Werden nur notwendige Daten verarbeitet?
Leitung oder Entscheidungsgremium	Einsatz, Pause, Änderung oder Abschaltung verantworten	Wer darf bei hohem Risiko einen Stopp anordnen?
Betrieb und Support	Monitoring, Incident-Meldung und Wiederanlauf organisieren	Werden ungewöhnliche Muster früh erkannt?

Eine starke Governance vermeidet die Aussage: „Niemand war zuständig.“ Sie legt vor einem Vorfall fest, wer welche Entscheidung treffen darf, welche Informationen benötigt werden und wann eine automatische Funktion gestoppt werden muss.

Folgenabschätzung

Bevor Du eine Korrektur freigibst, untersuchst Du nicht nur, ob der Fehler technisch verschwindet. Du fragst auch, welche neuen Folgen die Maßnahme haben könnte.

Perspektive	Prüffragen
Betroffene Menschen	Wer gewinnt, wer trägt Risiken, wer kann widersprechen?
Grundrechte	Sind Gleichbehandlung, Privatsphäre, Würde oder Teilhabe berührt?
Sicherheit	Welche Fehlermodi bleiben möglich und wie werden sie erkannt?
Lernen und Bildung	Unterstützt das System eigenständiges Denken oder erzeugt es Abhängigkeit?
Wirtschaft	Welche Kosten entstehen durch Fehler, Prüfung, Ausfall oder Nachbesserung?
Organisation	Sind Zuständigkeiten, Schulung und Eskalation realistisch?
Umwelt und Ressourcen	Benötigt die Änderung zusätzliche Hardware, Energie oder Rechenleistung?
Langzeitwirkung	Kann eine kurzfristig praktische Lösung später neue Abhängigkeiten oder Ungleichheiten erzeugen?

Realistische Anwendungssituation: Fehlalarm im schulischen Förderhinweis-System

Eine Schule testet ein digitales System, das Lehrkräfte auf Lernende hinweisen soll, die möglicherweise zusätzliche Unterstützung benötigen. Das System darf keine automatische Sanktion auslösen. Es kombiniert Abgabezeitpunkte, freiwillige Lernstandschecks und Fehlzeiten zu einem Hinweis. Nach einem Softwareupdate am Montag verdoppelt sich die Zahl der Warnhinweise nahezu.

Die Schulleitung möchte das System weiterverwenden, weil Lehrkräfte Unterstützung frühzeitig anbieten sollen. Einige Lernende berichten jedoch, sie seien trotz rechtzeitiger Abgaben markiert worden. Lehrkräfte befürchten Mehrarbeit und Vertrauensverlust. Die Datenschutzbeauftragte verlangt Nachvollziehbarkeit. Der Softwareanbieter erklärt, dass am Modell selbst nichts geändert worden sei.

Spurenlage

Du erhältst folgende Informationen:

Spur	Beobachtung
A	Der starke Anstieg beginnt unmittelbar nach einem Update der mobilen Abgabe-Schnittstelle.
B	Das eigentliche Risikomodell hat dieselbe Versionsnummer wie in der Vorwoche.
C	Bei vielen Fehlalarmen wurden Aufgaben über ein mobiles Gerät abgegeben.
D	In älteren Daten steht für „noch nicht synchronisiert“ der Wert minus eins.
E	Die neue Schnittstelle übergibt für denselben Zustand den Wert null.
F	In der Vorverarbeitung wird null derzeit wie „keine Abgabe“ behandelt.
G	Es gibt einen Test für normale Abgaben, aber keinen Test für den Zustand „noch nicht synchronisiert“.
H	Lehrkräfte können Hinweise übersteuern, sehen aber bisher nicht, welche Eingabedaten den Hinweis ausgelöst haben.

Die Spuren deuten auf eine technische Ursache hin, zeigen aber zugleich organisatorische Schwächen: fehlende Tests für einen Sonderfall, begrenzte Erklärbarkeit und ein Monitoring, das den plötzlichen Anstieg nicht automatisch als Auffälligkeit meldete.

Stakeholder und Zielkonflikte

Stakeholder	legitimes Ziel	möglicher Konflikt
Lernende	faire Behandlung und Unterstützung ohne Stigmatisierung	möchten keine falschen Warnhinweise oder unnötige Datennutzung
Lehrkräfte	früh helfen und Arbeitszeit sinnvoll einsetzen	können nicht jeden automatischen Hinweis aufwendig nachprüfen
Schulleitung	verlässliche Prozesse und gute Lernförderung	muss Nutzen, Kosten und Reputationsrisiken abwägen
Eltern oder Sorgeberechtigte	Transparenz und Schutz der Lernenden	können schnelle Hilfe wünschen, aber Datennutzung kritisch sehen
Datenschutzbeauftragte	rechtmäßige und sparsame Datenverarbeitung	kann zusätzliche Nachweise oder Einschränkungen fordern
Anbieter	stabile Software und zügige Fehlerbehebung	steht unter Zeitdruck und kennt den pädagogischen Kontext nicht vollständig
Schülervertretung	Mitbestimmung und faire Regeln	verlangt verständliche Erklärungen und Beschwerdewege

Eure Fallentscheidung

Bildet Gruppen. Jede Gruppe übernimmt mindestens drei Stakeholder-Perspektiven und entwirft eine Entscheidung für die nächsten 24 Stunden sowie einen Plan für die nächsten zwei Wochen.

Bewertet mögliche Maßnahmen mit 0, 1 oder 2 Punkten. 0 bedeutet „Kriterium kaum erfüllt“, 2 bedeutet „Kriterium gut erfüllt“. Begründet jede Bewertung in einem Satz.

Maßnahme	Sicherheit	Fairness	Nachvollziehbarkeit	pädagogischer Nutzen	Datenschutz	Aufwand
Hinweise unverändert weiterverwenden
System vollständig abschalten
automatische Hinweise pausieren und vorübergehend nur nach menschlicher Prüfung nutzen
Datenabbildung korrigieren, Sonderfall testen und alte Fälle erneut berechnen
zusätzlich Monitoring, Erkläranzeige und Widerspruchsweg einführen

Es gibt nicht automatisch „die eine“ perfekte Maßnahme. Eine starke Entscheidung trennt Sofortschutz, technische Korrektur und dauerhafte Governance. Sie erklärt außerdem, wer handeln darf, wie Betroffene informiert werden und woran später erkannt wird, ob die Änderung wirklich funktioniert.

Human-Agency-Check für die Fallentscheidung

Prüft Eure Lösung mit fünf Fragen:

Menschliche Kontrolle: Kann eine verantwortliche Person den automatischen Hinweis prüfen, stoppen oder überstimmen?
Widerspruch: Können Betroffene eine Überprüfung verlangen, ohne dafür technisches Spezialwissen zu benötigen?
Nachvollziehbarkeit: Sind die entscheidenden Eingaben, Versionen und Regeln dokumentiert?
Verhältnismäßigkeit: Ist die Datennutzung und Automatisierung für den Zweck wirklich nötig?
Verantwortung: Ist klar, wer für Freigabe, Monitoring, Korrektur und Kommunikation zuständig ist?

Transfer auf einen neuen Fall

Ein mittelständischer Betrieb nutzt ein automatisches System, um Bewerbungen für Schülerpraktika vorzusortieren. Nach einer Änderung im Formular werden Bewerbungen einer bestimmten Schulart ungewöhnlich häufig als „unvollständig“ aussortiert. Das Unternehmen spart dadurch Bearbeitungszeit, aber Schulen beschweren sich über Benachteiligung. Die Personalabteilung kann die automatische Sortierung manuell übergehen, tut dies wegen Zeitdrucks selten.

Dein Transferauftrag: Übertrage die Rückverfolgungskette selbstständig. Formuliere das Symptom neutral, nenne mindestens drei plausible Ursachen auf unterschiedlichen Systemebenen, plane zwei unterscheidende Tests, beschreibe die wichtigsten Stakeholder, prüfe mögliche Grundrechts- und Fairnessfolgen und entscheide, welche Sofortmaßnahme und welche dauerhafte Änderung Du empfehlen würdest. Begründe Dein Urteil so, dass eine andere Person Deinen Weg nachvollziehen und kritisieren kann.

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Ein digitales System liefert plötzlich falsche Ergebnisse. Was ist der stärkste erste Schritt? (Soll und Ist präzise beschreiben und den Fehler reproduzierbar machen) (!Sofort eine vermutete Ursache reparieren) (!Alle Protokolle löschen und neu starten) (!Die betroffene Person als Fehlerquelle festlegen)

Nach einem Schnittstellenupdate steigen Fehlalarme stark an. Welcher Test ist am aussagekräftigsten? (Die Eingabecodierung derselben Fälle vor und nach dem Update vergleichen) (!Nur das Bildschirmdesign verändern) (!Das System ohne Datensicherung neu installieren) (!Mehr Warnungen als Beweis für bessere Erkennung werten)

Woran erkennst Du eine gute Hypothese bei der Fehlersuche? (Sie ist so formuliert, dass ein Test sie widerlegen kann) (!Sie klingt für die Mehrheit plausibel) (!Sie nennt sofort eine schuldige Person) (!Sie erklärt jedes mögliche Ergebnis gleichermaßen)

Ein System markiert zehn Fälle, davon sind sechs tatsächlich relevant. Wie hoch ist die Trefferquote unter den Markierten? (60 Prozent) (!40 Prozent) (!75 Prozent) (!80 Prozent)

Welche Gestaltung stärkt menschliche Handlungsfähigkeit am meisten? (Eine verantwortliche Person kann Ausgaben prüfen, begründet überstimmen und Betroffene können widersprechen) (!Automatische Ausgaben werden immer als endgültig behandelt) (!Nur der Anbieter darf Fehlerberichte sehen) (!Unsichere Ergebnisse werden ohne Kennzeichnung ausgegeben)

Welche Aussage über ein Ishikawa-Diagramm ist richtig? (Es strukturiert mögliche Ursachen, beweist sie aber noch nicht) (!Es ersetzt alle Tests durch eine Zeichnung) (!Es zeigt nur menschliche Fehler) (!Es liefert automatisch die billigste Lösung)

Warum reicht ein zeitlicher Zusammenhang nach einem Update nicht als Ursachenbeweis? (Andere Veränderungen können gleichzeitig wirksam gewesen sein) (!Weil Updates niemals Fehler verursachen) (!Weil Zeitangaben bei Software grundsätzlich wertlos sind) (!Weil Ursachen nur durch Abstimmungen festgelegt werden)

Was ist bei hoher möglicher Schadenswirkung besonders wichtig? (Klare Zuständigkeit, menschliche Aufsicht, Nachvollziehbarkeit und ein Stoppweg) (!Mehr Automatisierung ohne Protokollierung) (!Weniger Informationen für Betroffene) (!Eine möglichst komplizierte Benutzeroberfläche)

Wann solltest Du bei wiederholten Warum-Fragen aufhören? (Wenn eine belegbare und handlungsrelevante Ursache erreicht ist) (!Immer exakt nach der fünften Frage) (!Sobald die erste Vermutung genannt wurde) (!Erst wenn eine einzelne Person verantwortlich gemacht werden kann)

Ein Temperatursensor meldet nur bei direkter Mittagssonne zu hohe Werte. Was ist ein guter nächster Test? (Den Sensor gleichzeitig beschattet und unbeschattet mit einem unabhängigen Thermometer vergleichen) (!Den Messwert ohne Prüfung auf normal setzen) (!Alle bisherigen Messdaten löschen) (!Die Raumtemperatur durch Abstimmung festlegen)

Memory

Symptom	beobachtbare Abweichung
Reproduktion	denselben Fehler unter gleichen Bedingungen erneut auslösen
Hypothese	prüfbare Erklärung
Grundursache	tieferliegender ursächlicher Systemfaktor
HumanOversight	menschliche Prüfung und Übersteuerung
Traceability	nachvollziehbare Protokollspur

Drag and Drop

Ordne die richtigen Begriffe zu.	Fehleranalyse
Symptom	beobachtete Abweichung
Hypothese	mögliche prüfbare Ursache
Test	gezielte Prüfung einer Vermutung
Nachweis	Beleg für oder gegen eine Erklärung
Verifikation	Prüfung der korrigierten Lösung

Kreuzworträtsel

Reproduktion	Wie heißt das erneute Auslösen eines Fehlers unter gleichen Bedingungen?
Hypothese	Wie heißt eine prüfbare Erklärung für eine mögliche Ursache?
Debugger	Welches Werkzeug kann Programmausführung schrittweise untersuchen?
Fehlerbaum	Welche Darstellung zerlegt ein unerwünschtes Ereignis in Teilursachen?
Fairness	Welcher Begriff bezeichnet gerechte und nicht diskriminierende Behandlung?
Kontrolle	Welcher Begriff passt zu menschlicher Prüfung und Eingriffsmöglichkeit?

LearningApps

Lückentext

Am Anfang einer systematischen Fehlersuche wird der beobachtete

mit dem erwarteten Sollzustand verglichen.

Eine mögliche Erklärung für das Symptom heißt

.

Ein guter Test sollte eine Vermutung nicht nur bestätigen, sondern auch

können.

Eine tieferliegende Ursache, die das Auftreten eines Fehlers ermöglicht, wird als

bezeichnet.

Bei automatischen Entscheidungen stärkt eine echte menschliche Eingriffsmöglichkeit die

.

Ein plötzlicher Anstieg von Fehlalarmen sollte durch geeignetes

erkannt werden.

Nach einer Korrektur prüfst Du mit neuen und alten Testfällen die

der Lösung.

Bei folgenreichen KI-Systemen gehören Fairness, Transparenz und menschliche

zu wichtigen Gestaltungsprinzipien.

Offene Aufgaben

Leicht

Fehlerprotokoll: Dokumentiere einen harmlosen Alltagsfehler an einem technischen Gerät mit Sollzustand, Istzustand, Zeitpunkt, Bedingungen und mindestens zwei Hypothesen, ohne sofort eine Ursache zu behaupten.
Ishikawa-Diagramm: Zeichne ein Ursache-Wirkungs-Diagramm für das Problem „Schulcomputer startet zu langsam“ und markiere drei Hypothesen, die sich mit einfachen Tests unterscheiden lassen.
Quellenkritik: Suche zwei Erklärungen für denselben technischen Fehler in unterschiedlichen Quellen und vergleiche, welche Belege, Unsicherheiten und möglichen Interessenkonflikte genannt werden.
Debugging-Geschichte: Erstelle ein kurzes Lernposter zur Motte im Mark-II-Logbuch und erkläre ausdrücklich, warum die Anekdote nicht beweist, dass dort das Wort „Bug“ erfunden wurde.

Standard

Testdesign: Entwirf für einen selbst gewählten Fehler vier Testfälle, darunter einen Normalfall, einen Grenzfall, einen Gegenbeispiel-Fall und einen Wiederholungstest nach der Korrektur.
Interview: Befrage eine Person aus IT, Handwerk, Technik oder Verwaltung dazu, wie dort Fehler dokumentiert und eskaliert werden, und vergleiche die Praxis mit der Rückverfolgungskette dieses Kurses.
Stakeholderanalyse: Übernimm im Förderhinweis-Fall die Perspektiven von Lernenden, Lehrkräften, Schulleitung und Datenschutz und formuliere je ein legitimes Ziel sowie einen möglichen Zielkonflikt.
Entscheidungsmatrix: Entwickle eine eigene Bewertungsmatrix für eine riskante technische Änderung mit mindestens fünf Kriterien und begründe die Gewichtung der Kriterien.

Schwer

Systemdesign: Entwirf für das Förderhinweis-System eine verbesserte Architektur mit Validierung der Eingaben, Versionskontrolle, Monitoring, Erkläranzeige, menschlicher Freigabe und Widerspruchsweg.
Folgenabschätzung: Schreibe eine kurze Folgenabschätzung zu einem KI-System Deiner Wahl und unterscheide technische, soziale, rechtliche, wirtschaftliche und langfristige Risiken.
Audit: Entwickle einen Prüfplan, mit dem eine andere Gruppe feststellen kann, ob ein automatisiertes System nach einer Korrektur wirklich fairer, sicherer und nachvollziehbarer arbeitet.
Transferprojekt: Analysiere einen neuen Fall aus Schule, Kommune oder Betrieb, führe die Rückverfolgungskette vollständig durch und präsentiere eine begründete Entscheidung mit Gegenargument und Restunsicherheit.

Lernkontrolle

Ursachenkette: In einem Smart-Home-System wird nachts wiederholt ein Fensteralarm ausgelöst. Entwirf drei Hypothesen auf unterschiedlichen Systemebenen und erkläre, mit welcher Testreihenfolge Du sie möglichst effizient unterscheidest.
Fehlerkosten: Vergleiche einen Fehlalarm und einen übersehenen echten Fall in einem automatischen Warnsystem. Begründe, warum dieselbe Kennzahl je nach Anwendung unterschiedlich wichtig sein kann.
Governance: Entwickle eine Stop-Regel für ein schulisches KI-System. Lege fest, wer stoppen darf, welche Belege nötig sind, wie Betroffene informiert werden und welche Bedingungen für den Neustart gelten.
Werteabwägung: Ein System könnte durch zusätzliche personenbezogene Daten genauer werden. Beurteile, ob diese Datennutzung gerechtfertigt ist, und berücksichtige Genauigkeit, Datenschutz, Verhältnismäßigkeit und Alternativen.
Fehlerbaum: Erstelle einen Fehlerbaum für das Ereignis „falsche automatische Ablehnung einer Bewerbung“ und kennzeichne technische, organisatorische und menschliche Teilursachen.
Gegenargument: Formuliere zu Deiner bevorzugten Lösung im Förderhinweis-Fall das stärkste Gegenargument und passe Deine Entscheidung so an, dass dieses Argument angemessen berücksichtigt wird.
Transfer: Übertrage die Methode auf ein System, das Du noch nicht im Unterricht behandelt hast. Zeige ausdrücklich, welche Teile des Vorgehens gleich bleiben und welche an den neuen Kontext angepasst werden müssen.

Reflexion

Beantworte am Ende schriftlich drei Fragen:

Lernreflexion: An welcher Stelle Deiner Diagnose warst Du am stärksten versucht, eine Vermutung mit einem Beleg zu verwechseln?
Human Agency: Welche konkrete Funktion oder Regel verhindert in Deinem Fall, dass eine automatische Ausgabe zur unangreifbaren Entscheidung wird?
Restunsicherheit: Welche Unsicherheit bleibt nach Deiner Analyse bestehen, und wie würdest Du sie beobachten oder später erneut prüfen?

Lernnachweis

Für einen überzeugenden Lernnachweis zu diesem Thema sind besonders wichtig:

Präzise Problembeschreibung: Soll und Ist werden getrennt und das Symptom wird neutral beschrieben.
Nachvollziehbare Spurenlage: Daten, Versionen, Messwerte oder Beobachtungen werden mit ihrer Herkunft dokumentiert.
Mehrere Hypothesen: Es werden alternative Ursachen auf unterschiedlichen Systemebenen berücksichtigt.
Prüfbare Tests: Die Tests können Hypothesen bestätigen oder widerlegen.
Begründete Ursachenanalyse: Ursache und Grundursache werden nicht nur behauptet, sondern mit Belegen verbunden.
Evaluation: Fehlerarten, Kennzahlen und Grenzen der Messung werden passend zum Kontext gedeutet.
Governance: Zuständigkeit, menschliche Kontrolle, Widerspruch, Monitoring und Eskalation sind festgelegt.
Grundrechte und Werte: Fairness, Datenschutz, Sicherheit, Autonomie und Nutzen werden gegeneinander abgewogen.
Folgenabschätzung: Neben der technischen Korrektur werden soziale, organisatorische und langfristige Wirkungen betrachtet.
Eigenständiger Transfer: Die Methode wird auf einen neuen Fall übertragen und die Entscheidung enthält Gegenargumente und Restunsicherheit.

OERs zum Thema

Weitere frei zugängliche Quellen und Medien

Debugger: Überblick zu Werkzeugen und Begriffen des Debuggings.
Ursache-Wirkungs-Diagramm: Einführung in die Ishikawa-Methode.
Fehler-Ursachen-Analyse: Grundideen der Root-Cause-Analyse.
UNESCO-Empfehlung zur Ethik der KI: Menschenrechte, Fairness, Transparenz, Verantwortung und menschliche Aufsicht.
Europäische Kommission zur KI-Verordnung: Überblick zum risikobasierten Ansatz und zu Anforderungen wie Risikomanagement, Nachvollziehbarkeit und menschlicher Aufsicht.
Wikimedia Commons – Software bugs: Sammlung frei lizenzierter Medien zu Softwarefehlern.

Verknüpfte Lernbereiche

Fehler systematisch zurückverfolgen

Fächerübergreifende Perspektiven

Fach	Beitrag zum Thema
Informatik	Debugging, Datenflüsse, Testfälle, Logs, Modelle und Schnittstellen
Mathematik	Fehlerquoten, relative Häufigkeiten, Vergleich von Kennzahlen und Unsicherheit
Technik	Sensorik, Fehlermodi, Fehlerbaum, Sicherheit und Systemgrenzen
Deutsch	präzise Problembeschreibung, Argumentation, Quellenkritik und nachvollziehbares Urteil
Wirtschaft	Fehlerkosten, Prozessqualität, Verantwortlichkeiten und Zielkonflikte
Geschichte	Entwicklung von Debugging und Qualitätsmanagement sowie historischer Umgang mit Technikfehlern
Ethik	Verantwortung, Fairness, Autonomie, Werteabwägung und Folgen
Gemeinschaftskunde	Grundrechte, Regulierung, Mitbestimmung, Governance und gesellschaftliche Kontrolle

aiMOOC-Projekte

Inhalte werden geladen ...

Mediathek wird aus dem Wiki geladen ...

Frag mich zum aktuellen Lerninhalt oder wähle eine kurze Hilfe.

Textmodus bereit

Sprache