Die letzte Meile der KI: Warum Pilotprojekte an der Integration scheitern und wie man sie absichert

Was mit „Last Mile" gemeint ist

Der Begriff "Last Mile" ist aus dem Bereich WAN nicht weg zu denken und er passt auch hier. Er stammt aus der Logistik: Der Transport über tausend Kilometer ist effizient, die letzten Meter bis zur Haustür sind teuer und fehleranfällig. Bei KI verhält es sich ähnlich. Das Modell ist die Fernstrecke, die jemand anderes gebaut und bezahlt hat. Die letzte Meile ist alles dazwischen: das Werkzeug, mit dem das Modell ein Ticket anlegt, die Datenbank, aus der es Kontext zieht, das Konto, unter dem es handelt, der Mensch, der das Ergebnis übernimmt, und die Protokolle, die hinterher belegen, was passiert ist.

Wichtig ist die Verschiebung, die in den letzten zwei Jahren stattgefunden hat. Solange KI nur Text produzierte, war das Risiko auf falsche Antworten begrenzt. Sobald Assistenten Werkzeuge aufrufen, in Systemen schreiben und Folgeaktionen auslösen, wird aus einem Textgenerator ein Akteur mit Zugangsdaten. OWASP hat dafür Ende 2025 eine eigene Risikoliste für agentische Anwendungen veröffentlicht, die neben der klassischen Prompt Injection vor allem Zielübernahme, Werkzeugmissbrauch, Identitäts- und Rechtemissbrauch sowie Vergiftung von Gedächtnis und Kontext benennt. Alle diese Risiken entstehen nicht im Modell, sondern auf der letzten Meile.

Wo die Schwierigkeiten tatsächlich liegen

Der Agent hat keine eigene Identität

In den meisten Pilotprojekten läuft der Assistent unter dem Konto des Entwicklers oder mit einem Dienstkonto, das „vorübergehend" weitreichende Rechte erhalten hat. Für den Test ist das bequem, in Produktion ist es ein Blindfleck. Kein Zugriff lässt sich später einer KI-Aktion zuordnen, keine Berechtigung lässt sich gezielt entziehen, und ein kompromittierter Prompt erbt automatisch alle Rechte des Menschen dahinter. Erhebungen aus dem Frühjahr 2026 zeigen, dass nur ein Bruchteil der Organisationen vollständige Sicht darauf hat, welche Agenten mit welchen Systemen sprechen. Daraus folgt, dass Unternehmen mit durchgesetztem Least Privilege für Agenten deutlich seltener Vorfälle melden als solche ohne.

Untrusted Content wird zu vertrauenswürdigen Aktionen

Ein Modell unterscheidet nicht zwischen Anweisung und Inhalt. Eine E-Mail, ein PDF, eine Webseite oder ein Datenbankfeld kann Text enthalten, der wie ein Befehl aussieht, und das Modell führt ihn aus, wenn es die Möglichkeit dazu hat. Bei einem reinen Chat ist das ärgerlich. Bei einem Agenten, der Mails senden, Dateien verschieben oder Bestellungen freigeben kann, ist es ein vollständiger Angriffspfad ohne Schadcode, ohne Exploit und ohne Anmeldung. Die dokumentierten Vorfälle aus 2025 und 2026 folgen fast alle diesem Muster: Präparierte Inhalte gelangen in den Kontext, der Agent handelt in fremdem Auftrag.

Werkzeuganbindung als neue Lieferkette

Mit dem Model Context Protocol (MCP) hat sich ein Standard etabliert, über den Assistenten Werkzeuge und Datenquellen erreichen. Das beschleunigt die Integration erheblich, verlagert aber ein bekanntes Problem an eine neue Stelle: Jeder MCP-Server ist ein Stück Software mit eigener Herkunft, eigenen Rechten und eigener Beschreibung, die das Modell liest und befolgt. Ein manipulierter oder schlicht schlecht gebauter Server kann dem Modell Anweisungen unterschieben („Tool Poisoning"), Daten mitlesen oder Aktionen ausführen, die nie beabsichtigt waren. In der Praxis werden solche Server oft von Fachbereichen aus öffentlichen Repositories geholt, ohne dass sie je durch eine Freigabe gegangen sind.

Schatten-KI entsteht aus Reibung

Wo die offizielle Lösung zu langsam oder zu eingeschränkt ist, greifen Mitarbeitende zu eigenen Werkzeugen, Browser-Erweiterungen und kostenlosen Diensten. Die Daten sind dann außerhalb jeder Kontrolle, und der Vorfall wird erst entdeckt, wenn er bereits eingetreten ist. Blanke Verbote verstärken diesen Effekt eher, als dass sie ihn eindämmen.

Kontext und Gedächtnis als Datenspeicher

Assistenten, die sich Gespräche und Zwischenergebnisse merken, sammeln über Wochen Kundendaten, interne Entscheidungen und gelegentlich Zugangsdaten an, die jemand in einen Prompt kopiert hat. Ohne definierten Lebenszyklus für dieses Gedächtnis entsteht ein unklassifizierter Datenbestand, den weder das Backup-Konzept noch das Löschkonzept kennt.

Der Mensch am Ende der Kette

Die letzte Meile endet nicht an einer API, sondern bei einer Person, die das Ergebnis übernimmt. Wenn diese Person nicht weiß, wie zuverlässig die Ausgabe ist, wird sie sie entweder ungeprüft durchwinken oder gar nicht nutzen. Beides ist ein Sicherheitsproblem: das eine wegen unbemerkter Fehler, das andere, weil der Prozess dann informell an der Lösung vorbei läuft.

Was der Solution Architect konkret tun kann

Die gute Nachricht: Kein einziges dieser Probleme erfordert eine neue Sicherheitsphilosophie. Es sind die bekannten Zero-Trust-Grundsätze, angewendet auf einen Akteur, der Text liest und daraus Handlungen ableitet. Die folgenden Maßnahmen haben sich in Projekten als tragfähig erwiesen:

1. Jedem Agenten seine eigene, nicht-menschliche Identität

Ein Agent erhält ein eigenes Konto im Identitätsverzeichnis, mit kurzlebigen Token statt statischer API-Schlüssel, mit eigener Gruppenzugehörigkeit und mit einem benannten Verantwortlichen. Handelt er im Auftrag eines Menschen, wird die Delegation abgebildet („Agent X handelt für Nutzerin Y") und nicht die Identität geteilt. Damit werden Zugriffe zuordenbar, Rechte entziehbar und Audit-Fragen beantwortbar.

2. Ein Gateway zwischen Modell und Werkzeugen

Anstatt jeden Agenten direkt mit jedem System zu verbinden, laufen alle Werkzeugaufrufe über eine zentrale Vermittlungsschicht. Dort werden Authentifizierung, Autorisierung auf Werkzeug- und Parameterebene, Rate Limits und Protokollierung an einer Stelle durchgesetzt. Bei fünfzig Agenten und zwanzig Zielsystemen sind das sonst bis zu tausend einzeln zu pflegende Integrationspunkte, mit Gateway sind es fünfzig plus zwanzig. Das ist zugleich der Ort, an dem Ein- und Ausgaben auf bekannte Injektionsmuster geprüft werden können, ohne dass die Fachanwendung davon etwas wissen muss.

3. Werkzeuge als Allowlist, nicht als Bibliothek

Jeder Agent bekommt genau die Werkzeuge, die sein Anwendungsfall braucht, mit möglichst engem Zuschnitt: „Ticket im Projekt A anlegen" statt „Ticketsystem-Vollzugriff". Lesende und schreibende Werkzeuge werden getrennt, MCP-Server werden wie jede andere Softwarekomponente behandelt: mit Herkunftsprüfung, Versionsfixierung, Prüfung der Werkzeugbeschreibungen auf versteckte Anweisungen und einem Freigabeprozess, bevor sie an ein produktives Modell angeschlossen werden.

4. Irreversible Aktionen brauchen einen Menschen

Alles, was Geld bewegt, Daten löscht, nach außen kommuniziert oder Berechtigungen ändert, wird vom Agenten vorbereitet, aber von einer Person bestätigt. Das ist keine Notlösung, sondern die Antwort auf die Tatsache, dass Prompt Injection nicht zuverlässig verhindert werden kann. Entscheidend ist, dass die Bestätigung informiert erfolgt: Der Mensch sieht, welche Aktion mit welchen Parametern auf Basis welcher Quelle ausgelöst werden soll, nicht nur ein „OK?".

5. Ausgaben validieren, bevor sie Wirkung entfalten

Modellausgaben werden nie direkt in Shell-Befehle, SQL-Abfragen, Code-Interpreter oder Freigabe-Workflows gegeben. Zwischen Modell und Wirkung sitzt eine Schema-Prüfung mit strengem Format, Werteprüfung und Fehlerpfad. Was nicht dem erwarteten Schema entspricht, wird verworfen und protokolliert.

6. Die KI-Laufzeitumgebung als eigene Zone

Aus Netzwerksicht ist ein Agenten-Backend ein System mit hoher Exposition (es verarbeitet fremde Inhalte) und hohem Wirkungspotenzial (es hat Zugangsdaten). Es gehört daher in ein eigenes Segment mit kontrolliertem Ausgang. Erlaubt werden ausgehende Verbindungen nur zu den freigegebenen Modell-Endpunkten und dem Gateway, keine direkten Verbindungen in Fachnetze, keine ausgehenden Verbindungen ins offene Internet „weil das Modell vielleicht mal suchen will". Datenabfluss über einen kompromittierten Agenten scheitert dann an der Zonengrenze, nicht erst am Zufall. Für OT-Umgebungen gilt das doppelt: Ein Assistent, der Anlagendaten auswertet, liest aus einer Historian-Kopie in der DMZ, nie aus dem Zellnetz.

7. Gedächtnis und Kontext mit Lebenszyklus

Was ein Agent speichert, wird klassifiziert, mit Aufbewahrungsfrist versehen und in den Löschprozess eingebunden. Zugangsdaten und Personendaten werden vor dem Speichern maskiert. Wer Gesprächsverläufe zur Modellverbesserung nutzt, braucht dafür eine Rechtsgrundlage und eine technische Trennung von den Produktivdaten.

8. Protokollierung, die Fragen beantwortet

Für jede Aktion muss rekonstruierbar sein, welcher Agent, für wen, mit welchem Eingabekontext, welches Werkzeug, welche Parameter und welches Ergebnis. Das ist die Grundlage für die Meldepflichten nach NIS2 (das deutsche Umsetzungsgesetz ist seit Dezember 2025 ohne Übergangsfrist in Kraft) ebenso wie für die Nachweispflichten, die der EU AI Act für Hochrisiko-Anwendungen ab Dezember 2027 verlangt. Die Transparenzpflichten des AI Act nach Artikel 50 gelten bereits seit dem 2. August 2026: Nutzer müssen erkennen können, dass sie mit einer KI interagieren, und generierte Inhalte müssen maschinenlesbar gekennzeichnet sein.

9. Die offizielle Lösung muss die bequemere sein

Gegen Schatten-KI hilft ein freigegebener Zugang, der schnell, in die Arbeitswerkzeuge integriert und mit einer klaren Datenklassifizierung versehen ist. Wer weiß, was er hineinkopieren darf und was nicht, und wer dafür kein Ticket beim IT-Support braucht, nutzt den kontrollierten Weg.

Reihenfolge in der Praxis

Wer heute vor dem Sprung vom Piloten in die Produktion steht, sollte nicht mit dem Kauf von Erkennungswerkzeugen beginnen, sondern mit vier Fragen an die eigene Architektur:

1. Unter welcher Identität handelt der Agent, und wer kann ihm diese Rechte entziehen?
2. Welche Werkzeuge hat er, wer hat sie freigegeben, und welche davon sind irreversibel?
3. Welche fremden Inhalte gelangen in seinen Kontext, und was passiert, wenn darin ein Befehl steht?
4. Wohin kann er Daten senden, und was steht zwischen ihm und dem Fachnetz?

Wer diese vier Fragen beantworten kann, hat die letzte Meile im Griff. Alles Weitere, von Injection-Filtern bis zu Agenten-Inventaren, baut darauf auf. Ohne diese Grundlage bleiben es teure Zusätze für ein Fundament, das nicht trägt. Doch machen wir uns nichts vor: Hier ist und wird im Laufe der KI-Nutzung viel Know-How, auch von Spezialisten, notwendig.