Voicebot Bea nach einem Jahr: Was wir über Enterprise Voice-KI gelernt haben

Im Mai 2026 haben wir Bea, unseren KI-Voice-Assistenten für Vergaberecht, live gestellt.

Heute, ein Jahr später, können wir sagen: Es funktioniert. Und wir haben dabei mehr gelernt als in den sechs Monaten Entwicklung davor.

Hier sind die ehrlichsten Erkenntnisse.

Was wir richtig gemacht haben

Der Echtzeit-Stack war die richtige Wahl.

Wir haben von Anfang auf LiveKit als WebRTC-Backbone gesetzt. Das bedeutete mehr Komplexität beim Setup — aber in der Praxis hat es sich bezahlt gemacht. Sprachlatenzen unter 800 Millisekunden, keine Dropouts bei Verbindungsproblemen, und ein Framework, das aktiv weiterentwickelt wird.

Hätten wir auf eine Pseudo-Realtime-Lösung mit HTTP-Polling gesetzt, hätten wir heute technische Schulden, die wir nicht abstottern könnten.

Mistral Voxtral für STT war ein Gamechanger.

Unsere erste Iteration nutzte ein lokales Whisper-Modell. Genau genug, aber zu langsam. Die Umstellung auf Mistral Voxtral (API) hat die Erkennungslatenz halbiert — bei vergleichbarer Genauigkeit.

Der Kompromiss: Cloud-Abhängigkeit für STT. Für unser Use-Case (internes Tool für Vergabefachleute, keine hochsensiblen Daten) war das akzeptabel. Für andere Organisationen mag die Abwägung anders aussehen.

RAG macht den Unterschied zwischen nützlich und unverzichtbar.

Ohne RAG kann Bea allgemeine Fragen zu Vergaberecht beantworten. Mit RAG — angebunden an unsere interne Wissensbasis von 2.700 Compliance-Dokumenten — beantwortet sie spezifische Fragen zu konkreten Ausschreibungen, aktuellen Schwellenwerten und internen Richtlinien.

Das ist der Unterschied, der aus einem Demo einen Produktivdienst macht.

Was uns überrascht hat

Die häufigsten Fehler kamen nicht vom Modell.

Wenn Bea falsch antwortete, lag das selten am LLM. Häufigere Ursachen:

• Fehlende Dokumente in der Wissensbasis (Lücken im Ingest)
• STT-Halluzinationen bei Hintergrundgeräuschen (besonders in Pausensituationen)
• Zu vage Nutzeranfragen ohne ausreichend Kontext

Das bedeutet: Arbeit an der Datenqualität und am Nutzerdialog-Design ist mindestens so wichtig wie Arbeit am Modell.

Voice-UX ist eine eigene Disziplin.

Ein Text-Interface verzeiht unklare Antworten. Der Nutzer scrollt einfach weiter. Bei Voice-Interfaces führt eine zu lange, zu komplexe oder zu generische Antwort dazu, dass der Nutzer aufhört zuzuhören — bevor die eigentliche Information kommt.

Wir haben gelernt: Antworten müssen in den ersten 15 Sekunden den Kern liefern. Alles andere ist optional. Das hat unsere System-Prompts komplett verändert.

Das Nemotron-Markdown-Problem.

Sprachmodelle haben eine natürliche Tendenz, ihre Antworten mit Markdown zu formatieren: Fettdruck, Aufzählungszeichen, Codeblöcke. Im Chat-Interface sieht das gut aus. Im TTS-System spricht Bea dann wörtlich „Sternchen, Sternchen, Hauptpunkt, Sternchen, Sternchen" — und niemand findet das hilfreich.

Die Lösung: Ein Nachbearbeitungsschritt, der Markdown vor der TTS-Übergabe bereinigt. Klingt trivial. Hat uns zwei Iterationen gekostet.

Was wir beim nächsten Mal anders machen würden

Früher mit echten Nutzern testen.

Wir haben Bea intern vier Monate lang getestet, bevor wir sie ausgerollt haben. Das war wertvoll — aber die ersten echten Nutzergespräche haben innerhalb von zwei Wochen mehr Edge Cases aufgedeckt als alle internen Tests.

Voice-KI-Anwendungen brauchen echte Gespräche. Nicht simulierte.

Monitoring von Anfang an einbauen.

Wie gut versteht Bea die Nutzer? Wie oft scheitert die RAG-Suche? Wie oft bricht der Nutzer ab? — Das wussten wir in den ersten Monaten nicht, weil wir kein Observability-System hatten.

Heute haben wir Metriken für Conversation Completion Rate, RAG Hit Rate, und Silence Events (wenn Nutzer aufgehört haben zu sprechen, ohne eine Antwort erhalten zu haben). Diese Zahlen haben unsere Prioritäten für jedes Update bestimmt.

Fallback-Szenarien von Tag 1 definieren.

Was passiert, wenn Bea eine Frage nicht beantworten kann? Was, wenn das LLM ein Timeout hat? Was, wenn die RAG-Suche keine Treffer liefert?

Wir hatten diese Szenarien zu wenig spezifiziert. Das führte zu konfusen Antworten statt klaren „Das weiß ich nicht"-Momenten. Im Voice-Kontext ist Stille oder Confusion deutlich schädlicher als in textbasierten Interfaces.

Wo Bea heute steht

Nach einem Jahr:

• Durchschnittlich 40–60 Konversationen pro Woche
• 78% der Anfragen werden ohne menschliche Eskalation beantwortet
• Nutzerfeedback: 4,1/5 nach internem NPS
• Laufzeit: 99,2% Uptime (3 geplante Wartungsfenster)

Das ist kein ChatGPT-Niveau. Aber es ist ein produktiver Assistent, der einen echten Arbeitsalltag erleichtert. Und er läuft vollständig on-premise, mit voller Datenkontrolle.

Voice-KI ist härter als Text-KI. Die Fehler sind sofortiger, die UX-Anforderungen strenger, die Nutzererwartungen höher.

Aber sie ist auch direkter. Wenn ein Nutzer nach einem Gespräch sagt „Das hat mir geholfen" — das Feedback kommt sofort. Nicht in einem Support-Ticket. Nicht in einer Umfrage.

Das ist der Grund, warum wir weitermachen.

#EnterpriseAI #VoiceAI #LiveKit #STT #TTS #BERTALAB #LocalAI #VoiceUX #RAG #LessonsLearned