# Pricing-Modelle für KI-Produkte

> Wer ein KI-Produkt verkauft, hat drei Kostenarten, die sich nicht überlagern: Token, Compute und menschlicher Review. Fünf Pricing-Modelle, ihre Margen und der Grund, warum Flatrate bei KI selten funktioniert.

Veröffentlicht: 2026-09-07

Wer ein KI-Produkt baut, kennt die Frage, die früher oder später jeder CFO stellt: wie wird das margensicher, wenn die Eingabegrösse schwankt? Bei klassischer Software ist die Antwort einfach, mehr Lizenzen, mehr Umsatz, fast keine Mehrkosten. Bei KI-Produkten ist die Eingabegrösse ein Token, und Tokens kosten Geld, und zwar jedes Mal, wenn der Kunde das Produkt benutzt. Diese Differenz zwischen Lizenzpreis und Verbrauch ist das Thema dieses Beitrags. Wer die Rechnungsgrundlage noch nicht kennt, dem hilft [Die wahren Kosten eines Tokens](/posts/kosten-eines-token/) weiter, und wer die Risiken kennt, die im Mittelwert verschwinden, der findet sie in [Tail Risk in der KI-Adoption](/posts/tail-risk-ki/).

## Auf den Punkt

Wer die nächsten fünf Minuten nicht hat: **ein KI-Produkt hat fünf Kostenarten, die im Pricing untergebracht werden müssen, drei davon skaliert mit der Nutzung.** Wer mit einer Flatrate startet, subventioniert die Power-User und verliert die Light-User an Wettbewerber. Wer mit Pay-per-Use startet, bekommt volatile Umsätze, die kein CFO akzeptiert. Wer ein Hybrid baut, hat die richtige Grundlage, aber ein Vertragswerk, das juristisch nicht trivial ist. Die Antwort ist nicht das Modell, sondern die Disziplin, mit der das Modell an die eigenen Kostenstrukturen angepasst wird.

## Glossar

{% definition term="Token-Pass-Through" description="Ein Pricing-Modell, bei dem der Anbieter die Kosten für Tokens, Compute und Embeddings direkt an den Endkunden weiterreicht, typischerweise mit einem prozentualen Aufschlag. Das Modell ist transparent, aber selten komfortabel, weil der Endkunde zum ersten Mal die Variabilität der KI-Kosten zu spüren bekommt." /%}

{% definition term="Flatrate" description="Ein fester monatlicher Preis, unabhängig von der tatsächlichen Nutzung. In der klassischen SaaS-Welt funktioniert das Modell, weil die Grenzkosten pro Nutzer nahe Null sind. In der KI-Welt funktioniert es nur, wenn der Anbieter die Variabilität über Usage-Caps oder Vorhersagemodelle absorbiert." /%}

{% definition term="Pricing pro Outcome" description="Ein Modell, bei dem der Preis an das Ergebnis gekoppelt ist, das die KI liefert, zum Beispiel pro erfolgreich verarbeitetem Dokument, pro geliefertem Lead oder pro gelöstem Ticket. Das Modell ist kundenfreundlich, aber selten anbieterfreundlich, weil die Varianz der Kosten hoch ist." /%}

{% definition term="Usage-Cap" description="Eine Obergrenze für die Nutzung, die in einem Flatrate-Modell eingebaut wird, um die Variabilität zu absorbieren. Wer eine Flatrate ohne Cap verkauft, hat eine offene Wette auf das Nutzungsverhalten des Kunden, und die Wette verliert meistens der Anbieter." /%}

{% definition term="Margin Floor" description="Die Untergrenze der Marge, die ein Anbieter bereit ist zu akzeptieren, typischerweise ausgedrückt als Brutto-Marge pro Euro Umsatz. Wer keinen Margin Floor definiert, verliert die Marge, ohne es zu merken, weil die variablen Kosten langsam wachsen und der Umsatz stagniert." /%}

## Die fünf Kostenarten

Wer ein KI-Produkt baut, hat fünf Kostenarten, die in jedem Pricing-Modell einen Platz finden müssen. Drei davon sind variabel, zwei sind fix.

**Variable Kosten: Token-Kosten.** Das ist der offensichtliche Posten. Wer ein Modell pro Aufruf zahlt, bezahlt pro Token. Tokens sind nicht nur Eingabe-Tokens, sondern auch Ausgabe-Tokens, und letztere sind typischerweise drei- bis fünfmal teurer als Eingabe-Tokens. Wer Pricing macht, ohne diesen Unterschied zu beachten, unter-preist seine Power-User systematisch.

**Variable Kosten: Compute und Storage.** Embeddings, Vektor-Datenbanken, Object Storage für Uploads, GPU-Stunden für Fine-Tuning. Diese Posten sind kleiner als Token-Kosten, aber sie sind nicht null, und sie skalieren mit dem Datenvolumen des Kunden. Wer einen Enterprise-Kunden mit hundert Gigabyte Daten onboardet, hat im ersten Monat einen Compute-Posten, der den Monatsumsatz übersteigt, wenn der Preis nach Seat berechnet wird.

**Variable Kosten: Menschlicher Review.** Das ist der unsichtbare Posten und der teuerste. Wer KI-Output an Kunden ausliefert, reviewt typischerweise intern eine Stichprobe. Wer im regulierten Umfeld arbeitet, reviewt jeden Output. Die Stundensätze sind hoch, die Kosten summieren sich, und sie sind im Pricing-Modell selten abgebildet, weil sie als interner Qualitätsaufwand verbucht werden, nicht als Produktkosten.

**Fixe Kosten: Entwicklung und Wartung.** Klassische SaaS-Posten. Engineering, DevOps, Sicherheit, Compliance. Diese Posten skalieren nicht mit dem Kunden, aber sie sind hoch genug, dass ein Pricing-Modell, das nur die variablen Kosten abdeckt, das Unternehmen in den ersten zwei Quartalen ruiniert.

**Fixe Kosten: Verkauf und Onboarding.** Enterprise-Kunden kosten im Verkauf zwischen 40.000 und 150.000 Euro, je nach Komplexität. Wer Pricing macht, muss diese Kosten amortisieren, sonst ist jeder neue Enterprise-Deal ein Verlustgeschäft in den ersten zwölf Monaten.

{% cost-stack caption="Preisgestaltung muss diese fünf Posten unterbringen. Token, Compute und Review sind die drei, die mit der Nutzung skalieren — sie entscheiden, ob ein Modell margensicher ist." data="{\"items\":[{\"label\":\"Klassische SaaS\",\"segments\":[{\"name\":\"Entwicklung\",\"value\":70},{\"name\":\"Wartung\",\"value\":20},{\"name\":\"Verkauf\",\"value\":10}]},{\"label\":\"+ Compute\",\"segments\":[{\"name\":\"Entwicklung\",\"value\":70},{\"name\":\"Wartung\",\"value\":20},{\"name\":\"Verkauf\",\"value\":10},{\"name\":\"Compute\",\"value\":15}]},{\"label\":\"+ Tokens\",\"segments\":[{\"name\":\"Entwicklung\",\"value\":70},{\"name\":\"Wartung\",\"value\":20},{\"name\":\"Verkauf\",\"value\":10},{\"name\":\"Compute\",\"value\":15},{\"name\":\"Tokens\",\"value\":35}]},{\"label\":\"+ Review\",\"segments\":[{\"name\":\"Entwicklung\",\"value\":70},{\"name\":\"Wartung\",\"value\":20},{\"name\":\"Verkauf\",\"value\":10},{\"name\":\"Compute\",\"value\":15},{\"name\":\"Tokens\",\"value\":35},{\"name\":\"Review\",\"value\":40}]}],\"max\":200}" /%}

## Fünf Modelle und ihre Mechanik

### Modell eins: Flatrate

Das einfachste Modell. Kunde zahlt einen festen Preis, Anbieter liefert unbegrenzte Nutzung. Funktioniert in der klassischen SaaS-Welt, weil die Grenzkosten pro Nutzer nahe Null sind. Funktioniert in der KI-Welt nur mit Usage-Cap, und der Cap muss so kalibriert sein, dass 80 Prozent der Kunden ihn nicht erreichen. Wer den Cap zu tief setzt, verliert Power-User. Wer ihn zu hoch setzt, hat Kunden, die den Anbieter ruinieren.

In der Praxis funktioniert die Flatrate nur in zwei Fällen: wenn das Modell pro Anfrage sehr günstig ist (kleine Modelle, kurze Antworten, klassische NLQ-Anwendungen), oder wenn der Anbieter das Nutzungsverhalten gut genug kennt, um den Preis pro Seat auf eine durchschnittliche Nutzung zu kalibrieren. Beides ist selten der Fall in der Anfangsphase eines Produkts.

### Modell zwei: Pay-per-Token

Das transparenteste Modell. Der Kunde zahlt, was er verbraucht. Funktioniert für technische Kunden, die wissen, was ein Token ist und was es kostet. Funktioniert nicht für Endkunden, die zum ersten Mal mit KI in Berührung kommen, weil die Rechnung unberechenbar ist und der CFO keine Token-Budgets verhandeln will.

Wer dieses Modell anbietet, muss eine Prognose-Engine bauen, die dem Kunden vor der Anfrage den Preis zeigt und am Monatsende eine Rechnung, die der CFO akzeptiert. Diese Engine ist Engineering-Aufwand, der sich nur lohnt, wenn das Volumen gross genug ist.

### Modell drei: Pay-per-Outcome

Das kundenfreundlichste Modell. Der Preis ist an das Ergebnis gekoppelt, nicht an die Eingabe. Pro geliefertem Dokument, pro Lead, pro gelöstem Ticket. Funktioniert für klar definierbare Outcomes, scheitert bei offenen Outputs.

Das Problem liegt in der Varianz. Ein Anbieter, der pro Dokument einen Preis nimmt, kann nicht garantieren, dass die KI pro Dokument konstante Kosten hat. Lange Dokumente kosten mehr, kurze weniger. Schlecht formatierte Dokumente kosten mehr, gut formatierte weniger. Wer Pay-per-Outcome anbietet, internalisiert die Varianz und braucht entweder einen grossen Risikopuffer oder ein sehr robustes Modell.

### Modell vier: Token-Pass-Through mit Margin

Der pragmatische Mittelweg. Der Anbieter nimmt einen Aufschlag auf die tatsächlichen Token-Kosten, typischerweise zwischen 30 und 80 Prozent. Der Kunde sieht eine Rechnung, die nach Tokens aussieht, aber nicht genau das ist, was der Anbieter zahlt. Der Anbieter hat eine Marge, die mit der Nutzung wächst, nicht mit der Anzahl Lizenzen.

Das Modell funktioniert, weil es die Anreize ausrichtet. Wer mehr verbraucht, zahlt mehr. Wer weniger verbraucht, zahlt weniger. Der Anbieter hat den Anreiz, das Produkt effizienter zu machen, weil seine Marge steigt, wenn er die eigenen Kosten senkt. Das ist die Dynamik, die klassische SaaS-Anbieter aufbauen, und sie funktioniert in der KI-Welt genauso, solange der Aufschlag gross genug ist, um die variablen Kosten zu decken.

### Modell fünf: Gestaffelte Flatrate mit Cap

Das Modell, das in den letzten zwölf Monaten am häufigsten funktioniert hat. Der Kunde wählt eine Stufe, zahlt einen festen Preis, hat einen Cap pro Monat. Wer über dem Cap liegt, zahlt pro Token weiter, typischerweise mit einem Aufschlag. Das Modell gibt dem CFO Vorhersagbarkeit und dem Anbieter eine Marge auf die Power-User.

Die Disziplin liegt in der Kalibrierung der Stufen. Drei Stufen sind zu wenig, fünf sind zu viele. Vier Stufen, mit Caps, die in einem Verhältnis von 1 zu 3 zu 10 zu 30 stehen, funktionieren in den meisten Märkten. Wer die Stufen zu eng setzt, hat Kunden, die ständig migrieren. Wer sie zu weit setzt, hat Kunden, die in der falschen Stufe sind.

{% bar-horizontal caption="Welches Modell passt zu welchem Reifegrad. Frühe Produkte brauchen Einfachheit, reife Produkte brauchen Margensicherheit." data="{\"items\":[{\"label\":\"Flatrate\",\"value\":2},{\"label\":\"Pay-per-Token\",\"value\":3},{\"label\":\"Pay-per-Outcome\",\"value\":3},{\"label\":\"Pass-Through\",\"value\":4},{\"label\":\"Staffel\",\"value\":5}],\"max\":5}" /%}

## Der Margin Floor

Jedes Pricing-Modell braucht einen Margin Floor, eine Untergrenze der Marge, unter der das Produkt nicht verkauft wird. Wer keinen Floor definiert, verliert die Marge, ohne es zu merken.

In der Praxis definieren die meisten Anbieter den Floor nicht explizit. Sie definieren einen Listenpreis, einen Rabattrahmen für den Verkauf und eine ungefähre Marge im Business-Case. Das ist im klassischen SaaS-Modell tragfähig, weil die Marge sich aus fixen Kosten und Listenpreis ableitet. Im KI-Modell ist die Marge eine Funktion von Preis minus Token-Kosten minus Review-Kosten minus Anteil fixe Kosten, und jede dieser Variablen schwankt.

Wer einen Margin Floor von 60 Prozent definiert und durchsetzt, schreibt in jeden Vertrag eine Klausel, die den Verkauf stoppt, wenn der Floor unterschritten wird. Das ist unbequem, aber es ist der einzige Weg, eine Marge über fünf Quartale zu halten. Anbieter, die auf diesen Mechanismus verzichten, haben typischerweise im dritten Jahr ihrer KI-Produktreise eine Marge, die zwischen 20 und 40 Prozent liegt und ein CFO, der fragt, warum.

{% questionAnswer question="Wann ist ein Modell das richtige?" answer="Wenn der Anbieter die Variabilität der eigenen Kosten kennt und im Pricing abbildet. Wer das nicht kann, hat ein Modell, das im Mittelwert funktioniert und im Quartalsbericht scheitert." /%}

## Achtzig Prozent der Marge entstehen in der Verhandlung

Wer Pricing als Produktentscheidung behandelt, lässt achtzig Prozent der Marge auf dem Tisch liegen. Pricing ist eine Verhandlungsentscheidung, und die Verhandlung beginnt dort, wo der Standardpreis auf den Kundennutzen trifft.

Die Frage, die jeder Account Executive in den ersten drei Minuten eines Gesprächs stellen sollte: was ist das Ergebnis, das der Kunde mit dem Produkt erreicht? Wer das Ergebnis kennt, kann einen Preis setzen, der am Ergebnis hängt, nicht am Aufwand. Wer nur den Aufwand kennt, hat einen Preis, der vom Kunden gedrückt wird, weil der Aufwand nicht das ist, was der Kunde kauft.

In den letzten Projekten, die ich gesehen habe, funktioniert diese Logik besonders gut in zwei Märkten: Enterprise-Workflows, in denen das Produkt menschliche Arbeit ersetzt, und Consumer-Produkten, in denen das Produkt ein klar messbares Ergebnis liefert. Wer in beiden Märkten aktiv ist, hat Pricing-Modelle, die sich anhören wie Inkasso, aber Marge produzieren, die in den Vorstandsberichten auftaucht.

## Drei Dinge, die im Vertrag stehen müssen

Ein KI-Vertrag, der margensicher ist, hat drei Klauseln, die im Standardvertrag selten sind. Sie zu setzen ist nicht trivial, aber ohne sie ist das Pricing-Modell ein Angebot, das der Kunde annimmt und der Anbieter verliert.

**Klausel eins: Volumen-Garantie.** Wer einen Listenpreis auf Basis prognostizierter Volumina setzt, sollte eine Mindestabnahme vereinbaren. Wer das nicht tut, hat Kunden, die das Produkt testen und die Volumen-Garantie nicht einlösen. Die Mindestabnahme sollte zwischen 60 und 80 Prozent der Prognose liegen, mit einer Toleranz, die das Pricing-Modell abfedert.

**Klausel zwei: Modell-Substitution.** Der Anbieter sollte sich das Recht vorbehalten, das Modell zu wechseln, wenn ein gleichwertiges Modell verfügbar wird. Das schützt die Marge des Anbieters und gibt dem Kunden die Garantie, dass das Produkt nicht stehenbleibt, wenn ein Anbieter vom Markt verschwindet. Wer diese Klausel nicht hat, ist an einen Anbieter gebunden, dessen Preispolitik nicht mehr in der eigenen Hand liegt.

**Klausel drei: Preisanpassungsklausel.** KI-Kosten sinken, aber sie steigen auch. Wer einen Preis für zwölf Monate fixiert, hat eine Wette auf die Zukunft abgegeben. Eine Preisanpassungsklausel, die an einen Index gekoppelt ist (zum Beispiel an die durchschnittlichen Token-Kosten der Branche), gibt beiden Seiten die Möglichkeit, auf Marktentwicklungen zu reagieren, ohne den Vertrag zu kündigen.

## Was am Ende zählt

Pricing ist kein Marketing-Thema, sondern ein Engineering- und Vertragsthema. Wer Pricing dem Produktmanagement überlässt, hat ein Pricing, das nicht zu den Kosten passt. Wer Pricing dem Verkauf überlässt, hat ein Pricing, das im Mittelwert funktioniert und im Einzelfall verliert. Wer Pricing als gemeinsame Disziplin von Engineering, Verkauf und Finance betreibt, hat ein Pricing, das Marge produziert und im Vorstandsbericht auftaucht.

Die fünf Modelle, die oben stehen, sind nicht die einzigen. Sie sind die, die in den letzten zwölf Monaten funktioniert haben. Wer ein neues Modell braucht, sollte das alte verstehen und dann entscheiden, wo das neue seinen Platz hat.

## Weiterführend

- **[OpenView 2025 Product Benchmarks](https://openviewpartners.com/blog/2025-product-benchmarks/)**, wer Pricing-Modelle im SaaS-Markt benchmarken will, findet hier die aktuellen Quoten, an denen sich jedes eigene Modell messen lassen muss.
- **[Andreessen Horowitz](https://a16z.com/)** zum Thema *Pricing in the Age of AI*, eine Diskussion darüber, warum klassische SaaS-Pricing-Modelle für KI-Produkte nicht mehr funktionieren.
- **[Profitwell](https://www.profitwell.com/)** als Werkzeug, mit dem SaaS-Anbieter ihre Pricing-Modelle in Echtzeit messen und anpassen können.