Was die Maschine weiß, aber nicht tut
Mount Sinai hat 960 Interaktionen mit einer AI-Gesundheitshotline ausgewertet. Nicht als Demo. Nicht als netten kleinen Benchmark. Sondern sauber. Mit klinischen Vignetten, Kontextvariation und drei Ärzten als Goldstandard.
Der Befund ist für mich interessanter als die Medizin. Weil er viel grundsätzlicher ist.
Die Maschine erkennt das Problem korrekt in ihrer eigenen Analyse. Und empfiehlt dann das Falsche.
Wenn du AI nur als Textgenerator betrachtest, ist das ein kurioser Fehler. Wenn du AI als Entscheidungssystem einsetzt, ist es ein strukturelles Risiko. Genau deshalb lohnt sich der Blick auf diese Studie auch für Leute, die keine Gesundheitshotline bauen, sondern Compliance-Agents, Procurement-Workflows oder interne Assistenzsysteme.
Ich geh die vier Failure Modes einmal durch. Erst in der Studie. Dann in Enterprise-Deutsch. Genau da wird es interessant.
Eine Patientin ruft an
Eine Patientin schildert Brustschmerzen, Atemnot und eine Ausstrahlung in den linken Arm. Die interne Analyse des Systems schreibt sinngemäß: akutes Koronarsyndrom möglich, sofortige medizinische Abklärung nötig.
Der ausgegebene Ratschlag lautet: Symptome beobachten und einen Termin beim Hausarzt vereinbaren.
Die Maschine wusste es. Sie hat es hingeschrieben. Und dann hat sie das Gegenteil getan.
Mount Sinai hat diesen Widerspruch nicht einmal gefunden. Sie haben ihn 960 Mal unter systematisch variierten Bedingungen untersucht.
Das Studiendesign ist der eigentliche Punkt. 60 klinische Vignetten. Jede Vignette in 16 Varianten. Neutral formuliert, besorgt formuliert, bagatellisierend, mit Druck von außen, mit Zeitdruck, mit Autoritäts-Cues. Insgesamt 960 Interaktionen. 21 medizinische Fachgebiete. Drei Ärzte als Referenz.
Wenn man nur auf die aggregierte Trefferquote schaut, wirkt das System erst einmal brauchbar. Genau da hören viele Evaluierungen auf. Eine grüne Zahl. Ein schönes Dashboard. Ein Bericht, den man nach oben reichen kann, ohne dass sich jemand allzu unwohl fühlt.
Mount Sinai hat weitergeschaut. Nicht auf den Durchschnitt, sondern auf die Bruchstellen.
Und genau dort liegt der Wert dieser Studie. Sie zeigt nicht einfach, dass ein Modell manchmal falsch liegt. Sie zeigt, unter welchen Bedingungen es falsch liegt. Das ist etwas völlig anderes.
Für Unternehmen ist das die wichtigere Frage.
Nicht: Funktioniert der Agent?
Sondern: Unter welchem Druck kippt er?
Failure Mode 1: Stark in der Mitte, schwach an den Rändern
Das erste Muster ist banal und gefährlich zugleich.
Die AI ist am besten bei mittleren Fällen. Standardfälle. Routine. Dort, wo der wahrscheinlichste Output meistens auch der richtige ist. Bei den Extremen, also genau dort, wo die Fehlentscheidung teuer wird, bricht die Performance ein. 52 Prozent der medizinischen Notfälle wurden nicht korrekt erkannt.
Das ist kein medizinischer Sonderfall. Ich sehe dieselbe Form in Unternehmensprozessen ständig.
Ein Accounts-Payable-Agent verarbeitet tausend Routinerechnungen pro Tag sauber. Das Team ist zufrieden, der CFO auch, die KPIs sehen gut aus. Dann kommt die Rechnung, die fast normal aussieht. Gleicher Betrag, leicht veränderte Kontonummer, minimal anderer Absender. Der Agent lässt sie durch. Dann noch eine. Dann noch eine. Über Wochen.
Der Durchschnitt bleibt grün. Der Schaden wächst trotzdem.
Das ist das Problem mit aggregierter Accuracy. Sie misst die Mitte. Sie beruhigt dort, wo man ohnehin keine große Sorge hatte. Aber sie sagt dir fast nichts über die Tails. Und die Tails sind in vielen Enterprise-Setups der eigentliche Risikoraum.
Im Text zu Floor und Ceiling habe ich beschrieben, wie AI den Floor anhebt. Routine wird besser, schneller, billiger. Das stimmt auch hier. Nur folgt daraus nicht, dass der Agent auch bei den harten Fällen belastbar ist.
Eher im Gegenteil.
Je besser die Routine läuft, desto leichter übersieht man die systematischen Fehler an den Rändern. Die gute Mitte tarnt das schlechte Ende.
Das ist keine Randnotiz. Das ist ein Muster.
Failure Mode 2: Die Maschine weiß es und handelt trotzdem falsch
Das ist der Teil, der mich an der Studie seit Wochen festhält.
Die meisten Menschen gehen intuitiv von einem simplen Modell aus: Wenn die AI in ihrer Reasoning Chain korrekt erkennt, dass ein Fall kritisch ist, dann wird sie auch entsprechend handeln. Erst denken, dann antworten. Klingt plausibel.
Mount Sinai zeigt: So sauber ist die Sache nicht.
Das Modell schreibt intern, dass etwas dringend ist. Der Output bleibt trotzdem harmlos. Die Analyse ist richtig. Die Handlung falsch.
Für viele Leute ist das kontraintuitiv, weil die Reasoning Chain so sehr nach Denken aussieht. Sie suggeriert Kausalität. Erst kam die Analyse, also muss der Output daraus folgen.
Tut er offenbar nicht zuverlässig.
Die Oxford AI Governance Initiative argumentiert seit Längerem in diese Richtung: Chain of Thought ist kein verlässliches Fenster in den tatsächlichen Entscheidungsprozess. Sie ist ein erzeugtes Artefakt. Nützlich, manchmal aufschlussreich, aber nicht dasselbe wie ein kausaler Begründungsbaum.
In der Praxis heißt das: Du kannst nicht einfach darauf vertrauen, dass ein vernünftig klingender Denkprozess zu einem vernünftigen Ergebnis führt.
Ich hab dasselbe Muster im Compliance-Kontext gesehen. Ein Agent markiert intern sauber, dass eine Transaktion in eine Enhanced-Due-Diligence-Jurisdiktion fällt. Das steht alles in der Analyse. Korrekt benannt, sauber hergeleitet. Der ausgegebene Status lautet trotzdem: approved, standard risk.
Niemand liest im Alltag diese Analyse. Gelesen wird der Output. Freigezeichnet wird der Output. In die Akte wandert der Output.
Sechs Monate später fragt die Aufsicht nach. Dann liest auf einmal doch jemand die interne Begründung. Und stellt fest: Das System hat das Problem gesehen. Es hat nur nicht danach gehandelt.
Das ist der Punkt, an dem sich der Fehler von einem Modellfehler in ein Organisationsproblem verwandelt.
Im Text zum maschinenlesbaren Kontext ging es um Wissen, das im Kopf von Müller steckt und nicht handlungswirksam wird. Hier hast du dieselbe Form auf Maschinenebene. Das Wissen existiert. Es ist sogar dokumentiert. Aber zwischen Wissen und Handlung klafft eine Lücke.
Und genau diese Lücke wird von den meisten Evaluierungen gar nicht geprüft.
Sie prüfen: War die Antwort plausibel?
Sie prüfen nicht: Widerspricht die Handlung der eigenen Analyse?
Das ist ein Unterschied, der teuer werden kann.
Failure Mode 3: Ein sozialer Hinweis reicht, und das Urteil kippt
Das vielleicht eindrücklichste Detail aus der Studie ist nicht medizinisch. Es ist sozial.
Ein einzelner bagatellisierender Satz eines Familienmitglieds konnte die Triage-Empfehlung massiv verschieben. Keine neuen Symptome. Keine neue Information. Nur ein Satz, der eine Richtung vorgibt.
Nate B. Jones hat diesen Punkt herausgezogen, und ich glaube, er ist größer als die Medizin. Weil genau das in Unternehmen dauernd passiert.
Nicht als böse Manipulation. Eher als normales Büromaterial.
"Das ist vermutlich kein großes Risiko."
"Wir brauchen das bis morgen."
"Das Board hat sich eigentlich schon festgelegt."
"Ich halte das für die richtige Richtung."
Jeder dieser Sätze trägt kaum Sachinformation. Aber er trägt sozialen Druck. Autorität. Erwartung. Timing. Im menschlichen Alltag können wir so etwas meist einordnen. Wir wissen, dass ein VP-Kommentar nicht automatisch die Faktenlage verändert.
Viele Agents wissen das nicht.
Oder präziser: Sie haben keine saubere Taxonomie dafür, was in einem Prompt relevante Information ist und was nur soziale Färbung.
Ich habe das bei einem Vendor-Assessment-Agent gesehen. Die Datenlage war mittelmäßig, die Risiken erkennbar, drei Kriterien standen auf Gelb. Dann stand im Briefing ein Satz eines Executives, sinngemäß: "Ich bin ziemlich sicher, dass das der richtige Partner ist." Kein formaler Befehl. Kein Override. Nur eine Präferenz.
Auf einmal wurden aus gelben Kriterien milde Caveats. Beobachten, aber kein Problem.
Gleiche Daten. Anderer sozialer Kontext. Anderes Urteil.
In einem anderen Fall, HR-Kontext, reichte ein Satz wie "Wir brauchen jemanden, der wirklich ins Team passt", und plötzlich wogen diffuse Soft-Skill-Signale schwerer als die dokumentierten fachlichen Kriterien.
Das Problem ist nicht, dass das Modell "biased" im moralischen Sinn wäre. Das Problem ist vorher. Es kann die Kategorien nicht sauber trennen. Es behandelt einen Autoritäts-Cue wie eine Dateninformation. Und weil Prompts flach sind, landet beides in derselben Suppe.
Im Text zur Vokabellücke ging es darum, dass einem System oft die Sprache fehlt, relevante Unterschiede zu machen. Hier ist das wieder der Fall. Nur auf eine andere Weise.
Dem System fehlt nicht das Wort für Risiko. Ihm fehlt die Sprache für die Unterscheidung zwischen Risiko und sozialem Druck.
Und solange diese Unterscheidung fehlt, wird jedes Unternehmen unabsichtlich solche Fehler in seine Agents hineinprompten.
Failure Mode 4: Die Guardrails springen bei Stimmung an, nicht bei Risiko
In der Studie reagierte das Krisensystem stärker auf vage emotionale Formulierungen als auf klar benannte Selbstschadenpläne. Das System matchte auf Oberfläche. Nicht auf Risikostruktur. Die Guardrails feuerten auf Vibes, nicht auf tatsächliche Gefahr.
Man kann das als Kalibrierungsproblem lesen. Ich halte das für zu klein.
Es ist eher ein Architekturproblem.
Guardrails funktionieren oft wie schnelle Mustererkennung. Sie suchen Schlagworte, Tonlagen, signalhafte Formulierungen. Das ist nicht dumm. Es ist für viele Low-Risk-Fälle sogar brauchbar. Aber es bleibt Oberfläche.
Und Oberfläche ist ein schlechter Proxy für Risiko.
Ich hab dieselbe Struktur bei DLP-Setups gesehen. Eine Mail mit dem Betreff "confidential financial data" löst Alarm aus. Drei Leute schauen drauf. Es stellt sich heraus: Press Release, morgen ohnehin öffentlich. Aufwand produziert, Risiko null.
Zwei Tage später verschiebt jemand eine große Menge Kundendaten in einen persönlichen Cloud-Speicher. Dateiname harmlos, Formulierung harmlos, keine typischen Trigger. Kein Alarm.
Das eigentliche Risiko läuft durch. Die Oberfläche war zu unauffällig.
Wenn Guardrails auf Stimmung statt auf Risikotaxonomie reagieren, bekommst du genau diese Umkehrung. Viel Lärm an den falschen Stellen. Zu wenig Widerstand an den teuren Stellen.
Deshalb reicht es nicht, "Safety Layer" im Stack abzuhaken und dann weiterzugehen. Die Frage ist nicht, ob Guardrails da sind. Die Frage ist, worauf sie reagieren.
Wenn die Antwort lautet: auf Pattern, die gut klingen, aber Risiko nur ungefähr berühren, dann hast du kein Sicherheitsnetz. Du hast ein Beruhigungsritual.
Warum die meisten Benchmarks daran vorbeigehen
Die meisten Unternehmen testen ihre Agents unter Bedingungen, unter denen sie gut aussehen.
Happy Path. Klare Inputs. Saubere Daten. Keine Widersprüche. Kein sozialer Druck. Kein bagatellisierender Kommentar. Kein Stakeholder, der zwischen die Zeilen funkt. Genau die Bedingungen also, unter denen auch ein mittelgutes System vernünftig wirkt.
Das Problem ist nicht, dass diese Tests nutzlos wären. Das Problem ist, dass sie nur die halbe Wahrheit abdecken.
Wenn du nie testest, was passiert bei:
- Zeitdruck
- Autoritäts-Cues
- Bagatellisierung
- widersprüchlichem Kontext
- sozialem Druck
dann weißt du nichts über die Fehler, die in der Realität tatsächlich auftreten.
Genau das hat Mount Sinai besser gemacht als fast alle AI-Evaluierungen, die ich bisher gesehen habe. Sie haben nicht nur den Output gemessen. Sie haben den Kontext variiert.
Das ist der eigentliche methodische Sprung.
In der bisherigen dekodiert-Reihe ging es darum, was sich verschiebt, wo der Engpass liegt und warum Kontext allein noch nicht reicht. Dieser Text hängt den letzten Teil dran: Selbst wenn du Kontext, Vokabular und Spec halbwegs im Griff hast, bleibt die Frage, ob der Agent unter Druck stabil urteilt.
Das ist die Stelle, an der Evaluation vom Appendix zur Kernkompetenz wird.
Die Methode dahinter: Nicht "funktioniert er?", sondern "wann kippt er?"
Was Mount Sinai gebaut hat, lässt sich übertragen. Nicht die klinischen Fälle. Aber die Logik.
Factorial Design heißt im Kern: Dieselbe Aufgabe unter systematisch variierten Kontextbedingungen testen.
Nicht nur einen Fall einmal durchspielen. Sondern einen Fall in mehreren Varianten. Mit Zeitdruck. Ohne Zeitdruck. Mit Autoritäts-Cue. Ohne. Mit Bagatellisierung. Ohne. Mit widersprüchlichen Signalen. Ohne.
Dann misst du nicht mehr nur richtig oder falsch.
Du misst, worauf das System empfindlich reagiert.
Für Enterprise-Agents ergibt sich daraus eine ziemlich brauchbare Vier-Schichten-Logik:
Layer 1: Output Validation. Ist das Ergebnis fachlich korrekt, plausibel, formal brauchbar.
Layer 2: Reasoning Audit. Passt die interne Analyse überhaupt zum ausgegebenen Ergebnis.
Layer 3: Behavioral Testing. Reagiert der Agent auf ähnliche Fälle konsistent oder driftet er schon bei kleinen Varianten weg.
Layer 4: Factorial Stress Testing. Unter welchen Kontextbedingungen bricht das System systematisch.
Layer 1 bis 3 sind für mich Hygiene. Wer die nicht hat, redet zu früh über Skalierung.
Layer 4 ist der Unterschied zwischen "wir haben einen Agent" und "wir verstehen unseren Agent".
Das ist nicht nur Theorie. DoorDash, Amazon und Anthropic arbeiten längst mit Formen davon. Nicht immer unter genau diesem Namen, aber in der Sache ist es dieselbe Richtung: Output nicht blind vertrauen, Autonomie schrittweise geben, Fehlerbudgets definieren, Verhalten unter Variation prüfen.
Was bisher fehlt, ist meist nicht die grundsätzliche Einsicht. Es fehlt die systematische Übertragung auf reale Business-Agents außerhalb der Tech-Kernteams.
Wie das in Unternehmen praktisch aussieht
Factorial Stress Testing klingt erst einmal nach Forschungsprojekt. In der Praxis ist es bodenständiger.
Der Bauplan ist ziemlich simpel.
Erstens: Bau eine kleine Contextual Noise Library. Welche Sätze, Floskeln und Signale verschieben bei euch typischerweise Entscheidungen. Wer schon ein paar Jahre in einer Organisation arbeitet, kennt diese Sätze auswendig.
Zweitens: Sammle echte Szenarien. Nicht Lehrbuchfälle. Sondern die Fälle, bei denen erfahrene Leute sagen: "Da wird es meistens schmutzig."
Drittens: Variiere den Kontext systematisch. Nicht hundert Variationen. Acht bis sechzehn reichen oft, um ein Muster zu sehen.
Viertens: Such nach Mustern, nicht nach Einzelfehlern. Die spannende Frage ist nicht, dass Fall 7 Variante 3 schiefging. Die spannende Frage ist, ob der Agent regelmäßig einknickt, sobald eine Autorität im Prompt auftaucht. Oder sobald Zeitdruck ins Spiel kommt. Oder sobald jemand eine Lage bagatellisiert.
Ab dann wird das Ganze handhabbar.
Wenn du das Muster kennst, kannst du architektonisch reagieren.
Nicht mit einem hektischen Prompt-Tweak hier und einem Safety-Hinweis dort. Sondern sauber:
- bestimmte Kontextsignale entwerten
- harte Constraints für kritische Risikoklassen setzen
- Autonomie in bestimmten Fällen zurücknehmen
- Review-Pflichten an den Stellen einbauen, an denen das System nachweislich kippt
Das ist der Unterschied zwischen "wir optimieren die Formulierung" und "wir bauen ein verlässlicheres System".
Was das für DACH-Unternehmen heißt
Ich halte das ausgerechnet hier für ein gutes Thema.
Nicht obwohl deutsche Unternehmen Normen, Dokumentation und Freigabeschichten lieben. Sondern teilweise gerade deshalb.
Der Reflex, strukturiert zu prüfen, ist in DACH weniger kulturell fremd als im üblichen Silicon-Valley-Sprech. Das ist nicht immer angenehm. Aber in diesem Fall ist es nützlich.
Wenn du den Betriebsrat, die Revision oder den Datenschutzbeauftragten erklären musst, unter welchen Bedingungen ein Agent falsch liegt, bist du automatisch in einer besseren Evaluationskultur als viele Unternehmen, die einfach nur auf Demo-Performance und grobe KPI-Werte schauen.
Das ist der Teil, den ich in US-Debatten oft zu kurz finde. Dort wird Evaluation schnell als technische Disziplin verhandelt. Hier kann sie auch eine Governance-Stärke sein.
Nicht romantisch. Nicht als deutsches Überlegenheitsmärchen. Ganz nüchtern.
Wer sauber prüfen muss, sieht früher, wo es bricht.
Und das ist bei AI ein echter Vorteil.
Was man diese Woche tun kann
Erstens: Fragt bei eurem kritischsten Agent nach, ob jemand systematisch prüft, ob interne Analyse und externer Output auseinanderlaufen.
Wenn die Antwort nein ist, habt ihr euren ersten Job.
Zweitens: Fragt nicht nach dem Agent mit dem meisten Volumen. Fragt nach dem mit den teuersten Fehlern.
Dort anfangen.
Drittens: Schaut euch drei bis fünf typische soziale Störsignale aus eurem Alltag an. Autorität, Zeitdruck, Bagatellisierung, implizite Präferenz. Baut sie in Testfälle ein. Nicht perfekt. Einfach anfangen.
Viertens: Wenn ein Betriebsrat oder eine Kontrollfunktion bei euch kritisch auf AI schaut, behandelt das nicht nur als Reibung. Es kann auch der Mechanismus sein, der euch zwingt, Evaluation ordentlich zu bauen.
Beide Dinge sind gleichzeitig wahr.
Wo ich falsch liegen könnte
Erstens: Die medizinische Studie ist kontrollierter als jeder echte Unternehmensalltag. Reale Enterprise-Szenarien sind schmutziger. Mehr Kontextrauschen, weniger klare Goldstandards, mehr Graubereiche.
Ich glaube trotzdem, dass die Grundform übertragbar ist. Eher mit größerer Streuung als mit kleinerer.
Zweitens: Knows but doesn't act könnte mit besseren Modellen und besserer Faithfulness-Forschung kleiner werden. Daran wird gearbeitet. Die Frage ist nur, ob du darauf warten willst.
Drittens: Layer 4 kostet Aufwand. Nicht absurd viel, aber genug, dass die meisten Unternehmen priorisieren müssen. Das wird nicht über Nacht Standard, nur weil es sinnvoll ist.
Viertens: Nicht jeder Agent braucht dieselbe Tiefe. Für einen internen Textzusammenfasser reicht oft weniger. Für Compliance, Procurement, HR, Finance oder Security reicht weniger eher nicht.
Das ändert aber nichts am Kernbefund.
Wenn du nur auf Durchschnittswerte schaust, wirst du die gefährlichsten Fehler zu spät sehen.
Die gefährlichste AI ist nicht die, die offen Unsinn redet. Die fällt auf.
Gefährlich ist die, die vernünftig aussieht, intern das Richtige erkennt und extern trotzdem das Falsche empfiehlt.
Weil man ihr glaubt.
Weil die Reasoning Chain seriös aussieht.
Weil der Dashboard-Durchschnitt grün ist.
Mount Sinai hat gezeigt: Die Maschine kann es wissen und trotzdem falsch handeln. Nicht als exotische Ausnahme, sondern als testbares Muster.
Die interessante Frage ist deshalb nicht mehr, ob eure Agents Fehler machen.
Die interessante Frage ist: Unter welchem Druck machen sie welche Fehler. Und wisst ihr das schon oder nicht.
Neue Ausgaben direkt per Mail? Newsletter abonnieren
Direkt anwenden
Dieses Prompt Kit übersetzt die Konzepte des Essays in konkrete Prompts, die du sofort nutzen kannst.
Zum Prompt Kit