KI-Projekt-Roadmap erstellen: Von der Idee bis zur Produktion

Der klassische Fehler einer KI-Roadmap ist nicht die verpasste Deadline, sondern die Roadmap selbst: ein Gantt-Diagramm, das so tut, als wären Modellqualität, Datenrealität und Nutzerakzeptanz planbar wie Bau-Meilensteine. Dann funktioniert der Pilot, alle feiern, und das Projekt stirbt trotzdem, weil niemand die unglamouröse Brücke von der funktionierenden Demo zum überwachten Produktionssystem geplant hat, dem echte Nutzer:innen vertrauen. Eine brauchbare KI-Roadmap ist anders gebaut: Phasen, die in Entscheidungs-Gates enden statt in Terminen, eine explizite Pilot-zu-Produktion-Phase mit eigenem Budget und vorab vereinbarte Regeln, wann neu zugeschnitten und wann gestoppt wird. Dieser Artikel liefert diese Struktur, mit einem Miniaturbeispiel.

Warum die meisten KI-Roadmaps am Realitätskontakt scheitern

KI-Roadmaps scheitern auf charakteristische Arten, und fast alle führen darauf zurück, dass ein Lernprozess wie ein Bauplan behandelt wird.

Die Phasenstruktur, mit realistischen Gates

Fünf Phasen decken den Weg von der Idee zum betriebenen System ab. Die Dauern sind typische Spannen für ein fokussiertes mittelgroßes Projekt, illustrativ, keine Versprechen, und jedes Gate ist eine echte Entscheidung, kein Status-Meeting.

Die Brücke vom Pilot in die Produktion, die niemand plant

Phase 4 ist der Ort, an dem KI-Projekte tatsächlich sterben, gerade weil sie nach einem erfolgreichen Pilot wie eine Formalität aussieht. Ist sie nicht: Sie ist reguläre, harte Engineering-Arbeit und kostet routinemäßig so viel wie der Pilot oder mehr. Planen Sie diese Punkte explizit, jeweils mit Verantwortlichem und Budgetzeile.

1. 1Integration in den echten Workflow: Der Pilot lief neben dem Prozess; die Produktion läuft in ihm, das heißt, die Systeme anzufassen, die Menschen wirklich nutzen (ERP, CRM, Ticketing), samt der Backlogs ihrer Verantwortlichen.
2. 2Monitoring und Alerting auf Modellqualität, nicht nur auf Verfügbarkeit: eine rollierende gelabelte Stichprobe oder Proxy-Metrik, Schwellenwerte und eine benannte Person, die alarmiert wird.
3. 3Fallbacks und Degradationspfade: Was passiert, je Prozessschritt, wenn das Modell nicht verfügbar oder unter der Schwelle ist, und wer entschieden hat, dass das akzeptabel ist.
4. 4Menschliche Aufsicht und Eskalationsdesign: Wer prüft was, ab welchen Konfidenzniveaus, und wie fließen Korrekturen als Trainingssignal zurück.
5. 5Nutzer-Rollout und Vertrauensaufbau: Schulung, ein Feedback-Kanal und eine explizite Adoptionsmetrik, ein technisch perfektes System, um das die Nutzer:innen herumarbeiten, ist gescheitert.
6. 6Compliance und Dokumentation abschließen: Modell-Dokumentation, Logging und, wo einschlägig, Pflichten aus dem EU AI Act vor dem Rollout fertigstellen, nicht danach nachrüsten.

Besetzung je Phase: Das Team ändert seine Form

Ein fixes Team über alle Phasen erstickt entweder die frühen Phasen mit Prozess oder lässt den späten die Engineering-Muskeln fehlen. Typische Formen, mit dem Hinweis, dass kleine Projekte Rollen in Personen bündeln statt in Kopfzahl.

Wann neu zuschneiden, wann stoppen

Gates funktionieren nur, wenn die Entscheidungsregeln vor dem Gate existieren. Vereinbaren Sie diese beim Kickoff und schreiben Sie sie in das Roadmap-Dokument selbst.

1. 1Neu zuschneiden, wenn das Problem echt, aber das Ziel falsch ist: Die Metrik bewegt sich, nur nicht genug, und ein engerer Zuschnitt (weniger Kategorien, ein Segment, Human-in-the-Loop statt Vollautomatisierung) nimmt die Hürde plausibel.
2. 2Neu zuschneiden, wenn die Daten einen benachbarten Use Case besser tragen als den geplanten, der Explorationsreport sollte das ausdrücklich sagen.
3. 3Stoppen, wenn die Decke strukturell ist: Die erreichbare Qualität liegt nach ehrlicher Exploration unter dem Minimum des Business Case, und mehr Modellierungsaufwand bearbeitet Rauschen, kein Signal.
4. 4Stoppen, wenn die Metrik-Eigentümerin weg ist: Will kein Stakeholder mehr, dass sich die Zahl bewegt, ist das Projekt organisatorisch tot, egal wie gesund es technisch ist.
5. 5Die Zwei-Zuschnitte-Regel anwenden: Ein Projekt, das zweimal neu zugeschnitten wurde, ohne ein Gate zu nehmen, ist per Default ein Stopp-Kandidat, und die Beweislast wechselt zur Fortführung.
6. 6Jeden Stopp ernten: Datenpipeline, Eval-Set und Erkenntnisreport als wiederverwendbare Assets archivieren und den Stopp-Grund dort festhalten, wo das nächste Team ihn findet.

Eine Miniatur-Beispiel-Roadmap

Eine illustrative, verdichtete Roadmap für das fiktive Retouren-Kategorisierungsprojekt aus unserem Briefing-Artikel, die Gates und Neuzuschnitt-Denken in der Praxis zeigt.