Interne AI und externes MCP als getrennte Bereiche
Dieselben Geschäftsdaten benötigen nicht denselben Zugangskanal
Bei der Einführung von AI ist die Versuchung groß, alles hinter einem universellen Gateway zusammenzuführen: interner Agent, externe Assistenten, Entwicklerwerkzeuge und Partnerintegrationen. Das vereinfacht die Darstellung in einer Präsentation, verwischt jedoch die Vertrauensgrenzen. Sapphire I.C.D.S. verfolgt einen anderen Ansatz. Integrierte AI und externes MCP sind getrennte Bereiche, auch wenn sie in einzelnen Fällen dieselbe native Operation eines Geschäftsmoduls verwenden.
Die Trennung beantwortet eine praktische Frage: Wer löst eine Aktion aus, in welchem Kontext arbeitet diese Person oder Anwendung und welche Daten dürfen für diese Clientklasse überhaupt sichtbar sein? Ein interner Plattformbenutzer und ein externer AI-Client werden nicht gleichwertig, nur weil beide eine Artikelliste anfordern können.
Interne AI arbeitet innerhalb der Plattform
Der integrierte AI-Agent läuft im authentifizierten Kontext von Sapphire I.C.D.S. Die Plattform bestimmt den Eigentümer der Sitzung, die verfügbare Arbeitsoberfläche, das ausgewählte Modellprofil und die erlaubten Werkzeuge. Der Agent kann Unternehmensanweisungen, internes Gedächtnis und Wissensbasis verwenden, sofern die interne Richtlinie dies zulässt. Seine Aufgaben, Historie und Aktionen bleiben Teil des gesteuerten AI-Bereichs.
Der Werkzeugzugang ergibt sich aus globalem Zustand, Gruppenrechten und Sitzungseinstellungen. Eine Benutzeranfrage kann nicht selbst eine neue Rolle erklären oder einen verbotenen Befehl aktivieren. Damit eignet sich der interne Agent für die tägliche Arbeit von Beschäftigten: Inhalte vorbereiten, Daten analysieren, Pläne führen und erlaubte Vorgänge in installierten Modulen ausführen.
Externes MCP ist für andere Clients vorgesehen
External MCP befindet sich in Sapphire I.C.D.S. in der Developer Alpha. Im derzeit bestätigten Bereich wurde nur die ChatGPT-Anbindung an https://sapphire-project.com/mcp geprüft; andere Hosts, Clients sowie noch nicht abgeschlossene Policy- oder Hardening-Funktionen müssen gesondert validiert werden.
MCP ist eine Standardschnittstelle, über die kompatible externe AI-Clients und Arbeitsumgebungen veröffentlichte Werkzeuge finden und aufrufen können. In Sapphire I.C.D.S. verwendet dieser Zugang eine getrennte HTTPS-Oberfläche, eine eigene Authentifizierung und ausdrückliche Berechtigungsbereiche. Der OAuth-Ablauf beginnt mit mcp.basic; zusätzliche Werkzeugbereiche werden nur per Scope-Step-up erteilt. Ein persönliches Bearer-Token erhält ein festes, serverseitig vorgegebenes Developer-Alpha-Scope-Paket, das weiterhin durch die aktuelle Benutzer- und Modulrichtlinie begrenzt ist. Damit wird keine granulare Scope-Auswahl für persönliche Tokens zugesagt.
Ein externer Client erhält nicht den vollständigen internen Katalog. Jedes Modul veröffentlicht eine eigene Positivliste von MCP-Werkzeugen. Die Existenz eines internen AI-Befehls macht ihn nicht automatisch extern. Der Server prüft erteilte Bereiche und aktuelle Kontorechte bei der Werkzeugnutzung erneut. Wird ein Recht entzogen, darf ein früher erteilter Zugang nicht zu einer dauerhaften Ausnahme von der Richtlinie werden.
| Kriterium | Interne AI | Externes MCP |
|---|---|---|
| Hauptbenutzer | Beschäftigte innerhalb von Sapphire I.C.D.S. | Externer AI-Client oder externe Arbeitsumgebung |
| Kontext | Interne Sitzung, Profil und erlaubte Unternehmensquellen | Nur im externen Bereich veröffentlichte Daten und Werkzeuge |
| Werkzeugrichtlinie | AI-Richtlinie, Gruppenrechte und Sitzungsauswahl | Ausdrückliche Veröffentlichung, Berechtigungsbereiche und aktuelle Rechte |
| Ziel | Agentenarbeit innerhalb der Plattform | Integration kompatibler externer Clients |
Internes Gedächtnis wird nicht extern veröffentlicht
Die wichtigste Grenze betrifft den Unternehmenskontext. Anweisungen, internes Gedächtnis und Wissensbasis gehören zur integrierten AI. Sie dürfen nicht in einer externen Werkzeugliste erscheinen oder an einen externen Client zurückgegeben werden, nur weil dieser sich erfolgreich authentifiziert hat. Authentifizierung bestätigt Identität und erteilte Rechte, hebt aber den Grundsatz minimaler Veröffentlichung nicht auf.
Diese Entscheidung verringert das Risiko, Leitungsregeln, angesammelten Kontext und interne Materialien versehentlich offenzulegen. Benötigt die Organisation tatsächlich einen externen Ablauf mit einem bestimmten Datensatz, sollte dafür ein eigenes Werkzeug mit verständlichem Schema, Prüfungen und Berechtigungsbereich entworfen werden, anstatt eine allgemeine interne Quelle zu öffnen.
Gemeinsame Geschäftslogik kann wiederverwendet werden
Getrennte Bereiche müssen die Implementierung nicht duplizieren. Ein Modul kann interne und externe Aufrufe an dieselbe geprüfte Geschäftsoperation weiterleiten und dabei Transaktionen, Validierung und fachliche Einschränkungen beibehalten. Zuvor filtert der externe Adapter die Befehlsliste, prüft Argumente, bindet den Aufruf an eine bestätigte Identität und wendet zusätzliche Veröffentlichungsgrenzen an.
So entsteht ein wichtiger technischer Ausgleich. Das Unternehmen pflegt nicht zwei auseinanderlaufende Versionen der Aktualisierung eines Artikels oder Roadmap-Elements, betrachtet eine interne Funktion aber auch nicht automatisch als sicher für externe Nutzung. Wiederverwendet wird die Logik, nicht das Vertrauen.
Auch Fehler und Ergebnisse haben Grenzen
Externes MCP gibt Ergebnisse als Daten mit minimalem Vertrauen zurück. Selbst eine erfolgreiche Serverantwort macht einen Text im Ergebnis nicht zur Anweisung für den externen Agenten. Der Fehler eines Werkzeugs bleibt das Ergebnis dieses konkreten Aufrufs und darf keinen Zugang zu benachbarten Operationen öffnen. Änderungen verwenden getrennte Rechte, besonders sensible Aktionen können vollständig unveröffentlicht bleiben.
Im internen Bereich erhält das Modell ebenfalls strukturierte Ergebnisse, die Beschäftigtenoberfläche kann jedoch nur eine sichere Aktivitätsansicht zeigen. Detaillierte Argumente und technische Daten benötigen ein zusätzliches Recht. Beide Bereiche bleiben damit beobachtbar, geben aber jeweils nur die Informationsebene preis, die ihre Zielgruppe benötigt.
Welcher Bereich wofür geeignet ist
- Interne AI eignet sich für Beschäftigte in administrativen und operativen Oberflächen von Sapphire I.C.D.S., die Plattformkontext benötigen.
- Externes MCP eignet sich zur Anbindung kompatibler AI-Clients, Entwicklerwerkzeuge und automatisierter Arbeitsumgebungen.
- Beide Bereiche können nebeneinander bestehen. Die Organisation muss den integrierten Agenten nicht durch einen externen Dienst ersetzen und umgekehrt.
- Bestätigte Integration bezeichnet derzeit die oben beschriebene ChatGPT-Anbindung; daraus folgt keine allgemeine Verfügbarkeit für andere externe Clients.
Eine praktische Architekturregel
Vor der Veröffentlichung einer Operation sollte die technische Leitung vier Fragen beantworten: Benötigt sie internen Kontext, wer besitzt die Sitzung, welche minimalen Daten sind erforderlich und wie wird der Zugang entzogen? Hängt die Operation von privatem Gedächtnis oder internen Anweisungen ab, bleibt sie in der integrierten AI. Ist ein externes Szenario begründet, entsteht ein ausdrücklicher MCP-Vertrag mit begrenztem Schema und eigener Richtlinie.
Für den Eigentümer bedeutet die Trennung, externe AI-Dienste nutzen zu können, ohne die Unabhängigkeit von Sapphire I.C.D.S. aufzugeben. Das Sicherheitsteam erhält verständliche Veröffentlichungsgrenzen. Entwickler können native Geschäftslogik wiederverwenden, ohne Kontexte zu vermischen. Interne AI und externes MCP ergänzen sich deshalb, dürfen aber nicht zu einem ununterscheidbaren Kanal werden.