Ein AI-Prototyp ist noch lange kein AI-Produkt

Eine funktionierende AI-Demo ist wertvoll. Sie beantwortet eine wichtige Frage: Kann ein Modell diese Aufgabe grundsätzlich lösen? Oft reicht dafür ein Notebook, ein Prompt, ein Dokumenten-Upload und ein überzeugender Testfall.

Für ein Produkt ist das nur der Anfang.

Ein AI-Produkt muss nicht nur im Happy Path sinnvoll antworten. Es muss auch dann kontrollierbar bleiben, wenn Nutzer unklare Fragen stellen, Quellsysteme ausfallen, Dokumente fehlen, das Modell halluziniert, Limits erreicht werden oder sich die Kosten unerwartet vervielfachen.

Der Unterschied zwischen Prototyp und Produkt liegt deshalb selten allein im gewählten Modell. Er liegt in den Schichten darum herum: Fehlerpfade, Guardrails, Recovery, Evaluation, Monitoring, Kostenkontrolle und Nutzerführung.

Die Demo optimiert auf Eindruck, das Produkt auf Wiederholbarkeit

Ein Prototyp hat meist günstige Bedingungen:

• wenige, sorgfältig ausgewählte Beispieldaten,
• ein klar formulierter Prompt,
• ein Nutzer, der das System versteht,
• keine oder geringe Parallelität,
• manuelle Kontrolle durch das Team,
• und ein Modell, das zum Zeitpunkt der Demo verfügbar ist.

Das ist legitim. Problematisch wird es, wenn aus einem gelungenen Termin unmittelbar ein Lieferauftrag für „genau diese Lösung in Produktion“ wird.

Ein Produkt muss unter realen Bedingungen funktionieren. Dazu gehören etwa:

• Nutzer formulieren Fachbegriffe falsch oder lassen Kontext weg.
• Ein Retrieval-System findet keine belastbare Quelle.
• Eine Datei ist zu groß, beschädigt oder enthält keinen extrahierbaren Text.
• Ein Tool-Aufruf liefert ein Timeout oder inkonsistente Daten.
• Ein Modellanbieter drosselt Anfragen oder ändert sein Verhalten.
• Ein Nutzer versucht, Systemanweisungen zu umgehen.
• Eine gute Antwort wäre zu teuer oder zu langsam.

Die entscheidende Produktfrage lautet daher nicht: „Kann das Modell eine gute Antwort erzeugen?“ Sondern: „Wie verhält sich das System zuverlässig, wenn es keine gute Antwort erzeugen kann?“

Schicht 1: Den Anwendungsfall eng genug schneiden

Viele AI-Projekte scheitern nicht an der Modellqualität, sondern an einem unscharfen Auftrag. „Ein Chatbot für unsere Wissensdatenbank“ beschreibt keine Produktfunktion. Es beschreibt eine Oberfläche mit unbekanntem Risiko.

Produktreif wird ein Use Case, wenn klar ist:

1. Wer nutzt die Funktion?
2. Welche Entscheidung oder Tätigkeit wird konkret unterstützt?
3. Welche Datenquellen dürfen verwendet werden?
4. Was darf das System selbstständig tun — und was nicht?
5. Woran messen wir Nutzen und Fehler?

Ein Beispiel: „Fragen zu internen Reiserichtlinien beantworten“ ist deutlich beherrschbarer als „Mitarbeitende bei HR-Fragen unterstützen“. Für den ersten Fall lassen sich Quellen, Aktualität, erlaubte Aussagen und Eskalationswege definieren. Beim zweiten Fall können arbeitsrechtliche, personenbezogene und sensible Themen auftauchen.

Ein enger erster Anwendungsfall ist keine Einschränkung der Vision. Er ist die Voraussetzung dafür, Qualität überhaupt messen und verantworten zu können.

Schicht 2: Fehlerpfade als fachliche Funktion behandeln

In klassischen Anwendungen werden Fehler häufig als technische Ausnahme betrachtet: Log schreiben, Fehlermeldung anzeigen, später analysieren. Bei AI-Systemen sind Fehlerpfade Teil der Kernfunktion.

Ein System, das keine belastbare Antwort kennt, sollte nicht kreativ werden. Es sollte beispielsweise:

• transparent sagen, dass die vorhandenen Quellen nicht ausreichen,
• die verwendeten Quellen anzeigen,
• auf einen verbindlichen Prozess oder Ansprechpartner verweisen,
• gezielt Rückfragen stellen,
• eine Aufgabe zur manuellen Bearbeitung erzeugen,
• oder eine Aktion bewusst nicht ausführen.

Das muss pro Use Case entschieden werden. „Ich weiß es nicht“ ist nicht immer die richtige Reaktion. Bei einem Support-Assistenten kann ein Ticket sinnvoll sein. Bei einer Vertragsprüfung ist möglicherweise eine Eskalation an Legal erforderlich. Bei einer Bestellfunktion darf ohne verifizierte Daten schlicht keine Bestellung ausgelöst werden.

Wichtig ist die Trennung zwischen Antwort erzeugen und Entscheidung treffen. Ein Modell kann einen Entwurf liefern. Die Freigabe, Buchung, Kündigung oder Preisänderung sollte nur unter klaren Regeln erfolgen.

Schicht 3: Guardrails an den Systemgrenzen bauen

Guardrails sind keine einzelne Prompt-Zeile. Ein Satz wie „Beachte die Datenschutzregeln“ ist keine Sicherheitsarchitektur.

Wirksame Guardrails sitzen an mehreren Stellen:

Ebene	Beispiel
Eingabe	Dateitypen, Größenlimits, Malware-Scan, Rate Limits, Erkennung offensichtlicher Prompt-Injection-Muster
Identität	Authentifizierung, Mandantentrennung, rollenbasierte Berechtigungen
Kontext	Retrieval nur aus Quellen, auf die der Nutzer Zugriff hat; Filter nach Aktualität und Dokumentstatus
Modell	Systeminstruktionen, strukturiertes Output-Format, Tool-Berechtigungen, begrenzte Iterationen
Aktion	Serverseitige Validierung, Freigaben, Idempotenz, erlaubte Parameterbereiche
Ausgabe	Quellenhinweise, PII-Filter, Formatprüfung, Kennzeichnung von Unsicherheit

Besonders kritisch wird es, sobald ein Agent Werkzeuge aufrufen darf. Dann ist die relevante Frage nicht mehr nur, ob der Text plausibel klingt. Sie lautet: Welche Aktionen darf das System unter welchen Voraussetzungen auslösen?

Ein Modell darf niemals die alleinige Instanz sein, die Berechtigungen prüft. Wenn ein Tool etwa Kundendaten laden oder Rechnungen erstellen kann, muss der Server unabhängig vom Modell prüfen, ob Nutzer, Mandant und Aktion zulässig sind.

Schicht 4: Retrieval ist ein Datenprodukt, kein Anhängsel

Viele Wissensassistenten nutzen Retrieval-Augmented Generation (RAG): Vor einer Modellanfrage werden passende Dokumentabschnitte gesucht und als Kontext übergeben. Das reduziert Halluzinationen, löst aber nicht automatisch das Qualitätsproblem.

Typische Ursachen schlechter Antworten sind:

• Dokumente sind veraltet oder widersprüchlich.
• Die Chunking-Strategie trennt relevante Informationen.
• Metadaten wie Gültigkeitsbereich, Sprache oder Dokumentversion fehlen.
• Berechtigungen werden erst nach der Suche statt davor geprüft.
• Die Suche liefert semantisch ähnliche, aber fachlich falsche Inhalte.
• Quellen werden nicht zitiert, sodass Nutzer Aussagen nicht prüfen können.

Daher braucht auch Retrieval einen klaren Betriebsprozess: Dokumente importieren, klassifizieren, versionieren, freigeben, aktualisieren und bei Bedarf entfernen. Wer nicht beantworten kann, welche Quelle zu welchem Zeitpunkt für eine Antwort verwendet wurde, kann die Qualität später kaum untersuchen.

Schicht 5: Evaluation vor dem Rollout, nicht nur nach Beschwerden

„Die Antworten sehen gut aus“ ist kein Qualitätsnachweis. AI-Funktionen brauchen ein Testset mit realistischen Fällen.

Ein brauchbares Evaluationsset enthält nicht nur Standardfragen, sondern auch:

• unvollständige und mehrdeutige Anfragen,
• falsche Annahmen in Nutzerfragen,
• veraltete oder widersprüchliche Quellen,
• Fragen ohne vorhandene Antwort,
• Berechtigungsgrenzen,
• adversariale Eingaben und Prompt Injection,
• lange Konversationen,
• Tool-Fehler und Timeouts.

Je nach Anwendungsfall lassen sich unterschiedliche Kriterien messen: fachliche Korrektheit, Quellenbezug, Vollständigkeit, Format, Latenz, Kosten und korrekte Verweigerung. Gerade die letzte Kategorie wird häufig vergessen. Ein System muss nicht jede Frage beantworten; es muss aber zuverlässig erkennen, wann es nicht antworten sollte.

Für Änderungen an Prompt, Modell, Retrieval oder Tooling sollte dieses Set automatisiert laufen. Sonst wird jede Verbesserung zum Risiko für bereits funktionierende Fälle.

Schicht 6: Observability für den gesamten Ablauf

In Produktion reicht ein Error-Tracking nicht aus. Ein AI-Request kann technisch erfolgreich sein und fachlich dennoch scheitern.

Für jeden Vorgang sollten — datenschutzkonform und mit angemessener Redaktion sensibler Inhalte — mindestens nachvollziehbar sein:

• verwendete Modell- und Prompt-Version,
• Laufzeit und Tokenverbrauch,
• Retrieval-Treffer und deren Scores,
• aufgerufene Tools und Resultate,
• Validierungs- und Guardrail-Entscheidungen,
• Fehler, Retries und Fallbacks,
• Nutzerfeedback und Abbruchpunkte.

Diese Daten dienen nicht nur dem Debugging. Sie machen sichtbar, ob ein Problem aus schlechter Datenqualität, einem Retrieval-Fehler, einem Modellwechsel, einer unklaren UX oder einem Infrastrukturengpass entsteht.

Ein praktisches Minimum sind Dashboards für Fehlerraten, Latenz, Kosten pro erfolgreicher Aufgabe, Retrieval-Qualität, Fallback-Rate und Eskalationen. Zusätzlich braucht es Alerts für ungewöhnliche Kostenanstiege, häufige Tool-Fehler und sicherheitsrelevante Muster.

Schicht 7: Kosten und Latenz als Produktanforderungen definieren

AI-Kosten skalieren oft anders als klassische Infrastruktur. Lange Konversationen, große Dokumente, viele Retrieval-Treffer und Agent-Schleifen können eine einzelne Nutzeraktion erheblich verteuern.

Kostenkontrolle beginnt mit expliziten Budgets:

• maximales Kontextfenster pro Anfrage,
• begrenzte Anzahl von Tool-Aufrufen,
• Token- und Zeitlimits pro Workflow,
• Modellrouting nach Aufgabe,
• Caching für wiederkehrende Ergebnisse,
• asynchrone Verarbeitung für nicht interaktive Aufgaben,
• Abbruchregeln für Schleifen ohne Fortschritt.

Dabei ist nicht immer das stärkste Modell die beste Wahl. Klassifikation, Extraktion, Formatvalidierung oder einfache Zusammenfassungen lassen sich häufig günstiger und schneller lösen als komplexe Analyseaufgaben. Eine belastbare Architektur trennt diese Aufgaben, statt jede Anfrage an dasselbe Modell zu schicken.

Auch Latenz ist UX. Wenn eine Antwort zehn Sekunden benötigt, braucht die Oberfläche einen verständlichen Zwischenzustand, eine Abbruchmöglichkeit und gegebenenfalls einen asynchronen Ablauf. Stilles Warten erzeugt Unsicherheit — unabhängig davon, wie gut die spätere Antwort ist.

Schicht 8: UX muss Unsicherheit sichtbar machen

Ein sprachlich überzeugender Text wird leicht als verlässlich wahrgenommen. Genau das ist bei AI-Produkten riskant.

Gute UX hilft Nutzern, Ergebnisse richtig einzuordnen:

• Quellen direkt an der relevanten Aussage anzeigen,
• Entwürfe klar als Entwürfe markieren,
• Unsicherheit nicht hinter scheinbar definitiver Sprache verstecken,
• Rückfragen stellen, wenn Kontext fehlt,
• Freigaben vor folgenreichen Aktionen verlangen,
• Feedback niedrigschwellig ermöglichen,
• und einen menschlichen Ausweg anbieten.

Der wichtigste UX-Fehler ist oft ein zu offenes Eingabefeld mit der impliziten Botschaft: „Frag alles.“ Besser sind geführte Einstiege, Beispiele, Auswahlmöglichkeiten und klare Grenzen. Sie verbessern nicht nur die Bedienung, sondern auch Qualität, Kosten und Sicherheit.

Eine pragmatische Produkt-Checkliste

Vor einem breiteren Rollout sollte ein Team diese Fragen konkret beantworten können:

• Ist der erste Use Case fachlich eng beschrieben und priorisiert?
• Gibt es definierte Erfolgs- und Qualitätskriterien?
• Sind Datenquellen, Aktualität, Eigentümer und Berechtigungen geklärt?
• Gibt es definierte Antworten für fehlenden Kontext und fehlende Quellen?
• Werden risikoreiche Aktionen serverseitig validiert und gegebenenfalls freigegeben?
• Existiert ein Testset mit Normalfällen, Grenzfällen und Missbrauchsversuchen?
• Werden Prompt-, Modell- und Retrieval-Änderungen gegen dieses Testset geprüft?
• Sind Latenz, Tokenverbrauch, Tool-Aufrufe und Fehlerraten beobachtbar?
• Gibt es Kostenlimits und eine Strategie bei Anbieterproblemen?
• Können Nutzer Quellen prüfen, Feedback geben und an Menschen eskalieren?
• Sind Datenschutz, Logging, Aufbewahrung und Mandantentrennung entschieden?
• Ist klar, wer im Betrieb Qualität, Daten und Incidents verantwortet?

Der Übergang zur Produktreife ist Delivery-Arbeit

Der Weg von der Demo zum Produkt ist kein nachgelagerter Härtungsschritt. Er verändert Architektur, Backlog und Teamzuschnitt von Anfang an.

In der Praxis hat sich ein iterativer Ablauf bewährt: erst einen eng begrenzten Use Case mit realen Daten und echten Nutzern umsetzen, dann Messbarkeit und Fehlerpfade ergänzen, anschließend anhand beobachteter Fälle erweitern. So entstehen keine abstrakten Compliance- oder Plattformprojekte ohne Nutzwert, aber auch keine unkontrollierten Chat-Demos mit Produktionszugriff.

Ein AI-Prototyp beweist Potenzial. Ein AI-Produkt beweist, dass dieses Potenzial unter realen Bedingungen verantwortbar geliefert werden kann. Die Differenz entsteht nicht in einem besseren Prompt, sondern in sauberer Produktarbeit und belastbarem Software Engineering.