Interner Chatbot für Unternehmen – mit Claude, AWS Bedrock und dem MCP

Veröffentlicht am: 01-06-20258 min Lesezeit
KI-Chatbot-Interface integriert in die Unternehmens-IT

Die meisten Unternehmens-Chatbots sind glorifizierte FAQ-Seiten. Hier erfahren Sie, wie wir interne KI-Assistenten bauen, die Ihr Unternehmen wirklich kennen – mit Claude, AWS Bedrock und dem Model Context Protocol.

Ihr Team fragt den Chatbot, wo die aktuelle Preisliste liegt. Die Antwort: „Ich habe keinen Zugriff auf diese Information." Kommt Ihnen das bekannt vor? Die meisten Unternehmens-Chatbots sind glorifizierte Suchmasken mit Persönlichkeit. Sie klingen intelligent, aber sobald sie echte Unternehmensdaten berühren sollen, stoßen sie an eine Wand.

Dieser Artikel zeigt, wie wir interne KI-Assistenten bauen, die Ihr Unternehmen wirklich kennen – verbunden mit Ihren Dokumenten, Ihrem CRM, Ihren internen Tools – mithilfe von Claude auf AWS Bedrock und dem Model Context Protocol (MCP).


Warum generische Chatbots im Unternehmenseinsatz scheitern

Das Problem liegt nicht beim KI-Modell selbst. GPT-4, Claude, Gemini – sie alle sind bemerkenswert leistungsfähig. Das Problem ist der Kontext. Ein Modell, das auf öffentlichen Internetdaten trainiert wurde, weiß nichts über Ihre internen Prozesse, Ihren Produktkatalog, Ihre Kundenhistorie oder die Arbeitsweise Ihres Teams.

Unternehmen reagieren auf diese Lücke typischerweise auf eine von zwei Weisen. Entweder sie verbringen Monate damit, ein Modell auf internen Daten zu feinabstimmen – teuer, langsam und sofort veraltet – oder sie setzen auf eine einfache RAG-Pipeline, die Dokumentfragmente abruft und hofft, dass das Modell den Rest schon irgendwie hinbekommt. Keiner dieser Ansätze skaliert gut.

ℹ️

Der eigentliche Bedarf ist kein intelligenteres Modell – sondern ein Modell, das in Ihren Systemen handeln kann. Ein Ticket lesen. Einen Kunden nachschlagen. Einen Workflow auslösen. Das erfordert eine grundlegend andere Architektur.


Der Stack: Claude auf AWS Bedrock

Wir deployen Claude (Anthropics Modellfamilie) über AWS Bedrock – Amazons verwalteten Service für Foundation Models. Diese Kombination bietet Ihnen mehrere unternehmenskritische Eigenschaften out of the box:

  • Datenschutz: Ihre Gespräche verlassen Ihr AWS-Konto nie und werden nicht zum Training von Anthropics Modellen genutzt
  • SOC 2-, ISO 27001- und HIPAA-Compliance durch AWS-Infrastruktur
  • Feingranulare IAM-Zugriffskontrolle – genau festlegbar, wer den Chatbot nutzen darf und worauf er zugreifen kann
  • Token-basierte Abrechnung ohne Sitzlizenzen: Kosten skalieren linear mit der tatsächlichen Nutzung
  • Claudes 200.000-Token-Kontextfenster ermöglicht die Verarbeitung ganzer Dokumente in einem einzigen Durchgang

Claude eignet sich besonders gut für Unternehmenseinsätze, weil das Modell Anweisungen präzise befolgt und lieber „Ich weiß es nicht" sagt, als eine selbstsicher klingende Halluzination zu produzieren. In einem internen Assistenten ist Halluzination keine lästige Eigenschaft – sie ist ein Haftungsrisiko.


Was ist MCP – das Model Context Protocol?

Das Model Context Protocol ist ein offener Standard, den Anthropic Ende 2024 eingeführt hat. Er definiert, wie KI-Modelle sich mit externen Datenquellen und Tools verbinden. Stellen Sie sich MCP wie den USB-C-Standard für KI-Integrationen vor: ein Protokoll, beliebige Tools.

Vor MCP war jede KI-Integration ein eigenes Engineering-Projekt. Sie schrieben speziellen Code, um Ihren Chatbot mit dem CRM zu verbinden, weiteren Code für das Dateisystem, noch mehr für die Datenbank. Jeder Connector musste bei Modellwechseln neu gebaut und bei API-Änderungen gepflegt werden.

Mit MCP bauen Sie einmalig einen MCP-Server für jedes System. Dieser Server stellt einen standardisierten Satz von Tools und Ressourcen bereit. Jeder MCP-kompatible Client – Claude und ein wachsendes Ökosystem weiterer Modelle – kann sie sofort nutzen.

💡

MCP reduziert die Integrationsfläche dramatisch. Statt N Modell × M Tool-Integrationen brauchen Sie nur N + M. Ein Server für Ihr CRM, einer für Ihren Dokumentenspeicher, einer für Ihr Ticketing-System – und jeder KI-Assistent kann alle nutzen.


Architektur: wie alles zusammenpasst

So sieht die High-Level-Architektur aus, die wir bei Enterprise-Chatbot-Deployments einsetzen:

  1. 1Der Mitarbeiter sendet eine Nachricht über eine Web- oder Slack-Oberfläche.
  2. 2Die Anfrage trifft einen API-Gateway-Endpunkt vor einer Lambda-Funktion.
  3. 3Die Lambda-Funktion initialisiert einen MCP-Client und ruft Claude auf AWS Bedrock auf – mit der Nutzernachricht, dem Gesprächsverlauf und der Liste verfügbarer MCP-Tools.
  4. 4Claude analysiert die Anfrage. Wenn Daten benötigt werden, ruft das Modell einen oder mehrere MCP-Tools auf – z. B. fetch_customer_info, search_documents oder create_support_ticket.
  5. 5Die MCP-Server führen die Tool-Aufrufe gegen die echten Systeme aus (Salesforce, Confluence, Jira, Ihre interne Datenbank) und liefern strukturierte Ergebnisse zurück.
  6. 6Claude kombiniert die Tool-Ergebnisse mit eigenem Reasoning und liefert eine fundierte Antwort.
  7. 7Die Antwort – inklusive aller ausgeführten Aktionen – wird per Streaming zurück an den Mitarbeiter übertragen.

Der entscheidende Punkt: Claude generiert nicht nur Text – das Modell orchestriert einen Workflow. Es entscheidet, wann es welche Tools in welcher Reihenfolge nutzt und wie es die Ergebnisse zusammenführt. Das macht den Assistenten wirklich nützlich.


Welche MCP-Server wir typischerweise bauen

Jedes Unternehmen hat andere Systeme, aber die folgenden MCP-Server tauchen in fast jedem unserer Deployments auf:

  • Dokumenten-Server – indiziert Confluence, SharePoint oder Google Drive und stellt Such- und Abruf-Tools bereit. Der Assistent findet das genaue Richtliniendokument, die Produktspezifikation oder den Onboarding-Leitfaden, den der Mitarbeiter benötigt.
  • CRM-Server – liest und schreibt Kundendaten. Das Vertriebsteam kann fragen „Was ist der Status des Deals mit Müller GmbH?" und bekommt eine echte Antwort, keine Vermutung.
  • Ticketing-Server – integriert Jira oder Zendesk. Der Assistent kann offene Tickets nachschlagen, neue anlegen und Issues eskalieren.
  • Kalender- und Verfügbarkeits-Server – ermöglicht das Prüfen von Terminen und das Vorschlagen von Besprechungszeiten.
  • Custom-API-Server – für proprietäre interne Tooling- oder Datenbanklösungen, die spezifisch für Ihr Unternehmen sind.

Reale Ergebnisse

Für ein mittelständisches Beratungsunternehmen haben wir diesen Stack in acht Wochen deployed. Der Assistent hatte Zugriff auf vier MCP-Server: die Confluence-Wissensdatenbank, das CRM (HubSpot), das Projektmanagement-Tool (Asana) und das HR-System für Urlaubs- und Richtlinienanfragen.

  • 14 Stunden pro Woche durchschnittlich pro Mitarbeiter eingespart – hauptsächlich bei der Informationssuche und routinemäßigen Verwaltungsaufgaben
  • 73 % weniger interne Slack-Nachrichten vom Typ „Weiß jemand, wo X zu finden ist?"
  • 41 % Rückgang bei internen IT-Support-Tickets im ersten Monat – Mitarbeiter erhielten sofortige, korrekte Antworten vom Assistenten statt Tickets zu erstellen
  • Onboarding-Zeit für neue Mitarbeiter von drei Wochen auf zehn Tage reduziert, weil der Assistent Verfahrensfragen on demand beantworten konnte
💡

Die größte Überraschung für die meisten Kunden ist nicht der Effizienzgewinn – es ist der Wandel in der Art, wie Mitarbeiter über Informationszugang denken. Wenn die Antwort auf jede Frage dreißig Sekunden entfernt ist, hören Menschen auf, Wissen zu horten, und fangen an, auf der Arbeit anderer aufzubauen.


Sicherheitsaspekte

KI-Assistenten mit echtem Systemzugriff erfordern ernsthaftes Sicherheitsdesign. Die Berechtigungen, die der Chatbot besitzt, sind die Berechtigungen, die er ausüben kann – und die Claude im Namen jedes Nutzers ausüben kann. Wir wenden folgende Prinzipien in jedem Deployment an:

  • Least-Privilege by Default: Jeder MCP-Server stellt nur die spezifischen Lese-/Schreiboperationen bereit, die der Assistent tatsächlich benötigt. Er kann einen Kundendatensatz abrufen, aber nicht löschen.
  • Nutzer-scoped Authentifizierung: Der Assistent authentifiziert sich im Namen des angemeldeten Nutzers und kann nur auf das zugreifen, was dieser Nutzer auch kann.
  • Audit Logging: Jeder Tool-Aufruf wird in CloudWatch protokolliert – mit Nutzeridentität, Zeitstempel, Tool-Name, Eingaben und Ausgaben.
  • PII-Maskierung: Personenbezogene Daten, die von Tools abgerufen werden, werden vor der Speicherung in Gesprächslogs maskiert.
  • Rate Limiting und Anomalie-Erkennung: Ungewöhnliche Nutzungsmuster lösen Alarme aus, bevor sie zu Sicherheitsvorfällen werden.

Ist das die richtige Lösung für Ihr Unternehmen?

Diese Architektur liefert den größten Mehrwert, wenn mindestens zwei der folgenden Punkte auf Ihr Unternehmen zutreffen:

  • Ihr Team verbringt erhebliche Zeit damit, interne Informationen über mehrere Systeme hinweg zu suchen
  • Sie haben wiederkehrende Verwaltungsworkflows, die derzeit einen Menschen erfordern, der etwas nachschlägt und dann handelt
  • Wissen ist zwischen Abteilungen isoliert, und die Kosten dieser Silos zeigen sich in langsamen Entscheidungen oder doppelter Arbeit
  • Sie nutzen AWS oder sind bereit, es einzusetzen (Bedrock ist AWS-nativ)

Wenn Sie neugierig sind, ob dies zu Ihrer Situation passt, bieten wir ein kostenloses Erstgespräch an, in dem wir Ihre Toollandschaft gegen eine Prototyp-Architektur mappen und Ihnen eine ehrliche Einschätzung von Aufwand und erwartetem Return geben.

Sollen Profis das für dich übernehmen?

Unser KI-Automatisierung & Business Automation Team kümmert sich um alles – von der Strategie bis zur Umsetzung.

Mehr über unseren KI-Automatisierung & Business Automation Service erfahren →

Bereit dein Unternehmen auf ein neues Level zu bringen?

Hau drauf
Interner Chatbot für Unternehmen – mit Claude, AWS Bedrock und dem MCP – ADBEAM Blog