Ein Industriehändler mit 40 Mitarbeitenden hatte innerhalb einer Woche einen funktionierenden KI-Agenten für Offerten. Er las eine eingehende Bestellanfrage, glich die Positionen mit einer Preisliste ab und entwarf eine Offerte, die versandfertig aussah. Der Verkaufsleiter war auf der Stelle überzeugt. Acht Monate später lag der Agent immer noch in einem Testordner, und das Team offerierte auf dieselbe Weise wie seit einem Jahrzehnt.
Am Modell lag es nicht. Das Reasoning hielt stand, und jede Beispielanfrage, die der Entwickler ihm vorlegte, kam sauber zurück. Was der Agent noch nicht geleistet hatte: den Kontakt mit dem echten Geschäft überleben. Das ERP, das er abfragen musste, die Preisausnahmen, die niemand aufgeschrieben hatte, und ein Verkaufsteam, das einem Kunden keine Zahl schicken würde, für die es nicht geradestehen konnte.
Diese Lücke hat inzwischen einen Namen: das Last-Mile-Problem der KI. Es ist die Distanz zwischen einem Modell, das in der Demo überzeugt, und einem System, das ein Unternehmen unbeaufsichtigt auf echter Arbeit laufen lässt. Die meisten KI-Projekte, die still im Sand verlaufen, haben ein Modell, das seinen Job macht. Sie scheitern an allem, was danach passieren muss.
Die Zahl, die alle zitieren, und was sie tatsächlich misst
Eine vielzitierte MIT-Studie hat dieses Muster beziffert: Rund 95 % der generativen KI-Piloten in Unternehmen zeigten keinen messbaren Effekt auf die Erfolgsrechnung. Der Bericht führte den Misserfolg auf eine «Lernlücke» bei der Einführung und Integration der Tools zurück, nicht auf schwache Modellqualität.
Die Zahl verbreitete sich schnell, der Widerspruch auch. Der meiste zielte auf die Methodik: Die Untersuchung stützte sich auf einige hundert Interviews und eine Auswertung öffentlicher Deployments, Begriffe wie «Pilot» und «P&L-Effekt» wurden nie scharf definiert, und eine Studie, die nur den unmittelbaren finanziellen Ertrag misst, unterschätzt Fortschritte in Workflows, in denen sich der Nutzen zuerst als weniger Fehler oder kürzere Durchlaufzeiten zeigt, bevor er in einer Erfolgsrechnung ankommt. Behandeln Sie die 95 % als groben Hinweis darauf, wo KI-Projekte stecken bleiben, nicht als gesicherte Tatsache für das nächste Board-Deck.
Was die Kritik überlebt, ist die Richtung des Befunds, und sie deckt sich mit dem, was in der Praxis immer wieder sichtbar wird. Der Engpass hat selten damit zu tun, ob das Modell die Aufgabe grundsätzlich beherrscht. Es geht fast immer um alles, was nötig ist, damit das Modell diese Aufgabe sicher und wiederholbar erledigen kann, in Systemen, die es lange vor der ersten KI-Lizenz schon gab.
Diese Lücke zu schliessen ist in der Regel anhaltende Ingenieursarbeit, eingebettet in den laufenden Betrieb eines Unternehmens, kein einmaliges Deployment-Ereignis. Genau das ist die Prämisse hinter einem Embedded-AI-Engineering-Service: eine technische Präsenz, die im Workflow bleibt, bis sich das System bezahlt macht, statt eines einmaligen Builds.
Was «das Modell funktioniert» nicht aussagt
Eine Demo beantwortet eine einzige Frage: Kann das Modell aus sauberen, wohlgeformten Eingaben eine gute Ausgabe erzeugen? Das ist ein echtes, nützliches Signal. Es ist aber nur ein kleiner Ausschnitt dessen, was Produktion verlangt.
Das hier liegt zwischen einer funktionierenden Demo und Software, der ein Unternehmen den unbeaufsichtigten Betrieb zutraut:
- Führende Systeme. Das Modell braucht live und authentifiziert Zugriff auf das, was die Wahrheit enthält: das ERP, das CRM, die Preisdatenbank, die Dokumentenablage. Die meisten dieser Systeme haben APIs, aber die Abdeckung ist ungleich, Rate Limits sind real, und «hat eine API» ist nicht dasselbe wie «ein Agent kann die nötigen Daten zuverlässig lesen und schreiben».
- Der unordentliche Rest realer Anfragen. Nennen Sie es die unordentlichen 20 Prozent, eine grobe Faustregel, keine gemessene Zahl: fehlerhaft formatierte Eingaben, mehrdeutige Positionen und Randfälle, die ein kuratiertes Demo-Set nie zutage fördert, die aber ständig auftauchen, sobald echtes Volumen kommt.
- Eine Evaluationssuite. Ein dokumentierter, wiederholbarer Weg, die Frage «funktioniert das noch?» zu beantworten, jenseits des Bauchgefühls nach ein paar Stichproben.
- Berechtigungen und Sicherheit. Ein Service-Account mit genug Zugriff für die Aufgabe und keinem Bit mehr, geprüft von der Stelle, die Sicherheit verantwortet, mit einer klaren Antwort darauf, was passiert, wenn der Agent Daten berührt, die er nicht berühren sollte.
- Passung in den Workflow. Der Agent muss sich in die heutige Arbeitsweise einfügen: Wer prüft seine Ausgaben, an welcher Stelle im Prozess, und was passiert, wenn er falsch liegt.
- Vertrauen der Mitarbeitenden. Der am schwersten planbare Punkt. Wer sich an einer falschen Zahl oder einem Tool, das zu viel versprach, schon die Finger verbrannt hat, gibt Ermessensentscheide nicht ab, nur weil das Engineering sagt, die Genauigkeitsmetrik sehe gut aus.
Jeder dieser Punkte kann ein Projekt für sich allein aufhalten. In der Praxis verstärken sie sich gegenseitig: Die Reparatur der ERP-Integration legt Datenqualitätsprobleme offen, das verändert, was die Eval-Suite prüfen muss, und das wiederum verändert, was das Verkaufsteam ohne Review zu akzeptieren bereit ist.
Warum generische Chatbots und Copilots von der Stange genau hier stecken bleiben
Das ist auch der Grund, warum eine Lizenz für einen Allzweck-Chatbot oder einen Copilot von der Stange die Lücke selten allein schliesst. Diese Tools lösen die Modellhälfte der Gleichung und überlassen die andere Hälfte komplett Ihnen.
| Generischer Chatbot / Copilot | Ein System, das die letzte Meile geschlossen hat | |
|---|---|---|
| Zugriff auf Ihre führenden Systeme | Meist keiner oder ein oberflächliches Plugin | Authentifizierter, eng gefasster Zugriff, gebaut für den konkreten Workflow |
| Umgang mit Randfällen | Weicht auf eine plausibel klingende Vermutung aus | Markiert, was er nicht weiss, und eskaliert |
| Evaluation | Vendor-Benchmarks auf generischen Aufgaben | Eine Testsuite aus Ihren eigenen historischen Fällen |
| Sicherheit und Berechtigungen | Standardmässig breite, generische Scopes | Least-Privilege-Zugriff, geprüft von Ihrem IT-Team |
| Vertrauen der Mitarbeitenden | Nirgendwo konkret verdient | An Ihren eigenen Daten verdient, vor dem Go-live |
Ein generischer Assistent kann eine plausibel klingende Offerte schreiben. Er hat keine Möglichkeit, diese Offerte gegen Ihre Preisliste, Ihren aktuellen Lagerbestand oder den Rabatt zu prüfen, den Ihre Finanzabteilung letztes Quartal für genau dieses Kundenkonto freigegeben hat. Er kann Ihnen nicht sagen, wann er rät. Die Lücke liegt in dem, wofür ein generisches Produkt gebaut ist; mit der Qualität des Reasonings hat sie wenig zu tun.
Ein Händler mit 40 Mitarbeitenden lernt den Unterschied auf die harte Tour
Zurück zum Offerten-Agenten vom Anfang. Das Unternehmen ist ein Komposit, zusammengesetzt aus Mustern, die bei ähnlich grossen Händlern bei der Automatisierung des Offerteneingangs immer wieder auftreten, und es zeigt, wie die Sechs-Punkte-Liste oben in einem echten Projekt durchschlägt.
Die Demo kostete einen Entwickler rund eine Woche, und sie war gut: saubere Extraktion der Spezifikationen aus einer Kunden-E-Mail, ein korrekt formatierter Entwurf, plausible Preise auf der Handvoll Beispielanfragen, mit denen sie gebaut worden war.
Dann traf das Projekt auf das echte Geschäft, auf vier verschiedene Arten.
Die Preisliste hatte Ausnahmen, die niemand dokumentiert hatte. Rund ein Fünftel der echten Anfragen betraf eine ausgelaufene SKU mit einem informellen Ersatzartikel, einen regionalen Frachtzuschlag, der je nach Sachbearbeiter unterschiedlich angewendet wurde, oder einen Bündelrabatt, an den sich der eine Verkäufer erinnerte und der andere nicht. Nichts davon stand in der Master-Preisliste, gegen die die Demo gebaut worden war.
Die ERP-Integration war das eigentliche Projekt. Aktuelle Preise und Lagerbestände lebten in einem ERP-System, nicht in der exportierten Tabelle, die für die Demo herhalten musste. Die Anbindung bedeutete: Felder mappen, API-Rate-Limits aushandeln und mit der Tatsache umgehen, dass ein gecachter Preis still von dem abweichen konnte, was das ERP eine Minute später zeigte.
Das Verkaufsteam traute dem Agenten nicht, und das mit gutem Grund. Die Verkäufer hatten sich schon einmal an einem Pricing-Tool die Finger verbrannt, das einem Kunden eine falsche Zahl geschickt hatte. Sie wollten jeden Entwurf sehen und freigeben, bevor er einen Kunden erreichte, und sie wollten eine einfache Möglichkeit, alles zu übersteuern, was verdächtig aussah. Das Design musste diese Anforderung als legitime Kontrolle behandeln, nicht als Reibung, die es wegzuautomatisieren galt.
Das Eval-Set entstand aus 200 historischen Offerten. Statt sich auf «sieht für mich gut aus» zu verlassen, zog das Team 200 echte frühere Offerten heran, schwärzte die Kundendaten und nutzte sie als Baseline: Reproduziert der Agent dieselbe Preislogik, erkennt er dieselben Ausnahmen, markiert er dieselben Positionen, die auch ein Mensch markiert hätte? Dieses Testset, mehr als die ursprüngliche Demo, brachte den Verkaufsleiter schliesslich dazu, den Betrieb ohne Review-Schritt für die einfachste Offertenkategorie freizugeben.
Der Agent, der Monate später endlich live ging, lief auf demselben Modell wie die Demo aus Woche eins. Der Unterschied war alles darum herum: eine ERP-Anbindung, eine dokumentierte Ausnahmeliste, ein Freigabe-Workflow, den das Verkaufsteam verlangt hatte, und eine Testsuite aus der eigenen Firmengeschichte. Die Demo war nie der schwierige Teil.
Was es tatsächlich braucht, um die letzte Meile zu schliessen
Ein paar Praktiken tauchen in den Projekten, die diese Lücke überwinden, immer wieder auf.
Eval-First-Entwicklung. Bauen Sie den Test vor dem Feature. Hamel Husain argumentiert, dass Teams, die diesen Schritt überspringen, am Ende nicht mehr sagen können, ob eine Änderung das System besser oder schlechter gemacht hat, und jede weitere Entscheidung wird zum Ratespiel. Ein repräsentatives Sample echter historischer Fälle zu ziehen und zu definieren, wie eine korrekte Antwort aussieht, bevor die Agentenlogik geschrieben wird, verändert den gesamten Bauprozess: Sie bauen auf ein messbares Ziel hin statt auf eine Demo, die bloss überzeugend aussieht.
Context Engineering mit echten Unternehmensdaten. Anthropic beschreibt Context Engineering als das Kuratieren der Informationen, die einem Modell zur Inferenzzeit zur Verfügung stehen, im Unterschied zum blossen Schreiben eines guten Prompts. Auf ein Geschäftssystem angewendet heisst das: das Modell in Ihren eigenen Preislisten, der früheren Korrespondenz und der Kundenhistorie verankern statt in seinem allgemeinen Trainingswissen, und bewusst entscheiden, was es sieht und was nur Rauschen wäre.
Hybride Architekturen. Die zuverlässigsten Systeme verlangen von einem Sprachmodell nicht, harte Geschäftsregeln durchzusetzen. Eine Preisuntergrenze, eine Freigabeschwelle, eine Compliance-Anforderung: Das gehört in deterministischen Code, der besteht oder scheitert, ohne Interpretationsspielraum. Der Job des Modells ist der Teil, der echtes Urteilsvermögen verlangt, etwa eine mehrdeutige Anfrage lesen oder einen Textentwurf für die menschliche Prüfung schreiben. Die klare Trennung der beiden macht das Verhalten eines Agenten vorhersehbar genug, um ihm bei Volumen zu vertrauen.
Jemand, der organisatorisch nah an der Arbeit ist. Spezifikationen übersehen Dinge. Die Person, die jeden Tag Frachtzuschläge verarbeitet, kennt eine Ausnahme, die im Anforderungsdokument nie erwähnt wird, und das in Woche zwei herauszufinden ist deutlich günstiger, als es nach dem Go-live herauszufinden. Erfolgreiche Projekte haben meist jemanden, ob eingebettete Mitarbeitende oder ein Vendor-Engineer vor Ort beim Team, der nah genug am Workflow selbst ist, um eine solche Lücke zu erkennen, bevor sie zum Produktionsvorfall wird.
Nichts davon ist exotisch. Es ist näher an disziplinierter Software-Engineering-Praxis als an irgendetwas, das spezifisch für grosse Sprachmodelle wäre. Der Unterschied: KI-Projekte überspringen diese Schritte oft, weil die Demo schon so überzeugend aussah, dass das Überspringen sicher wirkte.
Warum daraus immer wieder dasselbe Liefermodell entsteht
Schauen Sie, wohin die Anbieter mit der grössten Erfahrung im Enterprise-KI-Deployment ihr Geld gelenkt haben, und ein Muster wird sichtbar. Im Juni 2026 hat AWS eine Milliarde Dollar für ein Forward-Deployed-Engineering-Programm zugesagt und bettet Engineers direkt bei Kunden und den Partnern ein, die sie betreuen, um genau solche Integrationslücken zu schliessen. Salesforce hat sich verpflichtet, ein Team von 1.000 dedizierten Engineers für seine Agentforce-Linie aufzubauen, aus demselben Grund. OpenAI hat 2025 eine ähnliche Funktion in der eigenen Organisation formalisiert.
Das ist kein Zufall. Wenn der schwierige Teil eines KI-Projekts Systemintegration, Randfallbehandlung und das Vertrauen der Mitarbeitenden ist, nicht Modellqualität, dann muss das Liefermodell Engineers so lange nah am Unternehmen halten, bis dieses Vertrauen verdient ist, und das dauert deutlich länger als der Bau einer Demo. Das ist ein anderes kommerzielles Arrangement als Software ab Regal, und es lohnt sich, es als eigenes Modell zu verstehen: Was ist ein Forward-Deployed Engineer? erklärt, wie diese Rolle und dieses Liefermodell tatsächlich funktionieren.
Diese Diagnose ist zugleich enger gefasst als die breitere Frage, warum KI-Agenten-Projekte überhaupt scheitern. Viele Projekte bringen nie auch nur ein funktionierendes Modell in eine echte Demo, aus Gründen, die mit der letzten Meile nichts zu tun haben: undefinierter Scope, kein Owner auf der Business-Seite, keine vor dem Build vereinbarte Erfolgsmessung. Warum KI-Agenten-Projekte scheitern behandelt dieses Risiko auf Projektebene samt Checkliste. Dieser Artikel setzt voraus, dass Sie diese Hürde genommen haben, und stellt die nächste Frage: Ihr Modell funktioniert, warum steuert es dann noch nicht das Geschäft? Die Antwort sind fast jedes Mal die sechs Dinge zwischen Demo und Produktion, und irgendjemand muss diese Arbeit tatsächlich machen.
Häufige Fragen
Was ist das Last-Mile-Problem der KI?
Es ist die Lücke zwischen einem KI-Modell, das in einer Demo oder einem Proof of Concept überzeugt, und einem System, das zuverlässig in den tatsächlichen Workflows eines Unternehmens läuft. Das Reasoning des Modells stimmt meist schon, wenn die Demo steht; was fehlt, sind die Anbindung an echte Systeme, der Umgang mit unsauberen Randfällen, eine Evaluationssuite, saubere Berechtigungen, die Passung in den Workflow und das Vertrauen der Mitarbeitenden. Diese Lücke zu schliessen ist ein Software- und Organisationsprojekt, kein Modellierungsproblem.
Stimmt es, dass 95 % der KI-Piloten scheitern?
Eine vielzitierte MIT-Studie berichtete, dass rund 95 % der generativen KI-Piloten in Unternehmen keinen messbaren Effekt auf die Erfolgsrechnung zeigten, und führte das vor allem auf Integrationslücken statt auf Modellqualität zurück. Stichprobe und Definitionen der Studie wurden von anderen Forschenden infrage gestellt; behandeln Sie die Zahl deshalb als Richtungssignal dafür, wo KI-Projekte stecken bleiben, nicht als präzisen Branchen-Benchmark.
Warum bleiben generische KI-Chatbots oder Copilots von der Stange im Arbeitsalltag hinter den Erwartungen zurück?
Sie kommen ohne jedes Wissen über die Preislisten, führenden Systeme, Ausnahmeregeln oder Freigabeprozesse eines konkreten Unternehmens. Ein generischer Assistent kann plausibel klingende Texte entwerfen, aber er kann keine Zahl gegen Ihr ERP prüfen, keine Anfrage markieren, die ausserhalb Ihrer Rabattpolitik liegt, und nicht das Vertrauen eines Teams gewinnen, das sich schon einmal an einer falschen Antwort die Finger verbrannt hat.
Was braucht es konkret, um die letzte Meile der KI zu schliessen?
In der Praxis: eine Evaluationssuite aus echten historischen Fällen, bevor der Agent neue anvertraut bekommt, Context Engineering, das das Modell in Ihren eigenen Daten verankert statt in generischem Wissen, eine hybride Architektur, in der deterministischer Code harte Regeln durchsetzt und das Modell Ermessensfragen übernimmt, sowie jemand, der nah genug am Tagesgeschäft ist, um zu erkennen, was ein Pflichtenheft übersieht.
Worin unterscheidet sich das Last-Mile-Problem von einem schlicht schlecht gescopten KI-Projekt?
Die beiden überlappen sich, sind aber nicht derselbe Fehler. Schlechtes Scoping ist ein organisatorisches Risiko, das ein Projekt versenken kann, bevor eine einzige Zeile Code ausgeliefert ist. Das Last-Mile-Problem setzt voraus, dass Scope und Modell vernünftig sind, und stellt eine engere Frage: Warum braucht ein technisch funktionierendes Modell trotzdem Monate, bis es Software ist, die das Unternehmen tatsächlich unbeaufsichtigt laufen lässt.