Der Engpass im Medtech-Support: Lange Antwortzeiten bei strenger Compliance
In der Medtech-Branche in Deutschland steht der Customer Support unter enormem Druck. Patienten und Kliniken erwarten schnelle Antworten auf technische Fragen, Terminanfragen und Reklamationen. Die First-Response-Time liegt bei vielen Unternehmen mit 201 bis 500 Mitarbeitern bei über 4 Stunden, weil Support-Mitarbeiter manuell in E-Mails, Tickets und internen Dokumenten suchen müssen. Gleichzeitig gilt die DSGVO mit Art. 9 für besondere Kategorien von Daten, und ISO 27001 verlangt nachweisbare Schutzmaßnahmen für die Vertraulichkeit. Cloud-basierte KI-Lösungen wie OpenAI oder Anthropic sind hier oft nicht einsetzbar, weil Patientendaten und interne Dokumente das Firmengebäude nicht verlassen dürfen. Das Ergebnis ist ein Teufelskreis: Die Mitarbeiter sind überlastet, die Antwortzeiten sind zu lang, und die Compliance-Vorgaben lassen keine schnellen Cloud-Lösungen zu. Betroffen sind nicht nur die Support-Mitarbeiter, sondern auch die Patienten, die auf Antworten warten, und die Geschäftsführung, die für die Reputation und die Compliance verantwortlich ist.
Warum Cloud-KI und interne Teams in der Medtech-Branche scheitern
Die meisten Unternehmen greifen zu zwei Ansätzen, die in der Praxis scheitern. Erstens der Kauf einer fertigen Cloud-Support-Plattform mit KI-Funktionen. Diese Systeme versprechen schnelle Implementierung, aber sie senden alle Daten an externe Server. Für ein Medtech-Unternehmen in Deutschland ist das ein Compliance-Bruch, der im Audit sofort auffällt. Zweitens der Versuch, ein internes Team mit der Entwicklung einer KI-Lösung zu betrauen. Das scheitert an der fehlenden Expertise in der Modell-Feinabstimmung und der Infrastruktur. Die Entwicklung eines stabilen RAG-Systems mit lokalen Modellen dauert Monate, und das Team fehlt für die eigentliche Support-Arbeit. Ein dritter Ansatz ist die manuelle Optimierung der Prozesse, also mehr Mitarbeiter einstellen oder Schichten verlängern. Das senkt die Antwortzeiten kurzfristig, erhöht aber die Kosten und löst das strukturelle Problem nicht. Alle drei Ansätze ignorieren die Kernanforderung: Die KI muss lokal laufen, in die bestehenden Systeme wie Google Workspace und das CRM integriert sein und den Mitarbeitern als Unterstützung dienen, nicht als Ersatz.
Lokale LLMs und Voice Agents: Die Compliance-sichere Architektur
Die Lösung liegt in einer Integration, die die bestehenden Systeme erweitert, statt sie zu ersetzen. Der Ansatz besteht aus drei Bausteinen. Erstens ein Voice Agent, der eingehende Anrufe entgegennimmt, die Frage transkribiert und eine erste Antwort generiert. Zweitens ein RAG-System, das auf den internen Dokumenten, Handbüchern und CRM-Einträgen basiert und die Antwort mit relevantem Kontext anreichert. Drittens eine Human-in-the-Loop-Schicht, die sicherstellt, dass jede Antwort, die medizinische oder vertragliche Relevanz hat, von einem Mitarbeiter freigegeben wird. Die gesamte Verarbeitung läuft auf der eigenen Hardware des Kunden. Das Sprachmodell für die Transkription ist Whisper oder Vosk, das LLM für die Antwortgenerierung ist ein Open-Weight-Modell wie Llama 3 70B oder Mistral Large, das über vLLM oder Ollama lokal betrieben wird. Die Integration in Google Workspace erfolgt über die Admin SDK API, um E-Mails und Kalender zu verknüpfen. Das System ist model-agnostic und kann später auf andere Use Cases wie interne Wissenssuche oder Dokumentenextraktion erweitert werden, ohne die Infrastruktur zu ändern.
Der 8-Wochen-Plan: Vom Audit zum Rollout
Der Rollout erfolgt in einem 8-Wochen-Integrationssprint, der in vier Phasen unterteilt ist. Woche 1-2: Prozess-Audit und Auswahl des Pilot-Workflows. Hier wird ein klarer, wiederkehrender Prozess wie Terminanfragen oder technische Fragen zu einem bestimmten Produkt ausgewählt. Die Datenqualität der internen Dokumente wird geprüft und aufbereitet. Woche 3-4: Setup der lokalen Inferenz-Umgebung. Die Hardware wird konfiguriert, die Modelle werden geladen und die Anbindung an Google Workspace und das CRM erfolgt. Das RAG-Modell wird auf den internen Dokumenten trainiert. Woche 5-6: Pilotbetrieb mit 10 % des Anrufvolumens. Die First-Response-Time und die Fehlerquote werden gemessen und dokumentiert. Die Mitarbeiter werden geschult und in den Human-in-the-Loop-Prozess eingebunden. Woche 7-8: Feinabstimmung und Rollout auf 100 % des Volumens. Ein Dashboard mit den Kern-KPIs wird eingerichtet, und der Managed Service wird gestartet. Der Sprint endet mit einem dokumentierten Vorher-Nachher-Vergleich der Kennzahlen und einem Betriebsplan für die laufende Betreuung.
Skalierung über Abteilungen: Vom Support zur internen Wissenssuche
Die Skalierung über Abteilungen hinweg gelingt durch die modulare Architektur. Der Voice Agent für den Support ist nur eine Instanz des Systems. Die gleiche lokale Inferenz-Schicht und das RAG-Framework können für andere Abteilungen wie Vertrieb, Einkauf oder interne Wissenssuche genutzt werden. Die Compliance-Vorgaben bleiben identisch, da alle Daten lokal bleiben. Die Integration in Google Workspace und das CRM ist bereits vorhanden und muss nicht neu aufgebaut werden. Neue Use Cases können in weiteren 4-Wochen-Sprints implementiert werden. Die interne Wissenssuche basiert auf dem gleichen RAG-Ansatz: Die internen Dokumente werden in ein Vektor-Datenbank-System wie Weaviate oder Qdrant eingebettet, und die Embeddings werden mit einem lokalen Modell wie BGE-M3 erzeugt. Wenn ein Mitarbeiter eine Frage stellt, wird die Frage in einen Vektor umgewandelt und die ähnlichsten Dokumente abgerufen. Das LLM generiert die Antwort auf Basis dieses Kontexts. Die Kosten für die Hardware und die Lizenzen bleiben konstant, da keine zusätzlichen Cloud-APIs benötigt werden. Die Skalierung ist also nicht nur technisch, sondern auch wirtschaftlich sinnvoll.
Leave a Reply