Mehrsprachiger KI-Assistent: Kundenservice in mehreren Sprachen

Ein polnisches E-Commerce-Unternehmen expandiert in die tschechischen, slowakischen und rumänischen Märkte. Die Kundenservice-Abteilung erhält Anfragen in vier Sprachen. Die Einstellung von Muttersprachlern für jede Sprache ist kostspielig, und die Übersetzung von Anfragen via Google Translate vor der Beantwortung durch einen polnischen Agenten führt zu Verzögerungen und stilistischen Fehlern, die Kunden sofort bemerken.

Dies ist kein exklusives Problem des E-Commerce. Es betrifft jedes Unternehmen, das Kunden aus verschiedenen Ländern bedient, ein internationales Team beschäftigt oder einfach Produkte in mehreren Sprachversionen anbietet. Ein mehrsprachiger KI-Assistent löst dieses Problem anders als der klassische Ansatz mit separaten Bots pro Sprache.

Der intuitive Ansatz lautet: Baue einen separaten Assistenten auf Polnisch, einen separaten auf Englisch, übersetze die gesamte Wissensdatenbank in jede Sprache. Ein solches System wird schnell zum operativen Albtraum. Jede Inhaltsaktualisierung erfordert eine Aktualisierung in N Sprachen, die Konsistenz der Antworten zwischen den Versionen ist schwer aufrechtzuerhalten, und die Skalierungskosten steigen linear mit der Anzahl der Sprachen.

Architekturen, die auf mehrsprachigen Embedding-Modellen basieren, lösen dieses Problem von der Vektorrepräsentation her. Statt Inhalte in jeder Sprache zu speichern, indexiert das System Dokumente einmal (meist in der Basissprache, oft Englisch oder Polnisch), und mehrsprachige Modelle sorgen dafür, dass eine Anfrage auf Rumänisch und eine semantisch ähnliche Anfrage auf Polnisch in eine ähnliche Region des Vektorraums treffen.

BGE-M3 unterstützt über 100 Sprachen mit einem einzigen Modell und ist lokal über Ollama verfügbar, was bedeutet, dass Kundenanfragen die Infrastruktur nicht vor der Suchphase verlassen. Dies ist wichtig bei personenbezogenen Daten in den Anfragen.

Drei Bedingungen, die erfüllt sein müssen, damit diese Architektur in der Praxis funktioniert:

• Qualität der Basisinhalte: Dokumente im Index müssen präzise sein. Mehrsprachige Embeddings übertragen die Qualität und Fehler der Quellinhalte in alle Sprachen.
• Generatives Modell mit mehrsprachiger Unterstützung: Das LLM muss nicht nur die Anfrage in der jeweiligen Sprache verstehen, sondern auch eine korrekte Antwort generieren. Nicht alle Modelle bewältigen mittelosteuropäische Sprachen so gut wie Englisch.
• Guardrails in jeder Sprache: Filter für Injections, Sicherheitsschwellen und thematische Grenzen müssen unabhängig von der Eingabesprache funktionieren. Ein Assistent, der auf Englisch Fragen außerhalb des Bereichs ablehnt, aber auf Tschechisch akzeptiert, hat eine Sicherheitslücke.

Der grundlegende Mechanismus eines mehrsprachigen Assistenten ist die Spracherkennung am Eingang und die Beibehaltung dieser Sprache während des gesamten Antwortflusses. Es lohnt sich, mehrere Ebenen zu unterscheiden:

Spracherkennung der Anfrage erfolgt deterministisch vor dem Aufruf des LLM. Bibliotheken wie langdetect oder lingua-py arbeiten lokal ohne Netzwerklatenz und klassifizieren die Sprache mit einer Sicherheit von über 95% für Texte mit mehr als 15 Zeichen. Bei kurzen Anfragen ("Status", "Hilfe", "Preis") sinkt die Sicherheit, und das System sollte entweder um Präzisierung bitten oder auf die Sitzungssprache zurückgreifen.

Spracherhaltung im Konversationskontext ist wichtig bei Assistenten, bei denen die Unterhaltung mehrere Runden dauert. Ein Kunde, der auf Englisch beginnt und dann auf Polnisch wechselt, sollte eine konsistente Antwort erhalten. Einfaches Schema: Die Sprache der ersten Anfrage in der Sitzung wird zur Standardsprache, spätere Änderungen werden respektiert, aber das System wechselt nicht bei einzelnen Wörtern in einer anderen Sprache (verhindert Wechsel durch zufällige Anglizismen).

Routing zum Modell: Nicht jedes generative Modell unterstützt alle Sprachen gleich gut. Ein in Produktionssystemen verwendetes Muster ist der LLM-Router, der basierend auf der erkannten Sprache ein Modell aus einer Matrix auswählt. Sprachen mit sehr guter Abdeckung in den Trainingsdaten (Englisch, Spanisch, Französisch, Chinesisch, Arabisch) können an allgemeine Modelle weitergeleitet werden. Mittelosteuropäische Sprachen (Polnisch, Tschechisch, Slowakisch, Rumänisch, Ungarisch) erfordern möglicherweise Modelle mit besserer Abdeckung dieser Daten oder explizit auf diese Sprachen trainierte Modelle.

Kundenanfrage (beliebige Sprache)
        │
        ▼
[Spracherkennung — lokal, deterministisch]
        │
        ▼
[PII-Maskierung — lokal, vor Verlassen der Infrastruktur]
        │
        ▼
[Embedding BGE-M3 — lokal, mehrsprachig, 1024-dim]
        │
        ▼
[Vektorsuche — gemeinsamer Index, Hybrid Search]
        │
        ▼
[Reranking — optional für Top-k-Kontexte]
        │
        ▼
[LLM-Router — Modellauswahl nach Sprache und Aufgabe]
        │
        ▼
[Antwortgenerierung in der Sprache der Anfrage]
        │
        ▼
[Guardrails — Bereich, Sicherheit, Injection-Check]
        │
        ▼
Antwort oder Human-Handoff

Der entscheidende Punkt ist der gemeinsame Index: Dokumente werden einmal indexiert, Hybrid Search kombiniert semantische mit lexikalischer Suche (BM25), und Reranking verbessert die Präzision für Anfragen mit sprachlichen Nuancen. Mehr zur Indexarchitektur im Artikel semantische Suche und Embeddings im Unternehmen.

Für die meisten Unternehmen mit 3-6 europäischen Sprachen und standardmäßigem Kundenservice ist ein gutes mehrsprachiges Modell mit einem Router zu einem spezialisierten Modell für mittelosteuropäische Sprachen die kosteneffizienteste Wahl.

Guardrails, die nur in einer Sprache funktionieren, vermitteln ein falsches Sicherheitsgefühl. Einige Ausfallmuster, die in Systemen auftreten, bei denen Guardrails ausschließlich für die Hauptsprache konzipiert wurden:

Injections durch Sprachwechsel: Ein Nutzer schreibt auf Englisch eine normale Unterhaltung und injiziert dann eine Anweisung auf Ukrainisch oder Arabisch in der Annahme, dass der Filter diese Sprache nicht unterstützt. Der Schutz vor Prompt Injection muss unabhängig von der Eingabesprache funktionieren, was entweder die Erkennung auf struktureller Ebene (Versuch der Rollenänderung, Systemanweisung) oder mehrsprachige Erkennungsmuster bedeutet.

Thematischer Bereich pro Sprache: Wenn der Guardrail „Antworte nicht auf Fragen außerhalb des Kundenservice-Bereichs“ durch eine Liste polnischer Wörter definiert ist, funktioniert er nicht für ungarische Anfragen. Der Bereich sollte auf semantischer Ebene definiert werden: Wenn die Cosinus-Ähnlichkeit der Anfrage zum Themenraum unter einem Schwellenwert liegt, lehnt das System unabhängig von der Sprache ab.

Sicherheitsschwelle und Sprache: Modelle haben eine geringere Antwortsicherheit für Sprachen mit geringer Abdeckung in den Trainingsdaten. Eine feste Sicherheitsschwelle, die für Englisch gut funktioniert, kann für Polnisch zu streng oder für Rumänisch zu lasch sein. Schwellenwerte sollten pro Sprache oder Sprachfamilie kalibriert werden.

Human-Handoff in der Sprache des Kunden: Wenn der Assistent eine Angelegenheit an einen Menschen eskaliert, muss die Eskalationsnachricht in der Sprache des Kunden verfasst sein, nicht in der Systemsprache. „Ich leite Sie an einen Berater weiter“ statt technischer Logs auf Englisch.

Muster für den Aufbau von Guardrails in komplexen Systemen werden im Artikel Sicherheit von KI-Agenten behandelt.

Mehrsprachigkeit ändert nichts an den DSGVO-Anforderungen, fügt jedoch zusätzliche Komplexitätsebenen hinzu. Kunden aus verschiedenen EU-Ländern unterliegen derselben Verordnung, aber lokale Aufsichtsbehörden (CNIL in Frankreich, BfDI in Deutschland, UODO in Polen) können unterschiedliche detaillierte Richtlinien haben.

Vier technische Anforderungen unabhängig von der Sprache:

• PII-Maskierung vor dem Embedding: Namen, E-Mail-Adressen, Telefonnummern, Bestellnummern mit personenbezogenen Daten werden lokal maskiert, bevor die Anfrage an die Embedding-Schicht oder ein externes LLM gesendet wird. BGE-M3, das lokal läuft, erfordert diesen Schritt nicht, aber die meisten Produktionssysteme kombinieren lokale und Cloud-Modelle.
• Data Residency: Wenn du Daten von Kunden aus Deutschland verarbeitest, stelle sicher, dass die Daten die EU-Server nicht verlassen. Viele Cloud-Anbieter bieten EU-Regionen an, aber Self-Hosting lokaler Modelle gibt hier Sicherheit ohne die Notwendigkeit, Verträge zu analysieren.
• Konversationsprotokolle pro Sprache: Protokolle für DSGVO-Audits sollten Informationen über die Sitzungssprache enthalten. Bei einer Anfrage auf Zugang oder Löschung von Daten eines französischsprachigen Kunden sollte die Antwort auf Französisch erfolgen, und der Umfang der gelöschten Daten muss klar sein.
• Einwilligung zur mehrsprachigen Personalisierung: Wenn der Assistent den Verlauf der Konversation zur Personalisierung der Antworten nutzt, muss die Einwilligung zur Datenverarbeitung zu diesem Zweck pro Nutzer gespeichert werden, unabhängig von der Sprache der Benutzeroberfläche.

Bei Systemen, die Kunden aus dem Gesundheits-, Finanzsektor oder Kinder betreuen, sollte vor der Implementierung eine DSFA durchgeführt werden. Die rechtlichen Pflichten im Jahr 2026 werden im Artikel AI Act und DSGVO 2026 behandelt.

Ein mehrsprachiger Assistent neigt dazu, Qualitätsprobleme zu verbergen. Das System sieht für die Sprache korrekt aus, die jemand im Team versteht, aber für Sprachen, die niemand nativ beherrscht, können Fehler systematisch und wochenlang unbemerkt bleiben.

Drei Metriken, die pro Sprache verfolgt werden sollten:

• Eskalationsrate pro Sprache: Welcher Anteil der Gespräche in einer bestimmten Sprache endet mit einer Weiterleitung an einen Menschen. Eine hohe Rate für eine bestimmte Sprache signalisiert eine niedrige Antwortqualität oder eine schlechte Abdeckung der Wissensdatenbank.
• Nutzerbewertung pro Sprache: Eine einfache Umfrage nach Abschluss des Gesprächs (Daumen hoch/runter oder Skala 1-5). Der Vergleich der Bewertungen für Englisch vs. Polnisch vs. Rumänisch zeigt Qualitätsunterschiede.
• Latenz pro Sprache: Mehrsprachige Modelle können unterschiedliche Generierungszeiten für verschiedene Sprachen aufgrund der Tokenisierung haben. Sprachen mit reicher Morphologie (Polnisch, Tschechisch, Ungarisch) generieren mehr Tokens aus demselben Text, was die Latenz beeinflussen kann.

Ein gutes Qualitätsmonitoring des Agenten sollte Metriken ab dem ersten Produktionstag pro Sprache aufschlüsseln, nicht erst nach Beschwerden.

Die Kosten eines mehrsprachigen Assistenten hängen von der Anzahl der Sprachen, dem Gesprächsvolumen und der gewählten Architektur (lokal vs. Cloud-API) ab. Ein Pilot mit einer zusätzlichen Sprache neben der Basissprache dauert in der Regel 2-4 Wochen und umfasst die Erweiterung der Guardrails, Qualitätstests der Antworten und die Kalibrierung der Schwellenwerte. Jede weitere Sprache bei stabilisierter Architektur erfordert weniger Aufwand, da die Infrastruktur bereits vorhanden ist.

Der ROI-Rechner ermöglicht die Eingabe realer Anfragevolumina pro Sprache, des Stundensatzes und der aktuellen Bearbeitungszeit, um die Amortisationszeit ohne Schätzungen „nach Gefühl“ zu sehen. Für Unternehmen mit 15%+ Anfragen in anderen Sprachen als der Basissprache amortisiert sich ein mehrsprachiger Assistent in der Regel schneller als die Einstellung eines separaten Agenten oder die manuelle Übersetzung jeder Anfrage.

Orientierungswerte für Implementierungen:

Der Pilot beginnt immer mit der Sprache mit dem größten Anfragevolumen neben der Basissprache, nicht mit der technisch anspruchsvollsten.

Beschreibe deinen aktuellen Sprachumfang und den Typ der Kundenanfragen, und das Modell schlägt eine Architektur und Guardrails vor, die zu deinem Fall passen (Playground: PII maskiert, keine Speicherung):

Nein, bei Verwendung mehrsprachiger Embedding-Modelle wie BGE-M3 reicht eine Wissensdatenbank in der Basissprache. Das Modell mappt Anfragen aus verschiedenen Sprachen in einen gemeinsamen Vektorraum, sodass die semantische Suche unabhängig von der Sprache der Anfrage korrekt funktioniert. Die Übersetzung der Basisinhalte in jede Sprache ist optional und nur dann gerechtfertigt, wenn die Dokumente idiomatische Ausdrücke enthalten, die schwer durch Embeddings zu übersetzen sind, oder wenn die Datenbank sehr spezialisierte Inhalte in einer bestimmten Sprache enthält.

Flektierende Sprachen wie Polnisch oder Tschechisch sind für Modelle aufgrund ihrer reichen Morphologie und geringeren Abdeckung in den Trainingsdaten im Vergleich zu Englisch schwieriger. In der Praxis bedeutet dies ein höheres Risiko für grammatikalische Fehler in den Antworten und eine geringere Retrieval-Sicherheit für Anfragen mit seltenen Wortformen. Das Produktionsmuster besteht darin, die Sicherheitsschwelle für diese Sprachen separat zu kalibrieren und zu Beginn eine höhere Eskalationsrate zum Menschen einzustellen, die mit der Erweiterung der Wissensdatenbank sinkt. Modelle wie Bielik (polnisch) oder mehrsprachige Modelle wie Mistral und Qwen mit guter mittelosteuropäischer Abdeckung sind eine bessere Wahl als Modelle, die ausschließlich auf Englisch optimiert sind.

Die erste Ursache ist ein Fehler bei der Spracherkennung bei sehr kurzen Anfragen. Lösung: Bei niedriger Erkennungssicherheit fragt der Assistent nach der bevorzugten Sprache oder verwendet die in Profil oder Sitzungsort definierte Sprache. Die zweite Ursache ist ein Modell, das die Sprache nicht über die gesamte Konversation hinweg beibehalten kann. Lösung: Die zu Beginn der Sitzung erkannte Sprache wird bei jedem LLM-Aufruf als Systemanweisung übergeben. Die dritte Ursache ist fehlender Kontext: Wenn die abgerufenen Fragmente ausschließlich in einer Sprache vorliegen, kann das Modell dieser Sprache folgen, statt der Sprache der Anfrage. Die Systemanweisung sollte explizit vorschreiben, in der Sprache des Nutzers zu antworten, unabhängig von der Sprache der Quellen.

Der AI Act stellt keine speziellen Anforderungen allein aufgrund von Mehrsprachigkeit. Die Anforderungen hängen vom Risiko der Anwendung ab: Ein Kundenservice-Assistent im E-Commerce ist in der Regel ein System mit geringem oder begrenztem Risiko, bei dem vor allem Transparenz (der Kunde muss wissen, dass er mit einer KI spricht) und die Möglichkeit der Eskalation zu einem Menschen erforderlich sind. Systeme, die Kreditwürdigkeit bewerten, rekrutieren oder Entscheidungen über den Zugang zu grundlegenden Dienstleistungen treffen, werden unabhängig von der Sprache als hochriskant eingestuft. Eine detaillierte Übersicht der Pflichten bietet der Artikel AI Act und DSGVO 2026. Wenn dein Assistent Kunden aus mehreren EU-Ländern bedient und sensible Daten verarbeitet, solltest du vor der Produktionsimplementierung eine DSFA durchführen.

Beginne damit, das Anfragevolumen pro Sprache der letzten 3 Monate zu messen. Wenn eine Sprache mehr als 15% der Anfragen ausmacht, gibt es eine geschäftliche Rechtfertigung für einen Pilot. Der nächste Schritt ist die Bewertung der Qualität der aktuellen Wissensdatenbank als Kandidat für den RAG-Index. Fragmentierte, inkonsistente oder veraltete Inhalte in der Basissprache führen in allen Sprachen zu schlechten Ergebnissen. Wie Unternehmensdaten für KI vorbereiten behandelt diesen Schritt im Detail. Die vollständige Implementierungsmethodik vom Audit bis zum Pilot ist im Artikel Wo anfangen mit der KI-Implementierung beschrieben.