Future{hacks}: Die Demo ist nicht das Projekt: Die Wahl des richtigen AI-Partners
Warum Copilot, Workshop und Chatbot noch keine AI-Umsetzung sind und worauf Unternehmen vor dem Vertrag wirklich achten müssen.
Laut einer Untersuchung des MIT-Projekts NANDA aus 2025 schaffen es nur 5 Prozent der selbst entwickelten Unternehmens-AI-Tools überhaupt in den produktiven Einsatz. Ein Satz aus der Studie bringt es auf den Punkt: Man habe dutzende Demos gesehen, aber nur ein oder zwei seien wirklich brauchbar gewesen, der Rest seien Wrapper oder Science-Projects.
Genau dieses Muster wiederholt sich gerade in unzähligen Verkaufsgesprächen zwischen Mittelstand und AI-Anbietern in der DACH-Region. Die Demo dauert zwanzig Minuten. Ein Anbieter lädt ein paar Dokumente hoch, stellt Fragen dazu, und der Assistent antwortet erstaunlich brauchbar.
Im Raum wird genickt, die Geschäftsführung sieht Geschwindigkeit, und irgendwo fällt der Satz: „Das könnten wir doch eigentlich sofort machen.“ Genau an diesem Punkt beginnt das eigentliche Problem: Die Demo zeigt, was ein Modell kann. Sie zeigt nicht, wer dafür geradesteht, wenn der Assistent im Tagesbetrieb eine falsche Antwort liefert.
Copilot, Workshop und Chatbot sind keine AI-Umsetzung
Sie sind der Teil, der am einfachsten zu zeigen ist, und genau deshalb der Teil, der am wenigsten über Lieferfähigkeit aussagt.
Viele Unternehmen bewerten AI-Anbieter nach der Qualität der Präsentation. Das ist verständlich, aber zu wenig. Die sichtbare Oberfläche ist meist der einfachste Teil. Der schwierige Teil beginnt dort, wo ein Assistent in echte Prozesse, Systeme und Zuständigkeiten eingebaut werden muss.
Ob ein Anbieter das wirklich kann, zeigt sich nicht in der Demo, sondern frühestens in einem eng abgegrenzten Proof of Concept, der unter echten Bedingungen läuft, nicht unter Idealbedingungen. Die entscheidende Frage vorab lautet: Liefert dieser Partner am Ende auch die Implementierung, die er in Aussicht stellt, oder bleibt er bei der Demo stehen?
Gute Berater klären solche Use Cases bereits im Erstgespräch und nennen dabei einen konkreten Zeitrahmen und ein messbares Ziel, keine allgemeinen Erfolgsversprechen.
Der Chatbot beantwortet Fragen. Er löst noch keinen Serviceprozess.
Nehmen wir einen Maschinenbauer, der seinen Service entlasten will. Techniker sollen schneller Antworten zu Wartung, Ersatzteilen und Fehlerbildern finden. Ein Anbieter lädt technische Handbücher in einen Assistenten, stellt typische Fragen und bekommt brauchbare Antworten zurück. Der erste Eindruck ist stark. Endlich muss niemand mehr hunderte Seiten PDF durchsuchen.
Drei Wochen später sieht die Realität anders aus. Die relevanten Informationen liegen nicht nur in Handbüchern, sondern auch im ERP, in Servicehistorien und in einzelnen Dateien. Nicht jede Information darf für jede Rolle sichtbar sein. Und wenn ein Techniker oder Kunde auf Basis einer Antwort handelt, muss klar sein, wer für deren Qualität gerade steht.
Das ist kein Datenproblem im klassischen Sinn, sondern ein Retrieval-Problem: Ein Assistent, der in der Demo saubere PDF-Handbücher durchsucht, trifft im Alltag auf ERP-Datensätze, unvollständige Servicehistorien und Dateien ohne einheitliche Struktur. Die Antwortqualität sinkt dabei nicht graduell, sondern sprunghaft, und in einer zwanzigminütigen Demo merkt das niemand.
Hinzu kommt ein Berechtigungsproblem, das technisch unterschätzt wird: Ein System, das Informationen aus mehreren Quellen zusammenführt, kann unbeabsichtigt Wissen aus einer Quelle in eine Antwort einfließen lassen, für die der Nutzer eigentlich keine Berechtigung hat. Das lässt sich nicht nachträglich filtern. Das muss von Anfang an mitgebaut sein.
Der Assistent kann weiterhin gute Antworten liefern. Nur verändert er damit noch keinen Serviceprozess. Er ist zunächst eine Oberfläche, die Fragen beantwortet. Umsetzung beginnt erst dann, wenn geklärt ist, welche Anfragen tatsächlich schneller bearbeitet werden sollen, auf welche Daten die Lösung zugreifen darf, wie sie in den bestehenden Ablauf passt und wer sie nach dem Pilot betreibt.
Genau dort trennt sich ein Demo-Lieferant von einem Umsetzungspartner. Der eine zeigt, dass ein Modell Inhalte verstehen und formulieren kann. Der andere hilft dem Unternehmen, aus dieser Fähigkeit eine belastbare Verbesserung im Alltag zu machen.
Die falsche Frage lautet: Was könnt ihr uns zeigen?
Demos und Workshops sind nicht wertlos. Sie helfen, Möglichkeiten sichtbar zu machen und Fachbereiche ins Gespräch zu bringen. Problematisch wird es, wenn ein Unternehmen danach annimmt, es hätte schon den richtigen Partner für die gesamte Umsetzung gefunden.
Ein Anbieter kann hervorragende Prototypen bauen und trotzdem nicht der richtige Partner sein, wenn Daten angebunden, Rechte geklärt oder ein System dauerhaft betrieben werden muss. Ein anderes Team kann Integration und Betrieb beherrschen, aber keine gute fachliche Priorisierung machen. Das wird erst zum Problem, wenn ein Anbieter für Aufgaben eingekauft wird, die er gar nicht beherrscht.
Die bessere Frage vor dem Vertrag lautet deshalb nicht: „Was könnt ihr uns zeigen?“ Sie lautet: „Was müsst ihr von uns wissen, damit diese Lösung im Alltag funktioniert?“ Wer darauf nur mit weiteren Screens, Prompts und Funktionslisten antwortet, verkauft wahrscheinlich eine Demo. Wer nach Prozess, Daten, Verantwortlichen und Erfolgskriterien fragt, denkt bereits an die Umsetzung.
Ein guter AI-Partner beginnt nicht mit einem Assistenten. Er beginnt mit dem Prozess, bei dem ein Assistent überhaupt Sinn ergibt. Beim Maschinenbauer wäre das nicht „Wir wollen einen Chatbot für den Service“, sondern etwa: „Wir wollen die Bearbeitungszeit bei Ersatzteilanfragen senken, weil Mitarbeitende heute Informationen aus mehreren Systemen zusammensuchen.“ Erst dann lässt sich prüfen, ob AI überhaupt der richtige Hebel ist und welche Daten, Schnittstellen und Entscheidungen dafür nötig sind.
Ein guter Pilot hat ein Enddatum
Ein Pilot ist eines der nützlichsten Werkzeuge im AI-Einkauf, vorausgesetzt, er wird auch wie einer behandelt. Das Problem beginnt erst dort, wo Unternehmen alles Pilot nennen, was eigentlich nur eine offene Frage ohne Termin ist. Der Assistent wird getestet, ein kleiner Kreis nutzt ihn, einzelne Rückmeldungen sind positiv.
Gleichzeitig bleibt offen, ob die Daten dauerhaft gepflegt werden, wer den Prozess verantwortet und was passieren muss, damit aus dem Test ein echter Teil der Arbeit wird. Das ist kein Pilot mehr. Das ist ein Test ohne Kriterien, der zufällig denselben Namen trägt.
Ein echter Pilot braucht deshalb mehr als eine funktionierende Demo. Er braucht einen klaren Zeitraum, einen abgegrenzten Anwendungsfall und eine Entscheidung am Ende: ausbauen, ändern oder stoppen. Genau diese Entscheidung macht den Unterschied zwischen einem Pilot, der seinen Zweck erfüllt, und einem Projekt, das nur so heißt.
Fehlt sie, bleibt der Assistent dort hängen, wo viele AI-Projekte seit Monaten stehen: zwischen guter Idee und echtem Betrieb, ohne dass jemand das offen ausspricht.
Das heißt nicht, dass jedes AI-Projekt vor dem Start bis ins letzte Detail durchgeplant sein muss. Gerade bei neuen Themen braucht es Raum zum Testen, und genau dafür ist ein Pilot da. Aber ein Pilot ist ein Werkzeug mit einer Frage, keine Verlängerung der Unentschlossenheit.
Ohne klare Erfolgskriterien wird daraus schnell ein Dauerprovisorium, das intern niemand abschaltet, weil es nie eine Vereinbarung darüber gab, wann es erfolgreich ist und wann nicht. Der Pilot ist dann nicht das Problem. Das Fehlen der Kriterien ist es.
Unser Future{hacks} Fazit
Die Demo darf beeindrucken. Sie zeigt nur, was ein Modell kann, nicht, was im eigenen Unternehmen daraus wird. Copilot, Claude und ein Workshop-Nachmittag sind deshalb keine AI-Umsetzung, sie sind ihre Voraussetzung.
Den Unterschied macht nicht das Tool, sondern die Frage, die danach gestellt wird. Wer beim AI-Einkauf nur prüft, was ein Modell kann, kauft eine Möglichkeit. Wer prüft, wer im Ernstfall haftet, wer die Daten pflegt und wer den Stecker ziehen darf, kauft etwas, das im Alltag tatsächlich übersteht.
Markus Kirchmaier ist Prokurist & Partner bei LEAN-CODERS und beschäftigt sich seit Jahren intensiv mit dem IT-Arbeitsmarkt sowie modernen IT-Systemen und technologischen Entwicklungen. Hier geht es zu den anderen Beiträgen aus der Future{hacks}-Reihe.
