Eigene Systeme & Fachverfahren anbinden

SovrGPT spricht mit externen Systemen ausschließlich über das Model Context Protocol (MCP) — einen offenen Standard, über den ein Modell Werkzeuge aufrufen kann. Bestandssoftware (DMS, ERP, Fachverfahren, interne Tools) bietet aber meist eine REST-/SOAP-/CMIS-API, kein MCP. Die Brücke dazwischen ist ein MCP-Adapter — auch „MCP-Bridge" genannt.

Was ist eine MCP-Bridge?

Eine MCP-Bridge ist eine schlanke Middleware, die zwei Sprachen übersetzt:

• Nach SovrGPT hin spricht sie MCP (JSON-RPC über Streamable HTTP).
• Nach Ihrer Software hin spricht sie deren bestehende API (REST, OData, SOAP, CMIS, GraphQL …). Eine einzelne Bridge kann mehrere dieser Protokolle gleichzeitig bedienen — z. B. die VIS-Suite, die REST, OData, SOAP und CMIS anbietet.

Sie ist kein proprietärer Konnektor und kein zweites Produkt, das Sie kaufen — sondern ein dünner Übersetzer, den Sie (oder Ihr Integrationspartner) in Ihrer eigenen Infrastruktur betreiben. SovrGPT bekommt von Ihrer Software nie direkten Zugriff; es kennt nur die Bridge-URL und ein Token.

Architektur auf einen Blick

┌──────────┐   MCP (JSON-RPC)    ┌──────────────┐   REST/SOAP/CMIS   ┌────────────────┐
│ SovrGPT  │ ──────────────────▶ │  MCP-Bridge  │ ─────────────────▶ │ Bestandssoftware│
│  (EU)    │ ◀────────────────── │ (Ihre Infra) │ ◀───────────────── │ (DMS/ERP/Fach.) │
└──────────┘   Tool-Ergebnis     └──────────────┘   API-Antwort      └────────────────┘

1. Das Modell entscheidet im Chat, ein Werkzeug aufzurufen (z. B. „Akte suchen").
2. SovrGPT sendet einen MCP-Tool-Call an die Bridge-URL (Ihr Endpunkt).
3. Die Bridge übersetzt den Call in einen API-Aufruf Ihrer Software.
4. Die API-Antwort wird zurück in ein MCP-Tool-Ergebnis übersetzt.
5. Das Modell formuliert daraus die Antwort — mit Quellen, falls vorhanden.

Warum eine Bridge — und nicht „direkt REST"?

• Ein Standard statt N Sonderfälle. SovrGPT muss nur MCP sprechen; jede Eigenheit Ihrer API kapselt die Bridge. Neue Systeme = neue Bridge, kein Eingriff in die Plattform.
• Sie behalten die Kontrolle. Die Bridge läuft bei Ihnen. Sie entscheidet, welche Endpunkte/Felder freigegeben werden — ein kuratierter Ausschnitt statt Vollzugriff. Credentials Ihrer Software verlassen Ihr Haus nie.
• Souveränität bleibt gewahrt. Datenfluss: SovrGPT (EU) ↔ Bridge (Ihre Infra) ↔ Software (Ihre Infra). Kein Hyperscaler dazwischen.

Drei Wege, eine Bridge bereitzustellen

Anbinden in der Praxis

Custom-Bridges werden wie jeder andere MCP-Server eingebunden:

1. Bridge in Ihrer Infrastruktur deployen (Container/VM), erreichbar per HTTPS.
2. In SovrGPT unter Sidebar → Marketplace → Custom-MCP die Bridge-URL und ein Bearer-Token eintragen.
3. Token wird AES-256-GCM-verschlüsselt in der EU-Datenbank abgelegt (Encrypted-Columns, org-scoped) — niemals clientseitig sichtbar.
4. Die Werkzeuge der Bridge erscheinen sofort im Composer. Schreibaktionen können pro Chat bestätigungspflichtig (confirm_writes) sein.

Verwaltungs-Fachverfahren (Behörden)

Für die öffentliche Verwaltung gibt es kuratierte Bridge-Vorlagen gegen die offenen eGovernment-Standards — kein proprietärer Konnektor nötig:

Weil CMIS und FIT-Connect offene HTTP-Standards sind, deckt eine Bridge mehrere DMS-Produkte ab. Echte Konnektoren innerhalb eines konkreten Fachverfahrens bleiben ein kundenspezifisches Integrationsprojekt.

Diese Behörden-Vorlagen sind nicht für alle Organisationen sichtbar: Ein Plattform-Admin schaltet sie pro Organisation über ein Entitlement (Behörden-Konnektoren) frei. Unternehmens-Tenants sehen sie nicht.

Sicherheit

• Token org-scoped & verschlüsselt — nur der Server kann entschlüsseln.
• Least Privilege — die Bridge gibt nur frei, was sie freigeben soll.
• Bestätigungspflicht — schreibende Aktionen werden pro Chat bestätigt.
• Audit — jeder Tool-Call wird protokolliert (usage_events/Audit-Log), inkl. Nachvollziehbarkeit für die Verwaltung.

Mehr zum Protokoll und zu Editor-Clients: MCP-Server · fertige Connectoren: Marketplace.