KI Use Cases bewerten: Kosten pro Aufgabe 2026

TL;DR

Ein belastbarer Business Case für KI Use Cases rechnet eine Aufgabe, nicht eine Abteilung. Nehmen Sie echte Token-Zahlen, aktuelle Preise, dann Caching, und vergleichen Sie gegen die Vollkosten der Stunden, die die Aufgabe heute verbraucht. Die meisten Use Cases, die diesen Test nicht bestehen, fallen um eine Größenordnung durch.

Warum eine Aufgabe rechnen und nicht eine Abteilung?

Eine Aufgabe zu rechnen liefert eine Zahl, die Sie in einer Woche prüfen können. Eine Abteilung zu rechnen liefert eine Zahl, die niemand widerlegen kann, und genau deshalb überleben solche Zahlen in Folien und sterben im Einkauf. Eine Aufgabe hat eine messbare Eingabegröße, eine messbare Ausgabegröße, eine messbare Monatsmenge und messbare Personalkosten von heute.

Die Rechnung passt in eine Tabelle, und das ist der Punkt. Vier Eingaben: Input-Tokens pro Aufgabe, Output-Tokens pro Aufgabe, Aufgaben pro Monat und Vollkostensatz der Person, die es heute macht. Alles andere ist Preisrecherche.

Zwei Fehler ruinieren die meisten Business Cases:

1. Gesparte Stunden als Geld zu buchen. Freie Kapazität ist keine Kostensenkung, solange niemand geht oder eine Stelle nicht besetzt wird. Schreiben Sie sie als Kapazität und lassen Sie die Fachverantwortung entscheiden, ob sie sich umwandelt.
2. Gegen das falsche Modell zu rechnen. Eine Triage-Aufgabe sieht auf Opus furchtbar und auf Haiku gratis aus. Die Modellwahl ist Teil des Business Case und kein Implementierungsdetail.

Was kostet eine Aufgabe zu aktuellen Preisen?

Nehmen Sie eine Dokumenten-Triage mit 8.000 Input-Tokens und 1.500 Output-Tokens. Zu aktuellen Listenpreisen reicht dieselbe Aufgabe von etwa 0,0016 USD auf Haiku 5.5 bis etwa 0,155 USD auf Fable 5.1, also Faktor 100. Die Modellwahl bewegt den Business Case weiter als jede andere Entscheidung.

Preise von der Modellpreisseite, mit unserer Rechnung für die Beispielaufgabe:

Modell	Input je Mio.	Output je Mio.	Kosten pro Aufgabe	20.000 Aufgaben im Monat
Claude Haiku 5.5	0,10 USD	0,50 USD	0,0016 USD	31 USD
Claude Sonnet 5.5	2 USD	10 USD	0,031 USD	620 USD
Claude Opus 5.5	4 USD	20 USD	0,062 USD	1.240 USD
Claude Fable 5.1	10 USD	50 USD	0,155 USD	3.100 USD

Dagegen die menschliche Seite. Dauert die Aufgabe 12 Minuten und liegt der Vollkostensatz bei 60 EUR pro Stunde, kostet die Aufgabe heute 12 EUR. Bei 20.000 Aufgaben im Monat sind das 240.000 EUR Aufwand monatlich. Die Sonnet-5.5-Zeile liegt bei 620 USD. So sieht fast jeder gut gewählte Dokumenten-Use-Case aus: die Token-Kosten sind ein Rundungsfehler, und die echte Frage ist Qualität und Prüfaufwand, nicht Preis.

Das sagt Ihnen auch, welche Use Cases wegfallen. Liegen die Token-Kosten im Bereich einer Größenordnung der Personalkosten, ist der Use Case falsch: entweder ist das Modell zu groß, der Prompt trägt zu viel Kontext, oder die Aufgabe wiederholt sich nicht genug. Unser Vergleich von Sonnet und Opus arbeitet durch, welche Lasten das größere Modell rechtfertigen.

Welche vier Korrekturen verändern die Zahl deutlich?

Vier Korrekturen bewegen ein Claude-Kostenmodell um jeweils mehr als 10 Prozent: Prompt-Caching nach unten, der neue Tokenizer nach oben, regionale Endpunkte nach oben und Batch-Verarbeitung nach unten. Wenden Sie alle vier an, bevor Sie eine Zahl zeigen, denn Prüfende finden sie später.

Prompt-Caching, nach unten. Sind 6.000 der 8.000 Input-Tokens ein stabiles Präfix, kosten Cache-Treffer bei Sonnet 5.5 nur 0,10 USD je Million statt 2 USD. Die Aufgabe fällt von 0,031 USD auf etwa 0,0196 USD, also rund 37 Prozent niedriger, und 20.000 Aufgaben fallen von 620 USD auf etwa 392 USD. Das Schreiben kostet 2,50 USD je Million einmal pro Cache-Lebensdauer, also rechnet sich Caching, sobald das Präfix mehr als zwei Mal genutzt wird. Unser Leitfaden zum Prompt-Caching bei Claude behandelt, was ein Präfix entwertet.

Der Tokenizer, nach oben. Claude 4.7 und neuere Modelle nutzen einen Tokenizer, der für denselben Text rund 30 Prozent mehr Tokens erzeugt, während Sonnet 4.6 und älter den vorherigen nutzen. Ein Modell auf Token-Zahlen von Sonnet 4.6 unterschätzt Sonnet 5.5 um etwa ein Drittel: aus der Beispielaufgabe werden rund 10.400 Input- und 1.950 Output-Tokens, also aus 0,031 USD etwa 0,040 USD. Messen Sie auf dem Modell nach, das Sie betreiben.

Residenz, nach oben. Regionale und Multi-Region-Endpunkte kosten 10 Prozent Aufschlag gegenüber globalen Endpunkten bei Claude Sonnet 4.5, Haiku 4.5, Opus 4.5 und allen neueren Modellen. Auf der First-Party-API kostet US-Inferenz über inference_geo Faktor 1,1 über Input, Output, Cache-Schreibvorgänge und Cache-Treffer. Berührt der Use Case personenbezogene Daten und braucht eine EU-Region, rechnen Sie die 10 Prozent ein, bevor jemand die Zahl sieht.

Batch, nach unten. Amazon Bedrock bietet ausgewählte Modelle, darunter die von Anthropic, für Batch-Inferenz zu einem um 50 Prozent niedrigeren Preis als On-Demand. Für jeden Use Case, der keine Antwort in Sekunden braucht, halbiert das die Position. Nächtliche Dokumentenverarbeitung und Nachläufe gehören hierher.

Zusammengerechnet, auf der Beispielaufgabe mit Caching, neuem Tokenizer und EU-Endpunkt:

Korrektur	Kosten pro Aufgabe	20.000 Aufgaben im Monat
Listenpreis Sonnet 5.5, ohne Korrekturen	0,031 USD	620 USD
Plus neuer Tokenizer, 30 Prozent mehr Tokens	0,040 USD	806 USD
Plus 90 Prozent Cache-Präfix	0,025 USD	507 USD
Plus regionaler Endpunkt, 10 Prozent	0,028 USD	558 USD
Dasselbe als Nacht-Batch auf Bedrock	0,014 USD	279 USD

Unser Leitfaden zu den Claude-API-Kosten in der EU hält die Tarifzahlen je Route aktuell.

Wie rechnen Sie Plätze und Entwicklungs-Use-Cases?

Plätze und Entwicklung folgen einem anderen Modell: Sie zahlen pro Person, nicht pro Aufgabe, und die Token-Kosten können Sie nicht Aufgabe für Aufgabe optimieren. Rechnen Sie diese zwei Positionen aus veröffentlichten Platzpreisen und Anthropics eigenen Einsatzzahlen, nicht aus einem Aufgabenmodell.

Für Wissensarbeit im Chat und in Cowork nennt claude.com/pricing Team-Standard-Plätze zu 20 USD pro Platz und Monat bei Jahreszahlung, 25 USD monatlich, für Teams von 2 bis 150 Personen, mit bis zu 500 USD monatlichen API-Credits im Pool. Enterprise kostet 20 USD pro Platz und Monat jährlich, der Verbrauch wird getrennt zu API-Preisen abgerechnet, bei mindestens 20 Plätzen. Premium-Plätze im Team-Plan kosten 100 USD pro Platz und Monat jährlich und tragen das fünffache Nutzungskontingent.

Für die Entwicklung nutzen Sie die veröffentlichten Einsatzzahlen statt eines Aufgabenmodells. Anthropics Kostenseite nennt rund 13 USD pro Entwickler und Aktivtag sowie 150 bis 250 USD pro Entwickler und Monat über Unternehmenseinsätze hinweg, bei 90 Prozent der Nutzer unter 30 USD pro Aktivtag. Bei 40 Entwicklern sind das 72.000 bis 120.000 USD pro Jahr, und diese Zahl gehört in den Business Case, nicht eine Schätzung pro Aufgabe.

Wo das Platzmodell kippt: bei platzbasierten Enterprise-Plänen erscheint der Ausgabenbericht nur, wenn Usage Credits aktiv sind, und deckt dann ausschließlich Überverbrauch ab, weil Nutzung innerhalb des Platzkontingents nicht in Dollar gemessen wird. Ein Business Case, der Kostenberichte pro Aufgabe auf einem Platzplan verspricht, verspricht etwas, das die Plattform nicht liefert. Planen Sie die Messung an dem, was die Analytik tatsächlich berichtet: wöchentlich aktive Mitglieder, Adoptionsgrad, Produkt-Stickiness, geschätzte Zeitersparnis und einen täglichen Ausgabenbericht mit einem Tag Verzug.

Wie priorisieren Sie ein Portfolio von KI Use Cases?

Priorisieren Sie nach zwei Achsen: wie wiederholbar die Aufgabe ist und wie teuer eine falsche Antwort wird. Die Menge rechtfertigt den Bauaufwand, die Fehlerkosten bestimmen, wie viel Prüfung Sie finanzieren müssen. Alles andere, auch die Begeisterung der Geschäftsführung, ist Rauschen, das das erste Quartal nicht übersteht.

Unser Bewertungsbogen, vier Fragen je Use Case:

1. Menge. Wie oft im Monat? Unter etwa 200 Fällen monatlich zahlt sich Bau- und Prüfaufwand selten zurück, wie gut die Ersparnis pro Aufgabe auch aussieht.
2. Fehlerkosten. Was passiert, wenn die Antwort falsch ist und niemand es merkt? Lautet die Antwort “ein Kunde wird falsch abgerechnet”, ist der Prüfschritt verpflichtend, und der Business Case muss ihn tragen.
3. Prüfbarkeit. Kann eine prüfende Person das Ergebnis schneller kontrollieren als die Aufgabe selbst zu erledigen? Wenn nicht, ist die Ersparnis eine Illusion, weil die Prüfung der neue Engpass wird.
4. Datenklasse. Werden personenbezogene oder regulierte Daten berührt? Dann rechnen Sie den Residenzaufschlag und die Vertragsarbeit ein, bevor Sie vergleichen.

Die Portfolioentscheidung, die daraus folgt:

Menge	Fehlerkosten	Urteil
Hoch	Niedrig	Zuerst bauen. Beste Rendite, geringste Governance
Hoch	Hoch	Als zweites bauen, mit finanziertem Prüfschritt
Niedrig	Niedrig	Chat-Platz und ein Skill, nicht bauen
Niedrig	Hoch	Bei Menschen lassen. Automatisierung erhöht Risiko ohne Ertrag

In diesem Raster sterben die Use Cases, die am häufigsten zuerst vorgestellt werden: ein Prozess mit hohen Fehlerkosten und niedriger Menge, der eine wichtige Person ärgert. Sagen Sie das im Business Case direkt, statt ihn höflich mitzubewerten.

Selbst rechnen oder auslagern?

Rechnen Sie den Business Case selbst. Er braucht vier Zahlen, die nur Sie haben: echte Token-Zahlen aus Ihren eigenen Prompts, die echte Menge, den Vollkostensatz und den ehrlichen Prüfaufwand. Externe Hilfe lohnt sich bei der Token-Messung und beim Tarifmodell, das mühsam und versionsabhängig ist, und beim Hinterfragen der Mengenangaben.

Was die Arbeit kostet, als unsere Schätzung und nicht als belegter Benchmark:

Schritt	Aufwand	Verantwortung
Echte Token-Zahlen auf 20 Beispielaufgaben messen	1 bis 2 Tage je Use Case	Entwicklung mit Console-Zugang
Aktuelle Menge und Bearbeitungszeit erheben	2 bis 5 Tage je Use Case	Prozessverantwortung
Tarifmodell mit Caching und Residenz bauen	3 Tage einmalig, danach Pflege	Controlling plus Entwicklung
Prüfaufwand aus einem Piloten schätzen	5 Tage je Use Case	Das Team, das prüfen wird
Portfolio bewerten und Streichliste	3 Tage	Wer Nein sagen kann

Unsere Einschätzung: die Messung ist billig, und in den Mengenangaben liegt der Betrug. Ein Business Case auf der Schätzung einer Prozessverantwortung von “etwa 2.000 Fälle im Monat”, die sich als 300 entpuppen, ist die häufigste Art, wie solche Programme ihre Glaubwürdigkeit verlieren. Ziehen Sie die Zahl aus einem System, nicht aus einem Menschen.

Was Sie von einem bezahlten Business Case verlangen sollten:

1. Token-Zahlen gemessen an Ihren Prompts und auf dem Modell, das Sie betreiben, mit genannter Tokenizer-Generation.
2. Menge aus einem Quellsystem, mit gezeigter Abfrage.
3. Prüfaufwand als Kostenposition, nicht wegannahmiert.
4. Residenzaufschlag angewendet, wo die Datenklasse es verlangt.
5. Eine benannte Streichliste. Ein Portfolio, in dem jeder Use Case besteht, wurde nicht bewertet.

Unsere Übersicht der Claude-Kosten hält die Plan- und API-Tabellen, auf denen diese Modelle beruhen. Wie der Business Case in den Programmablauf passt, steht in unserer KI-Strategie für die EU.

FAQ

Was ist ein Business Case für KI Use Cases?

Ein Business Case für einen KI Use Case rechnet eine konkrete Aufgabe zu aktuellen Token-Preisen, addiert den nötigen Prüfaufwand und vergleicht die Summe mit den Vollkosten der Stunden, die die Aufgabe heute verbraucht. Plätze werden getrennt zu Platzpreisen gerechnet, Entwicklungsnutzung an veröffentlichten Zahlen pro Entwickler.

Was kostet eine einzelne Claude-Aufgabe?

Für eine Aufgabe mit 8.000 Input- und 1.500 Output-Tokens etwa 0,0016 USD auf Haiku 5.5, 0,031 USD auf Sonnet 5.5, 0,062 USD auf Opus 5.5 und 0,155 USD auf Fable 5.1 zu Listenpreisen. Ein gecachtes Präfix senkt die Sonnet-Zahl um rund ein Drittel, ein regionaler Endpunkt erhöht sie um 10 Prozent.

Welche Korrekturen fehlen in Kostenmodellen meistens?

Vier. Prompt-Caching senkt die Zahl, der neue Tokenizer ab Claude 4.7 erhöht sie für denselben Text um rund 30 Prozent, regionale Endpunkte addieren 10 Prozent, und Batch-Inferenz auf Bedrock halbiert sie. Ein Modell, dem eine davon fehlt, liegt um mehr als 10 Prozent falsch.

Pro Aufgabe oder pro Platz rechnen: was gilt?

Pro Aufgabe gilt für API- und Automatisierungs-Use-Cases, bei denen Sie Prompt und Menge steuern. Pro Platz gilt für Menschen in Chat, Cowork und Claude Code, wo Sie 20 USD pro Platz und Monat bei Team Standard oder Enterprise jährlich zahlen. Entwicklungsnutzung rechnet sich besser mit 150 bis 250 USD pro Entwickler und Monat.

Wie entscheiden wir, welche Use Cases wegfallen?

Menge gegen Fehlerkosten bewerten. Hohe Menge und niedrige Fehlerkosten wird zuerst gebaut. Niedrige Menge und hohe Fehlerkosten bleibt bei Menschen, weil Automatisierung dort Risiko ohne Ertrag addiert. Unter etwa 200 Fällen im Monat zahlt sich Bau- und Prüfaufwand selten zurück.

Können wir Kosten pro Aufgabe auf einem Platzplan berichten?

Nicht verlässlich. Bei platzbasierten Enterprise-Plänen erscheint der Ausgabenbericht nur, wenn Usage Credits aktiv sind, und deckt dann ausschließlich Überverbrauch ab, weil Nutzung innerhalb des Platzkontingents nicht in Dollar gemessen wird. Für Kosten pro Aufgabe führen Sie die Last über die API oder einen Cloud-Anbieter, wo Tokens direkt abgerechnet werden.

Quellen

1. Anthropic: Modell- und Feature-Preise (28. Oktober 2026)
2. Anthropic: Claude Preise und Pläne (28. Oktober 2026)
3. Claude Code: Kosten steuern (28. Oktober 2026)
4. Anthropic: Data residency (28. Oktober 2026)
5. AWS: Amazon Bedrock Preise (28. Oktober 2026)
6. Anthropic Support: Nutzungsanalytik für Team und Enterprise (28. Oktober 2026)