KI-Kosten pro erfolgreicher Aufgabe berechnen: Formel, Messmodell und Beispiel
Die belastbare Rechnung lautet:
Kosten pro erfolgreicher KI-Aufgabe = alle zurechenbaren Kosten des Workflows ÷ Anzahl der Aufgaben, die die festgelegten Akzeptanzkriterien erfüllen.
In den Zähler gehören Modellaufrufe, Tools, Fehlversuche, Infrastruktur, menschliche Prüfung und laufender Betrieb. In den Nenner gehört ein fachlich akzeptiertes Ergebnis. Bei null erfolgreichen Aufgaben ist die Kennzahl nicht definiert; berichten Sie dann die angefallenen Kosten und den fehlenden Erfolg ausdrücklich.
Ein teureres Modell kann wirtschaftlicher sein, wenn es weniger Wiederholungen und menschliche Korrekturen benötigt. Ob das für Ihren Workflow gilt, muss gemessen werden.
Anfrage, KI-Lauf und erledigte Aufgabe sind unterschiedliche Einheiten
| Kennzahl | Was wird gemessen? | Wofür ist sie geeignet? |
|---|---|---|
| API-Kosten pro Aufruf | Kosten einer einzelnen Modellanfrage | Technische Verbrauchsanalyse |
| Kosten pro automatisch akzeptiertem KI-Ergebnis | Gesamte definierte Kostenbasis geteilt durch automatisch akzeptierte Aufgaben | Wirtschaftlicher Variantenvergleich bei klar definiertem Scope |
| Kosten pro abgeschlossenem Geschäftsvorgang | Gesamte Prozesskosten geteilt durch alle erledigten Vorgänge | Business Case einschließlich Prüfung und Fallback |
Eine fachliche Aufgabe kann mehrere Modellaufrufe enthalten. Ein Agent kann recherchieren, ein Dokument abrufen, ein Tool ausführen, das Ergebnis validieren und nach einem Fehler erneut beginnen. Fünf erfolgreiche API-Aufrufe ergeben trotzdem nur eine erledigte Aufgabe.
Ein technisch erfolgreicher HTTP-Request belegt keinen fachlichen Erfolg. Muss das Ergebnis anschließend vollständig neu erstellt werden, ist die KI-Aufgabe nicht automatisch erfolgreich.
Erfolg muss vor dem Test definiert werden
Für eine strukturierte Dokumentenprüfung könnte ein erfolgreicher Task beispielsweise bedeuten:
- alle Pflichtfelder wurden erkannt,
- Werte und Datentypen sind gültig,
- relevante Beträge erfüllen die definierten Prüfregeln,
- Quelle und Dokumentversion sind nachvollziehbar,
- es wurde keine verbotene Aktion ausgelöst,
- das Ergebnis wurde ohne inhaltliche Korrektur übernommen.
Bei Agenten kommen Ausführungskriterien hinzu: richtige Tools, zulässige Parameter, eingehaltene Freigaben und korrekte Zustandsänderungen. Wie solche Pfade geprüft werden, beschreibt AI Agent Evaluation.
Ein praktikables Statusmodell besteht aus vier Ergebnissen:
- Automatisch akzeptiert: Das Ergebnis erfüllt alle Kriterien ohne menschliche Änderung.
- Nach Prüfung korrigiert: Ein Mensch muss das Ergebnis inhaltlich ändern.
- Manueller Fallback: Die KI-Aufgabe scheitert; der Vorgang wird anderweitig erledigt.
- Nicht erledigt: Es liegt kein akzeptiertes Ergebnis vor.
Ein korrigiertes Ergebnis kann einen erledigten Geschäftsvorgang ergeben. Es sollte aber nicht als vollautomatischer KI-Erfolg gezählt werden. Berichten Sie deshalb beide Kennzahlen mit benannter Kostenbasis: pro automatisch akzeptiertem Ergebnis und pro abgeschlossenem Geschäftsvorgang.
Was in den Kostenzähler gehört
Modell und Inferenz
Erfassen Sie Input-, Output- und gegebenenfalls gesondert verrechnete Tokenkategorien, Cache-Nutzung, Embeddings, zusätzliche Modellaufrufe, Retries und Modell-Fallbacks.
Die offizielle OpenAI-Preisliste führt neben Modellpreisen unter anderem eigene Positionen für Tools und Container. Ein einzelner Tokenpreis bildet die gesamte Rechnung daher nicht ab. Quellenstand: 22. Oktober 2026.
Versionieren Sie die verwendete Preistabelle mit Anbieter, Modell, Verarbeitungsstufe, Währung und Gültigkeitsdatum. Ersetzen Sie Schätzungen später durch tatsächlich verrechnete Kosten, soweit diese zuordenbar sind.
Tools und externe Dienste
Je nach Workflow entstehen Kosten für Suche, OCR, Dokumenten-Parsing, Datenbanken, Vektorsuche, Fach-APIs, Codeausführung, Storage und Datenübertragung.
Ordnen Sie jeden Schritt dem ursprünglichen Task zu. Einzelne Rechnungen pro Modellaufruf erklären sonst nicht, was der gesamte Vorgang gekostet hat.
Infrastruktur und Betrieb
Auch eine API-Lösung benötigt Anwendung, Datenhaltung, Queues, Logging und Monitoring. Bei selbst betriebenen Modellen kommen reservierte und ungenutzte Rechenkapazität, Updates und Betriebsverantwortung hinzu.
Ein Vergleich zwischen API und Self-Hosting braucht dieselbe Aufgabe und Qualitätsschwelle. Die Architekturfragen behandelt Private AI vs. Public Cloud.
Menschliche Prüfung und Korrektur
Messen Sie Prüfzeit, inhaltliche Korrekturen, Rückfragen, manuelle Eingaben, Eskalationen und vollständige Ersatzbearbeitung. Eine kurze Freigabe und eine fachliche Rekonstruktion dürfen nicht denselben Bearbeitungsaufwand erhalten.
Für eine Planrechnung können gemessene Minuten mit einem ausdrücklich angegebenen internen Stundensatz bewertet werden. Der Satz ist eine Kalkulationsannahme und nicht automatisch eine zusätzliche zahlungswirksame Ausgabe.
Laufende Qualitätssicherung
Berücksichtigen Sie anteilige Evaluation, Stichproben, Fehleranalyse, Pflege von Testfällen und notwendige Anpassungen an Modell- oder Anbieteränderungen.
Weisen Sie einmalige Entwicklungskosten separat aus. Im Business Case können sie über einen transparent festgelegten Zeitraum oder eine erwartete Aufgabenmenge amortisiert werden. Rechnen Sie gemeinsame Plattformkosten nach demselben Schlüssel auf beide Varianten um und vermeiden Sie Doppelzählungen.
Minimales Messschema pro Aufgabe
Jeder Modell- und Tool-Aufruf muss mit dem fachlichen Ergebnis desselben Tasks verbunden werden. Dafür genügt am Anfang ein kleines Messschema:
| Feld | Zweck |
|---|---|
workflow_name | Stabiler Name der fachlichen Aufgabe |
task_id | Verknüpft alle Aufrufe mit einem Vorgang |
attempt_id | Trennt Erstversuch, Retry und Fallback |
| Anbieter und Modellversion | Macht Varianten vergleichbar |
| Tokenkategorien und Preisstand | Ermittelt Modellkosten |
| Tool und Tool-Kosten | Erfasst Suche, OCR, APIs und Ausführung |
outcome_status | Automatisch akzeptiert, korrigiert, Fallback oder offen |
failure_reason | Ordnet Kosten einer Fehlerklasse zu |
review_minutes | Erfasst menschliche Arbeit |
| Prompt-, Workflow- und Policy-Version | Erklärt Unterschiede zwischen Läufen |
Das ist ein vorgeschlagenes Anwendungsschema. Inhalte und personenbezogene Daten müssen dafür nicht pauschal vollständig protokolliert werden. Benötigt wird die Evidenz, mit der Kosten und Ergebnisstatus zuverlässig zusammengeführt werden können.
Fiktives Rechenbeispiel: Das teurere Modell gewinnt
Das folgende Beispiel ist vollständig fiktiv. Es beschreibt keinen Kundenfall und keinen Modellbenchmark. Zwei Varianten bearbeiten jeweils dieselben 1.000 technischen Servicevorgänge mit denselben Akzeptanzkriterien.
| Kennzahl im Testzeitraum | Variante A | Variante B |
|---|---|---|
| Bearbeitete Aufgaben | 1.000 | 1.000 |
| Automatisch akzeptiert | 760 | 860 |
| Nach menschlicher Korrektur erledigt | 170 | 100 |
| Manuell erledigt | 50 | 30 |
| Nicht erledigt | 20 | 10 |
| Modell- und Tool-Kosten | 160 € | 320 € |
| Plattform und Logging | 140 € | 150 € |
| Prüfung, Korrektur und manueller Fallback | 1.250 € | 600 € |
| Anteilig Evaluation und Betrieb | 450 € | 430 € |
| Gesamtkosten | 2.000 € | 1.500 € |
Die menschliche Arbeit umfasst im Beispiel sämtliche Prüfungen, Korrekturen und manuellen Fallbacks. Bei einem angenommenen internen Satz von 50 Euro pro Stunde entsprechen die Beträge 25 beziehungsweise 12 Stunden. Evaluation und Betrieb werden getrennt erfasst und sind darin nicht nochmals enthalten.
Variante A:
- pro bearbeiteter Aufgabe: 2.000 € ÷ 1.000 = 2,00 €
- pro automatisch akzeptiertem Ergebnis: 2.000 € ÷ 760 = 2,63 €
- pro erledigtem Geschäftsvorgang: 2.000 € ÷ 980 = 2,04 €
Variante B:
- pro bearbeiteter Aufgabe: 1.500 € ÷ 1.000 = 1,50 €
- pro automatisch akzeptiertem Ergebnis: 1.500 € ÷ 860 = 1,74 €
- pro erledigtem Geschäftsvorgang: 1.500 € ÷ 990 = 1,52 €
Die Gesamtkosten je automatisch akzeptiertem Ergebnis sind hier ein Belastungsmaß für den gesamten Workflow. Sie enthalten auch den Aufwand für nicht automatisch erledigte Fälle. Sie sind nicht die isolierten Herstellkosten ausschließlich der erfolgreichen Teilmenge.
Im fiktiven Beispiel sinken die Gesamtkosten um 25 Prozent; pro automatisch akzeptiertem Ergebnis um rund 34 Prozent. Ausschlaggebend ist die geringere Nacharbeit trotz höherer Modell- und Tool-Kosten.
Vor einer Entscheidung wären zusätzlich Sicherheits-, Qualitäts- und Latenzanforderungen zu prüfen. Ein günstigerer Durchschnitt rechtfertigt keine kritische Fehlentscheidung.
Durchschnittswerte können teure Fehlerklassen verdecken
Segmentieren Sie nach Aufgaben, die Ihren Workflow tatsächlich unterscheiden: etwa Dokumentlänge, Sprache, Datenquelle, Tool-Nutzung oder fachliche Ausnahme.
Prüfen Sie, welche Fallgruppen besonders viele Retries, lange Kontexte oder manuelle Bearbeitung auslösen. Sonst kann eine kleine, geschäftskritische Gruppe regelmäßig eskalieren, während der Mittelwert unauffällig bleibt.
Sieben typische Rechenfehler
- Jede technisch abgeschlossene Antwort als Erfolg zählen.
- Korrigierte Ergebnisse als vollautomatisch behandeln.
- Retries ohne Verbindung zum ursprünglichen Task auswerten.
- Nur Tokens statt des gesamten Workflows vergleichen.
- Entwicklung und laufenden Betrieb ohne nachvollziehbaren Schlüssel vermischen.
- Varianten mit unterschiedlichen Testfällen oder Qualitätsgrenzen vergleichen.
- Kritische Fehlerklassen im Gesamtdurchschnitt verstecken.
Von der Kennzahl zur Go-/No-Go-Entscheidung
Definieren Sie zuerst eine konkrete Aufgabe, ihre Akzeptanzkriterien und kritische Fehler. Testen Sie Varianten anschließend gegen dieselben repräsentativen Fälle. Erfassen Sie alle Versuche und menschlichen Arbeitsschritte.
Die wirtschaftliche Grenze gehört ebenfalls vor den Test: Wie viel darf ein akzeptierter Vorgang kosten, damit der Workflow gegenüber dem bestehenden Prozess tragfähig bleibt?
Wie ein Pilot mit überprüfbaren Erfolgskriterien aufgebaut wird, zeigt KI-Pilot planen.
Wenn ein vorhandener Pilot grundsätzlich funktioniert, aber Erfolgsquote, Nacharbeit und Kosten nicht sauber zusammengeführt werden können, unterstütze ich Sie im AI Production Readiness & Reliability Sprint bei einer messbaren Entscheidungsgrundlage.