Sollte Ihr Produkt KI nutzen? Ein Praxisleitfaden

KI kann in einem Produkt nützlich sein, aber „KI einbauen“ ist keine Produktanforderung. Beginnen Sie mit dem Problem der Nutzenden, der Entscheidung, die die Software stützen muss, und den Kosten, diese Entscheidung falsch zu treffen.

Der Druck zur Einführung ist real — und die Lücke dahinter ebenso.

Der 2026 AI Index (wird in einem neuen Tab geöffnet) von Stanford HAI berichtet, dass die KI-Einführung in Organisationen 2025 auf 88 % der befragten Organisationen gestiegen ist. Er hält außerdem fest, dass der Einsatz von KI-Agenten in nahezu jeder Unternehmensfunktion „noch am Anfang steht“.

Für 2026 State of AI in the Enterprise (wird in einem neuen Tab geöffnet) von Deloitte wurden 3.235 Führungskräfte in 24 Ländern befragt. Ergebnis: 74 % der Organisationen hoffen, ihren Umsatz durch KI zu steigern, gegenüber 20 %, die das bereits tun.

Die Einführung ist nahezu universell. Der realisierte Nutzen ist es nicht.

Diese Lücke ist der Grund, vor einer Festlegung für ein Gespräch langsamer zu machen. Die Frage ist nicht, ob KI leistungsfähig ist. Sie lautet, ob dieses Feature für diese Nutzenden ein Problem ist, für das KI die richtige Form hat.

Wann KI passt — und wann nicht

Ein normaler Arbeitsablauf ist oft die bessere Wahl, wenn die Regeln klar sind. Formulare, Berechtigungen, Suche, Berechnungen, Benachrichtigungen und geplante Aufgaben brauchen kein Sprachmodell, nur weil eines verfügbar ist.

Das ist keine Gegenposition um ihrer selbst willen. Googles Rules of Machine Learning (wird in einem neuen Tab geöffnet), der interne Leitfaden für ML-Entwickelnde, beginnt mit einer direkten Anweisung: „Scheuen Sie sich nicht, ein Produkt ohne maschinelles Lernen zu veröffentlichen.“

Die Begründung: Eine einfache Faustregel erfasst bereits einen großen Teil des Werts. Maschinelles Lernen verdient seinen Platz erst, wenn diese Regeln zu verworren werden, um sie zu pflegen.

Ein konventioneller Arbeitsablauf ist meist die bessere Antwort, wenn:

• die Regeln aufgeschrieben und von den Prozessverantwortlichen abgestimmt werden können
• dieselbe Eingabe immer dieselbe Ausgabe erzeugen soll
• eine falsche Antwort teuer ist und die richtige im Voraus bekannt sein kann
• jemand genau erklären können muss, warum das System getan hat, was es getan hat
• die Daten bereits strukturiert, validiert und vollständig sind

KI verdient ihren Platz, wenn die Eingabe unordentlich oder unvorhersehbar ist oder sich mit festen Regeln schwer fassen lässt:

• lange Dokumente, Threads oder Gesprächsnotizen zusammenfassen
• Freitextnachrichten klassifizieren, deren Formulierungen stark variieren
• Felder aus Dokumenten extrahieren, die nie einer einzigen Vorlage folgen
• einer Person helfen, Informationen zu erkunden, statt an ihrer Stelle zu entscheiden
• eine erste Fassung entwerfen, die ein Mensch prüft und bearbeitet

Das Muster in der zweiten Liste: Ein Mensch bleibt im Prozess. Die Ausgabe ist ein Entwurf, ein Vorschlag oder ein Ausgangspunkt statt einer endgültigen Entscheidung.

Dort verdienen sich solche Features üblicherweise zuerst ihren Platz.

Beginnen Sie mit der richtigen Frage

Die erste Frage lautet nicht „Welches Modell sollen wir nehmen?“ Fragen Sie stattdessen: „Was sollen die Nutzenden tun können, und an welcher Stelle kommt Unsicherheit in den Ablauf?“ Diese Antwort entscheidet, ob KI ins Produkt gehört.

Legen Sie fest, wie ein gutes Ergebnis aussieht, bevor Sie bauen. Eine Entwurfszusammenfassung reicht vielleicht mit einer kurzen menschlichen Prüfung. Eine Entscheidung, die die Software allein trifft, braucht womöglich strengere Kontrollen, eine klare Erklärung und einen sicheren Weg, sie zu stoppen oder zu korrigieren.

Das AI Risk Management Framework (wird in einem neuen Tab geöffnet), im Januar 2023 als freiwillige Leitlinie des NIST veröffentlicht, sagt es deutlich. Unter seinen Merkmalen vertrauenswürdiger Systeme gilt gültig und zuverlässig als „notwendige Bedingung für Vertrauenswürdigkeit“.

Es ist die Grundlage, auf der die übrigen Merkmale ruhen. Ein Feature, das beeindruckend, aber unzuverlässig ist, hat die erste Hürde nicht genommen.

Fragen, die Sie vor der Festlegung stellen sollten

Wenn jemand ein KI-Feature vorschlägt, trennt eine kurze Fragenliste meist einen durchdachten Plan von einem begeisterten:

1. Welche Aufgabe erledigt das, und wie würden wir sie ohne KI erledigen?
2. Was kostet eine falsche Antwort die Nutzenden, und wer bemerkt sie zuerst?
3. Welche Daten sieht das Feature, und wohin gehen sie?
4. Wie testen wir es vor dem Launch, und wie oft danach?
5. Was tut das Produkt, wenn das Modell nicht verfügbar oder unsicher ist?
6. Was kostet das pro Nutzenden und Monat beim Zehnfachen des heutigen Volumens?

Für keine dieser Fragen braucht es technischen Hintergrund. Für überzeugende Antworten darauf schon.

Gestalten Sie für die menschliche Prüfung

Menschliche Prüfung ist keine vage Sicherheitsformel. Geben Sie den Prüfenden genug Kontext, um die Ausgabe zu bewerten, einen klaren Weg, sie zu bearbeiten, und eine Möglichkeit, einen Fehler zu melden, dem das Produktteam nachgehen kann.

Die etablierten Rahmenwerke verlangen eine Aufsicht, die schriftlich belegt ist — nicht eine, die man sich vornimmt.

Die Funktion Map des NIST-Rahmenwerks erwartet, dass „Prozesse für die menschliche Aufsicht im Einklang mit den Richtlinien der Organisation definiert, bewertet und dokumentiert werden“.

In der EU schreibt Article 14 of the AI Act (wird in einem neuen Tab geöffnet) vor, dass Systeme seiner Hochrisiko-Kategorie so gestaltet werden, „dass sie während der Dauer ihrer Verwendung von natürlichen Personen wirksam beaufsichtigt werden können“.

Nicht jedes Produkt fällt in diese Kategorie. Das Gestaltungsprinzip bleibt eine sinnvolle Voreinstellung, lange bevor es eine rechtliche wird.

Die Sicherheitsleitlinien sehen es genauso. Die OWASP Top 10 for LLM Applications (wird in einem neuen Tab geöffnet) führen Excessive Agency unter ihren Risiken für 2025 auf.

Die empfohlene Gegenmaßnahme ist eindeutig: „Nutzen Sie Human-in-the-Loop-Kontrolle, um für Aktionen mit hoher Auswirkung eine menschliche Freigabe zu verlangen, bevor sie ausgeführt werden.“

Wenn ein Feature eigenständig Geld ausgeben, Nachrichten senden oder Datensätze ändern kann, gehört dieser Freigabeschritt zum Bau. Er ist keine spätere Härtungsaufgabe.

Legen Sie Datenregeln vor dem Bau fest

Datenzugriff und Datenschutz müssen Teil des Entwurfs sein. Bestimmen Sie, welche Informationen das Feature erhält, wo sie verarbeitet werden, wie lange sie aufbewahrt werden und welche Personen oder Systeme auf das Ergebnis zugreifen dürfen.

OWASP führt Sensitive Information Disclosure (wird in einem neuen Tab geöffnet) an zweiter Stelle seiner LLM-Risiken für 2025. Die Leitlinie läuft auf eine Regel hinaus, die die meisten Teams kennen und unter Termindruck übergehen: „Beschränken Sie den Zugriff auf sensible Daten nach dem Prinzip der geringsten Rechte.“

Das Modell ist ein weiteres System mit Zugriff auf die Informationen Ihrer Nutzenden und sollte auch so eingegrenzt werden.

Die Anbieter veröffentlichen konkrete Bedingungen, und sie unterscheiden sich genug, um relevant zu sein. Drei lohnen sich, bevor der Entwurf feststeht:

• Nutzung für Training. OpenAIs Dokumentation zu Datenkontrollen (wird in einem neuen Tab geöffnet) besagt, dass „Daten, die an die OpenAI-API gesendet werden, nicht zum Trainieren oder Verbessern von OpenAI-Modellen verwendet werden“ — mit einem separaten Aufbewahrungsfenster für die Missbrauchsüberwachung.
• Aufbewahrung. Anthropics Dokumentation zur Datenaufbewahrung (wird in einem neuen Tab geöffnet) beschreibt Zero Data Retention so, dass Prompts und Antworten nach der Rückgabe der Antwort nicht ruhend gespeichert werden. Die eigene Eignungstabelle führt zustandsbehaftete Funktionen als Ausnahmen auf — Zero Retention gilt also nicht pauschal.
• Wo die Inferenz läuft. Die Region ist konfigurierbar und wird gesondert bepreist. Anthropics Dokumentation zur Datenresidenz (wird in einem neuen Tab geöffnet) hält fest, dass Inferenz ausschließlich in den USA „mit dem 1,1-Fachen des Standardtarifs bepreist wird“.

Wenn das Produkt personenbezogene Daten von Personen in der EU verarbeitet, ist die Pflicht bereits in der Entwurfsphase ausdrücklich.

Der Leitfaden der Europäischen Kommission zu Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen (wird in einem neuen Tab geöffnet) besagt, dass Organisationen standardmäßig „sicherstellen sollten, dass personenbezogene Daten mit dem höchsten Datenschutz verarbeitet werden“.

Das ist eine Entscheidung vor der Integration, nicht nach dem Vorfall.

Planen Sie die Kosten pro Nutzenden

Gehen Sie nicht davon aus, dass ein gehosteter KI-Dienst günstig ist, weil das erste Experiment wenig kostet. Nutzung, Speicherung, Monitoring, Wiederholungen, Prüfzeit und künftige Modellwechsel wirken alle auf die Betriebskosten.

KI-Anbieter berechnen üblicherweise die verarbeitete Textmenge, sodass die Kosten mit der Nutzung wachsen statt mit der Mitarbeiterzahl.

Die Stellschrauben nennt die anbietereigene Preisdokumentation (wird in einem neuen Tab geöffnet): Modellwahl, Prompt-Caching, Token-Overhead bei Tool-Aufrufen und Batching. Die Batch-API von Anthropic bietet für asynchrone Arbeit „einen Rabatt von 50 % auf Eingabe- und Ausgabe-Token“.

Ein Feature, das zum vollen Preis unwirtschaftlich ist, kann in Ordnung sein, wenn die Arbeit nicht sofort erledigt sein muss.

Es gibt auch eine Sicherheitsdimension. Der OWASP-Eintrag Unbounded Consumption (wird in einem neuen Tab geöffnet) beschreibt, wie „Angreifende durch das Auslösen einer großen Zahl von Operationen das nutzungsabhängige Kostenmodell cloudbasierter KI-Dienste ausnutzen“.

Das wird manchmal Denial of Wallet genannt. Ratenbegrenzungen, Kontingente und Nutzungsüberwachung gehören in die erste Version, nicht in die zweite.

Testen Sie zuerst mit echten Beispielen

Bauen Sie ein kleines Testset, bevor Sie das Feature für fertig erklären. Verwenden Sie repräsentative Beispiele, nehmen Sie schwierige Fälle auf und halten Sie die Fehlerarten fest, die für die späteren Nutzenden zählen.

Beide großen Anbieter behandeln das als etwas, das man zuerst tut — nicht als etwas, das man später ergänzt.

Der Leitfaden von Anthropic zum Entwickeln empirischer Evaluierungen (wird in einem neuen Tab geöffnet) ist konkret zur Form eines nützlichen Sets: „Seien Sie aufgabenspezifisch: Entwerfen Sie Evals, die Ihre reale Aufgabenverteilung abbilden. Vergessen Sie nicht, Randfälle einzubeziehen!“

OpenAIs Leitfaden zu Evals (wird in einem neuen Tab geöffnet) beschreibt dieselbe Praxis als Verständnis dafür, wie eine Anwendung gegenüber den Erwartungen abschneidet. Genau das macht einen Modell- oder Prompt-Wechsel sicher auslieferbar.

Eine nützliche Evaluierung muss nicht jede Antwort vorhersagen. Sie sollte zeigen, ob das Feature für seine Aufgabe hilfreich ist, wo es scheitert und wann der Ablauf die Kontrolle an einen Menschen zurückgeben muss.

Evaluierung endet auch nicht mit dem Launch. Microsofts Leitfaden zur Observability (wird in einem neuen Tab geöffnet) beschreibt, wie der Lebenszyklus in den Produktivbetrieb hineinreicht — mit „Qualitäts- und Sicherheitsevaluierung des Produktionsverkehrs anhand einer Stichprobe“.

Die reale Nutzung enthält Eingaben, die Ihr Testset nie vorhergesehen hat.

Planen Sie den Rückfall

Auch ein Rückfall braucht einen praktischen Entwurf. Ist das Modell nicht verfügbar, zu langsam oder unsicher, sollte das Produkt trotzdem erklären, was die Nutzenden als Nächstes tun können, statt einen leeren Zustand oder eine irreführende Antwort zu hinterlassen.

Entscheiden Sie im Voraus, was das Feature in drei Situationen tut: wenn das Modell nichts Brauchbares liefert, wenn die Anfrage in eine Zeitüberschreitung läuft und wenn die Konfidenz niedrig ist.

Jede davon ist eine Produktentscheidung mit sichtbaren Folgen für die Nutzenden. Und jede ist jetzt günstiger zu treffen als während eines Vorfalls.

Es lohnt sich außerdem zu entscheiden, wie leicht Sie später Modell oder Anbieter wechseln könnten. Prompts, Evaluierungssets und eine dünne Schnittstelle zwischen Produkt und Modell erhalten diese Option.

Ein durchgerechnetes Beispiel

Um das konkret zu machen: Stellen Sie sich ein Support-Team vor, das in eingehenden E-Mails versinkt. Jede Nachricht muss gelesen, kategorisiert und an die richtige Person geleitet werden, und das Volumen ist den Menschen dahinter über den Kopf gewachsen.

Der Impuls ist, nach einem KI-Agenten zu greifen, der jede E-Mail liest und beantwortet. Gehen Sie stattdessen die Fragen durch.

Was ist die Aufgabe, und wie würden wir sie ohne KI erledigen? Routing nach Stichwort und Absender deckt die klaren Fälle bereits ab. Schwierig sind die mehrdeutigen Freitextnachrichten — genau die Form, die zu einem Modell passt.

Was kostet eine falsche Antwort? Eine falsch geleitete E-Mail kostet Minuten. Eine automatische Antwort, die eine Rückerstattungsrichtlinie erfindet, kostet weit mehr. Die sichere erste Version schlägt daher eine Kategorie und einen Entwurf vor; gesendet wird weiterhin von einem Menschen.

Wie testen wir es? Ein paar hundert bereits gelöste E-Mails werden zum Evaluierungsset, die unordentlichen und ungewöhnlichen bewusst eingeschlossen. Wenn die vorgeschlagene Kategorie oft genug stimmt, um Lesezeit zu sparen, verdient sie ihren Platz.

Das Feature, das ausgeliefert wird, ist eng geschnitten: klassifizieren und entwerfen, ein Mensch sendet, Stichwortregeln erledigen weiterhin die offensichtlichen Fälle, und alles wird protokolliert, damit das Evaluierungsset weiter wächst.

Das ist ein kleineres, sichereres und günstigeres Produkt als der Agent, den sich das Team zuerst vorgestellt hat — und dasjenige, das den Kontakt mit echten Postfächern eher übersteht.

Entscheiden, was gebaut wird

Mit KI etwas zu bauen und KI im Produkt auszuliefern sind zwei verschiedene Entscheidungen. Entwicklerinnen und Entwickler können beim Programmieren KI-Werkzeuge nutzen und trotzdem ein Produkt liefern, das auf gewöhnlicher Software, auf KI-Funktionen oder auf beidem läuft.

Entscheiden Sie bei einem neuen Produkt zuerst den kleinsten nützlichen Ablauf. Fügen Sie ein KI-Feature nur hinzu, wenn es diesen Ablauf für definierte Nutzende verbessert und sich mit Belegen testen lässt, die das Team pflegen kann.

Der stärkste KI-Produktplan ist bei seinen Grenzen konkret. Er benennt die Aufgabe, die Daten, die prüfende Person, den Rückfall, die Evaluierungsmethode und die Kostenannahmen, bevor das Feature zu einem Versprechen wird.

Wenn Sie KI gegen Automatisierung oder Individualsoftware abwägen, bringen Sie die Entscheidung früh ins Planungsgespräch. Die richtige Antwort kann KI sein, ein regelbasierter Ablauf — oder gar keine neue Technologie.