Zurück zum Blog
Kunftia Blog

Zwischen KI-Versprechen und Realität: Was ich beim Aufbau eines Chatbots im Unternehmen gelernt habe

Viele KI-Versprechen klingen beeindruckend. Meine Erfahrung aus der Entwicklung von Nauli zeigt: Ein Prototyp ist schnell gebaut, die eigentliche Arbeit beginnt bei Integration, Datenqualität, Tests und ehrlicher Erwartungssteuerung.

12. April 2026 Zied Mcharek
KI Chatbot Nauli RAG KI-Automatisierung

Warum ich diesen Beitrag schreibe

Wer sich gerade mit KI im Unternehmen beschäftigt, hört oft sehr große Versprechen.

Es ist Sonntagmorgen. Ich trinke meinen Kaffee und prüfe parallel die Testergebnisse, die über Nacht gelaufen sind. Auf den ersten Blick sieht alles gut aus. Aber dann entdecke ich, dass unser Chatbot bei der Antwortgenerierung plötzlich rund 20 Prozent langsamer geworden ist.

Damit ist klar: Das wird leider kein entspannter Sonntag.

Trotzdem oder vielleicht genau deshalb habe ich mich entschieden, diesen Beitrag zu schreiben.

Da ist von enormen Produktivitätssprüngen die Rede, von 80 Prozent Zeitersparnis, von neuen Margen, von automatisiertem Wachstum und davon, dass Teams mit KI plötzlich doppelt so schnell arbeiten. Das klingt gut. Manchmal zu gut.

Ich will hier bewusst eine ehrlichere Perspektive zeigen.

Ich bezweifle nicht, dass KI in vielen Bereichen sehr hilfreich ist. KI kann Texte schneller schreiben. KI kann beim Coding unterstützen. KI kann neue Geschäftsmodelle ermöglichen. Und sie kann in bestimmten Prozessen echten Mehrwert schaffen.

Aber meine persönliche Erfahrung ist: Die Realität in Unternehmen ist deutlich weniger spektakulär als viele Schlagzeilen vermuten lassen. Und manchmal wird es sogar gefährlich. Nicht technisch im engeren Sinn, sondern organisatorisch. Denn sobald überall erzählt wird, dass die KI “doch schon alles kann”, steigt auf Entwickler, Fachbereiche und Projektteams oft nur der Druck. Plötzlich wird erwartet, dass alles noch schneller gehen muss. Dass weniger Rückfragen nötig sind. Dass Qualität quasi automatisch mitgeliefert wird.

Genau das erlebe ich so nicht.

Ein Prototyp ist schnell gebaut, ein verlässliches System nicht

Ich schreibe das nicht aus Distanz, sondern aus eigener Erfahrung. Im Dezember 2024 habe ich angefangen, unseren Chatbot Nauli als Prototyp zu entwickeln. Damals waren Coding-Agenten noch längst nicht so weit wie heute. Vieles wurde klassisch gebaut, und genau das hat mir geholfen, die Technik hinter einem RAG-System wirklich zu verstehen.

Mich fasziniert bis heute, dass wir mit Vektoren in hochdimensionalen Räumen arbeiten, also mit etwas, das man mathematisch beschreiben, aber kaum wirklich intuitiv “sehen” kann. Gerade diese Mischung aus praktischer Anwendung und abstrakter Technik hat mich von Anfang an gereizt.

Der erste Prototyp war schnell da. Das ist übrigens ein wichtiger Punkt: Eine Demo ist heute oft nicht das Problem. Ein Chatbot, der in einer isolierten Umgebung erste Fragen beantwortet, lässt sich vergleichsweise schnell zeigen. Auch wir hatten relativ früh etwas, das funktioniert hat.

Die Version 0.1 von Nauli war im März 2025 so weit, dass ich sie in einem ersten Kundengespräch erfolgreich präsentieren konnte. Und genau dort beginnt der Teil, der in vielen LinkedIn-Posts und Hochglanzpräsentationen kaum vorkommt.

Denn nach der Demo ging es nicht mehr um die Frage, ob ein Chatbot grundsätzlich antworten kann. Es ging um die Integration in die reale Umgebung des Kunden. Und ich muss ehrlich sagen: Ich habe das anfangs unterschätzt.

Die Infrastruktur beim Kunden ist die erste Realität

Die Entwicklungsumgebung auf einer schnellen lokalen Maschine ist nicht die Realität eines Unternehmens. In der Praxis trifft man auf sehr unterschiedliche Voraussetzungen.

Es gibt Kunden mit eigenem Rechenzentrum, bei denen Modelle lokal laufen sollen. Es gibt Kunden, die stark in der Cloud unterwegs sind, aber eben nicht alle bei denselben großen Anbietern. Und es gibt auch Umgebungen, in denen bestehende lokale Server und gewachsene Infrastruktur eine wichtige Rolle spielen, obwohl sie nicht speziell für moderne KI-Anwendungen aufgebaut wurden.

All das muss man berücksichtigen.

Ich bin heute sehr froh, dass wir bei Nauli früh auf eine Microservice-Architektur gesetzt haben. Das gibt uns Flexibilität. Aber auch damit deckt man nicht automatisch jeden Sonderfall ab. In manchen Projekten braucht es zusätzliche Anpassungen. Das ist kein Scheitern, sondern normale Realität. Standardisierung ist wichtig, aber in echten Unternehmensprojekten bleibt eine gewisse Sonderlösung manchmal trotzdem notwendig.

Genau hier zeigt sich für mich ein Kernproblem vieler KI-Versprechen: Die Folien sehen oft so aus, als müsste man nur ein Modell auswählen und ein paar Daten anschließen. In der Praxis hängen Erfolg oder Frust aber sehr stark an Infrastruktur, Sicherheitsanforderungen, Betriebsmodell und Integration in bestehende Systeme.

Testing ist kein Extra, sondern Pflicht

Mein Hintergrund prägt dabei stark, wie ich an solche Systeme herangehe. Ich komme unter anderem aus dem Testmanagement in der Automobilbranche. Deshalb war für mich von Anfang an klar, dass wir nicht einfach nur “möglichst viel KI” in ein Produkt kippen dürfen.

Ich wollte ein System bauen, das sich kontrolliert weiterentwickelt.

Jede Erweiterung wird bei uns intensiv getestet. Wir arbeiten mit einem automatisierten Golden-Testkatalog, also mit einer festen Menge an Prüf- und Vergleichsfällen, die sicherstellen soll, dass das System besser wird, ohne dass Antwortqualität oder Performance unbemerkt kippen.

Genau dieser Teil macht mir bis heute sehr viel Spaß: zu sehen, wie ein System schrittweise reifer wird, statt nur kurzfristig spektakulär zu wirken.

Das klingt vielleicht unspektakulär. Ist es auch. Aber gerade darin liegt aus meiner Sicht der Unterschied zwischen einer überzeugenden Demo und einem verlässlichen Produktivsystem.

Der zweite große Realitätscheck: die Daten

Selbst wenn die Architektur sauber ist und die Tests stimmen, kommt der zweite große Prüfstein: die Daten.

Und das ist aus meiner Sicht der Punkt, an dem die größten Missverständnisse entstehen.

Viele denken bei Datenproblemen sofort an riesige PDF-Dateien mit tausend Seiten. Ehrlich gesagt: Das ist oft noch das kleinere Problem. Schwieriger sind in der Praxis ganz andere Dinge:

  • Excel-Dateien mit zehntausenden Zellen
  • Inhalte mit Prozessbildern, Tabellen und Sonderformatierungen
  • Dokumente, in denen sich mit der Zeit Widersprüche eingeschlichen haben
  • Fachbegriffe, die über Abteilungen hinweg unterschiedlich verwendet werden
  • gewachsene Ablagen, in denen Wissen verteilt und nicht einheitlich strukturiert ist

Wichtig ist mir dabei eines sehr klar zu sagen: Es geht nicht darum, dass Kundendaten “schlecht” wären.

Im Gegenteil. Diese Daten sind meistens über Jahre von Menschen für Menschen entstanden. Genau deshalb funktionieren sie im Arbeitsalltag ja oft überhaupt noch. Mitarbeitende finden darin Informationen, erkennen Zusammenhänge und wissen meist auch, welche Quelle wie zu lesen ist.

Aber ein System, das Informationen maschinell verarbeiten, aufteilen, indexieren und wieder präzise zusammensetzen soll, stellt andere Anforderungen.

Besonders schwierig wird es dort, wo Inhalte nicht einfach “alt” sind, sondern innerhalb der Dokumente oder zwischen mehreren Quellen Widersprüche enthalten. Dann sollte man sich nicht wundern, wenn die KI in einem Fall Antwort A und in einem anderen Fall Antwort B gibt. Das ist nicht automatisch ein Zeichen dafür, dass das System “spinnt”, sondern oft ein Hinweis darauf, dass die zugrunde liegende Wissensbasis selbst nicht eindeutig genug ist.

Wer dann sagt: “Der Chatbot ist doch intelligent, der wird das schon verstehen”, baut oft auf die falsche Erwartung.

Warum ein intelligenter Chatbot nicht automatisch gute Antworten gibt

Gerade bei RAG-Systemen wird oft unterschätzt, wie viel vor der eigentlichen Antworterzeugung passieren muss. Relevante Quellen müssen gefunden, Inhalte sauber aufbereitet, sinnvolle Ausschnitte gebildet, Berechtigungen berücksichtigt und Ergebnisse passend zusammengestellt werden.

Microsoft beschreibt in seinen Unterlagen zu RAG sehr klar genau diese Schwierigkeiten: komplexe Nutzerfragen, verteilte Datenquellen, begrenzte Token-Fenster, hohe Erwartungen an Antwortgeschwindigkeit und die Notwendigkeit von Sicherheit und Governance. Das deckt sich sehr stark mit meiner Erfahrung aus Projekten. Ein RAG-System scheitert selten nur am Modell. Es scheitert viel häufiger an Suchqualität, Datenzugriff, Struktur und Betriebsrealität. Mehr dazu beschreibt Microsoft Learn in der Übersicht zu den Herausforderungen von RAG-Systemen.

Auch OpenAI weist inzwischen sehr klar darauf hin, dass Halluzinationen ein grundlegendes Problem großer Sprachmodelle bleiben. Bessere Modelle helfen, aber das Problem verschwindet nicht einfach. Genau deshalb ist es gefährlich, aus einem gut formulierten Satz direkt auf Verlässlichkeit zu schließen. Der Beitrag Why language models hallucinate bringt das aus meiner Sicht sehr gut auf den Punkt.

Für mich heißt das in der Praxis: Gute Sprache ist nicht dasselbe wie gute Antworten.

Zwischen Begeisterung und Wirklichkeit

Ich bin weiterhin begeistert von KI-Werkzeugen. Wirklich. Ich sehe jeden Tag, wie hilfreich sie in der Entwicklung und bei der Arbeit an Produkten sein können. Gerade beim Schreiben, Strukturieren, Reflektieren, Testen oder beim Beschleunigen bestimmter Entwicklungsschritte bringen sie echten Nutzen.

Aber ich bin vorsichtig geworden bei allem, was nach automatischer Wunderwirkung klingt.

Das betrifft übrigens nicht nur Chatbot-Projekte. Die DORA-Forschung von Google Cloud beschreibt KI ausdrücklich eher als Verstärker bestehender Stärken und Schwächen einer Organisation als als automatisches Wundermittel. Der größte Nutzen kommt nicht einfach aus dem Tool selbst, sondern aus dem organisatorischen System drumherum. Wer saubere Prozesse, gute Zusammenarbeit und eine realistische Einführung hat, profitiert stärker. Wer schon vorher strukturelle Probleme hatte, verstärkt sie mit KI im Zweifel eher. Die Kernaussage findet sich im Bericht State of AI-assisted Software Development 2025.

Auch aus der Entwicklerperspektive lohnt sich mehr Ehrlichkeit. Eine Studie von METR aus dem Jahr 2025 kam in einem konkreten Setting mit erfahrenen Open-Source-Entwicklern zu einem überraschenden Ergebnis: Die Beteiligten erwarteten, mit KI schneller zu werden, waren unter Studienbedingungen aber im Schnitt langsamer. Das heißt nicht, dass KI nichts bringt. Aber es zeigt sehr deutlich, dass Wahrnehmung, Demo und reale Wirkung nicht immer deckungsgleich sind. Die Studie ist hier verlinkt: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.

Genau deshalb halte ich wenig von pauschalen Aussagen wie “mit KI verdoppeln Sie Ihre Marge” oder “Ihre Entwickler sind jetzt 80 Prozent schneller”. Solche Aussagen mögen Aufmerksamkeit erzeugen. Aber sie helfen Unternehmen selten dabei, ein belastbares Projekt aufzusetzen.

Was wir Kunden lieber ehrlich sagen

Wir sagen nicht: “KI löst alles.”

Wir sagen auch nicht: “Gebt uns eure Daten und dann läuft das schon.”

Und wir versprechen keine Fantasiezahlen, nur weil sie sich gut verkaufen.

Wir sagen lieber:

  • Ja, KI kann sehr hilfreich sein.
  • Ja, ein Chatbot kann Prozesse entlasten.
  • Ja, Wissenszugang lässt sich deutlich verbessern.
  • Aber nein, nicht jeder Datenbestand ist sofort KI-fähig.
  • Nein, nicht jede Infrastruktur passt ohne Weiteres.
  • Und nein, ein guter Prototyp ist noch kein gutes Produktivsystem.

Unsere Aufgabe ist deshalb nicht nur, ein System zu bauen. Unsere Aufgabe ist auch, Kunden durch die schwierigen Stellen zu begleiten. Daten gemeinsam zu bereinigen. Grenzen offen anzusprechen. Lösungen schrittweise auszubauen. Und dort, wo Standardwege nicht reichen, zusätzliche Features oder angepasste Lösungen zu entwickeln.

Für mich ist das kein Zeichen von Schwäche, sondern von Professionalität.

Mein Rat an Entscheider, die mit einem KI-Chatbot starten wollen

Wenn ich heute einen Entscheider beraten würde, der mit einem KI-Chatbot starten will, dann würde ich drei Dinge sagen.

1. Starten Sie kleiner, als Sie ursprünglich vorhaben

Nicht mit allen Daten, allen Prozessen und allen Sonderfällen gleichzeitig. Sondern mit einem klaren, überschaubaren Anwendungsfall, bei dem Nutzen, Risiken und Testfälle gut sichtbar sind.

2. Rechnen Sie mit Arbeit an den Grundlagen

Die eigentliche Hebelwirkung liegt oft in Datenstruktur, Testlogik, Berechtigungen und Integration, nicht im Modellnamen auf der Folie.

3. Verwechseln Sie eine gute Demo nicht mit einem stabilen Betrieb

Der Unterschied zwischen “sieht beeindruckend aus” und “funktioniert im Alltag zuverlässig” ist größer, als viele annehmen.

Fazit

Ich bin weiterhin überzeugt, dass KI im Unternehmen viel bewegen kann. Sonst würde ich Nauli nicht bauen.

Aber ich glaube genauso, dass die Enttäuschung nach der ersten Euphorie groß sein kann, wenn Projekte mit falschen Erwartungen starten.

KI ja.

Aber bitte ehrlich.

Nicht mit falschen Versprechen, sondern mit sauberer Architektur, realistischen Zielen, guten Tests und dem Respekt vor der Realität in echten Unternehmen.

Wenn Sie tiefer in die technischen Grundlagen einsteigen möchten, lesen Sie auch unseren Beitrag zur RAG-Implementierung im Unternehmen. Für die Perspektive auf interne Suche und gewachsene Wissenslandschaften passt außerdem Intranet-Suche verbessern: Welche KI-Suchlösung besser als die Standardsuche ist. Mehr zu unserer Lösung finden Sie auf der Nauli-Seite.

Externe Quellen

Dieser Beitrag wurde von meinen Erfahrungen inspiriert und mit Unterstützung von KI geschrieben ;-)