KI-Features im Produkt: wann sie Wert schaffen und wann nur Kosten

Wann ein KI-Feature im Produkt wirklich Wert schafft

KI lässt sich heute in fast jedes Produkt einbauen. Ein paar Zeilen gegen eine Sprachmodell-API, ein Eingabefeld, fertig ist die Demo. Genau diese Leichtigkeit ist die Falle. Ein Feature, das du in einem Nachmittag zusammensteckst, sieht im Pitch grossartig aus und kostet dich danach über Monate Geld, Nerven und Vertrauen deiner Nutzer.

Wert entsteht, wenn ein KI-Feature eine Aufgabe übernimmt, die für deine Nutzer mühsam, wiederkehrend und zeitfressend ist, und wenn das Modell diese Aufgabe verlässlich genug erledigt, dass am Ende weniger Arbeit übrig bleibt, nicht mehr. Das klingt simpel, ist aber der Punkt, an dem die meisten Ideen auseinanderfallen. Eine Zusammenfassung langer Support-Tickets spart einem Agenten echte Minuten pro Fall. Ein Frag die KI-Chatfenster ohne klaren Job daneben spart niemandem etwas und produziert nur Antworten, die jemand gegenlesen muss.

Die nützliche Trennlinie verläuft zwischen Assistenz und Automatik. Ein Assistenz-Feature schlägt vor, der Mensch entscheidet: ein Textentwurf, eine Kategorisierung zur Bestätigung, eine Suche, die natürliche Sprache versteht. Hier darf das Modell auch mal danebenliegen, weil die Korrektur billig ist. Ein Automatik-Feature handelt selbst: es verschickt, bucht, gibt frei. Dort wird jeder Fehler teuer, und die Latte für Verlässlichkeit liegt um ein Vielfaches höher. Die meisten guten ersten KI-Features sind Assistenz.

Verlässlichkeit ist das eigentliche Produktproblem

Ein Sprachmodell ist von Natur aus probabilistisch. Es gibt dir die wahrscheinlichste Antwort, nicht die richtige, und bei derselben Eingabe morgen vielleicht eine andere. Für ein Produkt heisst das: du baust nicht auf einem deterministischen Baustein, sondern auf einem, der mit einer gewissen Rate falschliegt. Diese Rate verschwindet nicht, du kannst sie nur eingrenzen und einplanen.

Deshalb ist die wichtigste Frage vor dem Bauen nicht kann das Modell das, sondern was passiert, wenn es danebenliegt. Bei einem Vorschlagstext korrigiert der Nutzer und macht weiter. Bei einer automatischen Rechnungsfreigabe steht ein falscher Betrag im System. Je näher ein Feature an Geld, Verträgen, Gesundheit oder rechtlichen Folgen sitzt, desto mehr Prüfung, Eskalation und menschliche Freigabe musst du drumherum bauen. Dieses Drumherum ist oft mehr Arbeit als der KI-Aufruf selbst.

Dazu kommt das Thema Halluzination: das Modell erfindet Fakten, die plausibel klingen. In einem Produkt, das Antworten aus deinen eigenen Daten geben soll, ist das ein direktes Risiko. Der übliche Weg dagegen heisst, dem Modell die relevanten Dokumente zur Antwortzeit mitzugeben, statt auf sein Allgemeinwissen zu vertrauen. Das senkt die Fehlerquote spürbar, kostet aber zusätzliche Infrastruktur: eine durchsuchbare Wissensbasis, Aktualisierung, Qualitätskontrolle. Ein KI-Feature ist selten nur ein API-Aufruf. Es ist eine kleine Datenpipeline mit einem Modell am Ende.

Die Kosten, die in der Demo unsichtbar sind

In der Demo zahlst du ein paar Rappen pro Aufruf und denkst, das skaliert schon. Die laufenden Kosten eines KI-Features entstehen aber an mehreren Stellen, und die Modell-API ist oft die kleinste davon. Statt erfundener Zahlen lohnt der Blick auf die Treiber.

Der direkte Modellverbrauch wird pro verarbeitetem Text abgerechnet. Wer lange Dokumente, Chatverläufe oder ganze Wissensbasen mitschickt, zahlt pro Anfrage deutlich mehr als die schlanke Demo vermuten lässt. Hier entscheidet die Architektur über die Rechnung: schickst du jedes Mal alles, oder nur das Nötige.

Die Entwicklung ist teurer als gedacht, weil das Tückische nicht der Normalfall ist, sondern die Ränder. Was tut das Feature bei leerer Eingabe, bei einer fremden Sprache, bei einem Versuch, das Modell zu manipulieren. Diese Fälle abzudecken kostet den grössten Teil der Zeit.

Der Betrieb läuft danach unbegrenzt weiter. Modelle werden von den Anbietern abgekündigt oder verändert, und ein Wechsel zwingt dich zum erneuten Testen deiner Prompts und Ausgaben. Antwortzeiten schwanken. Dein Feature braucht Überwachung wie jeder andere Produktteil, eher mehr. Was nach dem Launch an Software wirklich kostet, haben wir hier breiter aufgeschlagen, und der Grundsatz Betrieb ab Tag eins gilt für KI-Features genauso. Wir betreiben mit Wortfreunde und Reazon eigene Produkte und kennen den Unterschied zwischen einem Feature, das im Pitch glänzt, und einem, das du jeden Tag am Laufen hältst.

Datenschutz entscheidet oft, was überhaupt geht

Sobald ein KI-Feature Nutzerdaten verarbeitet, ist Datenschutz keine Fussnote, sondern eine Vorbedingung. Bei einem gehosteten Sprachmodell verlassen Daten dein System und gehen an einen Anbieter, häufig ins Ausland. Für ein Schweizer KMU, das mit Personendaten, Kundenakten oder Gesundheitsinformationen arbeitet, ist das die erste Frage, nicht die letzte: dürfen diese Daten überhaupt dorthin, brauchst du einen Auftragsverarbeitungsvertrag, werden sie zum Training weiterverwendet.

Daraus folgen reale Abwägungen. Anbieter mit Verarbeitung in Europa und vertraglich ausgeschlossenem Training senken das Risiko, kosten aber mehr und bieten weniger Auswahl. Modelle auf eigener oder gemieteter Infrastruktur halten Daten im Haus, verlangen dafür Hardware und Wissen. Manchmal ist die saubere Antwort, die heikelsten Daten erst gar nicht ins Modell zu geben, sondern sie vorher zu anonymisieren oder herauszuhalten. Diese Wahl triffst du am besten vor der ersten Zeile Code, denn sie bestimmt Architektur und Kosten. Sie gehört zur selben Familie von Pflichten wie Auth, Billing und Compliance, die jedes ernsthafte SaaS ohnehin tragen muss.

Wann du besser kein KI-Feature baust

Es gibt Fälle, in denen ein KI-Feature die falsche Antwort ist, auch wenn es technisch ginge. Wenn eine klare Regel die Aufgabe löst, nimm die Regel. Ein Modell, das mit unsicherer Wahrscheinlichkeit das tut, was eine simple Wenn-dann-Logik immer korrekt erledigt, ist teurer Aufwand ohne Gegenwert und obendrein schwerer zu testen.

Wenn dir die Daten fehlen, hilft KI auch nicht. Ein Feature, das aus deinen Inhalten Antworten ziehen soll, ist nur so gut wie diese Inhalte. Sind sie lückenhaft, veraltet oder unstrukturiert, produziert das Modell selbstbewussten Unsinn, und du hast ein Vertrauensproblem statt eines Features. Hier ist die Reihenfolge entscheidend: erst die Datenbasis ordnen, dann über KI nachdenken.

Und wenn der eigentliche Produktkern noch wackelt, ist ein KI-Feature Ablenkung. Solange Nutzer nicht verstehen, wofür dein Produkt da ist, löst auch ein cleveres KI-Extra das nicht. Welche erste Funktion den Produktkern trägt, ist die Frage vor der KI-Frage. Der naheliegende Einwand lautet: Aber alle bauen gerade KI ein. Stimmt, und ein grosser Teil davon ist Feature-Theater, das nach dem Launch keiner benutzt. Aufmerksamkeit gewinnt am Ende, was funktioniert, nicht was im Changelog mit KI stehen hat.

Womit du anfängst, ohne dich zu verheben

Fang an einer Stelle an, wo der Nutzen offensichtlich und der Fehler billig ist. Such die eine Aufgabe in deinem Produkt, die heute manuell, wiederholt und ungeliebt erledigt wird: Texte vorformulieren, eingehende Anfragen grob einordnen, lange Inhalte zusammenfassen, eine Suche verständlicher machen. Solche Assistenz-Features bringen schnell spürbaren Wert, und wenn das Modell mal danebenliegt, korrigiert der Mensch in Sekunden.

Bau es klein und beobachtbar. Setz dem Feature von Anfang an Grenzen, protokolliere, was rein- und rausgeht, und miss, ob es wirklich genutzt wird und Zeit spart. Halte den Menschen in der Schleife, bis die Zahlen für sich sprechen. Diese Reihenfolge, erst Assistenz, dann irgendwann Automatik, ist keine Vorsicht um der Vorsicht willen, sondern der billigste Weg zu lernen, ob das Feature trägt, bevor du Verantwortung an das Modell abgibst.

Was du lässt: alles, was nur deshalb gebaut wird, weil es mit KI gut klingt. Generische Chatbots ohne klaren Job. Automatik an heiklen Stellen, bevor du die Verlässlichkeit gemessen hast. Features auf einer Datenbasis, die du noch nicht im Griff hast. Die Entscheidung, ein KI-Feature zu bauen, ist am Ende dieselbe wie jede andere Produktentscheidung in der SaaS-Produktentwicklung: Sie muss sich an Nutzen, Kosten und Betrieb messen lassen, nicht am Reiz der Technik. KI verschiebt nicht die Frage, sie macht sie nur dringlicher, weil die Demo so verführerisch billig ist und der Betrieb so verlässlich teuer.