Docs
MCP-Gateway auswählen: Worauf es im Mittelstand ankommt
Stand: 19. August 2026
Die kurze Antwort
Bei der Auswahl eines MCP-Gateways entscheiden vier Kriterien: das Betriebsmodell (läuft die Software beim Unternehmen oder beim Anbieter), das Berechtigungsmodell (wie fein lässt sich steuern, welche KI was darf), die Protokollierung (lässt sich jeder Zugriff nachträglich belegen) und das Bezugs- und Lizenzmodell (wie wird gezählt, was passiert bei Vertragsende). Die Produktkategorie ist jung und verändert sich schnell — ein strukturiertes Anbietergespräch entlang dieser vier Punkte trägt weiter als jeder Funktionsvergleich.
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, einschließlich der abgelehnten, 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 die abgelehnten?
- 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?
Faktenbox
- Vier Auswahlkriterien entscheiden: Betriebsmodell, Berechtigungsmodell, Protokollierung, Bezugs- und Lizenzmodell.
- Drei Angebotsarten: Open-Source-Bausteine für Entwicklerteams, Module großer API-Plattformen, eigenständige Gateways für Fachabteilungen.
- Self-hosted heißt: Zugangsdaten und Protokolle bleiben im Haus — die Betriebsverantwortung auch.
- Ein MCP-Gateway nützt nur Mitarbeitern mit KI-Assistent: Der Zugriff läuft über die KI, nicht über die Person.
- Die datenschutzrechtliche Verantwortung bleibt in jedem Betriebsmodell beim Unternehmen.
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 Zugang, nicht nach KI-Verbrauch. Ein 30-Tage-Trial ist eingebaut — kostenlos. JanuaPort ist Early Access (v0.x); was heute funktioniert und was Roadmap ist, steht klar gekennzeichnet auf den verlinkten Seiten.
Häufige Fragen
Häufige Fragen zur Auswahl eines MCP-Gateways
Was kostet ein MCP-Gateway?
- Das hängt vom Lizenzmodell ab: verbreitet sind Preise je Nutzer oder je Zugang, daneben Abrechnung nach Aufrufen oder Verbrauch; bei Open-Source-Bausteinen entstehen die Kosten im Betrieb statt in der Lizenz. Wichtiger als die Höhe ist die Planbarkeit — eine Rechnung, die mit der Nutzung wächst, bestraft genau das Verhalten, das man sich von der Einführung wünscht.
Muss ein MCP-Gateway im eigenen Haus laufen?
- Nein. Es gibt Cloud-Dienste und self-hosted Angebote. Die Frage dahinter lautet: Dürfen Anfragen, Antworten und die Zugangsdaten der Fachsysteme durch die Infrastruktur eines Dritten laufen? Wer sie mit Nein beantwortet, wählt self-hosted und übernimmt dafür die Betriebsverantwortung.
Funktioniert jeder MCP-Gateway mit jedem KI-Assistenten?
- MCP ist ein offener Standard, und ein Gateway verhält sich gegenüber dem KI-Assistenten wie ein gewöhnlicher MCP-Server. Jeder Assistent, der MCP spricht, kann sich verbinden, ohne den Gateway besonders unterstützen zu müssen. Entscheidend ist nur, dass der KI-Assistent des Unternehmens MCP beherrscht.
Wie lange dauert die Einführung eines MCP-Gateways?
- Die Installation ist selten der Aufwandstreiber — je nach Angebot reicht sie vom Start eines einzelnen Containers bis zum Plattform-Projekt. Die eigentliche Arbeit steckt im Berechtigungskonzept und in der Anbindung der Fachsysteme: Wer darf was, und welche Systeme kommen zuerst? Realistisch plant man die Einführung als schrittweisen Ausbau, nicht als Stichtag.
Braucht man für ein MCP-Gateway eigenes IT-Personal?
- Für einen Cloud-Dienst nicht — dafür gibt man Datenhoheit ab. Self-hosted braucht jemanden, der eine Anwendung betreiben kann: Updates einspielen, Sicherungen prüfen. Manche Anbieter senken diese Hürde mit vorkonfigurierten Geräten oder Betriebsleistungen; das ist dann eine Frage des konkreten Angebots, nicht der Kategorie.
Kontakt
Haben Sie Fragen? Sprechen Sie mit uns.
Ob Einordnung, konkreter Anwendungsfall oder erste Schritte — schreiben Sie uns, wir melden uns zurück.