MCP-Gateway auswählen: Worauf es im Mittelstand ankommt

Auswahlkriterien

Worauf kommt es bei der Auswahl an?

1. Betriebsmodell und Datenhoheit. Ein MCP-Gateway sieht zwangsläufig alles, was zwischen den KI-Assistenten und den Fachsystemen ausgetauscht wird — Anfragen, Antworten und je nach Bauart auch die Zugangsdaten zu den Systemen. Die erste Frage ist deshalb nicht, was der Gateway kann, sondern wo er läuft und wer ihn betreibt.

2. Berechtigungsmodell. Entscheidend ist der Auslieferungszustand: Darf eine neu verbundene KI zunächst nichts, bis jemand ausdrücklich freigibt — oder alles, bis jemand einschränkt? Danach zählt die Feinheit: Lassen sich Rechte je System, je Werkzeug und je Aktion vergeben, ist die Herkunft eines Rechts sichtbar, und wirkt ein Entzug sofort?

3. Protokollierung. Wenn eine KI in der Buchhaltung arbeitet, will die Geschäftsführung im Zweifel belegen können, wer wann was ausgelöst hat — auch gegenüber einem Prüfer. Dafür muss jeder Zugriff protokolliert werden — auch der, der an einer Regel scheitert — und das Protokoll darf nachträglich nicht veränderbar sein.

4. Bezug und Lizenzmodell. Wie wird gezählt — je Nutzer, je Aufruf, nach Verbrauch? Läuft die Software weiter, wenn der Anbieter nicht erreichbar ist? Sendet sie Daten an den Hersteller? Ein Lizenzmodell, das mit der Nutzung wächst, bestraft genau das Verhalten, das man sich von der Einführung wünscht.

Quer zu allen vier Kriterien liegt die Frage, für wen das Angebot gebaut ist: Ein Gateway für Entwicklerteams setzt andere Fähigkeiten im Haus voraus als eines, das eine Fachabteilung über eine Oberfläche verwaltet. Die beste Technik nützt nichts, wenn niemand im Unternehmen sie bedienen kann.

Welche Arten von MCP-Gateways gibt es?

Der Markt lässt sich grob in drei Gruppen ordnen — ohne Anspruch auf scharfe Grenzen, dafür ist die Kategorie zu jung:

Open-Source-Bausteine für Entwicklerteams. Der Schwerpunkt liegt auf Routing und Proxy-Funktion; konfiguriert wird über Dateien, betrieben oft in Container-Clustern. Stark, wenn ein eigenes Plattform-Team existiert, das die Bausteine zusammensetzt und pflegt — und genau das ist die Voraussetzung.

Module großer API-Management-Plattformen. Hier ist der Gateway eine Funktion innerhalb einer breiteren Suite für Schnittstellen-Verwaltung. Naheliegend, wenn eine solche Plattform ohnehin im Haus ist; wer sie nur für die MCP-Funktion einführt, kauft viel Umfeld mit.

Eigenständige Gateways für Fachabteilungen und Mittelstand. Als fertiges Produkt gedacht: Verwaltung über eine Oberfläche statt über Konfigurationsdateien, Betrieb als einzelne Anwendung. Zielgruppe sind Unternehmen, die KI-Zugriffe kontrollieren wollen, ohne dafür ein Infrastruktur-Projekt zu starten.

Für alle drei Gruppen gilt: Die Angebote ändern sich derzeit im Monatsrhythmus. Bei allem, was man über MCP-Gateways liest — diese Seite eingeschlossen —, lohnt der Blick auf das Stand-Datum.

Betriebsmodell

Self-hosted oder als Cloud-Dienst — was heißt das für Datenhoheit und DSGVO?

Beim Cloud-Dienst läuft der Gateway beim Anbieter: Anfragen, Antworten und meist auch die Zugangsdaten der Fachsysteme passieren dessen Infrastruktur. Das ist bequem — der Anbieter betreibt, aktualisiert und skaliert —, macht ihn aber zum Auftragsverarbeiter mit allem, was dazugehört: Vertrag zur Auftragsverarbeitung, Prüfung der technischen und organisatorischen Maßnahmen, bei Anbietern außerhalb der EU die Drittlandsfrage.

Self-hosted heißt: Die Software läuft auf Infrastruktur des Unternehmens, Zugangsdaten und Protokolle bleiben im Haus. Die Auftragsverarbeitungs-Kette wird kürzer — dafür liegt die Betriebsverantwortung beim Unternehmen: Updates einspielen, Sicherungen prüfen, den Server selbst schützen.

In beide Richtungen gilt: Die datenschutzrechtliche Verantwortung für das, was eine KI mit personenbezogenen Daten tut, bleibt in beiden Modellen beim Unternehmen. Ein Gateway liefert die technische Kontrolle und den Nachweis — das Berechtigungskonzept und die Rechtsgrundlagen ersetzt er nicht.

Anbietergespräch

Welche Fragen sollte man einem Anbieter stellen?

Eine Checkliste für das Anbietergespräch — die Antworten sollten sich am Produkt überprüfen lassen, nicht nur auf Folien:

Zu Berechtigungen:

• Was darf eine neu verbundene KI im Auslieferungszustand — nichts oder alles?
• Wie fein lassen sich Rechte vergeben: je System, je Werkzeug, je Aktion?
• Wie wird ein Recht entzogen, und wirkt der Entzug sofort?

Zum Nachweis:

• Wird jeder Zugriff protokolliert — auch der, der an einer Regel scheitert?
• Ist das Protokoll nachträglich veränderbar, und wer könnte das?
• Lässt sich das Protokoll exportieren und außerhalb des Systems auswerten?

Zu Zugangsdaten und Kundendaten:

• Wo liegen die Zugangsdaten der Fachsysteme, und wie sind sie verschlüsselt?
• Bekommt der KI-Anbieter diese Zugangsdaten zu irgendeinem Zeitpunkt zu sehen?
• Können sensible Felder — etwa Kontonummern — gegenüber dem KI-Anbieter pseudonymisiert werden?

Zu Betrieb und Bezug:

• Was braucht der Betrieb konkret — einen einzelnen Container, ein Cluster, eine bestimmte Datenbank?
• Wie wird lizenziert und gezählt — je Nutzer, je Aufruf, nach Verbrauch — und ist die Rechnung damit planbar?
• Sendet die Software Daten an den Hersteller, und läuft sie weiter, wenn der Anbieter nicht erreichbar ist?
• Was passiert bei Vertragsende mit Konfiguration und Protokollen?

Wer auf diese Fragen klare, am laufenden Produkt überprüfbare Antworten bekommt, hat die Auswahl im Wesentlichen geschafft.

Abgrenzung

Wann reicht ein einzelner MCP-Server ohne Gateway?

Ein MCP-Server ist der Stecker am einzelnen Programm; der Gateway ist die Schaltzentrale dahinter. Für einen einzelnen Mitarbeiter, der testweise ein einzelnes System an seinen KI-Assistenten anschließt, ist ein direkter MCP-Server völlig ausreichend — ein Gateway wäre Overhead.

Der Wechselpunkt ist erreicht, wenn mehrere Mitarbeiter zugreifen, mehrere Systeme angebunden werden oder Nachvollziehbarkeit gefordert ist. Dann entstehen ohne Gateway viele Einzelverbindungen mit verstreuten Zugangsdaten und ohne gemeinsames Protokoll — das Problem, das die Kategorie überhaupt begründet. Ausführlich: Was ist ein MCP-Gateway — und wann braucht man einen?

JanuaPort

Wo JanuaPort in diesem Bild steht

JanuaPort ist ein self-hosted MCP-Gateway der dritten Kategorie: gebaut für Unternehmen ohne eigenes Plattform-Team, betrieben als einzelner Docker-Container auf eigener Infrastruktur. Neu verbundene KIs dürfen zunächst nichts (deny by default), Zugangsdaten liegen verschlüsselt in einem Vault, und jeder Zugriff steht in einem nachträglich nicht veränderbaren Protokoll — wie das zusammenspielt, zeigt die Seite Governance. Die Lizenz funktioniert offline, die Software sendet keine Daten an uns, und wo sie läuft, entscheiden Sie: Betrieb. Abgerechnet wird pro Identity, nicht nach KI-Verbrauch. Drei Identities sind dauerhaft kostenlos. Was heute funktioniert und was Roadmap ist, steht klar gekennzeichnet auf den verlinkten Seiten.