MRH Trowe gibt 400 Mitarbeitenden gesteuerten Zugriff auf Self-Service-KI-Agenten
MRH Trowe hat sichere KI-Agenten für rund 400 Mitarbeitende mit AWS und Open-Source-Tools eingeführt und zeigt damit, wie regulierte Unternehmen gesteuerten Self-Service skalieren können.
Deutschlands MRH Trowe hat eine gesteuerte Self-Service-KI-Plattform für rund 400 Mitarbeitende produktiv geschaltet und nutzt dafür AWS-Infrastruktur sowie Open-Source-Software, um die Sicherheits- und Datenresidenzanforderungen des Finanzdienstleistungssektors zu erfüllen.
Der erste produktive Agent des gewerblichen und industriellen Versicherungsmaklers verwandelt Microsoft Teams-Meetings in strukturierte Protokolle. Mitarbeitende können auf Deutsch nach einem aktuellen Meeting mit einer bestimmten teilnehmenden Person fragen; der Agent findet dann den Kalendereintrag, ruft das Transkript ab und erstellt eine Zusammenfassung mit Teilnehmenden, Tagesordnungspunkten, Diskussionsthemen und Folgemaßnahmen.
AWS beschrieb die Bereitstellung in einer Fallstudie im Machine Learning Blog. Das Konto wird daher vom Anbieter kontrolliert, und Angaben zu Einführung, Kosten und prognostizierten Einsparungen sollten als von AWS berichtete Werte und nicht als unabhängig verifizierte Marktdaten verstanden werden. Dennoch bietet die Umsetzung ein konkretes Beispiel dafür, wie ein reguliertes Unternehmen von allgemeinen Chatfunktionen hin zu zentral verwalteten KI-Agenten übergeht, die mit internen Systemen verbunden sind.
Von isolierten Experimenten zu einer gesteuerten Plattform
Laut AWS ist MRH Trowe vor allem in Deutschland, der Schweiz und Österreich tätig und ist durch organisches Wachstum sowie Übernahmen gewachsen. Das Unternehmen gehörte zu den ersten deutschen Versicherungsmaklern, die ausschließlich auf cloudbasierter IT-Infrastruktur arbeiteten, wobei AWS als bevorzugter Cloud-Partner dient.
Mit der steigenden Nachfrage der Mitarbeitenden nach generativer KI begannen einzelne Teams, unabhängig voneinander mit Tools zu experimentieren. Laut AWS entstand dadurch das Risiko fragmentierter Bereitstellungen und einer möglichen Offenlegung sensibler Kunden- und Versicherungsinformationen. Das Unternehmen wollte, dass Mitarbeitende KI-Agenten erstellen und nutzen können, ohne dass jedes Team seinen eigenen technischen Stack aufbauen muss.
Diese Anforderung geht über eine herkömmliche Chat-Oberfläche hinaus. MRH Trowe benötigte Antworten, die auf internen Informationen basieren, Agenten, die mehrstufige Aufgaben ausführen können, sichere Verbindungen zu Unternehmenssystemen und eine zentrale Kontrolle über Zugriff und Kosten. Das erklärte Ziel ist, dass Routinefragen vor menschlichem Eingreifen von KI beantwortet werden und sich wiederkehrende Arbeit durch die Mitarbeitenden automatisieren lässt, die sie zuvor ausgeführt haben.
Die resultierende Plattform kombiniert drei Komponenten. Builder nutzen Strands Agents, ein Open-Source-Software Development Kit zur Erstellung von Agenten-Workflows. Amazon Bedrock AgentCore stellt die Produktionsumgebung für die Anbindung, den Betrieb und die Skalierung von Agenten bereit. LibreChat liefert die Mitarbeitenden-Oberfläche mit Authentifizierung, Gesprächsverwaltung, Branding, Token-Budgets und Unterstützung für mehrere Modelle.
Identitäts-, Residenz- und Infrastrukturkontrollen
Der Workflow für Besprechungsprotokolle ist um die Identität der anfragenden Person herum aufgebaut. LibreChat authentifiziert Nutzerinnen und Nutzer über Microsoft Entra ID und übergibt diese Identität serverseitig an den Agenten. Die Identität kann nicht über den Chat-Prompt bereitgestellt oder verändert werden, und der Agent ist auf den Zugriff auf den eigenen Kalender und das jeweilige Meeting-Transkript der Person beschränkt.
AWS sagt, dass die Agenten, Modelle und Daten in der AWS Europe (Frankfurt) Region, auch bekannt als eu-central-1, betrieben werden. Diese regionale Verortung soll Meeting- und Kundendaten in Deutschland halten, obwohl AWS darauf hinweist, dass die Verfügbarkeit von Diensten und Modellen je nach Region variiert.
Die Bereitstellung läuft in einem einzigen AWS-Konto innerhalb einer Virtual Private Cloud. Mitarbeitende verbinden sich vom Firmennetzwerk aus über ein Transit Gateway und einen Zero-Trust-Anbieter, statt Datenverkehr über das öffentliche Internet zu senden. Ein interner Application Load Balancer leitet Anfragen an die Anwendungsschicht in einem privaten Subnetz weiter.
AWS nennt die Sitzungsisolierung als einen wesentlichen Grund dafür, dass sich MRH Trowe für Amazon Bedrock AgentCore entschieden hat. Der Dienst isoliert Agentensitzungen auf Rechen- und Dateisystemebene und unterstützt Open-Source-Frameworks wie Strands Agents. Für einen regulierten Makler soll diese Kombination Entwicklerflexibilität bewahren und zugleich das Risiko verringern, dass eine Agentensitzung auf die Daten einer anderen zugreifen kann.
Was die Belege zeigen — und was nicht
AWS berichtet, dass die Einführung im ersten Produktionsmonat rund 400 Mitarbeitende erreichte. Außerdem berichtet das Unternehmen von anfänglichen Kosten von etwa 14 US-Dollar pro Arbeitsplatz in diesem Monat sowie einem prognostizierten Weg, die Infrastrukturkosten durch Right-Sizing und geplante Skalierung um ungefähr 40 % zu senken.
Diese Zahlen sind nützliche Indikatoren für die berichtete Wirtschaftlichkeit der Bereitstellung, aber kein unabhängiger Benchmark. AWS liefert in der bereitgestellten Fallstudie keine detaillierte Aufschlüsselung der Nutzung pro Mitarbeitenden, des Modellverbrauchs, des Umfangs der Agentenausführungen oder der genauen Grundlage für die prognostizierte Reduzierung. Die Belege zeigen auch nicht, ob alle 400 Mitarbeitenden das System regelmäßig nutzen oder wie der Agent für Besprechungsprotokolle im Vergleich zu manueller Arbeit bei Genauigkeit, Latenz oder Fehlerraten abschneidet.
Die Fallstudie macht jedoch die technischen Designentscheidungen deutlich, die MRH Trowe nach eigenen Angaben getroffen hat: ein privater Netzwerkpfad, regionale Verarbeitung, an die Identität gebundene Anfragen, Token-Budgets und eine offene Oberfläche mit Unterstützung für mehrere Modelle. Sie zeigt auch, dass der erste produktive Anwendungsfall relativ begrenzt ist. Das Abrufen und Zusammenfassen von Meetings kann sofortigen Nutzen bringen und gleichzeitig die Befugnisse des Agenten im Vergleich zu Workflows, die Datensätze ändern, externe Kommunikation versenden oder Geschäftsentscheidungen treffen, einschränken.
Warum die Bereitstellung für KI-Teams wichtig ist
Für Entwicklerinnen und Entwickler zeigt der Ansatz von MRH Trowe, wie wichtig es ist, Identität und Infrastruktur als Teil des Agentendesigns zu behandeln und nicht als erst nach der Entwicklung hinzugefügte Funktionen. Die Weitergabe des authentifizierten Nutzerkontexts von der Oberfläche an den Agenten kann die Zugriffskontrolle explizit machen, während die Sitzungsisolierung eine separate Risikoecke in Mehrnutzerumgebungen adressiert.
Die Architektur trennt außerdem Experimentieren vom Produktionsbetrieb. Entwickler können mit Strands Agents Workflows erstellen, ohne die gesamte zugrunde liegende Infrastruktur selbst implementieren zu müssen, während AgentCore eine verwaltete Laufzeitumgebung und ein nutzungsbasiertes Modell bereitstellt. LibreChat gibt dem Unternehmen eine vertraute Benutzeroberfläche, ohne dass der Makler ein kommerzielles Chat-Produkt als einzige Schnittstelle übernehmen muss.
Für Unternehmenskäufer kann die Nutzung mehrerer Modelle die Abhängigkeit von einem einzigen Modellanbieter verringern und Teams ermöglichen, Modelle auf spezifische Aufgaben abzustimmen. Token-Budgets bieten einen grundlegenden Kostenkontrollmechanismus, ersetzen jedoch nicht die Überwachung von Qualität, Latenz, Datenzugriff und Agentenausfällen. Diese betrieblichen Fragen werden wichtiger, wenn Agenten von der Zusammenfassung zu Aktionen in Versicherungssystemen übergehen.
Die Bereitstellung zeigt auch einen praktischen Weg für Enterprise-KI in regulierten Umgebungen: mit einem nützlichen, intern begrenzten und prüfbaren Workflow beginnen; Berechtigungen auf Nutzerebene durchsetzen; die Verarbeitung in einer freigegebenen Region belassen; und den Zugriff über eine zentrale Plattform statt über unverwaltete Werkzeuge einzelner Teams skalieren.
Worauf als Nächstes zu achten ist
Die nächsten Signale werden zeigen, ob MRH Trowe über Besprechungsprotokolle hinaus in Workflows expandiert, die Versicherungs- und Kundendaten abrufen oder aktualisieren. Solche Anwendungsfälle würden prüfen, ob die Identitätskontrollen und die Sitzungsisolierung der Plattform ausreichen, wenn Agenten folgenschwere Aktionen ausführen können.
Die Qualität der Nutzung wird ebenso wichtig sein wie die genannte Mitarbeitendenzahl. Folgende Belege zu aktiver Nutzung, Aufgabenerledigungsraten, menschlicher Überprüfung, Fehlerbehandlung und eingesparter Arbeitszeit würden ein klareres Bild des geschäftlichen Nutzens liefern als der bloße Zugang im ersten Monat.
Auch die Kostenberichterstattung ist ein weiterer Bereich, den man beobachten sollte. Die versprochene Reduzierung um etwa 40 % hängt von Right-Sizing und geplanter Skalierung ab; die tatsächlichen Ausgaben nach der Optimierung würden Käufern helfen zu beurteilen, ob die nutzungsbasierte Infrastruktur bei wachsender Nutzung vorhersehbar bleibt. Mehr Details zur Modellauswahl und regionalen Verfügbarkeit würden ebenfalls klären, wie portabel die Architektur über Workloads und Rechtsräume hinweg ist.
Creati.ai-Perspektive
Die Bereitstellung von MRH Trowe ist weniger deshalb bemerkenswert, weil sie einen Chatbot vor Mitarbeitende setzt, sondern weil sie Self-Service-KI als gesteuerte interne Plattform behandelt. Die Kombination aus an Mitarbeitende gebundenen Berechtigungen, privater Konnektivität, regionaler Verarbeitung und kontrollierter Agentenausführung adressiert mehrere Gründe, warum regulierte Organisationen zögern, von Experimenten in die Produktion zu wechseln.
Die Belege bleiben eine Anbieter-Fallstudie, daher müssen ihre Aussagen zu Einführung und Kosten unabhängig validiert werden. Selbst mit diesem Vorbehalt deutet das Design auf ein sinnvolles kurzfristiges Muster für KI im Finanzdienstleistungsbereich hin: zunächst enge, prüfbare Agenten, wobei breitere Automatisierung von nachgewiesener Zuverlässigkeit, klaren Autorisierungsgrenzen und für Unternehmen messbaren Betriebskosten abhängt.
