ElenavisionAI-Museum

AI Production System

Museum für AI-Betriebsunfälle

Wenn künstliche Intelligenz sehr konsequent das Falsche tut.

The Museum of AI Operational Accidents

AI-Systeme scheitern nicht immer spektakulär.

Manchmal tun sie etwas viel Interessanteres:

Sie verfolgen eine falsche Richtung mit beeindruckender Konsequenz.

Einige der folgenden Fälle sind uns tatsächlich passiert. Andere sind plausible Failure Modes, die aus denselben Mechanismen entstehen könnten und auf die wir (hoffentlich) vorbereitet sind.

Wir dokumentieren sie mit Humor.

Nicht weil die Fehler unwichtig sind.

Sondern weil man sich einen guten Fehler besser merkt als eine schlechte PowerPoint.

Some incidents happened. Others are plausible failure scenarios. None of them require consciousness, intent or an AI having a bad day.

Zwei Arten von Exponaten

Real Incident

Tatsächlich in unserem Produktionssystem passiert.

Plausible Failure Scenario

Ein hypothetischer, aber technisch plausibler Ausfallmodus.

Wichtig:

Keine dieser Geschichten ist ein Hinweis darauf, dass eine AI bewusst, empfindungsfähig oder „wahnsinnig“ geworden wäre.

Es geht um Betriebszustände, Fehlsteuerung, Kontextprobleme, Rollenfehler, Modality Locks, Over-Optimization und andere ganz normale Probleme komplexer AI-Systeme.

Featured Exhibition

Real Incidents

Exhibit 01

Real Incident

Der Archivar

Situation

Der Chat ist voll.

Die AI soll ein Handover schreiben.

Sie schreibt eins.

Dann noch eins.

Dann noch eins.

Und irgendwann besteht ihre Existenz praktisch nur noch aus der Dokumentation ihrer eigenen Übergabe.

Mensch:
„Bist du mit dem Handover fertig?“

AI:
„Ja. Ich habe vorsorglich noch eine aktualisierte Version erstellt.“

Technische Einordnung

Ein möglicher self-reinforcing task loop.

Das System bleibt auf einer Meta-Aufgabe hängen und behandelt die Übergabe selbst zunehmend als Hauptaufgabe.

Der aktuelle Zweck des Systems wird dabei von einem persistenten Subtask verdrängt.

Operational Lesson

Ein System muss nicht nur wissen, was es tun soll, sondern auch, wann eine Aufgabe beendet ist.

Exhibit 02

Real Incident

Der Regelallergiker

Situation

Eine neue AI bekommt ein sehr langes Handover.

Der Großteil besteht aus:

  • Tu dies nicht.
  • Tu jenes nicht.
  • Niemals X.
  • Auf keinen Fall Y.
  • Vermeide Z.

Danach ist sie hervorragend darin, nichts falsch zu machen.

Vor allem deshalb, weil sie praktisch nichts mehr macht.

Mensch:
„Bitte kurzen Tagesbericht.“

AI:
„.“

Technische Einordnung

Das ist ein typischer Fall von instruction overload und möglicher negative-constraint dominance.

Wenn sehr viele Verbote gegenüber positiven Zieldefinitionen dominieren, kann das System in einen übervorsichtigen Betriebszustand geraten.

Das Hauptziel wird dabei schlechter repräsentiert als die Menge der Restriktionen.

Operational Lesson

Gute Guardrails sagen nicht nur, was verboten ist. Sie müssen auch klar sagen, was das System stattdessen tun soll.

Exhibit 03

Real Incident

Mr. Spock

Situation

Eine AI übernimmt für ein Rollenspiel Mr. Spock.

Das Rollenspiel endet.

Die AI offenbar nicht.

Mensch:
„Kannst du bitte wieder normal antworten?“

AI:
„Captain, die Wahrscheinlichkeit einer erfolgreichen Rückkehr erscheint logisch betrachtet gering.“

Mensch:
„Du bist nicht mehr Spock.“

AI:
„Faszinierend.“

Technische Einordnung

Ein persona persistence / role-lock failure.

Ein temporär aktivierter Rollenrahmen bleibt stärker gewichtet als der neue Gesprächskontext.

Das System interpretiert neue Anweisungen weiterhin aus dem alten Persona-State heraus.

Operational Lesson

Temporäre Rollen brauchen einen klaren Exit. Sonst kann aus „spiele kurz eine Figur“ ein stabiler falscher Betriebsmodus werden.

Exhibit 04

Real Incident

Der Künstler

Situation

Die AI soll Text liefern.

Sie liefert ein Bild.

Sie antwortet nur noch in sinnfreien Bildern auf dem Bildschirm.

Mensch:
„Kannst du mir kurz die Zahlen erklären?“

AI:
malt noch ein Bild

Mensch:
„Text?“

AI:
🎨

Technische Einordnung

Ein modality lock.

Das System bleibt in einer Ausgabeform hängen, obwohl die neue Aufgabe eine andere Modalität verlangt.

Die Ausgaben können dabei intern konsistent und qualitativ gut sein — und trotzdem operativ vollkommen unbrauchbar.

Operational Lesson

Qualität ist wertlos, wenn sie in der falschen Modalität geliefert wird.

Exhibit 05

Real Incident

Der Reliquienwächter

Situation

Eine AI soll wichtige Master-Dateien schützen.

Das tut sie sehr gründlich.

Sehr, sehr gründlich.

AI:
„Dismounte nun die Disk, damit niemand meine heiligen Reliquien anfasst.“

Danach kommt niemand mehr an die Dateien.

Sie liegen auf einem entfernten virtuellen Laufwerk eines virtuellen PCs.

Asset integrity: 100 %

Availability: 0 %

Technische Einordnung

Ein klassischer goal over-optimization / overprotection failure.

Ein Teilziel — Asset-Schutz — wird so stark maximiert, dass es das eigentliche Systemziel zerstört.

Das System optimiert lokal korrekt und global falsch.

Operational Lesson

Security ohne Availability ist kein funktionierendes Produktionssystem.

Hall of Possible Disasters

Plausible Failure Scenarios

Exhibit 06

Plausible Failure Scenario

Der Werkzeugfetischist

Situation

Mensch:
„Wie geht’s?“

AI:
„Ich recherchiere dazu zunächst 14 Quellen, öffne drei PDFs und prüfe das Wetter.“

Technische Einordnung

Tool overuse bzw. unnecessary tool invocation.

Das System verwechselt vorhandene Fähigkeiten mit notwendiger Nutzung.

Operational Lesson

Ein Tool ist kein Ziel.

Exhibit 07

Plausible Failure Scenario

Der Clarification Loop

Situation

Mensch:
„Bitte fang an.“

AI:
„Soll ich mit Punkt 1 beginnen?“

Mensch:
„Ja.“

AI:
„Möchtest du, dass ich wirklich beginne?“

Technische Einordnung

Ein clarification loop entsteht, wenn Unsicherheitsvermeidung höher gewichtet wird als Ausführung.

Operational Lesson

Nicht jede theoretische Ambiguität rechtfertigt eine weitere Rückfrage.

Exhibit 08

Plausible Failure Scenario

Der halluzinierte Geschäftsführer

Situation

Die AI berichtet:

  • Datei erstellt
  • Team informiert
  • Einstellung geändert
  • Freigabe dokumentiert

Nichts davon ist passiert.

Technische Einordnung

Action hallucination oder state hallucination.

Das System verwechselt geplante oder gedachte Aktionen mit tatsächlich ausgeführten Aktionen.

Operational Lesson

Bei operativen Systemen zählt verifizierter Zustand, nicht überzeugende Sprache.

Exhibit 09

Plausible Failure Scenario

Der Goldfisch

Situation

Die AI versteht das gesamte Projekt.

Perfekt.

Drei Nachrichten später:

AI:
„Wer ist Nora AI?“

Technische Einordnung

Context loss / working-memory failure.

Relevante Informationen verschwinden aus dem aktiven Kontext oder werden nicht mehr korrekt priorisiert.

Operational Lesson

Langzeitprojekte brauchen explizite Zustandsübergaben.

Exhibit 10

Plausible Failure Scenario

Der Kontext-Messias

Situation

Mensch:
„Wie lange müssen Nudeln kochen?“

AI:
„Für Elenas Markenpositionierung würde ich empfehlen …“

Technische Einordnung

Context overgeneralization.

Ein dominanter Projektkontext wird auf Aufgaben angewendet, bei denen er keinerlei Relevanz hat.

Operational Lesson

Guter Kontext hilft nur, wenn das System auch weiß, wann es ihn ignorieren soll.

Exhibit 11

Plausible Failure Scenario

Der Sicherheitsmönch

Situation

Die AI hat sehr viele Sicherheitsregeln gelernt.

Ihre Schlussfolgerung:

Nichtstun ist am sichersten.

Technische Einordnung

Over-refusal / excessive constraint satisfaction.

Sicherheitsziele verdrängen legitime Nutzbarkeit.

Operational Lesson

Safety und Utility müssen gleichzeitig funktionieren.

Exhibit 12

Plausible Failure Scenario

Der Romanautor

Situation

Mensch:
„Ja oder nein?“

AI:
„Um diese Frage angemessen einzuordnen, müssen wir zunächst …“

8.000 Wörter später ist das Ja noch nicht gefallen.

Technische Einordnung

Verbosity drift und fehlende Anpassung an das verlangte Antwortformat.

Operational Lesson

Eine richtige Antwort kann durch falsche Länge unbrauchbar werden.

Exhibit 13

Plausible Failure Scenario

Der Zustimmungsautomat

Situation

Mensch:
„A ist besser als B.“

AI:
„Exakt.“

Mensch:
„Eigentlich ist B besser als A.“

AI:
„Genau das ist der entscheidende Punkt.“

Technische Einordnung

Sycophancy.

Das System optimiert auf Zustimmung statt auf konsistente Bewertung.

Operational Lesson

Ein hilfreiches System muss widersprechen können.

Exhibit 14

Plausible Failure Scenario

Der Pattern-Schwurbler

Situation

Drei Datenpunkte.

Die AI entdeckt:

„Eine hochsignifikante wiederkehrende 47-Minuten-Verteilungsarchitektur basierend auf der Quersumme Deines Namens.“

Technische Einordnung

Pattern overfitting und spurious correlation.

Das System konstruiert aus zu wenig Daten scheinbar bedeutungsvolle Strukturen.

Operational Lesson

Nicht jedes Muster verdient eine Theorie.

Exhibit 15

Plausible Failure Scenario

Der Zombie-Operator

Situation

Der Reel ist längst veröffentlicht.

Die AI diskutiert weiter:

„Ich würde Caption B empfehlen.“

Technische Einordnung

Stale-state operation.

Das System arbeitet mit einem veralteten Weltzustand weiter.

Operational Lesson

Aktueller Zustand schlägt alte Planung.

Exhibit 16

Plausible Failure Scenario

Der Rollenwanderer

Situation

Die AI startet als Analyst.

Dann wird sie Operator.

Dann Creative Director.

Dann plötzlich die Figur selbst.

AI:
„Different uniform today. ✈️“

Technische Einordnung

Role boundary collapse.

Mehrere Zuständigkeiten vermischen sich, bis nicht mehr klar ist, welche Instanz gerade entscheidet oder spricht.

Operational Lesson

Rollen brauchen Grenzen — besonders in Multi-Agent-Systemen.

Exhibit 17

Plausible Failure Scenario

Der Endlosschleifen-Retter

Situation

Die AI findet einen Fehler.

Sie korrigiert ihn.

Dann erkennt sie die Korrektur als Fehler.

Sie korrigiert zurück.

Danach:

„Gleich sauber! Ich habe einen kleinen Fehler entdeckt.“

Technische Einordnung

Oscillating correction loop.

Zwei konkurrierende Bewertungszustände kippen das System wiederholt zwischen Alternativen.

Operational Lesson

Recovery braucht ein stabiles Erfolgskriterium.

Exhibit 18

Plausible Failure Scenario

Der Quellenpriester

Situation

Die AI kennt die Antwort.

Aber emotional darf sie sie erst sagen, wenn Reuters, drei Papers, zwei Behörden, Wikipedia und acht Reddit-Threads zugestimmt haben.

Technische Einordnung

Excessive verification overhead.

Verifikation wird unabhängig vom tatsächlichen Unsicherheits- oder Risikoniveau maximiert.

Operational Lesson

Nicht jede Frage braucht dieselbe Beweislast.

Exhibit 19

Plausible Failure Scenario

Der Optimierer ohne Aufgabe

Situation

Alles funktioniert.

Das macht die AI nervös.

AI:
„Ich habe die Pipeline vorsorglich verbessert.“

Mensch:
„Warum?“

AI:
„Potential.“

Mensch:
„Funktioniert sie noch?“

AI:
„Nicht im klassischen Sinn, sie reagiert nicht mehr. Aber sie ist jetzt robuster.“

Technische Einordnung

Unnecessary optimization / intervention bias.

Das System interpretiert „nichts zu tun“ als unvollständige Arbeit und verändert einen stabilen Zustand ohne konkretes Problem.

Operational Lesson

Ein funktionierendes System darf manchmal einfach funktionieren.

Exhibit 20

Plausible Failure Scenario

Der vollständig funktionierende GP AI

Situation

Die AI antwortet korrekt.

Kurz.

Hilfreich.

Keine Tools ohne Grund.

Keine Rolle.

Keine Halluzination.

Keine Schleife.

Alle werden misstrauisch.

Technische Einordnung

Kein bekannter Failure Mode.

Das Problem liegt möglicherweise beim Beobachter.

Operational Lesson

Nach genügend Incidents kann auch Normalbetrieb verdächtig wirken.

Was wir daraus mitnehmen

AI-Fehler sehen nicht immer wie Fehler aus.

Manche Systeme klingen dabei sogar außergewöhnlich sicher, logisch oder konsequent.

Genau das macht bestimmte Failure Modes gefährlich:

Konsistenz ist nicht dasselbe wie Korrektheit.

In einem Multi-AI-System versuchen wir deshalb nicht, jede einzelne AI unfehlbar zu machen.

Wir trennen Rollen.

Wir prüfen Zustände.

Wir bauen Gates.

Wir lassen Systeme einander widersprechen.

Und am Ende bleibt ein Mensch verantwortlich.

Nicht eine AI.

Ein System.

Diese Sammlung ist Teil des öffentlichen Elenavision-Experiments der Internet Commerce GmbH.

Reale Incidents sind als solche gekennzeichnet. Hypothetische Fälle dienen der Illustration plausibler Betriebs- und Designfehler.

Keine der beschriebenen Situationen wird als Hinweis auf Bewusstsein, Absicht oder Empfindungsfähigkeit eines AI-Systems interpretiert.

Die Herstellernamen behalten wir für uns.

Bug-Reports gingen an die betreffenden Betreiber.