KI-Roadmap in 90 Tagen — Vom Discovery zum produktiven Piloten

„Wir wollen mit KI anfangen, aber niemand traut sich den ersten Schritt." Diesen Satz hören wir in fast jedem ersten Gespräch mit mittelständischen Geschäftsführungen — und er beschreibt das eigentliche Problem präzise. Die Frage ist selten, ob KI im Unternehmen Wert bringen kann, sondern wie der erste produktive Pilot in einem überschaubaren Zeit- und Kosten-Rahmen aufgesetzt wird, ohne sich in einer mehrjährigen Strategie-Diskussion zu verlieren. Aus über zwei Dutzend Pilot-Projekten im deutschen Mittelstand hat sich für uns ein Rhythmus von 90 Tagen als der robusteste Rahmen herausgestellt: lang genug, um substanziellen Wert zu liefern, kurz genug, um Aufmerksamkeit, Budget und Energie der Beteiligten zu halten. Dieser Artikel zeigt, wie eine solche 90-Tage-Roadmap konkret aussieht — von Tag 1 Discovery bis Tag 90 produktiver Pilot, mit den Stolpersteinen aus der Praxis, mit KPIs für jede Phase und mit einem ehrlichen Blick darauf, was in diesem Zeitfenster geht und was nicht. Für die Gesamteinordnung empfehlen wir den Überblicks-Artikel zur KI-Strategie für den Mittelstand.

Warum 90 Tage realistisch sind

Drei Quartale, zwölf Monate oder zwei Jahre — viele KI-Beratungen verkaufen Programme, die ohne Not in die Länge gezogen sind. Aus unserer Erfahrung ist das ein systematischer Fehler, und zwar aus drei Gründen. Erstens: Aufmerksamkeit ist die knappste Ressource im Mittelstand. Geschäftsführungen, die ein Pilot-Projekt persönlich begleiten, halten diese Aufmerksamkeit drei Monate. Wer länger braucht, bekommt seinen Schluss-Termin in einer halbleeren Steuerungsrunde. Zweitens: Technologie-Stacks im KI-Umfeld bewegen sich schnell. Ein zwölf-Monate-Plan, der im Januar mit GPT-5 startet, läuft im Dezember in einer komplett anderen Welt — neue Modelle, neue Preise, neue Anbieter, neue regulatorische Vorgaben. Drittens: der Lerneffekt einer kurzen, klaren Iteration ist höher als der einer langen, vagen Planung. Ein 90-Tage-Pilot zwingt zu echten Entscheidungen.

Realistisch sind 90 Tage allerdings nur unter klaren Bedingungen. Es geht um einen einzelnen Use-Case, eine überschaubare Nutzergruppe von zehn bis fünfzig Personen, vorhandene Daten in akzeptabler Qualität und eine entschlossene Stakeholder-Konstellation mit klarer Verantwortlichkeit. Wer in 90 Tagen einen konzernweiten Roll-out plant, ein Custom-Modell mit eigenem Training und gleichzeitig drei Use-Cases parallel angeht, hat den Rahmen falsch verstanden. Die Roadmap, die wir hier beschreiben, ist eine 90-Tage-Roadmap für genau einen Piloten — die zweite und dritte Welle folgt im Anschluss, mit dem Vorteil, dass dann interne Erfahrung, Tooling und Governance bereits stehen.

Eine Beobachtung aus der Praxis: in den Projekten, die wir nach diesem Modell aufgesetzt haben, lag die durchschnittliche Zeit bis zur ersten messbaren Wirkung beim Endnutzer bei 67 Tagen, die Zeit bis zur formalen Pilot-Abnahme bei 86 Tagen. Das ist nicht Magie, sondern Konsequenz: jeder Tag hat ein definiertes Ziel, jede Woche einen festen Review-Punkt, jede Phase einen Übergabe-Punkt mit klaren Akzeptanz-Kriterien.

Tag 1 bis 30 — Discovery

Die ersten dreißig Tage entscheiden über Erfolg oder Misserfolg des gesamten Piloten. In dieser Phase geht es nicht um Technologie, sondern um drei klassische Beratungs-Disziplinen: Use-Case-Definition, Datensichtung und Stakeholder-Mapping. Wer diese drei Bausteine sauber ablegt, hat die schwierigste Arbeit der gesamten 90 Tage bereits erledigt.

Use-Case-Workshop. In der ersten oder zweiten Woche moderieren wir einen ganztägigen Workshop mit drei bis sieben Personen aus Fach- und IT-Abteilung. Ziel ist eine Liste von acht bis fünfzehn potenziellen Use-Cases, gewichtet nach geschätztem Wertbeitrag, Daten-Verfügbarkeit, Komplexität und politischer Sensibilität. Aus dieser Liste wird genau ein Use-Case ausgewählt — nicht zwei, nicht drei. Die Auswahl ist eine Geschäftsführungs-Entscheidung, weil sie über das Budget der nächsten 60 Tage bestimmt. Typische Kandidaten im Mittelstand sind Angebots-Erstellung, Lieferanten-Korrespondenz, technische Dokumentation, Service-Anfragen-Triage oder interne Wissens-Suche.

Datensichtung. In den Wochen zwei und drei prüfen wir die Daten, die für den ausgewählten Use-Case relevant sind: Vollständigkeit, Aktualität, Strukturierung, Zugriffsrechte und Datenschutz-Implikationen. Diese Sichtung ist oft unbequem, weil sie unausgesprochene Datenqualitäts-Probleme an die Oberfläche bringt. Sie ist aber zwingend, weil KI auf schmutzigen Daten plausible, aber falsche Ergebnisse liefert. Wenn die Datensichtung rote Flaggen ergibt, ist der ehrliche Weg, den Piloten auf einen Use-Case mit besserer Datenlage zu verschieben oder eine vier- bis achtwöchige Daten-Aufbereitungs-Phase voranzustellen — dann verlängert sich die Roadmap auf 120 bis 150 Tage, was im Zweifel gesünder ist als ein scheiternder Pilot. Vertiefend siehe unseren Cluster zur DSGVO-konformen KI-Nutzung.

Stakeholder-Mapping. Parallel klären wir, wer im Unternehmen welche Rolle einnimmt: Sponsor in der Geschäftsführung, fachlicher Eigentümer, technischer Lead, Datenschutz-Ansprechperson, Betriebsrat, ausgewählte Endnutzer für die Pilot-Gruppe. Pro Rolle ein Name, eine Erreichbarkeit, ein Zeit-Budget. Dieses Mapping ist kein Bürokratie-Selbstzweck — es ist die Grundlage dafür, dass am Tag 65, wenn die ersten Endnutzer Feedback geben, sofort die richtige Person die richtige Entscheidung trifft.

Die Discovery-Phase endet mit einem zweiseitigen Steckbrief: Use-Case in einem Satz, Erfolgs-Kriterien in drei bis fünf KPIs, Daten-Bestand und -Lücken, Stakeholder-Liste, geschätzter Aufwand für Phase zwei und drei, Datenschutz-Bewertung. Dieser Steckbrief wird in einem Steuerungs-Meeting am Tag 30 von der Geschäftsführung formell abgenommen — oder das Projekt wird hier sauber gestoppt, was deutlich besser ist als ein Pilot ohne Mandat.

Tag 31 bis 60 — Pilot-Build

Mit dem abgenommenen Steckbrief beginnt die Bau-Phase. Ziel ist ein funktionsfähiges MVP — ein Minimum Viable Product — das von einer kleinen Pilot-Gruppe in echten Arbeits-Situationen genutzt werden kann. Die Phase teilt sich in drei Blöcke: Tooling-Auswahl, Bau und Datenschutz-Setup.

Tooling-Auswahl in Tag 31 bis 35. Innerhalb der ersten Woche dieser Phase legen wir den Technologie-Stack fest. Das ist eine Entscheidung mit weitreichenden Folgen, die wir bewusst kurz halten — fünf Tage, nicht fünf Wochen. Die Auswahl orientiert sich am gewählten Use-Case, an bestehenden Lizenzen, an Datenschutz-Vorgaben und am internen Know-how. Für Mittelständler ergibt sich pragmatisch oft eine Kombination aus Microsoft Copilot oder ChatGPT Enterprise für Standard-Use-Cases, ergänzt durch spezialisierte Anbieter für branchenspezifische Anforderungen. Eine ausführliche Übersicht der Anbieter findet sich in unserem KI-Tools-Vergleich 2026.

MVP-Bau in Tag 36 bis 55. Der eigentliche Bau läuft drei Wochen. In dieser Zeit entsteht ein nutzbares System für die Pilot-Gruppe: Integration in die bestehende Arbeitsumgebung, Anbindung an die relevanten Datenquellen, ein einfaches Frontend oder Plugin, grundlegende Logging-Funktionen. Wichtig ist die Beschränkung auf das, was die Pilot-Gruppe wirklich braucht — keine perfekt ausgearbeiteten Admin-Oberflächen, keine SSO-Integration mit jeder Schatten-IT-Anwendung des Hauses, kein komplettes Rollen-Modell. Das alles kommt in Phase drei oder im Skalierungs-Projekt nach Tag 90.

Datenschutz-Setup in Tag 50 bis 60. Parallel zum MVP-Bau bauen wir die Datenschutz-Grundlage auf: Datenschutz-Folgenabschätzung, Auftragsverarbeitungs-Verträge mit dem Tooling-Anbieter, technisch-organisatorische Maßnahmen, Information des Betriebsrats, Schulungs-Material für die Pilot-Gruppe. Diese Arbeit ist undankbar, weil sie nichts sichtbar Produktives schafft — sie ist aber zwingend, weil ein Pilot ohne Datenschutz-Grundlage spätestens bei der Skalierung blockiert wird. Wer hier schludert, verbrennt seine Roadmap.

Die Build-Phase endet am Tag 60 mit einer formalen MVP-Abnahme: das System läuft, die Pilot-Gruppe hat Zugang, die Datenschutz-Unterlagen sind unterzeichnet, das Steuerungs-Gremium nimmt ab. Wenn an dieser Stelle wichtige Bausteine fehlen, ist es besser, die Build-Phase um zwei Wochen zu verlängern und die Pilot-Phase entsprechend zu kürzen — ein unfertiges MVP zu starten produziert nur Frust und schlechte KPIs.

Tag 61 bis 90 — Test und Skalierung

Die letzte Phase ist die Bewährungsprobe. Das MVP ist gebaut, die Pilot-Gruppe nutzt es, und jetzt geht es darum, in dreißig Tagen belastbare Daten zu sammeln, das System gezielt zu verbessern und die Grundlage für die Skalierungs-Entscheidung zu legen. Die Phase teilt sich in drei Teil-Blöcke: Test-Lauf, Iterations-Zyklen und Skalierungs-Vorbereitung.

Test-Lauf in Tag 61 bis 70. In den ersten zehn Tagen läuft das System unter realen Bedingungen. Die Pilot-Gruppe arbeitet damit, Logs werden gesammelt, kurze Feedback-Runden finden zweimal pro Woche statt. Wichtig: in dieser Zeit ändern wir am System bewusst möglichst wenig, weil wir saubere Baseline-Daten brauchen. Wer in Woche eins ständig nachpatcht, kann am Ende nicht sagen, welche Verbesserung worauf zurückging.

Iterations-Zyklen in Tag 71 bis 85. Mit den ersten zwei Wochen Daten beginnen die gezielten Iterationen. Typische Stellschrauben sind Prompt-Optimierung, Anbindung weiterer Datenquellen, Anpassung der Antwort-Formate, Korrektur falsch verstandener Anwendungsfälle. Jede Iteration läuft in einem klar abgegrenzten Mini-Zyklus von zwei bis vier Tagen mit Hypothese, Änderung, Messung. Das ist methodisch klassische Produktentwicklung — nichts KI-spezifisches, aber in vielen Mittelständlern ungewohnt.

Skalierungs-Vorbereitung in Tag 81 bis 90. Parallel zu den letzten Iterationen entsteht die Entscheidungs-Vorlage für die Skalierung. Sie enthält: KPI-Vergleich Soll/Ist, identifizierte Stolpersteine, geschätzter Aufwand für die Skalierung auf hundert, fünfhundert oder tausend Nutzer, Lizenzkosten-Hochrechnung, Risiko-Bewertung, Empfehlung der Geschäftsführung. Am Tag 90 wird in einem Abschluss-Meeting entschieden: skalieren, nachschärfen oder stoppen. Alle drei Optionen sind legitim — ein Pilot, der seinen Wert nicht belegt hat, sollte ehrlich gestoppt werden, statt ihn aus Stolz in den produktiven Betrieb zu drücken.

Stolpersteine aus der Praxis

Über mehrere Pilot-Projekte haben sich drei Stolpersteine als die häufigsten Gründe herauskristallisiert, warum 90-Tage-Roadmaps aus der Spur laufen — und sie haben überraschend wenig mit Technologie zu tun.

• Interne PolitikDer häufigste Killer mittelständischer KI-Piloten ist nicht die Technik, sondern interner Widerstand: Abteilungen, die ihren Datenbestand nicht öffnen wollen, Führungskräfte, die ihren Bereich nicht durchleuchtet sehen wollen, IT-Mitarbeitende, die Sorge um den eigenen Status haben. Wirksam dagegen ist ein klarer Auftrag der Geschäftsführung, ein sichtbarer Sponsor und eine ehrliche Kommunikation darüber, dass es um Ergänzung und Entlastung geht, nicht um Ersatz.
• DatenqualitätDaten sind in fast jedem Mittelständler schlechter strukturiert, als die IT-Abteilung in der Sommerklausur vermutet. Verteilte Excel-Dateien, halbgepflegte CRM-Datensätze, doppelte Kunden-Stammdaten und Wissens-Inseln in Mail-Postfächern sind die Regel. Der Pilot muss damit umgehen — entweder durch Use-Case-Wahl mit guter Datenbasis oder durch ehrliche Daten-Aufbereitungs-Phase.
• Skill-GapInterne Teams haben selten gleichzeitig fachliches Verständnis, KI-Erfahrung und Datenschutz-Wissen. Der pragmatische Weg ist eine gemischte Aufstellung: interner Fach-Eigentümer plus interner IT-Lead plus externes Begleit-Team mit klar abgegrenzten Wochen-Stunden. Wer rein intern arbeitet, braucht Senior-Kapazität — und die ist im Mittelstand selten frei.
• Erwartungs-ManagementGeschäftsführungen, die durch öffentliche Berichterstattung KI als Magie wahrnehmen, kommen mit überhöhten Erwartungen in den Piloten. Realistische KPIs in der Discovery-Phase sind das Gegenmittel — ein Pilot, der 15 Minuten pro Mitarbeiter pro Tag spart, ist ein Erfolg, kein Misserfolg.
• Vendor-WechselkostenWer den Stack zu eng an einen Anbieter koppelt, zahlt beim Wechsel doppelt. Modulare Architekturen mit austauschbarem Modell-Layer und sauberen Schnittstellen reduzieren das Risiko, ohne die Bau-Geschwindigkeit relevant zu drücken.

KPIs pro Phase

Belastbare Steuerung braucht KPIs, die in jeder Phase passend gewählt sind. Was in Tag 1 bis 30 misst, was in Tag 31 bis 60 misst und was in Tag 61 bis 90 misst, ist unterschiedlich — wer die gleichen KPIs über alle Phasen drüber legt, optimiert auf die falsche Zielgröße.

Phase	KPI	Zielwert
Discovery (Tag 1–30)	Use-Case-Auswahl getroffen	1 Use-Case bis Tag 14
Discovery (Tag 1–30)	Daten-Verfügbarkeit bewertet	schriftliche Bewertung Tag 22
Discovery (Tag 1–30)	Stakeholder-Mapping abgeschlossen	alle Rollen besetzt Tag 25
Build (Tag 31–60)	MVP-Bereitschaft	Pilot-Gruppe nutzt Tag 58
Build (Tag 31–60)	Datenschutz-Folgenabschätzung	unterzeichnet Tag 55
Build (Tag 31–60)	Schulung Pilot-Gruppe	100 % geschult Tag 60
Test (Tag 61–90)	Aktive Nutzungs-Rate	über 60 % der Pilot-Gruppe wöchentlich
Test (Tag 61–90)	Mess-Wert für Wertbeitrag	Use-Case-spezifisch, z. B. Bearbeitungs-Zeit –20 %
Test (Tag 61–90)	Skalierungs-Entscheidung	Vorlage Tag 88, Entscheidung Tag 90

Die KPI-Tabelle ist kein Selbstzweck, sondern Steuerungs-Werkzeug. Jede Zeile gehört in das wöchentliche Statusbild, jeder Zielwert wird offen kommuniziert. Wer KPIs versteckt, weil sie unangenehm sind, hat ein Kultur-Problem, das auch nach erfolgreichem Piloten nicht weggeht. Detailliert zur Wirtschaftlichkeits-Messung siehe KI-Kosten und ROI berechnen.

Reepa-Begleitung

Wir begleiten 90-Tage-Roadmaps in zwei Konstellationen. In der Vollbegleitung übernehmen wir Workshop-Moderation, technische Architektur, Bau-Begleitung, Datenschutz-Setup und Steuerungs-Kommunikation — der Aufwand liegt bei rund 35 bis 60 Tagewerken über die 90 Tage verteilt, gestaffelt nach Use-Case-Komplexität. In der Sparring-Variante stellt das Unternehmen das Bau-Team, und wir liefern Workshop-Moderation, Architektur-Review, KPI-Setup und Eskalations-Backup — Aufwand etwa 12 bis 25 Tagewerke. Welche Variante passt, klärt sich in der Discovery-Phase.

Unsere Stärke liegt in der Verbindung von KI-Technik mit klassischer Projekt-Methodik und Cybersecurity-Erfahrung. Gerade Datenschutz und Sicherheits-Aspekte sind in deutschen Mittelständlern oft die eigentlichen Blocker — und genau hier kommen unsere Erfahrungen aus dem Cybersecurity-Geschäft zum Tragen. Ein KI-Pilot, der bei der ersten Datenschutz-Prüfung scheitert, ist eine teure Lektion, die wir unseren Kunden ersparen wollen.

Häufige Fragen