Von der Demo zur Produktion: Was der Einsatz eines KI-Agenten 2026 wirklich erfordert

Die Lücke zwischen einer guten Demo und einem fertigen Feature

Jedes Unternehmen, mit dem wir 2026 sprechen, hat die Demo bereits gesehen. Jemand im Team hat ein LLM an eine Tabelle angeschlossen oder an einem Wochenende einen Chatbot auf Basis interner Dokumente gebaut, und beim All-Hands sah das großartig aus. Dann lag es drei Monate lang ungenutzt in einem Slack-Channel, weil niemand die Frage beantworten konnte: Was passiert, wenn es vor einem Kunden falschliegt – oder schlimmer, vor einem Prüfer?

Genau in dieser Lücke – zwischen „das Modell hat einmal eine gute Antwort geliefert" und „das läuft unbeaufsichtigt gegen echte Daten, für echte Nutzer, jeden Tag" – steckt fast unsere gesamte Projektzeit im Bereich KI/ML. Den Prompt zu bauen ist eine Sache von einem Nachmittag. Ihn so sicher zu machen, dass man ihn unbeaufsichtigt laufen lassen kann, ist das eigentliche Projekt.

Hier ist, was eine Demo tatsächlich von einem Produktionssystem unterscheidet – und was es kostet, diese Lücke zu schließen.

Demos überspringen genau die Teile, die für Zuverlässigkeit sorgen

Eine Demo ist eine einzelne Eingabe, einmal ausgeführt, von jemandem, der weiß, wie man die Frage formuliert. Produktion bedeutet Tausende unvorhersehbare Eingaben, fortlaufend, von Menschen, die weder wissen noch interessiert, wie das Modell funktioniert. Beim Sprung dorthin brechen zuerst drei Dinge:

1. Niemand kann sagen, ob eine Prompt-Änderung die Sache besser oder schlechter gemacht hat. Ohne einen festen Satz an Testfällen und erwarteten Ergebnissen – ein Eval-Set – ist jede Prompt-Anpassung reines Raten. Wir bauen ein Eval-Set aus echten Nutzerfragen, bevor wir einen Produktions-Prompt überhaupt anfassen, und lassen es bei jeder Modell- oder Prompt-Änderung erneut laufen. Wenn ein Kunde uns nicht sagen kann, dass sich die Erfolgsquote von einem Wert zu einem besseren bewegt hat, kann er eine Änderung nicht sicher ausrollen – er hofft nur.

2. Das Modell ist nur so gut wie das, was es abrufen kann. Bei allem, was auf den eigenen Daten basiert – Support-Dokumente, Verträge, interne Wikis – zählt die Qualität des Retrievals mehr als die Wahl des Modells. Naives Chunking und eine einzelne Vektorsuche liefern Ihnen eine Demo, die bei den drei getesteten Fragen funktioniert. Produktions-RAG braucht Hybrid-Suche (Keyword plus Vektor), Reranking und die zwingende Anforderung, dass jede Antwort ihr Quelldokument nennt. Wenn das System nicht zeigen kann, woher eine Antwort stammt, sollten Sie es nicht in einem kundenseitigen Feature einsetzen.

3. Agenten, die Tools nutzen, brauchen ein Berechtigungsmodell, nicht nur einen Prompt. Sobald ein Agent eine Rückerstattung auslösen, einen CRM-Datensatz ändern oder in jemandes Namen eine E-Mail verschicken kann, reicht „das Modell hat sich dafür entschieden" als Erklärung nicht mehr aus. Jede Aktion braucht einen klar definierten Wirkungsradius: was der Agent autonom darf, was eine menschliche Freigabe erfordert und was er niemals anfassen darf. Für jeden Agenten, den wir bauen, führen wir eine explizite No-Go-Liste – meist alles Unumkehrbare oder Finanzielle – noch bevor wir die erste Tool-Definition schreiben.

Der Fehlerfall, mit dem niemand rechnet: selbstbewusst falsche Antworten

Ein API-Ausfall ist offensichtlich. Ein Modell, das flüssig und falsch antwortet, ist es nicht. Genau dieses Risiko zerstört das Vertrauen in ein KI-Feature schneller als alles andere – eine einzige falsche Antwort, mit voller Überzeugung geliefert, und das Team, das das Projekt vorangetrieben hat, verbringt das nächste Quartal damit, es zu verteidigen.

Die Lösung ist kein besseres Modell. Sie ist struktureller Natur: Zitate für alles verlangen, was auf den eigenen Daten basiert, eine Konfidenzschwelle einbauen, die unsichere Antworten an einen Menschen weiterleitet statt zu raten, und jeden Prompt, jedes Retrieval und jede Completion loggen, damit sich im Fehlerfall exakt rekonstruieren lässt, was passiert ist. Wir behandeln diese Logging-Ebene als nicht verhandelbar – genauso wie Error-Logging in einem Zahlungsprozess. Niemand bemerkt sie, bis der Tag kommt, an dem man sie dringend braucht.

Interne Automatisierung ist aktuell der schnellste KI-ROI

Kundenseitige Agenten bekommen die Aufmerksamkeit, aber die KI-Arbeit mit der höchsten Erfolgssicherheit, die wir 2026 leisten, ist intern: eingehende Support-Tickets triagieren, bevor ein Mensch sie sieht, Verkaufsgespräche zu CRM-Notizen zusammenfassen, Positionen aus Rechnungen und Verträgen extrahieren, und Mitarbeitenden erlauben, Fragen gegen interne Dokumente zu stellen, statt im Slack-Channel nachzufragen. Der Einsatz ist geringer – ein internes Tool, das gelegentlich falschliegt, wird von einer Kollegin oder einem Kollegen korrigiert, nicht von einem Kunden –, deshalb können die Leitplanken schlanker ausfallen und die Amortisation schneller eintreten.

Ein klar abgegrenzter RAG-Assistent auf der eigenen Unternehmensdokumentation ist realistisch ein Projekt ab $7,000+, mit einem funktionierenden Prototyp in 2 bis 4 Wochen und einer produktionsreifen Version – Auth, Logging, Eval-Set, Quellenangaben – in 8 bis 12 Wochen. Tool-nutzende Agenten, die in echte Systeme eingebunden werden (ein CRM, ein Ticketing-System, ein ERP), starten bei etwa $20,000+, weil der Aufwand für Berechtigungen und Tests mit dem skaliert, was der Agent anfassen darf. Reine Workflow-Automatisierung – kein Modell im Loop, nur zuverlässige Datenbewegung zwischen Tools – beginnt niedriger, ab $3,000 für eine einzelne Integration.

Was wir festlegen, bevor der erste Prompt geschrieben wird

Bei jedem KI-Projekt werden vier Dinge entschieden, bevor Code ausgeliefert wird – nicht danach:

• Ein Owner für das Eval-Set. Jemand, dessen Aufgabe es ist, einen Qualitätsabfall zu bemerken – nicht „das Team" im Abstrakten.
• Eine dokumentierte No-Go-Liste. Die konkreten Aktionen, die das System niemals ohne vorherige menschliche Bestätigung ausführen darf.
• Eine Kostenobergrenze. Token-Budgets pro Nutzer oder pro Tag, mit Warnungen, bevor die Rechnung jemanden überrascht. Triage mit einem günstigen Modell plus Eskalation an ein Frontier-Modell – nicht Frontier-Modell für alles.
• Ein Rollback-Plan. Modellanbieter ändern das Verhalten unter einem stabilen API-Namen häufiger, als Teams erwarten. Fällt die Genauigkeit nach einem stillen Update des Anbieters ab, brauchen Sie eine vorherige Prompt-Version und einen vorherigen Eval-Score zum Vergleich.

Überspringt man eines davon, scheitert das Projekt nicht laut – es scheitert leise, Wochen nach dem Launch, wenn jemand bemerkt, dass das System schon eine Weile selbstbewusst falschgelegen hat und niemand hingesehen hat.

Das Fazit

Das Modell ist 2026 selten der Flaschenhals. Frontier-APIs von OpenAI und Anthropic, kombiniert mit Retrieval-Frameworks wie LlamaIndex und Vektor-Stores wie pgvector, reichen für die überwältigende Mehrheit geschäftlicher Anwendungsfälle völlig aus. Was darüber entscheidet, ob ein KI-Feature den Kontakt mit echten Nutzern übersteht, ist das unspektakuläre Engineering drumherum: Evals, Grounding, Berechtigungen, Logging und ein Kostenmodell, das die Finanzabteilung nicht überrascht.

Genau das ist die Arbeit unseres Teams für KI & Machine Learning – aus einer funktionierenden Demo ein System zu machen, das ein Unternehmen tatsächlich unbeaufsichtigt betreiben kann. Wenn eher die interne Automatisierung Ihr eigentliches Anliegen ist – Tools verbinden und repetitive Arbeit eliminieren, statt ein neues KI-Feature zu bauen –, geht unser Team für Automatisierung & Integrationen genauso vor: schnell prototypen, dann härten, bevor es etwas berührt, das wirklich zählt.