Wie eine echte KI-Steuerungsebene aussieht (und wie man sie aufbaut, bevor sich MCP Sprawl selbst aufbaut)

In einem früheren Beitrag habe ich dargelegt, dass Middleware zur KI-Steuerungsebene für Unternehmen geworden ist. Da große Sprachmodelle zunehmend von der Generierung von Empfehlungen zur Umsetzung von Maßnahmen übergehen, markiert das Model Context Protocol (MCP) einen wichtigen Wandel in der Art und Weise, wie KI-Systeme mit realen Tools und Daten interagieren. Indem es Modellen ermöglicht, Tools direkt aufzurufen, verkürzt MCP den Weg von der Absicht zur Ausführung und verändert die Art und Weise, wie Arbeit in Unternehmenssystemen erledigt wird.

Diese Geschwindigkeit ist zwar leistungsstark, offenbart jedoch auch eine Lücke. Wenn die Ausführung einfach wird, werden Koordination, Kontrolle und Verantwortlichkeit schwieriger. MCP befasst sich mit dem N×M-Integrationsproblem zwischen Modellen und Tools, definiert jedoch nicht, wie Aktionen gesteuert, überwacht oder eingeschränkt werden, sobald Agenten innerhalb von Produktionssystemen operieren.

Wenn die Autonomie von Agenten ohne Instabilität oder Risiken skaliert werden soll, dürfen Orchestrierung und Governance keine Option sein. Die Frage, die in diesem Beitrag, Teil 2, untersucht wird, ist einfach, aber entscheidend: Was muss eine KI-Steuerungsebene tatsächlich gewährleisten, damit autonome Agenten sicher und zuverlässig im Unternehmen arbeiten können?

Der erste Fehlermodus: Onboarding-Tools statt Fähigkeiten

Die meisten MCP-Einführungen beginnen auf die gleiche Weise. Teams legen offen, was sie bereits besitzen:

• Ein Skript wird zu einem Werkzeug
• Eine Abfrage wird zu einem Werkzeug
• Ein Microservice wird zu einem Werkzeug
• Ein Workflow wird zum Werkzeug

Lokal funktioniert das gut. Es reduziert die Einrichtungszeit und zeigt sofortige Fortschritte. Auf Unternehmensebene entsteht dadurch jedoch ein Problem, das in der Regel später auftritt, nämlich beim ersten Vorfall, der Team- oder Systemgrenzen überschreitet.

Ein Werkzeug ist nichts, worüber das Unternehmen nachdenken kann. Werkzeuge beschreiben Mechanismen. Unternehmen denken über Ergebnisse nach. Was das Unternehmen tatsächlich interessiert, sieht eher so aus:

• An Bord eines Kunden
• Eine Rechnungsstreitigkeit beilegen
• Bereitstellung eines Mitarbeiters
• Eine Rückerstattung vornehmen
• Einen Vorfall mit Leitplanken abschließen
• Eine Gelegenheit schaffen und anhand der Richtlinien überprüfen

Die Kluft zwischen diesen beiden Perspektiven ist der Ausgangspunkt für die Ausbreitung von MCP. Ein Agent versteht die Bedeutung einer Organisation nur, wenn Sie diese kodieren. Er weiß nicht, dass fünf einzeln gültige Tool-Aufrufe, die in der falschen Reihenfolge ausgeführt werden, die gleichen Auswirkungen nachgelagert haben können wie eine fehlerhafte Produktionsänderung. Und da die Entscheidungen des Agenten probabilistisch sind, kann der Ausführungspfad von Lauf zu Lauf variieren.

Dies führt zum ersten Grundsatz einer echten KI-Steuerungsebene: Weniger Dinge offenlegen und Dinge auf höherer Ebene offenlegen.

Anstatt jede einzelne Handlung offenzulegen, legen Sie Fähigkeiten offen, die Ergebnisse repräsentieren, hinter denen Sie stehen können:

• Nicht „Kundendatei aktualisieren“
• Nicht „Rechnung erstellen“
• Nicht „Rabatt anwenden“
• Nicht „E-Mail senden“

Legen Sie das „Abrechnungsproblem lösen“ offen und verbergen Sie die Mechanismen hinter einem geregelten Workflow, der standardmäßig Bestellungen, Wiederholungsversuche, Genehmigungen, Maskierungen und Protokollierungen durchsetzt.

Was die Steuerungsebene garantieren muss

Sobald Sie von Tools zu Fähigkeiten übergehen, wird die Rolle der Steuerungsebene deutlicher. Sie dient dazu, eine Reihe spezifischer Ausführungsgarantien zu bieten. Diese Garantien ermöglichen es den Agenten, innerhalb der Produktionssysteme sicher und autonom zu arbeiten.

1. Abstraktion der Fähigkeiten

Agenten sollten keine Unternehmensinterna dynamisch zusammenstellen. Sie sollten stabile, versionierte Funktionen aufrufen, die die Geschäftsabsicht widerspiegeln. In der Praxis bedeutet dies:

• Eine „Onboard-Kunden”-Funktion anstelle eines Netzwerks aus CRM-, Abrechnungs- und Support-Tools
• Eingaben und Ausgaben, die eher die Absicht als interne Schemadetails beschreiben
• Explizite Versionierung, da sich Geschäftsregeln auch dann ändern, wenn Agenten dies nicht tun.

Hier haben Integrationsplattformen in der Vergangenheit eine stille, aber entscheidende Rolle gespielt, indem sie viele System-APIs in einen einzigen, steuerbaren Geschäftsprozess übersetzt haben.

2. Durchsetzung von Richtlinien zum Zeitpunkt der Handlung

MCP ermöglicht die Verbindung, nicht die Kontrolle. Eine Produktionssteuerungsebene muss entscheiden, ob eine Aktion ausgeführt werden soll, bevor sie stattfindet. Dazu müssen Fragen beantwortet werden wie:

• Ist dieser Agent berechtigt, diese Aktion in dieser Umgebung für dieses Kundensegment durchzuführen?
• Ist der Datenumfang angemessen, einschließlich Maskierung, Umgang mit personenbezogenen Daten und regulatorischen Beschränkungen?
• Halten wir uns an die Rate Limits, Change Windows oder Regeln zur Aufgabentrennung?
• Erfordert diese Aktion eine Genehmigung durch einen Menschen oder eine sekundäre Validierung?

Mit dem Wachstum von MCP-Ökosystemen wird die Fragmentierung von Identitäten zu einem echten Risiko. Viele Tools, viele Anmeldedaten und inkonsistente Zugriffskontrollen sind keine theoretischen Probleme. Sie sind der Grund, warum Unternehmen gehackt werden.

3. Zustand und Idempotenz

Agenten versuchen es erneut. Frameworks versuchen es erneut. Netzwerke versagen teilweise und auf verwirrende Weise. Ohne einen dauerhaften Zustand führt hilfreiche Automatisierung zu doppelten Rückerstattungen, doppelten Tickets und doppelten Kontoänderungen. Eine echte Steuerungsebene macht dies durch folgende Maßnahmen deutlich:

• Korrelations-IDs über Schritte hinweg
• Deduplizierungsschlüssel
• Sichere Wiederholungsversuche und Ausgleichsmaßnahmen
• Klare Fehlermodi statt narrativer Erklärungen

4. Deterministische Orchestrierung rund um probabilistische Entscheidungen

Lassen Sie den Agenten entscheiden, was zu tun ist. Lassen Sie ihn nicht entscheiden, wie die Ausführung abläuft. Die Trennung ist beabsichtigt:

• Die probabilistische Schicht interpretiert die Absicht und wählt eine Fähigkeit aus.
• Die deterministische Schicht übernimmt die Orchestrierung, Reihenfolge, Fehlerbehandlung und Rückabwicklung.

Im ersten Teil habe ich vor Ausführungswegen gewarnt, die zur Laufzeit entdeckt werden. So lässt sich dieses Risiko eindämmen, ohne die Autonomie zu beeinträchtigen.

5. Beobachtbarkeit, die die Rechenschaftspflicht unterstützt

Sie brauchen keine weiteren Protokolle. Sie brauchen Antworten:

• Was hat der Agent versucht?
• Welche Funktion wurde aufgerufen?
• Auf welche Daten wurde zugegriffen und was wurde maskiert?
• Welche nachgelagerten Systeme waren betroffen und in welcher Reihenfolge?
• Was hat sich geändert und wem gehört das Ergebnis?

Wenn Ihre Erklärung nach dem Vorfall mit „das Modell hat entschieden“ endet, ist das System nicht produktionsreif.

6. Menschliche Überwachung als Teil des Arbeitsablaufs

Human-in-the-Loop wird oft als Fallback dargestellt. In ausgereiften Systemen ist es ein Designmerkmal. Aufsicht funktioniert am besten, wenn sie strukturiert ist:

• Genehmigungen über den festgelegten Schwellenwerten
• Überprüfungen für sensible Aktionen wie Zugriffsänderungen oder Datenexporte
• Weiterleitung an den richtigen Eigentümer statt an eine allgemeine Warteschlange

7. Simulation und Änderungsmanagement

Fähigkeiten entwickeln sich weiter und müssen wie Software behandelt werden. Das bedeutet:

• Sandbox-Ausführung
• Wiederholung gegen historische Fälle
• Drift-Erkennung, wenn sich Ergebnisse ohne Versionsaktualisierungen ändern
• Definierte Rollback-Pfade

Mit MCP lassen sich Tools ganz einfach hinzufügen. Eine Steuerungsebene sorgt für die sichere Weiterentwicklung der Funktionen.

Wo MCP endet und die Verantwortung des Unternehmens beginnt

Insgesamt betrachtet ist die Architektur unkompliziert:

• Agenten und Anwendungen interagieren mit Benutzern
• MCP stellt die Standardprotokollschicht bereit.
• Das Unternehmen veröffentlicht einen geregelten Funktionskatalog.
• Eine Integrations- und Orchestrierungsschicht sorgt für die Einhaltung von Ausführungsgarantien.
• Aufzeichnungssysteme bleiben Aufzeichnungssysteme

MCP funktioniert wie ein universeller Konnektor. Es handelt sich dabei nicht um ein Betriebssystem. Unternehmen benötigen weiterhin eine zentralisierte Kontrolle über Berechtigungen, Richtlinien, Prozesse und Audits, selbst wenn die Ausführung aus Gründen der Latenz, des Datenschutzes oder der Souveränität in der Nähe der Daten erfolgt.

Aus diesem Grund treten Integration und Orchestrierung still und leise wieder als Steuerungsebene für agentenbasierte Systeme in den Vordergrund. Sie bilden die Governance-Ebene, die MCP bewusst auslässt.

Wie man eine MCP-Ausbreitung verhindert, bevor sie sich verfestigt

Wenn Teams bereits alles, was sie besitzen, MCP-fähig machen, ist die Lösung kein Richtlinienmemo. Es geht darum, die Definition von Erfolg zu ändern.

Zunächst sollten Sie die Einführung von Tools einstellen und stattdessen mit der Einführung von Fähigkeiten beginnen. Machen Sie die Schaffung von Fähigkeiten zum Arbeitsergebnis. Teams können weiterhin intern Tools entwickeln, aber was veröffentlicht wird, muss eine klare Absicht, klare Einschränkungen, klare Verantwortlichkeiten und eine klare Überprüfbarkeit aufweisen.

Zweitens: Zentralisieren Sie die Durchsetzung und dezentralisieren Sie gleichzeitig die Beiträge. Lassen Sie Teams frei ihre Fähigkeiten einbringen, aber standardisieren Sie Identität, Richtlinien, Protokollierung, Tests und Bereitstellung. So verhindern Sie, dass Innovationen zu operativer Instabilität führen.

Drittens: Behandeln Sie die Beobachtbarkeit als Produktanforderung. Wenn Sie nicht schnell beantworten können, „was passiert ist“, wird die Autonomie letztendlich eingeschränkt werden. Dieser Verlauf ist vorhersehbar und entspricht dem zuvor beschriebenen.

Was dies in der Praxis bedeutet

Die Einführung von MCP wird sich weiter beschleunigen. Das Ökosystem wird wachsen. Die Anzahl der Tools wird sich vervielfachen.

Die Organisationen, die erfolgreich sein werden, sind nicht diejenigen mit den meisten MCP-fähigen Tools. Es werden diejenigen sein, die ihren Mitarbeitern Freiraum lassen, ohne dass die Umsetzung im Chaos versinkt.

Dazu ist eine Steuerungsebene erforderlich, die sich zu den Ergebnissen eine Meinung bildet.

• Agenten bleiben flexibel
• Die Ausführung bleibt stabil.
• Autonomie bleibt beherrschbar

Die Infrastruktur, die dies ermöglicht, wird nicht auffällig sein. Sie wird nicht im Trend liegen. Aber sie ist das, worauf sich Unternehmen standardisieren werden, sobald die agentenbasierte Ausführung an ihre tatsächlichen operativen Grenzen stößt.

Wenn Sie bereits darüber nachdenken, wie Sie von MCP-Experimenten zu einer geregelten, produktionsreifen Autonomie übergehen können, ist jetzt der richtige Zeitpunkt, um sich anzuschauen, wie eine echte integrationsgesteuerte Steuerungsebene in der Praxis funktioniert.

Buchen Sie eine Demo, um zu erfahren, wie die Ausführung von Agenten koordiniert, gesteuert und beobachtet werden kann, ohne dabei an Geschwindigkeit einzubüßen.

Intelligenz ist optional. Koordination nicht.