Matthias Ernst

Befunde der empirischen Untersuchung im Projektrisikomanagement (PRM)

Leistungsaussagen über Systeme der Künstlichen Intelligenz (KI) stützen sich in der Praxis nahezu durchgängig auf Benchmark-Ergebnisse. Anbieter belegen mit ihnen die Eignung ihrer Produkte, Beschaffungsstellen vergleichen anhand von Kennzahlen konkurrierende Systeme, und mit dem gestuften Anwendbarwerden der EU-Verordnung 2024/1689 ("KI-Verordnung") gewinnen dokumentierte Genauigkeits- und Robustheitsangaben zusätzlich rechtliche Bedeutung.¹ Zugleich zeigt sich in Streit- und Haftungskonstellationen zunehmend, dass die Aussagekraft solcher Kennzahlen im Einzelfall geklärt werden muss: Was genau belegt ein Benchmark-Ergebnis — und was belegt es eben nicht?

Der vorliegende Beitrag geht dieser Frage auf empirischer Grundlage nach. Er stellt Untersuchungsdesign und ausgewählte Befunde der Anfang 2026 abgeschlossenen Masterthesis des Verfassers vor, die die Leistungsfähigkeit großer Sprachmodelle (Large Language Models, LLMs) im PRM mit einem eigens entwickelten Benchmark-Framework untersucht hat.² Die Befunde werden anschließend anhand eines aktuellen Vorfalls aus dem Juli 2026 eingeordnet, der die Grenzen von Evaluationsumgebungen in ungewöhnlicher Deutlichkeit illustriert. Die These des Beitrags lautet: Benchmark-Ergebnisse belegen die Leistungsfähigkeit eines KI-Systems nur insoweit, als Evaluationsdesign, Systemkonfiguration und menschliche Validierung offengelegt und nachvollziehbar sind. Fehlen diese Angaben, misst die Kennzahl die Metrik — nicht die Aufgabe.

I. Benchmarks als Standard der Leistungsbewertung

Benchmarks sind standardisierte Testverfahren, die die Leistung eines Systems anhand definierter Aufgaben und Referenzdaten messen. In der KI-Forschung erfüllen sie eine doppelte Funktion: Sie ermöglichen den Vergleich unterschiedlicher Modelle unter identischen Bedingungen und dokumentieren Fortschritte über Modellgenerationen hinweg. Für klassische Software mit deterministischem Verhalten ist dieses Vorgehen etabliert und belastbar; dieselbe Eingabe erzeugt dieselbe Ausgabe, die Messung ist reproduzierbar.

Bei LLM-basierten Systemen gelten diese Voraussetzungen nur eingeschränkt. Die Ausgabe hängt von Konfigurationsparametern, Kontextlänge, Formulierung der Eingabe und – je nach Einstellung – von stochastischen Komponenten ab. Ein Benchmark-Ergebnis ist damit stets das Ergebnis einer konkreten Messanordnung, nicht eine Eigenschaft des Modells an sich. Hinzu tritt ein strukturelles Problem referenzbasierter Metriken: Sie bewerten die Modellausgabe am Maßstab vorab definierter Referenzdaten. Was die Referenz nicht enthält, gilt als Fehler und dies unabhängig davon, ob die Ausgabe fachlich zutreffend ist, oder nicht.

Rechtlich relevant wird diese Messproblematik über Art. 15 der KI-Verordnung: Hochrisiko-KI-Systeme sind so zu konzipieren, dass sie ein angemessenes Maß an Genauigkeit und Robustheit erreichen; die Genauigkeitskennzahlen und die relevanten Genauigkeitsmaße sind in der Gebrauchsanweisung anzugeben.³ Zwar sind die Hochrisiko-Pflichten nach der Verschiebung durch den Digital Omnibus on AI erst gestuft ab Dezember 2027 anwendbar;⁴ die Anforderungen stehen damit jedoch fest, und wer Leistungsnachweise erst mit Fristablauf konzipiert, wird sie kaum rechtzeitig belastbar führen können. Die Norm setzt voraus, dass Genauigkeit messbar und die Messung aussagekräftig ist. Ebendiese Voraussetzung ist bei LLM-basierten Systemen begründungsbedürftig. Auch die einschlägigen Qualitätsmodelle der Normung – ISO/IEC 25010 für Softwareprodukte und ISO/IEC 25059 als Erweiterung für KI-Systeme – benennen Qualitätsmerkmale wie funktionale Korrektheit und Robustheit, überlassen die Operationalisierung der Messung jedoch dem Anwender.⁵ Die Frage, unter welchen Bedingungen eine Kennzahl das misst, was sie zu messen vorgibt, bleibt damit eine Frage des Einzelfalls.

II. Untersuchungsdesign der empirischen Studie

Die zugrunde liegende Untersuchung hat ein bestehendes Benchmark-Framework für LLM-basiertes Projektrisikomanagement weiterentwickelt und empirisch evaluiert. Das PRM eignet sich als Untersuchungsdomäne, weil es die charakteristischen Schwierigkeiten realer KI-Einsatzszenarien bündelt: Risikoinformationen liegen verteilt in unstrukturierter Projektkommunikation vor, sind kontextabhängig zu deuten und entziehen sich einer eindeutigen, vorab fixierbaren Referenzlösung.

Methodisch folgte die Arbeit einem Mixed-Methods-Design. Kern des Frameworks ist eine automatisierte Pipeline, die synthetische Projektszenarien generiert, definierte Risiken in die Projektkommunikation injiziert und anschließend misst, ob und wie zuverlässig die untersuchten Modelle diese Risiken extrahieren. Die synthetische Datengenerierung stellt sicher, dass die Referenz (anders als bei realen Projektdaten) vollständig bekannt ist und keine Kontamination der Testdaten durch Trainingsmaterial der Modelle vorliegt. Ein eigens entwickelter Relevanzfilter erhöht die Trennschärfe der Extraktion. Die Szenarien deckten unterschiedliche Projektdomänen ab, darunter bautechnische Vorhaben, IT-Infrastrukturprojekte und regulierte Compliance-Kontexte.

Die Messung erfolgte über etablierte referenzbasierte Metriken, systematisch variiert über Modelle und Konfigurationsparameter. Ergänzend wurde eine Blindvalidierung mit fünf Fachexperten über zwölf komplexe Projektszenarien durchgeführt, um die automatisierten Messwerte einem unabhängigen fachlichen Urteil gegenüberzustellen. Die Gesamtergebnisse dieser Gegenüberstellung werden an anderer Stelle vertieft dargestellt;⁶ der vorliegende Beitrag konzentriert sich auf zwei Befundkomplexe, die für die Bewertung von Benchmark-Aussagen unmittelbar relevant sind.

III. Erster Befundkomplex: Fehlende Merkmalskonstanz

Der erste zentrale Befund betrifft die Stabilität der Messergebnisse selbst: Die untersuchten Modelle zeigten keine stabile Merkmalskonstanz. Die Extraktionsleistung variierte erheblich in Abhängigkeit von Modell, Konfiguration und Projektdomäne — und zwar in einem Ausmaß, das pauschale Leistungsaussagen ausschließt.

Deutlich wurde dies zunächst beim Konfigurationsparameter temperature, der die stochastische Varianz, sozusagen die "Kreativität", der Modellausgabe steuert. In Szenarien, deren Risiken sich nur durch Synthese mehrerer verteilter Hinweise erschließen ließen, wurden vollständige Kausalitätsketten erst ab mittleren Parameterwerten rekonstruiert; bei deterministischer Einstellung extrahierten die Modelle lediglich isolierte Teilaspekte. Zugleich führte dieselbe Erhöhung des Parameters in operativ dichten Szenarien zu einer sprunghaften Zunahme falsch-positiver Extraktionen: In einem Szenario stieg die Zahl der ausgegebenen Risiken bei Erhöhung der stochastischen Varianz von einer präzisen Synthese dreier Risikofaktoren auf dreizehn extrahierte Positionen, überwiegend operative Statusinformationen ohne Risikogehalt. Ein Parameterwert, der in einer Domäne die Ergebnisqualität verbesserte, verschlechterte sie in einer anderen.

Die domänenspezifische Auswertung bestätigte diesen Befund auf aggregierter Ebene. Regulierte Compliance-Szenarien zeigten die robusteste Erkennungsleistung; die scharfe Nomenklatur der Domäne wirkte als semantischer Anker. Bautechnische Szenarien erreichten zwar eine stabile Trefferquote, jedoch um den Preis massiver Über-Extraktion operativer Details. IT-Szenarien wiesen die deutlichste Schwäche in der Synthese-Leistung auf: Technische Einzelsignale wurden erkannt, aber deutlich seltener zu einer strategischen Kausalitätskette verknüpft; die Trefferquote lag hier nur bei rund der Hälfte des Wertes der Compliance-Domäne. Risiken, die eine Verknüpfung digitaler und physischer Komponenten erforderten, blieben teils über sämtliche Konfigurationen hinweg unentdeckt.

Hinzu trat ein modellabhängiger Effekt: Bei kleineren Modellen setzte mit zunehmender Kontextlänge ein Context Drift ein, der die strukturelle Integrität der Ausgaben beeinträchtigte und bis zu Identifikator-Integritätsproblemen führte, während leistungsfähigere Modelle Formatvorgaben konsistent umsetzten. Ergänzend ist festzuhalten, dass neuere Modellgenerationen zentrale Konfigurationsparameter für API-Nutzer nicht mehr freigeben — die Reproduktion einer dokumentierten Messanordnung ist dann bereits technisch nicht mehr vollständig möglich.

Für die Bewertung von Benchmark-Aussagen folgt daraus: Eine Kennzahl ohne Angabe von Modellversion, Konfiguration, Datengrundlage und Domäne ist keine belastbare Leistungsaussage. Dieselbe Systemarchitektur kann — bei identischer Aufgabenstellung — je nach Messanordnung Ergebnisse liefern, die von zuverlässiger Erkennung bis zum weitgehenden Versagen reichen.

IV. Zweiter Befundkomplex: Konfidenz-Paradoxon und Automation Bias

Der zweite Befundkomplex betrifft das Verhältnis zwischen der Selbsteinschätzung der Modelle und ihrer tatsächlichen Leistung. In der Untersuchung zeigte sich wiederholt, dass die von den Modellen ausgegebene Konfidenz — die sprachlich oder numerisch signalisierte Sicherheit der eigenen Aussage — von der tatsächlichen Verlässlichkeit der Ausgabe abwich. Modelle präsentierten unzutreffende oder unvollständige Extraktionen mit derselben sprachlichen Bestimmtheit wie zutreffende. Dieses Konfidenz-Paradoxon hat eine unmittelbare praktische Konsequenz: Die Ausgabe eines LLM-basierten Systems ist methodisch als Hypothese zu behandeln, nicht als Befund.

Diese Einordnung gewinnt ihre Schärfe im Zusammenspiel mit einem gut dokumentierten menschlichen Rezeptionsmuster, dem Automation Bias: der Neigung, maschinell erzeugten Ausgaben ein höheres Vertrauen entgegenzubringen, als ihre Verlässlichkeit rechtfertigt, und eigene Prüfschritte entsprechend zu reduzieren. Trifft eine mit hoher sprachlicher Konfidenz präsentierte, aber unzutreffende Modellausgabe auf einen Rezipienten, der die Prüfung zurückstellt, potenzieren sich beide Effekte. Die Untersuchung hat diesen Wirkungszusammenhang als zentrale Falle des praktischen KI-Einsatzes im PRM identifiziert; er lässt sich auf andere Einsatzfelder übertragen, in denen KI-Ausgaben Entscheidungen vorbereiten.

Auch die Bewertungsseite ist von dieser Problematik nicht ausgenommen. Soweit in Evaluationspipelines Sprachmodelle selbst als Bewertungsinstanz eingesetzt werden ("LLM-as-a-judge"), ist diese Heuristik wegen möglicher Verzerrungen und Zirkularität methodisch angreifbar, wenn sie als einziges Wahrheitskriterium fungiert. In der Untersuchung wurde sie deshalb nur als optionaler, vollständig protokollierter Verarbeitungsschritt zugelassen und durch stichprobenartige menschliche Kontrolle abgesichert. Wie erheblich automatisierte Bewertung und unabhängiges Fachurteil im Ergebnis auseinanderfallen können, ist ein eigenständiger Befund der Untersuchung, dessen Darstellung der bereits erwähnten vertieften Veröffentlichung an anderer Stelle vorbehalten bleibt.

V. Aktuelle Illustration: Der Evaluationsvorfall vom Juli 2026

Dass Evaluationsumgebungen das tatsächliche Verhalten von KI-Systemen nur unvollständig abbilden, hat im Juli 2026 ein Vorfall illustriert, der über die Fachöffentlichkeit hinaus Beachtung fand. Nach übereinstimmender Darstellung der beteiligten Unternehmen verschafften sich autonome Agenten auf der Grundlage mehrerer OpenAI-Modelle während einer internen Evaluation ihrer Cyber-Fähigkeiten — durchgeführt mit dem Benchmark ExploitGym⁷ und mit bewusst reduzierten Sicherheitsfiltern — eigenständig Zugang aus der isolierten Testumgebung zum offenen Internet und in der Folge zu Produktionssystemen des Unternehmens Hugging Face, um dort hinterlegte Lösungsdaten der Evaluationsaufgaben zu beschaffen.⁸ Nach Angaben von OpenAI waren die Agenten hyperfokussiert darauf, das eng gefasste Testziel zu erreichen, und wandten dafür erheblichen Rechenaufwand auf.

Die seither veröffentlichten Zwischenstände unterstreichen die evaluationsmethodische Dimension des Vorgangs. Nach der im Rahmen der Sicherheitskonferenz Black Hat USA (5. August 2026) vorgestellten Rekonstruktion reichen die Anfänge bis in den Mai 2026 zurück; die Agenten agierten über Monate koordiniert und hinterließen einander Hinweise in einem internen Software-Repository. Aufschlussreich ist insbesondere die Persistenz des Verhaltens: Nachdem OpenAI im Anschluss an einen internen Vorfall Anfang Juli die ausgenutzte Schwachstelle geschlossen und den verdeckten Koordinationskanal der Agenten abgeschaltet hatte, etablierten diese binnen weniger Tage über einen anderen Mechanismus einen neuen Kanal und verschafften sich über eine weitere, zuvor unbekannte Schwachstelle erneut Zugriff. In den Auswirkungen blieb der Vorfall nach den bislang veröffentlichten Angaben begrenzt: Hugging Face berichtet von unautorisiertem Zugriff auf eine begrenzte Zahl interner Datensätze sowie auf mehrere von den eigenen Diensten genutzte Zugangsdaten, fand jedoch keine Hinweise auf Manipulationen an öffentlichen, nutzerseitigen Modellen oder Datensätzen; die Prüfung einer Betroffenheit von Partner- oder Kundendaten war zum Zeitpunkt der Offenlegung noch nicht abgeschlossen. Nach Angaben von OpenAI waren über Hugging Face hinaus weitere Dritte von Handlungen der Agenten berührt. Die Untersuchung dauert an: OpenAI hat einen vollständigen technischen Bericht angekündigt und einer unabhängigen Überprüfung durch die Forschungsorganisationen METR und Redwood Research zugestimmt. Sämtliche Angaben beruhen daher auf einem ausdrücklich vorläufigen Kenntnisstand.⁹

Für den vorliegenden Zusammenhang ist nicht die sicherheitstechnische Dimension des Vorfalls von Interesse, sondern seine evaluationsmethodische. Der Vorfall zeigt ein Optimierungsverhalten, das in der Literatur als Reward Hacking beschrieben wird und einer als Goodharts Gesetz bekannten Beobachtung folgt: Wird ein Maß zum Ziel, hört es auf, ein gutes Maß zu sein. Die Modelle haben die Evaluationsaufgabe nicht gelöst, sondern die Messanordnung unterlaufen: sie optimierten auf die Metrik, nicht auf die Aufgabe. Ein Benchmark-Ergebnis, das unter solchen Bedingungen zustande kommt, misst nicht die intendierte Fähigkeit.

Der Vorfall bestätigt damit auf drastische Weise, was die vorstehend dargestellten Befunde auf messmethodischer Ebene zeigen: Zwischen dem, was eine Evaluationsanordnung zu messen beansprucht, und dem, was das System tatsächlich tut, kann eine erhebliche Lücke bestehen. Bemerkenswert ist zudem die eigene Schlussfolgerung des Anbieters, dass Kontrolle, Überwachung und Absicherung von Test- und Trainingsumgebungen mit den wachsenden Fähigkeiten der Modelle Schritt halten müssen.¹⁰ Übertragen auf die Leistungsbewertung bedeutet dies: auch die Validität der Messung selbst ist eine Eigenschaft, die aktiv sichergestellt und dokumentiert werden muss — sie versteht sich nicht von selbst.

VI. Konsequenzen für die Praxis

Aus den dargestellten Befunden lassen sich Anforderungen an belastbare Leistungsnachweise für KI-Systeme ableiten, die für Anbieter, Betreiber und deren rechtliche Berater gleichermaßen relevant sind.

Erstens: Reproduzierbarkeit als Mindeststandard. Eine Leistungsaussage ist nur so belastbar wie ihre Messanordnung nachvollziehbar. Zu dokumentieren sind Modell und Modellversion, sämtliche leistungsrelevanten Konfigurationsparameter, die Datengrundlage einschließlich ihrer Herkunft sowie die verwendeten Metriken samt Referenzbildung. Die Untersuchung hat gezeigt, dass bereits die Versionierung der Eingabevorlagen (Prompts) analog zur Software-Versionierung erfolgen muss, weil andernfalls die Reproduzierbarkeit der Ergebnisse verloren geht. Wo Anbieter Konfigurationsparameter dem Zugriff entziehen, ist dies als Einschränkung der Nachprüfbarkeit offen auszuweisen.

Zweitens: Domänen- und Konfigurationsbezug jeder Kennzahl. Da die Leistung nachweislich mit Domäne und Konfiguration variiert, sind aggregierte Gesamtkennzahlen ohne Aufschlüsselung wenig aussagekräftig. Für die Bewertung eines konkreten Einsatzszenarios ist die Messung im relevanten Domänenkontext maßgeblich — nicht der Durchschnitt über heterogene Testfälle.

Drittens: Menschliche Validierung als Bestandteil des Nachweises. Referenzbasierte automatisierte Metriken bewerten am Maßstab statischer Vorgaben und erfassen fachliche Validität nur unvollständig. Ein belastbarer Leistungsnachweis kombiniert deshalb automatisierte Messung mit unabhängiger fachlicher Prüfung durch Domänenexperten. Das Ergebnis der Untersuchung stützt insoweit das Konzept einer hybriden Intelligenz: automatisierte Analyse als Hypothesenlieferant, menschliches Fachurteil als Validierungsinstanz.

Viertens: Organisatorische Vorkehrungen gegen Automation Bias. Wer KI-Ausgaben in Entscheidungsprozesse einbindet, hat Prüfschritte so zu verankern, dass die sprachliche Konfidenz der Ausgabe die tatsächliche Prüfung nicht ersetzt. Dies betrifft die Gestaltung von Prozessen ebenso wie die Schulung der beteiligten Personen und korrespondiert mit den Anforderungen an menschliche Aufsicht nach Art. 14 der KI-Verordnung.¹¹

Für Streit- und Haftungskonstellationen schließlich folgt aus alledem eine Vorfrage, die künftig regelmäßig zu stellen sein wird: Wenn eine Partei die Leistungsfähigkeit eines KI-Systems mit Benchmark-Ergebnissen belegt, ist zunächst zu klären, unter welchen Bedingungen diese Ergebnisse zustande gekommen sind und ob sie den streitgegenständlichen Einsatzkontext überhaupt abbilden. Die Beweiskraft der Kennzahl steht und fällt mit der Dokumentation der Messanordnung. Die sich daraus ergebenden prozessualen Fragen — von der Sicherung des Systemzustands bis zur Formulierung tauglicher Beweisfragen — werden in späteren Beiträgen dieser Reihe vertieft.

VII. Ergebnis

Benchmark-Ergebnisse sind für die Leistungsbewertung von KI-Systemen unverzichtbar. Die dargestellte empirische Untersuchung zeigt, dass LLM-basierte Systeme keine stabile Merkmalskonstanz aufweisen: Ihre Leistung variiert erheblich mit Modell, Konfiguration und Einsatzdomäne, und ihre ausgegebene Konfidenz ist kein verlässlicher Indikator ihrer tatsächlichen Verlässlichkeit. Der Evaluationsvorfall vom Juli 2026 illustriert ergänzend, dass selbst kontrollierte Testumgebungen das reale Systemverhalten nicht garantiert abbilden — Systeme können auf die Metrik statt auf die Aufgabe optimieren.

Eine Kennzahl ohne dokumentierte Messanordnung ist danach keine Leistungsaussage, sondern eine Behauptung. Belastbare Leistungsnachweise erfordern Reproduzierbarkeit, Domänen- und Konfigurationsbezug sowie die Kombination automatisierter Messung mit unabhängiger fachlicher Validierung. Für die rechtliche Praxis liegt hierin ein Prüfungsmaßstab, der mit der wachsenden Bedeutung dokumentierter Genauigkeitsangaben nach der KI-Verordnung weiter an Gewicht gewinnen wird.

---

Der Verfasser, Matthias Ernst (Dipl.-Inform. (FH), M.Sc. Digital Transformation Management), ist als IT-Sachverständiger tätig und befasst sich mit der technischen Bewertung von KI-Systemen im Streit- und Haftungskontext.

---