KI-Risiken sind Projektrisiken

Die auffälligste KI-Panne ist oft nicht die gefährlichste.

Eine frei erfundene Quelle, ein nicht existierendes Gerichtsurteil oder eine offensichtlich falsche Zahl fällt mit etwas Aufmerksamkeit auf. Schwieriger wird es, wenn eine Antwort zu 95 Prozent plausibel ist, aber an einer kleinen Stelle eine falsche Voraussetzung verwendet, einen Begriff verwechselt, einen Zwischenschritt überspringt oder eine veraltete Information so überzeugend in einen korrekten Zusammenhang einbaut, dass der Fehler unsichtbar mitwandert.

Genau dort wird aus einem Modellfehler ein Projektrisiko.

Professionelle Qualitätskontrolle fragt nicht nur, ob eine KI halluziniert. Sie fragt, welche Fehlerklassen in diesem Projekt relevant sind, wie sie sich fortpflanzen können, welche Kontrollen sie früh erkennen und wie viel Verifikation sich das Projekt real leisten kann.

Halluzination ist nur eine Fehlerklasse

Der Begriff „Halluzination“ ist populär, aber für Projektmanagement zu grob. Er lenkt den Blick auf erfundene Fakten, während viele reale Qualitätsprobleme anders aussehen.

Ein professioneller Risikokatalog sollte mindestens unterscheiden:

Damit verschiebt sich die Frage von „Ist das Modell gut?“ zu: Welche Fehler darf dieser konkrete Workflow nicht durchlassen?

Der gefährlichste Fehler klingt oft vernünftig

Offensichtliche Halluzinationen besitzen einen Vorteil: Sie können Verdacht erzeugen.

Subtile Fehler besitzen diesen Vorteil nicht. Sie passen in Sprache, Ton, Format und Argumentationsstruktur. Ein Modell kann zehn korrekte Fakten nennen und daraus eine falsche Priorität ableiten. Es kann eine richtige Rechtsnorm verwenden, aber auf die falsche Organisationsrolle anwenden. Es kann einen technisch funktionierenden Code erzeugen, der einen Edge Case falsch behandelt. Es kann in einer Marktanalyse alle Quellen korrekt zitieren und trotzdem Ursache und Korrelation verwechseln.

Je professioneller die Oberfläche, desto gefährlicher kann der Vertrauenseffekt werden.

Qualitätskontrolle darf deshalb nicht nur die offensichtlichen Fehler suchen. Sie muss die Stellen markieren, an denen eine plausibel klingende Antwort entscheidungswirksam wird.

Eine wichtige Quellenkorrektur: Deloitte statt „Lloyd“

Im zugrunde liegenden Projektmaterial wird ein australischer Beratungsfall als „Lloyd-Skandal“ bezeichnet. Der belastbare öffentlich dokumentierte Fall ist jedoch der Deloitte-Australia-Bericht für das australische Department of Employment and Workplace Relations.

Der Bericht enthielt unter anderem nicht existente akademische Referenzen und ein falsches Zitat aus einer Gerichtsentscheidung. Deloitte veröffentlichte eine korrigierte Fassung und erstattete einen Teil des Honorars.^[5]

Für diesen Artikel ist nicht die Firmenmarke entscheidend, sondern der Kontrollfehler:

Ein professionell aussehendes Deliverable erreichte den Kunden, obwohl zentrale Behauptungen nicht sauber gegen Primärquellen verifiziert waren.

Das ist ein Projektmanagementproblem, nicht nur ein Sprachmodellproblem.

Qualität muss ins Risikoregister

In klassischen Projekten werden Termine, Budget, Lieferanten, Ressourcen, Scope und Abhängigkeiten als Risiken behandelt.

Bei KI-Projekten kommen zusätzliche Qualitätsrisiken hinzu:

Falsche Fakten, nicht belegte Behauptungen, inkonsistente Versionen, unerkannte Edge Cases, fehlerhafte Tool-Aufrufe, unvollständige Reviews, Modell- oder Providerwechsel, instabile Outputs, Kontextverlust, fehlerhafte Evaluierungen — und menschliche Prüfkapazität als Engpass.

Diese Risiken gehören nicht in eine Fußnote. Sie brauchen Owner, Wahrscheinlichkeit, Auswirkung, Detection-Mechanismus und Response.

Surface Correctness ist nicht Semantic Correctness

Ein Output kann formal perfekt aussehen und inhaltlich falsch sein.

Deshalb sollten zwei Qualitätsdimensionen getrennt werden:

Surface Correctness

Format stimmt. Tabellen sind vollständig. Quellen sind syntaktisch vorhanden. Code kompiliert. Sprache ist professionell. Schema wird eingehalten.

Semantic Correctness

Aussage stimmt tatsächlich. Quelle trägt den Claim. Schlussfolgerung folgt aus der Evidenz. Prozesszustand entspricht der Behauptung. Randfälle sind angemessen berücksichtigt. Entscheidung ist für den konkreten Kontext gültig.

Automatisierung prüft Surface Correctness oft sehr gut. Professionelle Qualität entsteht erst, wenn Semantic Correctness ebenfalls kontrolliert wird.

Der Claim ist die kleinste prüfbare Einheit

Lange KI-Texte werden häufig als Ganzes geprüft: „Sieht gut aus“, „wirkt plausibel“, „Quellen sind drin“.

Das ist für kritische Inhalte zu grob.

Besser ist eine Claim-Level-Verifikation. Ein entscheidungsrelevanter Claim wird als Objekt betrachtet:

Was wird genau behauptet? Ist die Aussage deskriptiv, kausal, normativ oder prognostisch? Welche Evidenz soll sie tragen? Stützt die Quelle wirklich genau diese Aussage? Ist die Quelle aktuell und autoritativ genug? Welche Unsicherheit bleibt? Welche Projektentscheidung hängt daran?

Dadurch wird aus „Quellenprüfung“ ein reproduzierbarer Qualitätsprozess.

Nicht jede Aussage braucht dieselbe Prüftiefe

Vollständige Verifikation jedes Satzes wäre in großen Projekten unbezahlbar.

Deshalb braucht Qualität eine Risikoklassifikation von Claims.

Die Frage lautet nicht „Wie viel prüfen wir?“, sondern wo investieren wir unsere knappe Verifikationskapazität?

Der Review-Budget-Fehler

Ein häufiger Projektfehler besteht darin, KI-Output massiv zu skalieren, ohne die menschliche Review-Kapazität mitzudenken.

Wenn ein System in Minuten 50 Seiten produziert, entsteht daraus noch kein 50-Seiten-Ergebnis. Es entsteht zunächst ein 50-Seiten-Prüfauftrag.

Genau hier entsteht Verification Fatigue:

Reviewer lesen nur noch Überschriften. Wiederholte korrekte Passagen senken die Aufmerksamkeit. Plausible Sprache erzeugt Routinevertrauen. Zeitdruck macht Stichproben kleiner. Schwierige Claims werden eher überflogen als einfache. „Reviewed“ wird zu einem Statusfeld ohne reale Prüfhandlung.

Damit kann ein HITL-Prozess formal vorhanden und praktisch wirkungslos sein.

Verification Capacity ist eine Projektressource

Neben Budget, GPU-Zeit und Tokens sollte ein KI-Projekt Verification Capacity planen.

Sie besteht aus:

Verfügbarer Expertenzeit, geeigneten automatisierten Checks, unabhängigen Modellreviews, Testdaten, Referenzquellen, reproduzierbaren Evals und Zeit für strittige Fälle.

Ein Team, das 100 Einheiten Output erzeugen, aber nur zehn Einheiten ernsthaft verifizieren kann, besitzt kein 100-Einheiten-System. Es besitzt ein Qualitätsdefizit von 90 Einheiten.

Verification Debt

Wenn Output schneller entsteht als Verifikation, akkumuliert Verification Debt.

Typische Symptome:

Offene Claims ohne Quelle, ungeprüfte Agentenergebnisse, alte Evals für neue Modellversionen, Review-Queues, nur teilweise geprüfte Reports, „später nachholen“-Kommentare, unklare Freigaben.

Verification Debt ist gefährlich, weil sie selten sichtbar explodiert. Sie wird still in die nächste Projektphase übernommen und dort zur Eingabe für weitere KI-Arbeit.

Fehlerfortpflanzung: Ein kleiner Fehler wird Projektzustand

Bei agentischen Workflows kann ein einzelner früher Fehler mehrfach verstärkt werden.

Beispiel:

Ein Research-Agent übernimmt eine falsche Marktzahl. Der Planungs-Agent verwendet sie als Budgetannahme. Der Risiko-Agent bewertet den Business Case darauf. Der Präsentations-Agent visualisiert die Zahl überzeugend. Der Reviewer prüft nur die Präsentation und nicht den Ursprung. Die Entscheidung wird freigegeben.

Der ursprüngliche Fehler erscheint am Ende nicht mehr als unsichere Aussage, sondern als konsolidierter Projektzustand.

Deshalb muss Qualitätskontrolle möglichst nah an der Entstehung kritischer Information stattfinden.

Error Propagation Graph

Für komplexe Projekte lohnt eine einfache Abhängigkeitskarte:

Quelle → Claim → Annahme → Entscheidung → Artefakt → Aktion

Ein Claim mit hoher Downstream-Zentralität verdient höhere Prüftiefe als eine isolierte Nebenbemerkung.

Das ist oft effizienter als pauschal „alles doppelt prüfen“.

Cross-Model-Checks sind hilfreich – aber kein Ground Truth

Ein zweites Modell kann Fehler finden, Blindspots markieren oder alternative Argumente liefern. Ein drittes Modell kann einen Konflikt sichtbar machen.

Aber Modellkonsens ist kein Wahrheitsbeweis.

Mehrere Modelle können:

Dieselbe populäre Fehlinformation gelernt haben, dieselbe mangelhafte Quelle verwenden, dieselbe missverständliche Aufgabenstellung falsch interpretieren oder sich durch den vorgelegten ersten Output ankern lassen.

Cross-Model-Triangulation ist deshalb ein Disagreement Detector, kein Truth Oracle.

Der Reviewer muss unabhängig genug sein

Ein Reviewer, der exakt denselben Kontext, dieselbe Argumentation und dieselben Annahmen übernimmt wie der Erzeuger, ist nur begrenzt unabhängig.

Bessere Reviewer bekommen je nach Aufgabe:

Den ursprünglichen Auftrag, die Bewertungskriterien, die Primärquellen, eventuell den Output — aber nicht zwingend die gesamte Begründung des Erzeugers.

So reduziert man Anchoring und erzeugt echte Gegenprüfung.

Generator und Reviewer brauchen unterschiedliche Ziele

Der Generator optimiert auf Erstellen.

Der Reviewer optimiert auf Fehler finden.

Das klingt banal, ist aber architektonisch wichtig. Wenn derselbe Prompt zuerst sagt „Erstelle eine überzeugende Empfehlung“ und danach „Prüfe kritisch deine Empfehlung“, bleibt das Modell häufig in der eigenen Trajektorie.

Eine starke Review-Rolle bekommt eine andere Mission:

Falsifizieren statt bestätigen. Gegenbeispiele suchen. Fehlende Evidenz markieren. Randfälle konstruieren. Unsicherheit erhöhen, wenn sie gerechtfertigt ist. Lieber einen kritischen Fehler finden als zehn Stilverbesserungen.

Drei Arten von Gradern

Moderne Eval-Architekturen kombinieren typischerweise mehrere Prüfertypen.

1. Deterministische Grader

Unit Tests, Schema-Checks, Regex- und String-Checks, Datenbankzustand, Rechenprüfung, statische Analyse.

Sie sind schnell und reproduzierbar, aber nur dort stark, wo Kriterien maschinenprüfbar sind.

2. Modellbasierte Grader

Sie können Kohärenz, Coverage, Groundedness, Ton, Rubrics oder offene Qualitätskriterien bewerten.

Ihre Schwäche: Der Prüfer ist selbst ein probabilistisches Modell.

3. Menschliche / fachliche Grader

Sie sind für normative, domänenspezifische oder hochkritische Fragen unverzichtbar, aber langsam und teuer.

Reife Qualitätssysteme kombinieren diese drei statt einen einzelnen Grader zur Wahrheit zu erklären.

Outcome schlägt Selbstbericht

Ein Agent kann sagen: „Die Datei wurde gespeichert“, „der Termin wurde gebucht“ oder „der Test ist bestanden“.

Das ist nur ein Textoutput.

Wo möglich, sollte Qualität am Endzustand geprüft werden:

Existiert die Datei tatsächlich? Enthält die Datenbank den neuen Eintrag? Ist die Bestellung wirklich angelegt? Besteht der Code die Tests? Wurde der richtige Datensatz verändert?

Ein realer Systemzustand ist häufig stärker als die Behauptung des Agenten über diesen Zustand.

Ausführungsverlauf und Outcome prüfen unterschiedliche Dinge

Der Outcome beantwortet: Hat es funktioniert?

Der Trace beantwortet: Wie ist es passiert?

Beides kann relevant sein.

Ein Agent kann den richtigen Endzustand über einen unerlaubten Weg erreichen. Oder er kann einen sauberen Prozess durchführen und an einer externen Störung scheitern.

Deshalb sollten kritische Evals zwischen Prozessqualität und Ergebnisqualität unterscheiden.

Nicht-Determinismus verlangt mehrere Trials

Ein einzelner erfolgreicher Run beweist bei stochastischen Systemen wenig.

Wenn dieselbe Aufgabe fünfmal ausgeführt wird und nur dreimal gelingt, ist „hat funktioniert“ keine ausreichende Qualitätsaussage.

Für wichtige Workflows braucht es deshalb mehrere Trials, Seeds oder Szenarien.

Zwei Fragen sind unterschiedlich:

Kann das System die Aufgabe mindestens einmal lösen?

Löst es die Aufgabe zuverlässig wiederholt?

Für kreative Exploration kann die erste Frage reichen. Für Kundenprozesse ist häufig die zweite entscheidend.

Capability Evals und Regression Evals

Auch diese beiden Eval-Typen erfüllen unterschiedliche Funktionen.

Capability Evals fragen: Welche schwierigen Aufgaben kann das System inzwischen lösen?

Regression Evals fragen: Beherrscht es weiterhin die Dinge, die gestern funktioniert haben?

Ein neues Modell, Prompt-Update oder Tool kann einen Benchmark verbessern und gleichzeitig einen alten Workflow brechen.

Deshalb gehört Regressionstestung in jeden relevanten Change-Prozess.

Aus realen Fehlern werden Testfälle

Der wertvollste Eval-Datensatz entsteht oft nicht aus theoretischen Fragen, sondern aus echten Projektfehlern.

Jeder relevante Incident kann zu einem Regression Case werden:

Fehler dokumentieren. Minimal reproduzierbaren Input sichern. Erwartetes Verhalten definieren. Falsches Verhalten als Failure Mode markieren. Grader bauen. Test in die Suite aufnehmen. Bei Modell-, Prompt- oder Toolwechsel erneut ausführen.

So verwandelt sich Projektgeschichte in Qualitätsinfrastruktur.

Groundedness ist mehr als „eine Quelle steht daneben“

Ein Claim ist nicht grounded, nur weil ein Link folgt.