KI-Workflow statt KI-Spielerei: ein Praxisbeispiel
Warum KI-Projekte scheitern und wie ein KI-Workflow messbaren Nutzen schafft: ein konkretes Kundenprojekt mit klaren Leitplanken.

Fast jedes Unternehmen probiert gerade KI aus. Trotzdem bleibt bei vielen Pilotprojekten nach der ersten beeindruckenden Demo wenig übrig, das sich in Umsatz, Kosten oder Zeit messen lässt.
Das liegt nicht automatisch an der KI. Häufig fehlt ein KI-Workflow, in dem Ergebnisse wiederholbar sind und Fehler auffallen. Wie das konkret aussieht, lässt sich besser an einem echten Kundenprojekt erklären als an der nächsten Prognose.
Die Zahlen, die Entscheider gerade nervös machen
Die bekannteste Zahl lautet: 95 Prozent der GenAI-Pilotprojekte liefern keinen messbaren wirtschaftlichen Nutzen. Sie stammt aus dem Report „The GenAI Divide: State of AI in Business 2025“ von Project NANDA am MIT Media Lab.
Der Report stützt sich auf 52 strukturierte Interviews, 153 Antworten von Führungskräften und mehr als 300 öffentlich dokumentierte KI-Initiativen. Das klingt belastbar. Die oft zitierte 95-Prozent-Zahl ist es aber nicht.
Der Bericht ist nicht peer-reviewed und auch keine „MIT-Studie“ im üblichen Sinn. Vor allem lässt sich aus den veröffentlichten Daten nicht sauber rekonstruieren, wie die 95 Prozent berechnet wurden. Der Wharton-Professor Kevin Werbach hat den Report mehrfach gelesen und fordert die zugrunde liegenden Daten oder eine Rücknahme der Behauptung. Eine ausführliche Kritik bei Futuriom weist zudem auf einen Interessenkonflikt hin: Der Report empfiehlt agentische Systeme, also genau die Architektur, an der Project NANDA selbst arbeitet.
Die Zahl hält einer Prüfung damit nicht stand. Die Beobachtung dahinter sollte Entscheider trotzdem beschäftigen.
Der Bitkom-Studienbericht 2026 liefert für Deutschland solidere Anhaltspunkte. In einer telefonischen Befragung von 604 Unternehmen gaben 41 Prozent an, KI aktiv einzusetzen. 2024 waren es 17 Prozent. Gleichzeitig sagten 33 Prozent, KI sei teurer als erwartet. 53 Prozent nannten fehlende KI-Kompetenz im Team als größte Hürde.
Der Einsatz hat sich also mehr als verdoppelt. Das Können und die Prozesse halten nicht im gleichen Tempo mit.
Auch die Produktivität lässt sich nicht aus dem Bauch heraus beurteilen. Eine METR-Studie von 2025 kam zu einem irritierenden Ergebnis: Erfahrene Open-Source-Entwickler arbeiteten mit damaligen KI-Tools 19 Prozent langsamer, hielten sich selbst aber für 20 Prozent schneller.
Wer daraus heute „KI macht Entwickler langsamer“ ableitet, lässt einen wichtigen Nachtrag weg. Im Update vom Februar 2026 erklärt METR das Folgeexperiment wegen starker Selektionseffekte für unzuverlässig. Entwickler, die besonders von KI profitierten, wollten selbst gegen Bezahlung nicht ohne sie arbeiten. Viele reichten außerdem gerade die Aufgaben nicht ein, bei denen sie KI am stärksten vermissten. METR geht inzwischen davon aus, dass KI Entwickler Anfang 2026 eher beschleunigt. Wie stark, bleibt offen.
Was von beiden Studien bleibt, ist die Lücke zwischen Gefühl und Messung. Niemand weiß intuitiv, ob ein KI-Pilotprojekt produktiv ist. Und ein Chat-Tool wird nicht zum Prozess, nur weil seine erste Antwort gut aussieht.
Spielerei und Workflow am selben Beispiel
Nehmen wir eine überschaubare Aufgabe: Auf einer Unternehmenswebsite soll ein Rechner entstehen, mit dem Interessenten ihr Einsparpotenzial ermitteln.
| KI-Spielerei | KI-Workflow |
|---|---|
| Ein Chat erzeugt fertiges HTML. | Der Rechner wird ein Baustein des bestehenden Systems. |
| Das Ergebnis sieht nach zehn Minuten gut aus. | Inhalte, Logik und Darstellung folgen klaren Verträgen. |
| Preisänderungen landen als Ticket beim Entwickler. | Der Kunde pflegt seine Zahlen selbst im CMS. |
| Fehler fallen auf, wenn jemand sie sieht. | Fehler stoppen den Build vor der Veröffentlichung. |
Beide Wege können am ersten Tag ähnlich aussehen. Der Unterschied zeigt sich beim ersten Preiswechsel, beim zweiten Einsatz des Rechners oder bei einer Erweiterung sechs Monate später.
Spielerei liefert ein Ergebnis. Ein Workflow liefert ein Ergebnis, das der Kunde ohne mich verändern kann.
Das Projekt: Conlivo
Conlivo entwickelt Software für Hausverwaltungen. Damit können sie ihre Heizkostenabrechnung selbst erstellen, statt sie vollständig bei einem Dienstleister einzukaufen.
Für das Unternehmen entstand eine neue Website mit Newsroom für Blog, Presse und Events, Suche, Pagination, strukturierten Daten, Consent- und Tracking-Setup, Redirects und Sitemap. Das Backend läuft mit Kirby CMS, das Frontend mit Nuxt. Wie dieses Headless-Setup grundsätzlich funktioniert, habe ich in einem eigenen Beitrag beschrieben.
Der belegbare Projektrahmen:
- zwei Repositories für Backend und Frontend
- 115 Commits zwischen dem 2. Juni und 11. Juli 2026
- 39 Tage Projektzeit, also knapp sechs Wochen
- 86 Vue-Komponenten
- 20 pflegbare Content-Bausteine im CMS
Diese Zahlen beweisen keine Qualität. Sie zeigen den Umfang, in dem der KI-Workflow funktionieren musste. Bei drei Komponenten kann man sich auf Aufmerksamkeit verlassen. Bei 86 sollte man ein besseres System haben.
Der Potenzialrechner zeigt den Unterschied
Der deutlichste Baustein ist der Potenzialrechner. Er beantwortet eine geschäftliche Frage, bevor ein Interessent ein Erstgespräch bucht: Was kostet es eine Hausverwaltung, ihre bisherige Lösung beizubehalten?
Dafür braucht der Rechner drei Werte:
- Anzahl der Wohnungen
- bisheriger Dienstleisterpreis pro Einheit
- neue Softwarekosten pro Einheit
Die Formel ist bewusst einfach: Anzahl × (Preis − Kosten). Das Ergebnis zeigt den möglichen zusätzlichen Gewinn pro Jahr. Ein Disclaimer erklärt, welche Annahmen die Rechnung vereinfacht.
Damit ist der Rechner kein dekoratives Element, sondern ein Vertriebswerkzeug. Technisch besteht er trotzdem nicht aus einem isolierten Stück Code. Er läuft durch eine Kette:
- Der Bauplan im CMS:
potenzialrechner.ymlbestimmt, welche Werte Conlivo pflegen darf. Dazu gehören Label, Einheit, Minimum, Maximum, Schrittweite, Nachkommastellen, Standardwert, Disclaimer und Button-Ziel. - Der Übersetzer:
blocks-resolver.phpwandelt die CMS-Daten in sauberes JSON für das Frontend um. - Der Vertrag:
post.tsdefiniert in TypeScript, wie diese Daten aussehen müssen. - Die Darstellung: Drei Vue-Komponenten zeigen den Rechner im Artikel, im Hero der Startseite und teilen sich die zugrunde liegende Logik.
Alle 14 im Frontend unterstützten Inhaltsbausteine sind in einem gemeinsamen Typ-Vertrag zusammengefasst. Wird ein neuer Baustein eingebaut und eine Station der Kette vergessen, erscheint nicht irgendwann ein kaputter Rechner auf der Website. Der Build meldet vorher einen Fehler.
Das ist die entscheidende Leitplanke. Ich muss nicht darauf vertrauen, dass die KI nie etwas vergisst. Ich muss dafür sorgen, dass Vergessen auffällt.
Ein Detail zeigt, wie viel Projektstruktur ausmachen kann. Im CMS-Bauplan steht ein Hilfetext. Er erklärt Conlivo, dass genau drei Eingabefelder in fester Reihenfolge vorgesehen sind und wie das Ergebnis berechnet wird. Gleichzeitig liest die KI denselben Text, wenn sie am Projekt arbeitet.
Eine Zeile Dokumentation hilft damit zwei Lesern: dem Menschen im CMS und dem Modell im Code. Dokumentation ist an dieser Stelle keine Pflichtübung. Sie erzeugt Arbeitsgeschwindigkeit.
Was die KI gemacht hat und was nicht
Gut delegierbar war die wiederkehrende Umsetzung. Wenn Bauplan und Datenvertrag feststehen, kann die KI das Muster zuverlässig durch mehrere Dateien ziehen. Das gilt auch für ähnliche Content-Bausteine, Typdefinitionen, Übersetzungen sowie Article-, FAQ- und Event-Schema für Suchmaschinen.
Bei 20 Bausteinen ist der erste Denkarbeit. Der zwölfte ist vor allem Fleißarbeit. Genau dort entsteht Produktivität.
Nicht delegierbar waren die Entscheidungen, an denen der Wert des Projekts hängt:
- Der Rechner sollte ein wiederverwendbarer CMS-Baustein werden und kein fest verdrahtetes Stück Code.
- Die Formel musste verständlich bleiben und brauchte wegen ihrer Vereinfachungen einen pflegbaren Disclaimer.
- Die Darstellung auf orangem Grund erforderte zwischen dem 7. und 9. Juli mehrere Anläufe für Kontrast, Lesbarkeit und Umbruchverhalten.
- Der Button nach dem Ergebnis musste zu einem Erstgespräch führen, statt den Nutzer mit einer interessanten Zahl allein zu lassen.
Die Designschleifen waren kein Versagen der KI. Sie waren der Teil, für den Urteilsvermögen nötig ist.
Ich nutze KI, um mir die langweiligen Teile abzunehmen, nicht das Denken. Die knappen sechs Wochen kommen nicht nur daher, dass ein Modell schneller tippt. Der Vorteil entsteht, weil ich über die nächste Entscheidung nachdenken kann, während die wiederkehrende Kette umgesetzt wird.
Mehr zur Verschiebung zwischen Umsetzung und Verantwortung steht im Beitrag darüber, wie KI die Arbeit von Entwicklern verändert.
Was der Kunde davon hat
Die technische Architektur ist nur dann relevant, wenn sie im Betrieb einen Unterschied macht. Bei Conlivo tut sie das:
- Ändert sich ein Preis pro Einheit, pflegt das Team die neue Annahme selbst im Kirby-Panel.
- Derselbe Rechner kann auf der Startseite und in einem Fachartikel erscheinen, ohne doppelt gebaut zu werden.
- Der Disclaimer bleibt redaktionell anpassbar.
- Das Ergebnis führt direkt zur nächsten Handlung: einem Erstgespräch.
- Unvollständige technische Änderungen fallen vor dem Launch auf.
Das macht den Vertriebseffekt noch nicht gemessen. Dafür wären echte Nutzungs- und Conversion-Daten nötig. Aber der Rechner ist so gebaut, dass er auf eine Conversion zuläuft und später ausgewertet werden kann.
Der wichtigste Unterschied zeigt sich ohnehin nicht am Tag des Launches. Er zeigt sich, wenn sich sechs Monate später eine Annahme ändert. Der eine Weg heißt dann „kurz beim Entwickler anrufen“. Der andere heißt „kurz ins Panel“.
Solche Entscheidungen beeinflussen auch das Budget. Im Beitrag über die Kosten einer professionellen Unternehmenswebsite 2026 erkläre ich genauer, warum KI mechanische Arbeit reduziert, aber Architektur, Review und Verantwortung nicht verschwinden lässt.
Vier Fragen für dein eigenes KI-Projekt
Ob es um Webentwicklung, interne Wissensarbeit oder Kundenservice geht: Mit vier Fragen lässt sich ein KI-Pilotprojekt recht schnell von einem belastbaren Workflow unterscheiden.
- Fällt ein Fehler automatisch auf? Wenn die einzige Kontrolle darin besteht, dass jemand hoffentlich genau hinschaut, ist das kein verlässlicher Prozess.
- Kann die KI den Kontext lesen, den auch dein Team nutzt? Wissen in Köpfen und Meetings ist für ein Modell unsichtbar. Klare Dateien, Regeln und Datenstrukturen schließen diese Lücke.
- Was passiert beim zwölften Durchlauf? Ein einmaliges Ergebnis kann eine gute Demo sein. Ein Prozess muss auch bei Wiederholung konsistent funktionieren.
- Bleibt etwas, das ohne die KI weiterläuft? Beim Potenzialrechner bleibt ein CMS-Baustein, den Conlivo selbst bedienen kann. Das Ergebnis ist nicht an die nächste Chat-Session gebunden.
Für Entscheider folgt daraus eine andere Frage an KI-Projekte. Nicht: „Welches Modell nutzen wir?“ Sondern: „Welcher bestehende Prozess wird dadurch verlässlich besser, und woran merken wir das?“
Fazit
Ob tatsächlich 95 Prozent der KI-Projekte scheitern, lässt sich mit dem oft zitierten Report nicht belegen. Dass viele Pilotprojekte keinen wirtschaftlichen Nutzen erreichen, ist trotzdem plausibel. Meist fehlt nicht das bessere Modell, sondern die Struktur rundherum.
Verträge, Baupläne und automatische Prüfungen klingen weniger spektakulär als eine KI-Demo. Sie sind aber der Grund, warum aus einem schnellen Ergebnis ein System wird, das Wochen und Monate später noch trägt.
Wenn du ein KI-Projekt hast, das beeindruckend gestartet ist und jetzt feststeckt, schau nicht zuerst auf das nächste Tool. Schau auf den Workflow, in dem das Tool arbeiten soll.
Schreib mir kurz, wo dein Pilotprojekt feststeckt. Oft lässt sich in einem kurzen Austausch erkennen, ob das Problem beim Tool liegt oder beim Workflow darum herum.
mail@eugen.workDieser Beitrag wurde mit Unterstützung von KI ausformuliert und übersetzt.