SOLUTIONS.mcp
Die meisten KI-Vorhaben in Unternehmen scheitern nicht am Modell, sondern am Zugang. Ein Assistent, der nur reden kann, hilft niemandem; er müsste an die Systeme heran, in denen die Arbeit stattfindet. Der übliche Weg dorthin ist eine eigene Anbindung je Anwendung, und mit ihr ein zweites Rechtekonzept, das erfahrungsgemäß großzügiger ausfällt als das erste.
Der Unterschied im Zugang
Was sich an der Anbindung ändert
heute üblich
mit dem Dienst
Was der Assistent bekommt
Was der Assistent anfassen kann, steht im Modell
Fünfzehn Werkzeuge in vier Gruppen, mehr braucht es nicht: Der Dienst wird nicht je Anwendung programmiert, er liest aus dem Modell ab, was es gibt.
Die Rechte werden nicht nachgebaut, sondern benutzt
Das ist der Kern und zugleich der Punkt, an dem sich dieser Weg von einer selbst gebauten Anbindung unterscheidet. Der Dienst hält keine eigenen Zugangsdaten für Ihre Anwendung. Jeder Aufruf wird mit dem Zugangsmerkmal der angemeldeten Person weitergereicht, und die Anwendung prüft ihn so, als käme er aus der Oberfläche.
Daraus folgt alles Weitere von selbst. Wer einen Datensatz nicht sehen darf, bekommt ihn auch über den Assistenten nicht. Zeilenfilter und Feldrechte gelten unverändert. Ein Assistent kann nicht mehr, als die Person könnte, die ihn bedient, und er kann auch nichts anderes. Einen technischen Sammelzugang, der über allem steht, gibt es nicht; er ist in solchen Anbindungen sonst die Schwachstelle.
Welche Entitäten überhaupt ansprechbar sind, entscheiden Sie je Anwendung. Was nicht freigegeben ist, existiert für den Assistenten nicht, unabhängig davon, wer fragt.
Dieselbe Frage, ohne den Weg durch drei Masken
Die Rechte einer Person stehen über mehrere Listen verteilt: Systemrollen, Sicherheitsgruppen und Zugriffsregeln je Anwendung. Der Assistent holt sie einzeln und legt sie zusammen; das Ergebnis lässt sich als Tabelle weiterverwenden.
Sichtbar wird dabei nur, was die fragende Person ohnehin sehen dürfte. Dieselbe Frage, gestellt von jemandem ohne Verwaltungsrechte, liefert weniger, und dafür muss keine zweite Regel gepflegt werden.
Ein Wächter steht vor dem Assistenten
Bevor eine Anfrage den Assistenten erreicht, prüft ein kleines, schnelles Modell sie auf Themenfremdes, auf Versuche, die Anweisungen zu unterlaufen, und auf offenkundig schädliche Absichten. Die vorangegangenen Züge des Gesprächs gehen mit ein, damit eine harmlose Rückfrage nicht als neuer Angriff gewertet wird.
Diese Prüfung sperrt im Zweifel. Fällt der Wächter aus, wird nicht durchgewunken, sondern abgelehnt; nach mehreren Fehlversuchen hintereinander schaltet er ganz ab und lässt erst nach einer Wartezeit wieder einen Versuch zu. Ein Wächter, der bei Störung alles durchlässt, wäre keiner.
Was Sie je Anwendung hinterlegen
Der Dienst wird nicht programmiert, sondern eingerichtet. Vier Angaben je Anwendung, alle fachlich:
Die Struktur selbst pflegen Sie nicht: Entitäten, Felder und deren Bedeutung liest der Dienst aus dem Modell der Anwendung. Ändert sich das Modell, ändert sich der Zugang mit, ohne dass jemand eine Beschreibung nachzieht.
Die Freigabe ist eine Tabelle, kein Programmierauftrag
Je Anwendung steht eine Zeile für jede Entität und eine Spalte für jede Operation. Wo kein Haken steht, existiert die Entität für den Assistenten nicht. Im Beispiel sind es elf Entitäten und zwanzig freigegebene Operationen.
Die Liste selbst pflegt niemand von Hand. Sie kommt aus dem Modell der Anwendung, und die Schaltfläche daneben holt sie neu, sobald das Modell gewachsen ist.
Was der Assistent von einem Datensatz zu sehen bekommt
Zu jeder freigegebenen Entität lässt sich einstellen, welche Felder in der Kurzform einer Trefferliste stehen und welche in der Zusammenfassung. Das hält den Assistenten bei der Sache: Ein Datensatz mit sechzig Feldern beantwortet keine Frage besser als einer mit sechs, er kostet nur mehr.
Darunter stehen Felder für Anweisungen, getrennt nach Lesen, Schreiben und Löschen. Dort steht die Fachlichkeit, die aus dem Modell nicht hervorgeht: dass ein Vorgang erst geschlossen wird, wenn die Prüfung vorliegt, oder dass ein Feld nur nach Rücksprache geändert wird.
Eine gute Formulierung wird einmal geschrieben
Wiederkehrende Aufgaben werden als Arbeitsanweisung hinterlegt, mit Platzhaltern für das, was jedes Mal wechselt. Im Beispiel steht ein Platzhalter für die Anwendung; der Rest sagt dem Assistenten, welche Daten er sich zuerst holen soll und wozu.
Wer die Anweisung aufruft, bekommt sie mit seiner eigenen Anwendung eingesetzt. So muss nicht jeder Anwender selbst herausfinden, wie eine Frage zu stellen ist, damit sie gut beantwortet wird.
Was der Betrieb kostet
Zwei Positionen, und die zweite ist die ungewöhnliche. Der Dienst selbst braucht ein Nutzungsrecht, wie unsere anderen Dienste auch; was das beim Vertragsende bedeutet, steht unter Lizenzmodell und Quellcode.
Dazu kommen die Kosten der Sprachmodelle. Dafür brauchen Sie einen eigenen Zugang bei Anthropic, abgerechnet wird direkt zwischen Ihnen und Anthropic, nach Verbrauch. Wir schlagen nichts darauf. Das ist die einzige Position in unserem gesamten Modell, die mit der Nutzung wächst, deshalb steht sie hier und nicht im Kleingedruckten.
Sie ist begrenzbar. Für jede Sitzung lässt sich ein Höchstbetrag hinterlegen, und für die verschiedenen Aufgaben sind unterschiedlich große Modelle eingestellt: die Einordnung einer Anfrage kostet nicht dasselbe wie eine Planung.
Was der Dienst nicht ist
Es ist kein Chatbot vor Ihrer Anwendung. Er beantwortet keine Fragen aus eigenem Wissen, sondern arbeitet mit Ihren Daten, über Ihre Schnittstelle, mit Ihren Rechten.
Es ist keine Anbindung an einen bestimmten Anbieter. Der Dienst spricht das offene Model Context Protocol. Der eingebaute Chat ist eine Bequemlichkeit; ein anderer Assistent, der dasselbe Protokoll beherrscht, kann dieselbe Anwendung ansprechen.
Und es ist keine Automatisierung ohne Aufsicht. Ein Assistent handelt im Namen einer Person, mit deren Rechten, und was er tut, ist dieser Person zugeordnet wie jede andere Änderung auch. Wer wissen will, was passiert ist, muss keine zweite Spur lesen.
Weiterlesen
Nein, und das ist die wichtigste Eigenschaft. Jeder Aufruf wird mit dem Zugangsmerkmal der angemeldeten Person weitergereicht. Wer einen Datensatz nicht öffnen darf, bekommt ihn auch über den Assistenten nicht. An den Rechten führt kein zweiter Weg vorbei.
Ja, wenn die Person das darf und die Entität dafür freigegeben ist. Anlegen, Ändern, Teiländern und Löschen gehören zu den Werkzeugen. Welche Entitäten überhaupt ansprechbar sind, entscheiden Sie je Anwendung; was nicht freigegeben ist, existiert für den Assistenten nicht.
Er hat keine Kommandozeile, keinen Schreibzugriff auf Dateien, keine Dateisuche und keinen Zugang ins Internet. Acht Werkzeuge des zugrunde liegenden Rahmens sind fest gesperrt. Übrig bleibt der Weg über die Schnittstelle Ihrer Anwendung, und der ist derselbe, den die Oberfläche benutzt.
Nein. Der Dienst spricht das offene Model Context Protocol, Ihre Anwendung ist damit für jeden Assistenten ansprechbar, der es beherrscht. Der eingebaute Chat ist eine Bequemlichkeit, keine Voraussetzung.
Der Dienst selbst braucht ein Nutzungsrecht. Dazu kommen die Kosten der Sprachmodelle, für die Sie einen eigenen Zugang bei Anthropic brauchen; abgerechnet wird direkt zwischen Ihnen und Anthropic, nach Verbrauch. Je Sitzung lässt sich ein Höchstbetrag hinterlegen.
Aus drei Quellen, die Sie pflegen: die Struktur der Anwendung liest er selbst aus dem Modell, dazu kommen eine Anleitung je Anwendung und wiederverwendbare Arbeitsanweisungen. Fachwissen wird hinterlegt, nicht geraten.
Was der Assistent liest, um eine Frage zu beantworten, geht an das Sprachmodell, denn dort wird die Antwort gebildet. Das ist eine bewusste Entscheidung pro Anwendung und pro Entität. Die Anwendung selbst läuft ohne jede Verbindung zu einem KI-Dienst, wenn Sie den Assistenten nicht einsetzen.
Sprechen Sie mit uns.