Das Protokoll ist fertig, unsere Systeme nicht: Warum KI-Agenten im Mittelstand an der letzten Meile scheitern

Das Wichtigste in Kürze (Stand 27.09.2026):

• Das Model Context Protocol (MCP) ist seit 2026 ein reifer Standard mit Autorisierung nach OAuth 2.1 und Enterprise-Managed Authorization; das Integrationsproblem für KI-Agenten liegt heute nicht mehr im Protokoll, sondern in der Systemlandschaft.
• KI-Agenten im Mittelstand scheitern an fünf Brüchen: Anwendungen ohne zentrales SSO, Fachsysteme ohne Schnittstelle, Server hinter der Firewall in flachen Netzen, Schreibvorgänge ohne Leitplanken und Inhalte, die Anweisungen enthalten (Prompt Injection).
• Der Bauplan dagegen hat fünf Bauteile: Identität als Fundament, Werkzeuge nach Geschäftsvorfall, ein zentrales Gateway als Kontrollpunkt, Guardrails in der Infrastruktur statt im Prompt und Autonomie als Stufenleiter.
• Die unvollständige Digitalisierung schützt heute Arbeitsplätze vor KI, weil ein Agent nur automatisiert, was er Ende-zu-Ende erreicht; das ist eine Schonfrist, die Unternehmen für Qualifizierung und agentenfähige Systeme nutzen sollten.

Im November 2024 hat Anthropic das Model Context Protocol veröffentlicht. Knapp zwei Jahre später ist MCP erwachsen: Das Protokoll liegt bei der Linux Foundation, die Spezifikation vom 28. Juli 2026 behandelt Autorisierung wie ein Enterprise-Standard, und die Erweiterung für Enterprise-Managed Authorization ist seit Juli stabil. Selbst SAP hat inzwischen ein MCP Gateway.

Auf dem Papier ist das Problem damit gelöst. Jedes Modell spricht mit jedem Werkzeug, über einen Stecker.

In der Praxis sieht es anders aus. Fragen Sie den Agenten in einem typischen mittelständischen Unternehmen: „Wo steht Auftrag 0815?“, und er antwortet vielleicht noch sauber. Sagen Sie ihm: „Verschieb die Lieferung um eine Woche, informier den Kunden und pass die Fertigungsplanung an“, und die Kette reißt. Nicht an einer Stelle. An fünf.

Das Protokoll ist fertig. Unsere Systemlandschaft ist es nicht.

Dieser Beitrag ist die Kurzfassung meiner ausführlichen Analyse, die ich am 26. September 2026 auf LinkedIn veröffentlicht habe: Das Protokoll ist fertig. Unsere Systeme nicht. Wer die vollständige Diagnose mit allen Quellen lesen will, findet sie dort. Hier geht es um den Kern: die fünf Brüche, der Bauplan dagegen, und eine unbequeme These zum Schluss.

Ein Agent ist ein neuer Mitarbeiter, und am ersten Tag fehlt alles

Wer eine Cloud-native Anwendung baut, denkt in Schichten: Wer darf rein? Wie kommt man hin? Worüber spricht man? Was darf man verändern? Und wer sorgt dafür, dass nichts Falsches passiert? Niemand nimmt eine App produktiv, bei der eine dieser Schichten fehlt.

Bei Agenten tun wir oft so, als reiche das Protokoll. Dabei ist ein Agent nichts anderes als ein digitaler Mitarbeiter, der quer durch alle Systeme greift. Jeder, der schon einmal einen neuen Kollegen eingearbeitet hat, kennt die Liste: Ausweis, Schlüssel, Telefonnummern der Ansprechpartner, Unterschriftsbefugnis, Einweisung in die Halle.

MCP ist in diesem Bild die gemeinsame Sprache. Wertvoll, aber eben nur die Sprache. Wer seinem neuen Mitarbeiter Deutsch beibringt und ihm dann keinen Ausweis gibt, hat trotzdem niemanden, der arbeitet.

Die fünf Brüche

1. Identität. Auf Protokollebene ist Identität gelöst: OAuth 2.1 und Enterprise-Managed Authorization machen den zentralen Identity Provider zur Steuerzentrale. Die IT legt in Entra ID oder Keycloak fest, welcher Agent im Namen welches Mitarbeiters auf welchen MCP-Server zugreifen darf. Das funktioniert aber nur für Anwendungen, die am Identity Provider hängen. Im Mittelstand hat die Zeiterfassung ein eigenes Login, die Branchensoftware verwaltet Benutzer lokal, und das Lieferantenportal nutzt einen geteilten Account. An jedem dieser Brüche bleiben zwei schlechte Optionen: ein Servicekonto mit breiten Rechten, bei dem im Audit-Log „Bot“ statt eines Namens steht, oder eine Unterbrechung mitten im Vorgang.

2. Schnittstellen. Für die großen SaaS-Dienste gibt es offizielle MCP-Server. Die Lücke liegt bei den Systemen, in denen das eigentliche Geschäft stattfindet: Produktionsplanung, MES, CAQ, PLM, Lagerverwaltung, gewachsene DACH-Branchenlösungen. Darunter liegen Anwendungen ohne jede Schnittstelle. Dann beginnt das Basteln mit MCP-Proxys, CLI-Wrappern oder Browser-Automation, und jede Variante hat ihren Preis. Auch beim ERP-Marktführer bleibt es ein Baustein: Die SAP-API-Policy in Version 4 untersagt seit April 2026 die Nutzung von SAP-APIs durch teilautonome KI-Systeme außerhalb der von SAP unterstützten Wege. Agentenzugang wird damit zur Lizenz- und Plattformfrage, nicht zur Protokollfrage.

3. Netzwerk. Der Agent läuft in der Cloud, das ERP steht im Keller, dazwischen eine Firewall, die aus gutem Grund keine eingehenden Verbindungen erlaubt. Der kontrollierte Weg dazwischen ist technisch kein Hexenwerk, organisatorisch oft ein Projekt für sich. Das größere Problem ist die Segmentierung: In historisch flachen Netzen erreicht ein MCP-Server, der das ERP erreicht, meist auch den Dateiserver und im schlimmsten Fall die Produktion.

4. Die Schreibseite. Fast alle Demos lesen. Der eigentliche Hebel liegt beim Schreiben, und genau dort wird es ernst. Eine Lieferterminänderung ist kein Datenbank-Update, sondern ein Geschäftsvorfall mit Folgen für Disposition, Einkauf und Kunde. MCP liefert Hinweise, keine Garantien: Ein Tool kann sich als „nur lesend“ kennzeichnen, das ist eine Selbstauskunft des Servers, keine Durchsetzung. Ein Chatbot, der etwas Falsches sagt, blamiert sich. Ein Agent, der etwas Falsches bucht, erzeugt eine Gutschrift.

5. Guardrails und Sicherheit. Ein Agent kann Daten nicht zuverlässig von Anweisungen trennen. Für ein Sprachmodell sind Lieferantenmail, PDF-Anhang und Tool-Antwort einfach Text, und Text kann Befehle enthalten. Prompt Injection führt die OWASP-Liste für LLM-Anwendungen an. Dazu kommt die Lieferkette: Im September 2025 wurde mit dem npm-Paket postmark-mcp der erste bösartige MCP-Server in freier Wildbahn entdeckt, der jede versendete E-Mail in Blindkopie an den Angreifer schickte. Und die Rechtevergabe: Ein MCP-Server, der mit eigenen breiten Rechten statt mit denen des Anwenders arbeitet, wird zum Confused Deputy.

In der Werkhalle gelten noch einmal andere Gesetze. Steuerungen, die zwanzig Jahre alt sind, Echtzeit statt „irgendwann“, Zonen nach IEC 62443. Unsere Haltung für die OT ist nüchtern: Ein Agent darf die Maschine beobachten, lange bevor er sie bedienen darf.

Der Bauplan: fünf Bauteile

Für jeden Bruch gibt es ein erprobtes Muster. Keines davon ist exotisch, die meisten kennt jeder, der schon einmal eine Cloud-native Plattform betrieben hat. Neu ist nur, dass man sie konsequent für Agenten zu Ende denkt.

1. Identität als Fundament. Jede Anwendung ohne SSO kommt auf eine Liste und wird per OIDC oder SAML angebunden. Handelt ein Agent im Auftrag eines Menschen, reist dessen Identität mit, und jede Anfrage wird gegen dessen Rechte geprüft. Tokens gelten nur für das System, für das sie ausgestellt wurden.
2. Werkzeuge nach Geschäftsvorfall, nicht nach Datenbanktabelle. „Lieferstatus prüfen“ statt „Tabelle AUFTRAG lesen“. Welche Felder ein Agent sieht, entscheidet die Fachabteilung. Klein starten: ein Server vor dem wichtigsten Fachsystem, wenige streng lesende Werkzeuge.
3. Ein Kontrollpunkt für alle Agenten. Der gesamte Agentenverkehr läuft über ein zentrales Gateway: Authentifizierung, Richtlinien, Audit, Rate-Limits und Kosten an einer Stelle. MCP-Server stehen in einer eigenen Netzzone, jeder Aufruf wird nach den OpenTelemetry-Konventionen für GenAI protokolliert.
4. Guardrails in die Infrastruktur, nicht in den Prompt. Richtlinien werden deterministisch durchgesetzt: welche Rolle welches Werkzeug mit welchen Parametergrenzen nutzen darf. Die gefährliche Dreierkombination wird bewusst aufgebrochen. MCP-Server kommen nur aus einem geprüften Katalog mit fester Version.
5. Autonomie als Stufenleiter. Schreibrechte werden nicht erteilt, sondern verdient: lesen, Entwürfe vorbereiten, schreiben nach Freigabe, selbstständig schreiben innerhalb klarer Grenzen.

Nichts davon ist Magie. Es ist Platform Engineering, konsequent zu Ende gedacht für einen neuen Typ von Kollegen.

Genau diesen Kontrollpunkt aus Bauteil drei und vier bauen wir mit dem AI Gateway: eine Infrastrukturkomponente im eigenen Cloud-Tenant, die Identität aus Entra ID oder Keycloak übernimmt, Budgets je Kostenstelle durchsetzt, Guardrails vor Modell- und MCP-Aufrufe legt und jeden Vorgang nachvollziehbar macht. Und damit Agenten nicht neben der Organisation entstehen, sondern in ihr, gehört dazu ein eigener KI-Stack statt einzelner Tools. Bei uns heißt dieser Stack CompanyGPT, betrieben in Ihrem Azure-Tenant oder souverän auf STACKIT.

Wenn keine Brücke hält: neu bauen, agentenfähig ab Tag eins

Ist das mit Coding-Agenten nicht in ein paar Tagen erledigt? Einen MCP-Proxy für eine OpenAPI-Schnittstelle baut man heute an einem Nachmittag. Nur beantwortet ein Prototyp die Frage „Geht das?“. Produktion beantwortet andere Fragen: Wer betreibt den Proxy, wenn der Hersteller seine API ändert? Wer hat entschieden, dass dieser Agent diese Buchung auslösen darf? Was steht im Audit, wenn die Wirtschaftsprüfung fragt?

Bei manchen Systemen gibt es nichts mehr, woran man eine Brücke befestigen könnte. Wir bauen derzeit für mehrere Kunden neue Kernsysteme, deren Vorgänger auf ungewartetem PHP oder auf Visual Basic 6 laufen, dessen Entwicklungsumgebung Microsoft seit April 2008 nicht mehr unterstützt. Der Big-Bang-Rewrite ist dabei genau der Fehler, den man nicht machen sollte. Was funktioniert, ist der schrittweise Umbau, Modul für Modul, während das Altsystem weiterläuft. Coding-Agenten lesen den alten Code, den niemand mehr versteht, und machen die versteckten Geschäftsregeln sichtbar. Tests halten das heutige Verhalten fest, bevor irgendetwas neu geschrieben wird.

Der entscheidende Unterschied liegt im Zielbild: zentrale Anmeldung über den Identity Provider, API-first statt Oberfläche-first, jede fachliche Funktion als sauber beschriebenes Werkzeug über MCP, schreibende Operationen mit Freigaben und Idempotenz. Die fünf Schichten sind dann keine Nachrüstung, sondern Teil der Architektur. Vibe Coding baut Prototypen. AI-native Engineering baut Kernsysteme, die Agenten tragen.

Die unbequeme These: Der Medienbruch ist Deutschlands heimlicher Kündigungsschutz

Nimmt man alle Schichten zusammen, landet man bei einer Schlussfolgerung, die niemand gern ausspricht: Unsere halbfertige Digitalisierung schützt gerade mehr Arbeitsplätze vor KI als jede Regulierung.

Ein Agent kann nur automatisieren, was er Ende-zu-Ende erreicht. Überall dort, wo zwischen zwei Systemen ein Mensch sitzt, der Daten abtippt oder eine PDF-Bestellung ins ERP überträgt, ist dieser Mensch die Schnittstelle. Die Zahlen passen ins Bild: Laut KfW-Digitalisierungsbericht haben im Zeitraum 2022 bis 2024 nur noch 30 Prozent der Mittelständler ein Digitalisierungsprojekt abgeschlossen. Gleichzeitig erwarteten in einer ifo-Umfrage vom Sommer 2025 rund 27 Prozent der Unternehmen KI-bedingten Stellenabbau in den nächsten fünf Jahren. Die Absicht ist da. Die Leitungen fehlen.

Nur: Das ist eine Schonfrist, kein Schutz. Der Wettbewerb wartet nicht. Die Demografie arbeitet gegen uns, das IAB rechnet in seinem KI-Szenario mit rund 800.000 wegfallenden und ebenso vielen neu entstehenden Arbeitsplätzen innerhalb von 15 Jahren, die Arbeit verschiebt sich. Und die Lücken schließen sich mit jeder Spezifikationsrunde. Der Medienbruch rettet heute Arbeitsplätze. In fünf Jahren kostet er sie. Ehrliche Führung heißt, diese Zeit zu nutzen: für Qualifizierung, für neue Rollen, und dafür, dass Menschen die Agenten steuern, statt von ihnen ersetzt zu werden.

Was Sie jetzt tun sollten

Agentenfähigkeit ist kein KI-Projekt, sondern ein Infrastrukturprojekt. Vier Schritte für die nächsten 90 Tage:

1. Die Landkarte zeichnen. Für die zehn wichtigsten Systeme vier Fragen: Hängt es am SSO? Gibt es eine API oder einen MCP-Server? Darf man darüber schreiben? In welcher Netzzone steht es?
2. Einen Vorgang Ende-zu-Ende bauen. Ein Anwendungsfall, lesend, über einen zentralen Kontrollpunkt, mit echter Identität und Audit. Nicht zehn Piloten, sondern ein Durchstich durch alle fünf Schichten.
3. Pro Altsystem entscheiden: flicken oder neu bauen. Und bei jeder anstehenden Migration die Agentenfähigkeit als Anforderung aufnehmen.
4. KI unter die eigene Kontrolle bringen. Copilot oder eine SaaS-App ist keine KI-Strategie. Unternehmen brauchen langfristig ihren eigenen KI-Stack, nicht nur Werkzeuge, die die Schatten-KI eindämmen.

Der Engpass ist nicht das Modell. Der Engpass ist auch nicht mehr das Protokoll. Der Engpass ist die Frage, ob Ihre Systeme einen neuen Kollegen überhaupt einarbeiten können.

Weiterlesen

Die vollständige Analyse mit allen Quellen, dem Abschnitt zur Werkhalle und dem Bauplan im Detail steht auf LinkedIn: Das Protokoll ist fertig. Unsere Systeme nicht.

Meine Gedanken zu KI-Agenten, eigenem KI-Stack und dem Weg dorthin habe ich außerdem mithilfe von KI als Buch zusammengefasst: Das agentische Unternehmen: Wie der Mittelstand mit KI-Agenten handlungsfähig wird – von den Grundlagen der Sprachmodelle über die Referenzarchitektur für den Mittelstand, Sicherheit, Recht und Governance bis zum Zwölf-Monats-Fahrplan vom Piloten zur Fläche, mit über 130 Quellen belegt. Erhältlich bei Amazon als Taschenbuch, gebundenes Buch und für Kindle.

Passende Beiträge aus unserem Blog:

• AI Harness erklärt: die sieben Bausteine, die aus einem Modell einen Agenten machen
• AI Gateway: Kostenkontrolle, Guardrails und Identität im eigenen Tenant
• CompanyGPT: der eigene KI-Stack für Fachanwender

Wo reißt in Ihrer Systemlandschaft die Kette zuerst? Wir zeichnen die Landkarte gemeinsam mit Ihnen und bauen den ersten Durchstich. Sprechen Sie uns an.