Strategiepapiere erzeugen keine operative Hebelwirkung. Deployte Workflows schon. Die meisten KI-Initiativen im Mittelstand scheitern nicht an der Technologie — sie scheitern daran, dass nie ein Datum existiert, an dem etwas produktiv gehen muss. Genau diese Lücke schließt ein 13-Wochen-Umsetzungskalender: Er bringt eine Organisation von der nüchternen Bewertung des Ist-Zustands zu einem governten, täglich laufenden KI-Workflow mit Lernschleifen — der Infrastruktur, auf der sich Wirkung aufaddiert statt einmalig zu verpuffen.
Das ist kein theoretisches Framework. Es ist ein Kalender mit harten Stichtagen, drei verbindlichen Decision Gates und einer Teamstruktur, die zur Realität eines Mittelständlers passt — nicht zu der eines Konzerns mit eigener Data-Science-Abteilung. Wer 13 Wochen ernst nimmt, hat am Ende eine Fähigkeit. Wer sie als grobe Richtschnur behandelt, hat nach zwölf Monaten ein Pilotprojekt, über das niemand mehr spricht.
Drei Phasen, drei Gates, ein binäres Prinzip
Die 13 Wochen gliedern sich in drei Phasen. Discovery (Wochen 1–2) bewertet den Ist-Zustand und entscheidet, welcher Workflow zuerst produktiv geht. Accelerator (Wochen 3–8) baut und deployt diesen ersten Workflow, bis er messbare Hebelwirkung erzeugt. OS Build (Wochen 9–13) installiert die Governance-Baseline, aktiviert Lernschleifen und skaliert auf einen zweiten Workflow — der Beweis, dass ein System existiert und kein Glücksfall.
Jede Phase endet mit einem Decision Gate, und jedes Gate ist bewusst binär: weiter zur nächsten Phase, oder stoppen und den Blocker beheben. Es gibt keinen dritten Zustand „läuft so halb mit". Gates zu überspringen ist der zuverlässigste Weg, wie aus einem 90-Tage-Plan ein 12-Monats-Projekt wird — weil ungelöste Probleme aus Woche 4 in Woche 11 nicht verschwunden, sondern teurer geworden sind.
Phase 1: Discovery — die Entscheidung erzwingen
Das Ziel der Discovery ist nicht, Möglichkeiten zu erkunden. Es ist, eine einzige Entscheidung zu treffen: Welcher Workflow geht zuerst produktiv. Alles, was diese Entscheidung nicht schärft, gehört nicht in diese zwei Wochen.
Woche 1 ist eine Untersuchung, kein Workshop. Den Einstieg bildet eine strukturierte Bewertung der sechs Dimensionen — Workflow-Readiness, Datenzugänglichkeit, Entscheidungsautorität, Compliance-Posture, Teamkapazität und Klarheit über das Operating Model. Jede Dimension wird ehrlich als blockierend, schwach, adäquat oder stark eingestuft. Parallel entstehen drei Artefakte, die jede spätere Entscheidung tragen: eine Datenlandschaftskarte (wo liegen die relevanten Daten, wie kommt man an sie heran, wie führt der Pfad zum Workflow), eine Stakeholder-Map (wer ist Executive Sponsor, wer Domänenexperte, wer technischer Counterpart) und eine Compliance-Vorbewertung. Letztere ordnet die Kandidaten-Workflows in die Risikologik des EU AI Act ein und klärt die DSGVO-Implikationen, bevor eine Zeile Pipeline-Code entsteht. Die Arbeit besteht aus sechs bis acht Stakeholder-Interviews à 45 Minuten, einer technischen Datenbewertung (Systemzugang, API-Verfügbarkeit, Datenqualität) und einer Sichtung bestehender Prozessdokumentation. Der häufigste Fehler in dieser Woche ist, sie mit strategischen Alignment-Meetings zu füllen. Wenn die Datenlandschaft bis Freitag nicht bewertet ist, rutscht der gesamte Zeitplan — und niemand merkt es, bis es zu spät ist.
Woche 2 trifft die Wahl und legt die Messlatte. Aus der Bewertung wählt das Team einen Workflow und dokumentiert die Begründung: warum dieser, warum jetzt, welcher Impact erwartet wird. Entscheidend ist die Baseline-Messung — aktueller Durchsatz, Fehlerquote, Zykluszeit und Kosten pro Einheit. Ohne diese Zahl gibt es später keine ehrliche ROI-Aussage, nur ein gutes Gefühl. Die KPI-Ziele werden für 30, 60 und 90 Tage nach Deployment fixiert, der Deployment-Plan skizziert Pipeline-Architektur, Integrationspunkte, Delegationslogik und Compliance-Ansatz. Bei der Auswahl gilt eine klare Hierarchie: hohe Workflow-Readiness, Daten innerhalb von zwei bis drei Wochen erreichbar (keine Multi-Monats-Infrastruktur als Voraussetzung), ein Executive Sponsor mit echter Autorität und genug Volumen für messbaren Impact. Für das erste Deployment ist es klug, bewusst keinen Workflow zu wählen, der unter dem EU AI Act als hochriskant gilt — also etwa kein automatisiertes Bewerber-Screening oder Kreditscoring. Diese Anwendungen fallen unter Annex III, und die volle Pflichtenlast für solche Systeme greift im Omnibus-Kompromiss erst ab dem 2. Dezember 2027. Den ersten Erfolg holt man sich anderswo: in der Sachbearbeitung, im Angebotswesen, in der Dokumentenverarbeitung — dort, wo Volumen, klare Erfolgskriterien und ein überschaubares Compliance-Profil zusammenkommen.
Decision Gate 1 ist erreicht, wenn der gewählte Workflow über alle sechs Dimensionen adäquat scort, die Baseline gemessen ist und der Executive Sponsor den Plan freigibt. Fehlt eines davon, wird der Blocker behoben, bevor es weitergeht — nicht parallel zu Phase 2, sondern davor.
Phase 2: Accelerator — kein Pilot, ein Produktionsprogramm
Der Accelerator ist ausdrücklich kein Pilot. Ein Pilot darf folgenlos scheitern; dieses Programm zielt auf einen Workflow, der täglich läuft, echtes Volumen verarbeitet und messbare Hebelwirkung erzeugt. Der Unterschied ist nicht semantisch — er bestimmt, wie ernst die Organisation Datenqualität, Eskalationspfade und Übergabe nimmt.
Wochen 3–4 bauen das Fundament. Zuerst die Datenpipeline: angebunden an die Quellsysteme, mit Extraktions- und Transformationslogik, Validierungschecks und Monitoring. Erst danach der Kontext-Layer — die Wissensbasis aus Domänenregeln, Ausnahmen und Referenzdaten, gespeist aus Interviews mit den Fachexperten und über RAG-Retrieval zugänglich gemacht. Parallel entsteht der Workflow-Prototyp, der reale Inputs end-to-end verarbeitet, sowie ein erster Entwurf der Delegationsmatrix. Compliance läuft hier mit, nicht hinterher: Logging und Audit-Trails werden eingebaut, während der Workflow entsteht. Der teuerste Fehler dieser Phase ist, das Modell zu bauen, bevor die Pipeline steht. Eine unzuverlässige Datenbasis macht jede spätere Genauigkeitsmessung wertlos — also zuerst die Pipeline stabilisieren, dann den Rest.
Wochen 5–6 gehen live und kalibrieren. Der Workflow verarbeitet ab jetzt täglich reale Inputs, unter Monitoring und Alerting. Domänenexperten prüfen die Outputs jeden Tag etwa 30 Minuten, und aus den ersten 14 Tagen Performance-Daten — Genauigkeit, Durchsatz, Konfidenzverteilungen, Eskalationsraten — wird die Entscheidungsarchitektur kalibriert. Die Konfidenz-Schwellenwerte werden an die tatsächlich beobachtete Genauigkeit angepasst, nicht an eine Annahme: Was das Modell entscheiden darf und was an einen Menschen eskaliert, ergibt sich aus Daten, nicht aus Bauchgefühl. Eskalierte Fälle müssen den richtigen Bearbeiter mit dem richtigen Kontext erreichen — das wird explizit getestet. Und das betroffene Team wird gebrieft, wie sich seine Arbeit verändert, bevor es die Veränderung erlebt.
Wochen 7–8 stabilisieren und übergeben Wissen. Aus den Erkenntnissen der Vorwochen werden Prompts verfeinert, Wissensbasis-Lücken geschlossen und Prozesse angepasst. Die Betriebsverfahren werden dokumentiert — wer überwacht, wer entscheidet, wie Ausnahmen laufen — und der Review-Rhythmus aus täglichen Stichproben, wöchentlichen Qualitäts- und monatlichen Performance-Reviews wird etabliert. Am Ende steht der 30-Tage-Report: alle KPIs gegen die Baseline, plus eine nüchterne ROI-Rechnung aus gemessener Verbesserung mal Stückökonomie. Decision Gate 2 fragt drei Dinge: Erzeugt der Workflow messbare Hebelwirkung, sind die Verfahren dokumentiert und funktionsfähig, und betreibt das Team ihn ohne externe Hilfe? Bei einem klaren Ja geht es weiter; braucht es mehr Stabilität, wird Phase 2 lieber um zwei Wochen verlängert, als ein wackliges Fundament in Phase 3 zu tragen.
Phase 3: OS Build — aus einem Projekt eine Fähigkeit machen
Ein einzelner Workflow ist ein Projekt. Ein Betriebssystem ist eine Fähigkeit. Phase 3 installiert die Infrastruktur, die den Unterschied ausmacht — und der Lackmustest dafür ist der zweite Workflow.
Wochen 9–10 verankern Governance und Lernen. Die in Phase 2 entstandenen Delegationsregeln, Review-Verfahren und Compliance-Ansätze werden in wiederverwendbare Richtlinien kodifiziert. Hier zahlt sich die frühe Compliance-Arbeit aus: Eine sauber dokumentierte Governance-Baseline ist genau das, was der EU AI Act ab dem 2. August 2026 in Form der Transparenzpflichten nach Artikel 50 einfordert — Nutzer müssen erkennen, wann sie mit einem KI-System interagieren oder KI-generierte Inhalte vor sich haben. Wer diese Logik von Anfang an einbaut, muss sie später nicht nachrüsten. Parallel wird die Lernschleifen-Architektur aufgesetzt: KI-Outputs werden mit den nachgelagerten Ergebnissen verbunden, sodass aus 60 Tagen Daten konkrete Verbesserungskandidaten und schnelle Erfolge ablesbar werden. Und ein zweiter Workflow-Kandidat wird gegen die sechs Dimensionen bewertet — diesmal mit der Erfahrung des ersten Deployments im Rücken. Der wiederkehrende Fehler ist, Governance als Dokumentationsübung zu behandeln. Governance ist operativ: die Delegationsmatrix, der Review-Rhythmus, die Eskalationsregeln, die Lernschleifen. Existiert sie nur in einem Dokument, das im Tagesgeschäft niemand öffnet, ist sie kein Steuerungsinstrument, sondern Papierkram.
Wochen 11–12 beweisen die Aufaddierung. Der zweite Workflow wird gebaut und deployt — und zwar spürbar schneller als der erste, weil Pipeline-Muster, Governance-Framework und Teamfähigkeit bereits existieren. Genau hier entscheidet sich, ob ein Betriebssystem installiert ist. Dauert der zweite Workflow genauso lange wie der erste, war der erste ein Einzelfall. Braucht er einen Bruchteil der Zeit, hat die Organisation ein System zum Deployen von KI — und die Aufaddierung hat begonnen. Ein Cross-Workflow-Dashboard macht beide Workflows in einer Ansicht sichtbar, und der Governance-Stresstest zeigt, wo das Framework unter zwei Workflows bricht, solange die Reparatur noch billig ist.
Woche 13 etabliert den Rhythmus und übergibt. Es entsteht ein Operating-Cadence-Dokument mit wöchentlichen, monatlichen und quartalsweisen Routinen, ein 90-Tage-Report über beide Workflows und eine Skalierungs-Roadmap für die nächsten drei bis sechs Monate. Der eigentliche Wert liegt im Wissenstransfer: Das interne Team muss Betriebsverfahren, Review-Rhythmus und Lernanalyse eigenverantwortlich beherrschen. Decision Gate 3 stellt die einzige Frage, die zählt: Hat die Organisation ein funktionierendes KI-Betriebssystem — nicht nur deployte Workflows, sondern Governance, Lernschleifen und einen operativen Rhythmus, der ohne externe Hilfe trägt und aufaddiert? Lautet die Antwort Ja, ist die Installation abgeschlossen und die Organisation skaliert eigenständig weiter.
Was es vom Team wirklich verlangt
Diese 13 Wochen funktionieren nur mit verbindlich allokierten Menschen — und Unterbesetzung verlängert nicht die Liste der offenen Punkte, sondern den gesamten Zeitplan. Auf Kundenseite braucht es einen Executive Sponsor mit rund 10 Prozent seiner Zeit und der Bereitschaft, wöchentlich zu entscheiden; zwei bis drei Domänenexperten mit 20 bis 30 Prozent Allokation, die für Wissensbasis und Qualitätsprüfung unersetzlich sind; einen IT-Counterpart mit 15 bis 20 Prozent für Datenzugang und Integration; und ab Woche 5 einen Workflow-Owner mit etwa 30 Prozent, der den täglichen Betrieb verantwortet. Diese Zahlen sind keine Wunschvorstellung, sondern die Untergrenze. Wer den Sponsor nur als Namen auf einer Folie führt, scheitert spätestens an Decision Gate 1 — denn dann fehlt die Autorität, eine Entscheidung in 48 Stunden zu erzwingen.
Was schiefgeht — und wie Sie sich erholen
Vier Bruchstellen tauchen so regelmäßig auf, dass man sie einplanen sollte. Stockt Woche 2, weil die Organisation sich nicht auf einen Workflow festlegen kann, fehlt es meist an Autorität: Dann grenzen Sie auf zwei Kandidaten ein, legen beide der Geschäftsführung mit klarer Empfehlung vor und holen die Entscheidung binnen 48 Stunden ein. Stockt Woche 4 an unzugänglichen Daten — der häufigste Blocker überhaupt —, bauen Sie einen Workaround für das erste Deployment (manueller Export, CSV-Upload, direkter Datenbankzugriff) und die saubere Pipeline parallel; auf die perfekte Pipeline zu warten, bevor der Build startet, ist der teuerste Geduldsfehler im ganzen Kalender. Zeigt Woche 6 eine Genauigkeit unter den Erwartungen, ist das die Regel, nicht die Ausnahme: Analysieren Sie die Fehlermuster, denn der Großteil der Fehler geht erfahrungsgemäß auf eine Handvoll Grundursachen zurück — meist Lücken im Kontext-Layer oder fehlende Domänenregeln —, beheben Sie diese und messen Sie neu. Und wird Governance um Woche 10 als Overhead empfunden, weil das Team die Verfahren nur befolgt, weil man es ihm sagte, dann zeigen Sie ihm die Lerndaten: Sobald sichtbar wird, dass die eigenen Review-Erkenntnisse die eigene Arbeitslast gesenkt haben, wird aus Compliance-Pflicht ein Werkzeug, das das Team selbst verteidigt.
Der 90-Tage-Kalender entspricht Plan 3 (OS Build) auf der KI-Betriebssystem-Seite; Plan 1 (Discovery) und Plan 2 (Accelerator) decken dieselbe Methodik auf kleinerem Engagement-Level ab — zugeschnitten auf den Startpunkt Ihrer Organisation. Wie der erste Workflow danach zur dauerhaften Fähigkeit wird, vertieft Vom KI-Pilot zur Produktion; wie Sie den Wert sauber belegen, KI-ROI messen.
Ein Fit Call klärt in 30 Minuten, welcher Ihrer Workflows die beste erste Wahl für die 90 Tage ist — und welche der sechs Dimensionen Sie zuerst absichern müssen, bevor die Uhr läuft.
References: Europäische Kommission, „AI Act — Regulatory framework on AI", digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai; EU Artificial Intelligence Act, „Article 50: Transparency Obligations", artificialintelligenceact.eu/article/50; Gibson Dunn, „EU AI Act Omnibus Agreement — Postponed High-Risk Deadlines and Other Key Changes", 2026, gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines-and-other-key-changes.