These: Computer-Use-Agent verfehlt rechnerisch 45 Prozent der Kriterien – und Softwarehersteller werden Trainingslieferanten

Laut OpenAI erreicht GPT-6 Astra auf elf Forschungsaufgaben mit Ironclad im Schnitt 55,0 Prozent der Rubric-Kriterien. Rechnerisch (eigene Rechnung, kein OpenAI-Zitat) heißt das: Im Mittel liegen 45 Prozent der Kriterien daneben. Der beste Computer-Use-Agent dieser Studie verfehlt also fast die Hälfte dessen, was Fachleute als Maßstab festgelegt haben. Das ist die erste Aussage. Die zweite: OpenAI sucht Softwarefirmen, deren Agenten heute noch scheitern. Wer seine Workflows liefert, macht den eigenen Burggraben zum Benchmark des Labs.

Dazu kommt eine Einschränkung, die in vielen Zusammenfassungen untergeht. Die genannten Zeiten, 37,0 Minuten für das Vergleichsmodell und 19,2 Minuten für Astra, sind simuliert. OpenAI nennt sie selbst „simulated estimates“ und ausdrücklich „not measured customer time savings“. Wer daraus eine Kundenersparnis ableitet, liest etwas in die Publikation hinein, das dort nicht steht.

Wir bei digital-magazin.de lesen solche Veröffentlichungen mit zwei Fragen: Was wurde gemessen? Und wer profitiert davon, dass genau das gemessen wurde? Bei diesem Stück lohnt sich beides.

Was OpenAI mit Ironclad gemacht hat

Die Quelle ist die OpenAI-Publikation vom Dienstag, 6. Oktober, „Advancing computer use with Ironclad“. Erster Partner des Vorhabens ist Ironclad, ein Anbieter für KI-gestütztes Vertragsmanagement. Laut OpenAI ist GPT-6 Astra das erste Frontier-Modell, das auf Ironclad-Aufgaben trainiert wurde.

Der Aufbau ist schnell erklärt. Es geht um elf Aufgaben aus den Bereichen Legal, Commercial und Procurement. Genannt werden zum Beispiel das Einrichten eines NDA, eine Beschaffungs-Freigabe und das Finden einer passenden Klausel je Rechtsordnung. Das sind keine exotischen Spielereien. Das ist Büroarbeit, die in Unternehmen täglich anfällt und bei der Fehler Folgen haben können.

Eine erfahrene Person braucht für eine solche Aufgabe laut Schätzung 30 bis 40 Minuten. Jede Aufgabe wird mit einer Rubric bewertet, also einem Kriterienkatalog, der je Aufgabe zwischen 8 und 50 Kriterien umfasst. Der Score ist der Anteil der erfüllten Kriterien. Das klingt nach Schulnote, ist aber feiner: Ein Agent kann den Vertrag anlegen, aber die falsche Rechtsordnung wählen und verliert genau dort Punkte.

Ironclad stellte dafür gehostete Produktumgebungen bereit, in denen das Modell üben konnte. OpenAI spricht von Übung und Reinforcement Learning. Das Modell klickt sich also durch eine echte Produktoberfläche, bekommt eine Bewertung und lernt daraus.

Womit trainiert wurde: SEC-EDGAR, synthetisch, keine Kundendaten

Die Fußnote 2 der Publikation ist wichtig, und sie beruhigt in einem Punkt. Die Trainingsaufgaben wurden laut OpenAI synthetisch aus öffentlichen Verträgen der SEC-Datenbank EDGAR erzeugt, mit einem Filter gegen Personenbezogenes. Es flossen keine Kundendaten ein, keine internen OpenAI-Verträge und keine nichtöffentlichen Ironclad-Kundendaten. Das ist sauber getrennt und sollte man fair festhalten.

Es ändert aber nichts an der Grundkonstruktion. Die Umgebung, die Aufgabenlogik und die Bewertungsmaßstäbe stammen aus einem Produkt. Das Modell lernt, dieses Produkt zu bedienen.

Die Zahlen im Überblick

Laut OpenAI liegt der mittlere Rubric-Score von Astra bei 55,0 Prozent, der des Vergleichsmodells Sol bei 41,6 Prozent. Das sind 13,4 Prozentpunkte Vorsprung, nach OpenAIs Rechnung 32 Prozent relativ. Ein internes Entwicklungsmodell kommt auf 63,7 Prozent. Es ist kein Produkt.

Die Grafik zeigt drei Balken, und keiner davon erreicht die Hälfte der Lücke zur vollen Punktzahl in einer Weise, die man als „gelöst“ bezeichnen könnte. Rechnerisch bleiben bei Astra 45 Prozent offen (eigene Rechnung), bei Sol knapp 58 Prozent und selbst beim internen Dev-Modell gut 36 Prozent. Wohlgemerkt: Das ist ein Durchschnitt über elf Aufgaben. Wie sich die Fehler verteilen, nennt die Publikation nicht in einer Form, die ich hier wiedergeben könnte.

Der Fortschritt ist real. +13,4 Prozentpunkte gegenüber dem Vorgänger sind kein Rauschen. Aber ein Fortschritt gegenüber Sol sagt nichts darüber, ob 55 Prozent für einen konkreten Einsatz reichen. Diese Aussage trifft OpenAI nicht, und ich treffe sie ebenso wenig.

Fair bleiben: Settings, Beispielaufgabe, Dev-Modell

Drei Einschränkungen gehören zur ehrlichen Lesart, und sie schwächen die These nicht, sie präzisieren sie.

Erstens die Reasoning-Settings. OpenAI vergleicht Astra mit Max Reasoning gegen Sol mit High Reasoning. Gemeint ist jeweils das Setting, in dem das Modell am besten abschnitt. Der Vergleich ist also bestes gegen bestes, nicht gleiche Einstellung gegen gleiche Einstellung. Das ist ein legitimer Ansatz, aber man sollte ihn kennen.

Zweitens die Beispielaufgabe. OpenAI zeigt eine einzelne Aufgabe, bei der Astra rund 94 Prozent in geschätzten 20 Minuten erreicht und Sol rund 85 Prozent in 32 Minuten. Das ist ein Beispiel, kein Mittelwert. Wer diese 94 Prozent als Normalfall liest, verwechselt eine ausgewählte Aufgabe mit dem Durchschnitt von 55,0 Prozent. Der Abstand zwischen beiden Zahlen zeigt vor allem eines: Die Streuung zwischen den Aufgaben ist groß.

Drittens das interne Modell. Die 63,7 Prozent stammen von einem Entwicklungsmodell. Es ist kein Produkt, und niemand kann es heute einsetzen. Es zeigt, wohin die Reise gehen könnte, nicht, was verfügbar ist.

Und die Fußnote 1: Die Ergebnisse gelten nur für diese elf Forschungsaufgaben, nicht für alle Ironclad-Workflows. Punkt.

Weiterführend zum Thema Abrechnung und Nutzungsmodelle bei Agenten hat unsere Redaktion die Einordnung zu Usage ohne Outcome bei OpenAI geschrieben. Dort geht es um die Frage, warum Nutzungszahlen allein noch keinen Ertrag belegen. Eine ähnliche Lücke zeigt sich hier.

Simulation ist kein Business Case

Jetzt zu den Minuten. Laut OpenAI liegt die geschätzte Zeit bei 19,2 Minuten für Astra gegen 37,0 Minuten für Sol, minus 48 Prozent. Das ist Astra gegen Sol, nicht Astra gegen Mensch. Und es ist, so die Fußnote, eine Simulation auf Basis angenommener Verarbeitungs- und Generierungsgeschwindigkeiten. Es ist keine gemessene Zeitersparnis bei Kundschaft.

Man kann der Versuchung nachgeben und die Zahlen nebeneinanderlegen: Menschen brauchen 30 bis 40 Minuten, der Agent 19,2. Klingt nach „fast doppelt so schnell“. Genau das wäre die falsche Schlussfolgerung. Die Menschenzeit ist eine Schätzung für erfahrene Personen. Die Agentenzeit ist simuliert. Beide wurden nicht im selben Setting gemessen. Vor allem aber fehlt in dieser Rechnung der Schritt danach.

Wer prüft das Ergebnis? Wer korrigiert die fehlenden Kriterien? Bei einem Score von 55,0 Prozent im Schnitt ist Abnahme kein Formalismus, sondern der Kern der Arbeit. Ein Agent, der in 19 simulierten Minuten ein Ergebnis liefert, das eine Person anschließend vollständig prüfen und teils neu machen muss, hat unter Umständen gar nichts gespart. Ob das so ist, weiß ich nicht. OpenAI weiß es auch nicht, jedenfalls steht es nicht in der Publikation. Genau das ist der Punkt.

Ich nenne deshalb keine Kosten, keine Euro-Hochrechnung und keine Stundenersparnis. Die Quelle liefert sie nicht, und jede Zahl dieser Art wäre erfunden.

Gestern andere These

Wer unsere Berichterstattung verfolgt, kennt den Dienstag: Gestern ging es um die Frage, ob „gesparte Stunden“ überhaupt die richtige Kennzahl sind. Das war eine andere These. Heute geht es nicht um die Kennzahl, sondern um die Fehlerquote hinter dem Score und um die Frage, wer die Trainingsaufgaben liefert.

Abgrenzung: Copilot Computer Use am Desktop

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptPhotorealistic close photo of a neat stack of blank contract documents with paper clips next to a closed laptop and a fountain pen on a desk, soft light, no logos, no readable text, no writing on the paper, no watermarks, 16:9

Am Freitag, 2. Oktober, ging es bei uns um Microsofts Ansatz. Dort steht im Mittelpunkt, was ein Agent auf dem Desktop anklicken darf und wer das freigibt. Die Einordnung finden Sie im Beitrag zu Copilot Computer Use mit Klickrechten und Approval.

Der Unterschied zur Ironclad-Konstellation ist grundlegend. Beim Desktop-Agenten stellt sich die Frage der Rechte und der Freigabe im laufenden Betrieb: Darf der Agent das, und wer bestätigt es? Bei Ironclad geht es um etwas davor: Ein Modell wird in einer gehosteten Produktumgebung des Partners trainiert und danach mit Rubrics bewertet. Das ist ein Trainingspartner-Setup. Die Kontrollfrage verschiebt sich von „Was darf der Agent heute?“ zu „Woran wird der Agent morgen gemessen, und von wem stammen die Maßstäbe?“.

Beides gehört zusammen, aber es sind zwei verschiedene Hebel. Wer nur über Rechte spricht, übersieht, dass Fähigkeit und Fehlerquote schon im Training angelegt werden. Wer nur über Benchmarks spricht, übersieht die Betriebsrealität.

Falsch wäre es, aus dem Ironclad-Beispiel auf Microsofts Produkte zu schließen oder umgekehrt. Beide Veröffentlichungen sind unabhängig voneinander, und ich vergleiche hier keine Scores zwischen ihnen.

Softwarefirmen als Trainingslieferanten

Der eigentlich spannende Satz der Publikation steht am Ende. OpenAI sucht weitere Softwarefirmen mit Aufgaben, „that today’s agents still can’t reliably complete“, also Aufgaben, die heutige Agenten noch nicht zuverlässig lösen. Gewünscht sind laut OpenAI Belege für die Fehler, Fachleute, eine sichere Testumgebung und nutzbare Daten.

Lesen Sie das aus Sicht eines Softwareherstellers. Sie bauen seit Jahren Workflows, die in Ihrem Produkt stecken: Freigabelogik, Rollenmodelle, Sonderfälle, die nur Ihre Fachleute kennen. Genau das ist Ihr Burggraben. Nun fragt ein KI-Labor: Zeigt uns, woran unsere Agenten scheitern, stellt uns eine Umgebung und Fachleute bereit.

Was passiert, wenn Sie zusagen? Ihr Produkt wird zum Übungsplatz. Ihre Fachleute definieren die Kriterien, nach denen ein Modell bewertet wird. Das Modell lernt, Ihre Oberfläche und Ihre Abläufe zu bedienen. Das kann ein Vorteil sein, denn ein Agent, der Ihr Produkt gut beherrscht, nützt auch Ihrer Kundschaft. Es ist aber ebenso eine Verschiebung: Was bisher implizites Wissen und Produktvorsprung war, wird zum expliziten Benchmark im Haus des Labs.

Das ist meine Einordnung, nicht OpenAIs Aussage. OpenAI sagt nicht, dass Partner ihren Vorsprung verlieren. Das Labor beschreibt eine Partnersuche. Ob und wie Partner profitieren, regelt kein öffentlicher Text. Aber die Logik ist erkennbar: Wer die schwierigsten Aufgaben liefert, definiert, was „gut“ heißt. Und wer definiert, was gut heißt, steuert, wohin die Modelle wachsen.

Warum die Fehlerquote den Partner-Call erklärt

Hier schließt sich der Kreis zur 45-Prozent-Rechnung. Ein Modell, das im Schnitt 55,0 Prozent der Kriterien erfüllt, hat noch viel Raum nach oben. Der Weg dorthin führt über genau die Aufgaben, an denen es heute scheitert. Das Labor braucht diese Aufgaben, und es braucht sie realistisch. Synthetische Verträge aus SEC-EDGAR tragen nur so weit. Für tiefere Fachlogik braucht es Partner, die ihre Produktumgebung öffnen.

Man kann das als nüchterne Arbeitsteilung sehen. Man kann es auch als Einladung lesen, die eigene Differenzierung abzugeben. Beide Lesarten sind plausibel, und die Entscheidung liegt bei jedem Hersteller selbst.

Aus der Praxis rund um Plattformen und Betriebsmodelle gibt es dazu eine passende Debatte: Wie viel Ausführung gehört in die Hand des Anbieters, wie viel bleibt beim Unternehmen? Dazu hat unsere Redaktion die Gedanken zur Rolle von ITAM bei KI-Agenten gesammelt. Wer Agenten einsetzt, muss wissen, was läuft, wer es verantwortet und welche Software darunter liegt.

Human Oversight bleibt Pflicht

OpenAI schreibt selbst, „human oversight still matters“. Menschliche Aufsicht bleibt wichtig. Das ist keine Floskel, sondern konsequent: Bei 55,0 Prozent im Schnitt wäre alles andere unredlich.

Ironclads CTO Sunita Verma äußert sich laut Publikation sinngemäß so, dass Agenten den gesamten Lebenszyklus eines Vertrags verstehen müssen (eigene Übersetzung, sinngemäß). Das trifft einen wahren Punkt. Ein NDA-Setup ist kein isolierter Klick, sondern Teil einer Kette: Anfrage, Prüfung, Freigabe, Unterschrift, Ablage, spätere Änderung. Ein Agent, der nur Einzelschritte beherrscht, macht an den Übergängen Fehler. Die Rubric-Kriterien bilden genau solche Übergänge ab, und dort dürften viele der fehlenden Punkte liegen. Das ist allerdings meine Vermutung. Die Publikation schlüsselt die verfehlten Kriterien nicht nach Art auf.

Für die Praxis folgt daraus kein Verbot, sondern eine Rollenverteilung. Der Agent bereitet vor, Menschen verantworten. Die Frage ist nur, wie viel Prüfaufwand dabei entsteht, und die beantwortet keine Simulation.

Dazu passt eine Beobachtung aus der Unternehmenspraxis: Betriebsmodelle für KI-Agenten scheitern selten an der Technik, sondern an unklaren Zuständigkeiten. Die Parallele ist schlicht: Wer Agenten einführt, ohne Aufsicht zu organisieren, hat ein Organisationsproblem, kein Modellproblem.

Wir bei digital-magazin.de halten das für den entscheidenden Unterschied zwischen Demo und Betrieb. Eine Demo darf bei 94 Prozent glänzen. Ein Betrieb muss mit dem Durchschnitt leben.

Was Entscheidende jetzt fragen müssen

Ob Sie Anwendende oder Hersteller sind: Aus der Publikation lassen sich konkrete Prüffragen ableiten. Stellen Sie sie Ihrem Anbieter, Ihrem Team oder sich selbst.

Fragen Sie nach dem Durchschnitt, nicht nach dem Beispiel. Wenn ein Anbieter eine Aufgabe mit 94 Prozent zeigt, fragen Sie nach dem Mittelwert über alle Aufgaben. Bei Ironclad sind es 55,0 Prozent, und das ist die ehrlichere Zahl.

Fragen Sie nach der Fehlerverteilung. Rechnerisch fehlen im Schnitt 45 Prozent der Kriterien (eigene Rechnung). Aber welche? Formale Mängel lassen sich leicht korrigieren. Falsche Rechtsordnung oder fehlende Freigabe nicht.

Trennen Sie Simulation und Messung. Zeitangaben, die auf angenommenen Verarbeitungsgeschwindigkeiten beruhen, sind keine Kundenersparnis. Verlangen Sie gemessene Zeiten inklusive Prüfung und Nacharbeit.

Klären Sie die Abnahme. Wer prüft, nach welchem Maßstab, in welcher Zeit? Ohne diese Antwort ist jede Zeitersparnis eine Behauptung.

Prüfen Sie die Vergleichsbasis. Max gegen High Reasoning, Forschungsaufgaben statt Gesamtworkflow, Dev-Modell statt Produkt: Jede dieser Einschränkungen verändert, was die Zahl bedeutet.

Als Hersteller: Entscheiden Sie bewusst, was Sie liefern. Wenn ein Labor Ihre Fehlerbelege, Fachleute und Testumgebung will, klären Sie vorher, was dabei an Wissen abfließt, was zurückkommt und wer die Bewertungsmaßstäbe festlegt. Schlechte Aufgaben zu liefern hilft niemandem. Gute Aufgaben zu liefern ist eine strategische Entscheidung, keine Gefälligkeit.

Als Anwendende: Fragen Sie Ihre Softwarelieferanten. Nehmen Ihre Anbieter an solchen Trainingsprogrammen teil? Welche Daten werden genutzt? OpenAI nennt für die Ironclad-Studie synthetische Aufgaben aus öffentlichen Verträgen und keine Kundendaten. Für künftige Partnerschaften gilt das nicht automatisch, und die Quelle sagt dazu nichts. Fragen Sie nach.

Elf Aufgaben, trotzdem brauchbar

Elf Aufgaben klingen nach wenig. Für eine Statistik ist das auch wenig. Für Einkauf und Recht taugt Ironclad trotzdem als Entscheidungshilfe, und zwar als Stresstest. Der Test zeigt, an welchen Stellen ein Agent bei mehrstufigen Vertrags- und Freigabe-Workflows strauchelt. Wer NDAs einrichtet, Beschaffungsfreigaben baut oder Klauseln an Rechtsordnungen anpasst, kennt genau diese Struktur: viele Regeln, Ausnahmen und ein Ergebnis, das am Ende belastbar sein muss. Dass der beste Wert bei 55,0 Prozent liegt, sagt Ihnen mehr über das Risiko als jede Demo.

Die Grenze liegt in der Übertragbarkeit. Die Aufgaben sind Forschungsaufgaben, die Daten aus SEC-EDGAR sind synthetisch. Ihre Unterlagen sind es nicht: Sie sind unordentlicher, haben eigene Formate und eigene Ausnahmen. Ob ein Agent dort ähnlich abschneidet, zeigt nur ein Pilot mit Ihren Dokumenten. Den Benchmark sollten Sie als Richtung lesen, nicht als Prognose für Ihren Betrieb.

Was „Aufsicht bleibt wichtig“ praktisch heißt

Der Satz wird gern als Pflichtfloskel gelesen. In der Praxis bedeutet er drei Dinge. Erstens: Vier-Augen-Prinzip bei jeder Freigabe, die Geld, Rechtsfolgen oder Außenwirkung hat. Der Agent liefert den Entwurf, ein Mensch unterschreibt. Zweitens: Stichproben auch dann, wenn alles gut läuft. Wer nur kontrolliert, wenn etwas auffällt, merkt schleichende Fehler zu spät. Drittens: ein klarer Eskalationsweg. Wenn der Agent unsicher ist oder Quellen widersprüchlich sind, muss feststehen, wer entscheidet und bis wann.

Wir bei digital-magazin.de würden diese drei Punkte vor dem ersten Einsatz schriftlich festlegen, nicht erst nach dem ersten Fehler.

Noch ein Hinweis für Ihre Business-Case-Folie: Wer simulierte Minuten dort eintragt, ohne die Abnahme einzupreisen, rechnet den Case schön. Die simulierten Zeiten messen den Agenten, nicht den Menschen, der prüft, korrigiert und freigibt. Rechnen Sie diese Zeit mit ein. Streichen Sie die Ersparnis, wenn sie ohne Prüfaufwand gerechnet ist.

Was bleibt?

Erstens: 55,0 Prozent sind laut OpenAI der mittlere Rubric-Score von GPT-6 Astra auf elf Ironclad-Forschungsaufgaben. Rechnerisch bleiben damit im Schnitt 45 Prozent der Kriterien offen (eigene Rechnung). Das ist ein deutlicher Fortschritt gegenüber Sol mit 41,6 Prozent, aber kein Beleg für Produktionsreife. Diese Behauptung steht nirgends, und sie wäre auch nicht zu halten.

Zweitens: Die Zeiten sind simuliert. 19,2 gegen 37,0 Minuten sind Schätzungen auf Basis angenommener Geschwindigkeiten, keine gemessene Ersparnis. Wer daraus einen Business Case baut, rechnet mit Zahlen, die niemand erhoben hat. Abnahme und Nacharbeit fehlen vollständig.

Drittens, und das ist die eigentliche Verschiebung: Die Publikation ist auch ein Aufruf an Softwarehersteller. OpenAI sucht Aufgaben, an denen Agenten heute scheitern. Wer sie liefert, wird zum Trainingslieferanten und macht seine Workflow-Tiefe zum Maßstab des Labs. Das kann Kundschaft nützen, es kann dem Hersteller nützen, und es verschiebt Macht. Ob es sich lohnt, hängt von Konditionen ab, die niemand öffentlich kennt.

Die nüchterne Schlussfolgerung: Agenten sind besser geworden und noch lange nicht fertig. Wer jetzt einkauft, einführt oder liefert, sollte Durchschnittswerte verlangen, Simulationen als Simulationen behandeln und die Aufsicht fest einplanen. Alles andere ist Marketing, auch wenn es als Forschung daherkommt.