Wie lange dauert ein KI-Projekt? Phasen und realistische Zeitplanung

Wer ein KI-Projekt plant, fragt zuerst nach dem Preis – und direkt danach, wie lange es dauert. Die zweite Frage ist unterschätzt schwer zu beantworten, weil die meisten Zeitpläne, die kursieren, nur die Entwicklung betrachten: das Modell konfigurieren, den Workflow bauen, testen. Was in diesen Plänen fehlt, sind die Dinge, die in der Praxis tatsächlich Zeit kosten – Datenzugang organisieren, interne Freigaben einholen, den Pilotbetrieb unter echten Bedingungen laufen lassen.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in kleinen und mittleren Unternehmen, die eine realistische Zeitplanung für ein KI-Vorhaben brauchen – für ein Budget, eine interne Präsentation oder die Entscheidung, ob sie das Thema selbst stemmen oder sich Unterstützung holen. Er beantwortet: Welche Phasen gibt es, was kann parallel laufen, welche Abhängigkeiten verzögern typischerweise, wie lange dauert ein Pilot, und wann ist ein Rollout realistisch.

Begriffe kurz geklärt

Für den Rest des Artikels unterscheide ich vier Begriffe, die in Angeboten und Zeitplänen oft vermischt werden:

• Entwicklungszeit ist die reine Bauzeit einer Lösung – Konfiguration, Integration, Testing. Sie ist der Teil, den die meisten Zeitpläne zeigen, aber selten der Teil, der die Gesamtdauer bestimmt.
• Projektlaufzeit ist die Zeit von der ersten Entscheidung bis zum produktiven Pilotstart – inklusive Analyse, Datenzugang und Freigaben. Sie ist in der Regel deutlich länger als die reine Entwicklungszeit.
• Pilotbetrieb ist der begrenzte Testzeitraum, in dem eine Lösung unter echten Bedingungen mit einer definierten Gruppe läuft, mit dem Ziel, gegen vorher festgelegte Erfolgskriterien zu messen.
• Rollout ist die Ausweitung einer erfolgreich getesteten Lösung auf weitere Teams oder Prozesse, inklusive Schulung und dauerhafter Betriebsverantwortung.

Die Verwechslung von Entwicklungszeit und Projektlaufzeit ist der häufigste Grund, warum Zeitpläne für KI-Projekte reißen: Ein Anbieter nennt „zwei Wochen” für die Konfiguration eines Chatbots – und meint damit tatsächlich nur die Konfiguration, nicht die drei Wochen, die vorher für die Klärung des Datenzugriffs draufgehen.

Welche Phasen gibt es?

Ein KI-Projekt in einem KMU lässt sich in drei Phasen ordnen, die aufeinander aufbauen und jeweils mit einer Entscheidung enden – nicht mit einem automatischen Übergang zur nächsten:

Phase	Kernfrage	Typisches Ergebnis	Was hier passiert
1. Analyse & Freigaben	Was genau bauen wir, mit welchen Daten, mit wessen Erlaubnis?	Abgegrenzter Use Case, geklärter Datenzugang, Freigabe für den Piloten	Prozess- und Datenprüfung, Zuständigkeiten klären, Erfolgskriterien festlegen
2. Pilot	Funktioniert es unter echten Bedingungen bei uns?	Messergebnis gegen vorher definierte Kriterien	Aufsetzen, Testbetrieb mit einer Gruppe, laufende Beobachtung
3. Rollout	Wie wird daraus Normalbetrieb?	Ausweitung, Schulung, benannte Betriebsverantwortung	Integration in weitere Teams/Prozesse, Monitoring, Governance

Eigenes Phasenmodell Philogic Labs für die Zeitplanung von KI-Projekten in KMU.

Der Unterschied zu einem klassischen Softwareprojekt liegt weniger in der Struktur als im Gewicht der einzelnen Phasen: Phase 1 dauert bei KI-Projekten in der Regel überproportional lange, weil Datenzugang und Freigaben – anders als bei Standardsoftware – nicht vorab spezifiziert werden können, sondern erst im Prozess sichtbar werden. Ein Prozess-Audit im Sinne von Process Mining, wie es etwa in der Microsoft-Dokumentation zu Power Automate beschrieben wird, macht genau diesen Schritt greifbar: Er zeigt anhand echter Ereignisdaten, wie ein Prozess tatsächlich abläuft – nicht, wie er auf dem Papier aussieht – und macht damit sichtbar, wo Automatisierung ansetzen kann und wo die Datenbasis noch lückenhaft ist.

Was kann parallel laufen?

Nicht jeder Schritt in Phase 1 muss sequenziell ablaufen. In der Praxis lassen sich drei Stränge meist parallelisieren, wenn sie früh genug angestoßen werden:

• Datenzugangsklärung und IT-Freigabe. Während der Fachbereich den Prozess beschreibt, kann die IT parallel prüfen, welche Systeme und Schnittstellen betroffen sind und welche Zugriffe technisch möglich sind.
• Datenschutzprüfung und Anbieterauswahl. Die Prüfung, ob und wie personenbezogene Daten verarbeitet werden (Auftragsverarbeitung, Rechtsgrundlage), kann parallel zur Evaluierung möglicher Tools oder Umsetzungspartner laufen – solange am Ende beide Ergebnisse zusammengeführt werden, bevor produktiv gestartet wird.
• Erfolgskriterien definieren und technische Vorbereitung. Während die Konfiguration einer Testumgebung beginnt, kann parallel festgelegt werden, woran der Pilot später gemessen wird.

Was sich dagegen kaum sinnvoll parallelisieren lässt: der Pilot selbst und die Auswertung. Ein Pilotbetrieb braucht eine Mindestlaufzeit unter echten Bedingungen, um belastbare Aussagen zu liefern – ihn zu verkürzen, um Zeit zu sparen, liefert am Ende keine verlässliche Entscheidungsgrundlage, sondern nur ein Bauchgefühl mit KI-Etikett. Ebenso wenig lässt sich der Rollout sinnvoll vor einer abgeschlossenen Pilotauswertung beginnen – wer parallel schon ausrollt, während der Pilot noch läuft, nimmt sich die Möglichkeit, rechtzeitig zu stoppen oder anzupassen.

Welche Abhängigkeiten verzögern?

Die Zahlen aus der aktuellen KI-Nutzung in Deutschland liefern einen indirekten Hinweis auf diese Abhängigkeiten: Laut Bitkom berichten 33 % der KI-nutzenden Unternehmen von höheren Kosten als erwartet – ein Muster, das sich in meiner Erfahrung fast immer auf unterschätzte Vorlaufzeiten zurückführen lässt, nicht auf die eigentliche technische Umsetzung. Vier Abhängigkeiten sind dabei besonders häufig:

1. Datenzugang. Die Information, die eine KI-Lösung braucht, liegt oft nicht dort, wo man sie erwartet – verteilt über mehrere Systeme, in unterschiedlichen Formaten, teils nur in Köpfen. Bis geklärt ist, wer worauf zugreifen darf und wie Daten technisch bereitgestellt werden, vergeht regelmäßig mehr Zeit als für die eigentliche Konfiguration der Lösung.

2. Interne Freigabeprozesse. Wer darf entscheiden, dass ein Pilot starten darf? Wer muss vorher informiert werden? In Unternehmen ohne klar benannte Zuständigkeit für KI-Themen (siehe dazu unsere Kategorie Kosten & ROI) zieht sich diese Klärung oft über mehrere Wochen, weil die Anfrage zwischen Abteilungen hin- und herwandert.

3. IT-Ressourcen und Systemzugriffe. Selbst eine einfache Anbindung an ein bestehendes System braucht IT-Kapazität – und die ist in KMU meist knapp und für das Tagesgeschäft verplant. Ein Pilot, der technisch in zwei Tagen stünde, wartet real oft zwei bis drei Wochen auf einen freien IT-Slot.

4. Nachträglich entdeckte Datenschutzfragen. Wenn die Datenschutzprüfung erst spät beginnt, tauchen Fragen zur Auftragsverarbeitung oder zur Rechtsgrundlage oft erst auf, wenn der Pilot eigentlich schon starten sollte – mit der Folge, dass der Start verschoben wird, statt dass die Frage von Anfang an mitläuft.

Diese vier Punkte sind der Grund, warum ein realistischer Zeitplan nicht bei der Entwicklungszeit ansetzen darf, sondern bei der Frage: Was muss geklärt sein, bevor überhaupt entwickelt werden kann?

Wie lange dauert ein Pilot?

Ein enger, gut vorbereiteter Pilot läuft in meiner Projekterfahrung typischerweise sechs bis zwölf Wochen. Diese Bandbreite gilt unter folgenden Annahmen: ein KMU mit einem einzelnen, klar abgegrenzten Use Case auf Basis bestehender Modelle (keine Eigenentwicklung), digital zugänglichen Daten und einer intern verantwortlichen Person mit realem Zeitbudget für den Piloten.

Die Spanne hängt vor allem an zwei Faktoren:

• Integrationstiefe. Ein Workflow, der auf bestehenden Tools aufsetzt (z. B. ein Sprachmodell an ein bereits vorhandenes Ticketsystem angebunden), lässt sich in Tagen bis wenigen Wochen aufsetzen. Eine tiefere Anbindung an ein gewachsenes ERP- oder CRM-System braucht dagegen mehr Abstimmung und Testzeit.
• Datenqualität im laufenden Betrieb. Auch wenn Daten grundsätzlich zugänglich sind, zeigt sich ihre tatsächliche Qualität oft erst im Testbetrieb – Formatinkonsistenzen, fehlende Felder, veraltete Einträge. Diese Erkenntnisse verlängern typischerweise die zweite Hälfte des Piloten, weil nachjustiert werden muss.

Ein zu kurzer Pilot liefert keine verlässliche Aussage: Nach wenigen Tagen zeigen sich selten die Randfälle, die im echten Betrieb auftreten. Ein zu langer Pilot – deutlich über zwölf Wochen ohne erkennbaren Grund – ist meist ein Zeichen dafür, dass der Scope zu groß gewählt wurde oder dass ungelöste Abhängigkeiten aus Phase 1 in den Piloten hineingezogen wurden, statt sie vorher zu klären.

Wann ist Rollout realistisch?

Ein Rollout ist frühestens nach einer abgeschlossenen, positiven Pilotauswertung realistisch – als eigener Entscheidungsschritt, nicht als automatische Verlängerung des Piloten. Praktisch heißt das: Erst wenn die vorher definierten Erfolgskriterien ausgewertet sind und die Entscheidung „ausrollen” gefallen ist, beginnt die Rollout-Phase.

Die Rollout-Phase selbst zieht sich in der Regel über mehrere Monate, gestuft nach Teams oder Prozessschritten, statt als einmaliger Schalter von einer kleinen Pilotgruppe auf den gesamten Betrieb. Dafür gibt es drei Gründe, die sich aus der Praxis ergeben:

1. Schulungsbedarf ist gestaffelt. Nicht jedes Team hat den gleichen Wissensstand oder die gleiche Betroffenheit – Schulungen lassen sich selten für 50 Personen an einem Tag sinnvoll durchführen.
2. Systemintegration braucht Zeit pro Anwendungsfall. Was im Piloten für ein Team funktioniert hat, muss für jedes weitere Team oder jeden weiteren Prozessschritt erneut auf Passung geprüft werden – Randfälle unterscheiden sich.
3. Betriebsverantwortung muss wachsen können. Eine Person, die den Piloten betreut hat, kann nicht ohne Weiteres den Betrieb für das gesamte Unternehmen übernehmen. Governance und Monitoring müssen mitskalieren.

Ein Warnsignal für einen unrealistischen Rollout-Plan: Wenn der Sprung von Pilot zu Vollbetrieb in wenigen Wochen erfolgen soll, ohne dass Schulung, Integration und Betriebsverantwortung explizit eingeplant sind, ist die Wahrscheinlichkeit hoch, dass der Rollout entweder verschoben wird oder mit spürbar schlechterer Qualität startet als der Pilot.

Rechenmodell: eigene Zeitschätzung für dein Projekt

Die folgende Tabelle fasst die drei Phasen mit Bandbreiten und den zugrunde liegenden Annahmen zusammen – als Ausgangspunkt für eine eigene Schätzung, nicht als Zusage. Verschiebt sich eine Annahme (z. B. mehrere parallele Systeme statt eines, keine internen IT-Kapazitäten), verschiebt sich auch die Bandbreite entsprechend nach oben.

Phase	Bandbreite (KMU, ein Use Case)	Zentrale Annahmen
1. Analyse & Freigaben	2–6 Wochen	Ein Prozess im Fokus, Daten grundsätzlich digital vorhanden, benannte Ansprechperson für Freigaben
2. Pilot	6–12 Wochen	Bestehende Modelle statt Eigenentwicklung, ein Team als Testgruppe, Erfolgskriterien vorher festgelegt
3. Rollout (erste Stufe)	4–10 Wochen je weiterem Team/Prozess	Positive Pilotentscheidung liegt vor, Schulungskapazität ist eingeplant, Betriebsverantwortung ist benannt

Eigenes Rechenmodell Philogic Labs, abgeleitet aus Beratungs- und Umsetzungsprojekten. Die Summe aus Phase 1 und 2 – grob zwei bis vier Monate bis zum ersten belastbaren Pilotergebnis – ist die Zahl, die ich Unternehmen für die erste Budgetplanung nenne. Alles, was diese Bandbreite deutlich unterschreitet, hat wahrscheinlich eine der Phasen übersprungen.

So nutzt du die Tabelle: Trage für dein Projekt ein, welche Annahme nicht zutrifft (z. B. „Daten liegen in drei getrennten Systemen ohne einheitliche Struktur”) und addiere pro abweichender Annahme grob ein bis drei Wochen Puffer auf die jeweilige Phase. Das ersetzt keine Detailplanung, gibt aber eine ehrlichere erste Zahl als eine pauschale Angabe „vier bis sechs Wochen für die KI-Einführung”, wie sie in vielen Angeboten kursiert.

Umsetzung: wie du den Zeitplan realistisch hältst

Aus der Praxis heraus haben sich bei mir vier Ansatzpunkte bewährt, um Zeitpläne einzuhalten statt sie ständig nachzuverhandeln:

• Datenzugang und Freigaben vor dem Start klären, nicht während des Piloten. Jede Klärung, die erst im laufenden Pilot passiert, kostet doppelt: einmal die eigentliche Klärung, einmal die Unterbrechung des Testbetriebs.
• Eine Ansprechperson pro Freigabe-Entscheidung benennen. Wenn eine Entscheidung „das Team” statt einer Person gehört, dauert sie fast immer länger als nötig.
• Erfolgskriterien vor dem Pilotstart schriftlich festhalten. Das verhindert nachträgliche Diskussionen darüber, was „erfolgreich” eigentlich bedeutet hätte – ein häufiger Grund, warum Pilotphasen sich verlängern, ohne dass sich fachlich etwas ändert.
• Puffer für Datenqualitätsprobleme einplanen, nicht hoffen, dass es keine gibt. In fast jedem Piloten zeigen sich im Betrieb Datenprobleme, die vorher nicht sichtbar waren. Das ist normal, kein Zeichen für ein gescheitertes Projekt – aber nur, wenn dafür Zeit eingeplant ist.

Wenn intern die Kapazität oder Erfahrung fehlt, diese Klärungen selbst zügig zu treiben, ist das ein legitimer Grund für externe Unterstützung – nicht, weil die Technik zu komplex wäre, sondern weil die Koordination zwischen Fachbereich, IT und Datenschutz Erfahrung braucht, um nicht wochenlang zu stocken.

Risiken & Grenzen

Ein paar ehrliche Einschränkungen zu den genannten Bandbreiten:

• Sie gelten für Projekte mit bestehenden Modellen, nicht für Eigenentwicklung. Wer ein Modell selbst trainieren oder tiefgreifend anpassen will, muss mit deutlich längeren und schwerer planbaren Zeiträumen rechnen – das ist ein anderes Projektprofil als der hier beschriebene Einstieg über bestehende Werkzeuge.
• Sie gelten für einen Use Case, nicht für ein Portfolio. Mehrere parallele Piloten verlängern nicht automatisch jeden einzelnen, verlangsamen aber fast immer die Gesamtorganisation, weil Aufmerksamkeit und Freigabekapazität begrenzt sind.
• Regulatorische Prüfungen können die Bandbreite sprengen. Bei Use Cases mit Bezug zu Personalentscheidungen oder anderen sensiblen Bereichen können zusätzliche rechtliche Prüfungen nötig werden, die sich nicht pauschal in Wochen beziffern lassen. Das ist keine Rechtsberatung – im Zweifel gehört diese Einschätzung zu einer Datenschutz- oder Rechtsberatung, nicht in eine Zeitplan-Tabelle.
• Keine Zahl hier ist eine Zusage. Jede Bandbreite in diesem Artikel basiert auf Annahmen, die für dein Projekt anders aussehen können. Sie sind ein Startpunkt für eine eigene Schätzung, kein Angebot.

Was du aus diesem Artikel nicht bekommst, ist eine Aussage darüber, ob sich ein KI-Projekt bei dir lohnt oder welche Kosten konkret entstehen – dazu gibt es eigene Artikel in unserer Kategorie Kosten & ROI. Wenn eine strukturierte Schulung der Mitarbeitenden Teil deines Zeitplans werden soll, findest du dazu mehr auf unserer Schulungsseite.

Checkliste: Zeitplan für dein KI-Projekt

1. Der Use Case ist auf einen Prozess begrenzt – nicht „KI im ganzen Unternehmen”.
2. Datenzugang ist geprüft: Wo liegen die Daten, wer darf zugreifen, in welcher Qualität?
3. Es gibt eine benannte Person, die Freigaben entscheiden darf – nicht „das Team”.
4. Datenschutzprüfung läuft parallel zur Anbieterauswahl, nicht erst danach.
5. IT-Ressourcen für den Piloten sind eingeplant, nicht nur „bei Gelegenheit” verfügbar.
6. Erfolgskriterien für den Piloten stehen schriftlich fest, bevor der Pilot startet.
7. Für die Pilotlaufzeit ist ein realistischer Puffer für Datenqualitätsprobleme eingeplant.
8. Rollout ist als eigener, gestufter Schritt geplant – nicht als automatische Verlängerung des Piloten.
9. Schulung, Integration und Betriebsverantwortung sind für den Rollout konkret benannt.
10. Der Gesamtzeitplan bildet alle drei Phasen ab – nicht nur die Entwicklungszeit.

Wenn du deinen Zeitplan gegen diese Liste geprüft hast und noch offene Fragen bleiben, klären wir sie am besten in einem kostenlosen Erstgespräch oder direkt im Rahmen unseres Beratungsangebots – dort schauen wir uns deinen konkreten Use Case an und schätzen Zeit und Budget mit deinen tatsächlichen Annahmen ein, nicht mit generischen Bandbreiten.