Es gibt ein Muster, das wir in fast jedem DACH-Engagement sehen. Die KI-Initiative ist sauber gescopt. Der Workflow ist identifiziert. Der Business Case steht. Dann fragt jemand: „Woher kommen die Daten?" Und die Antwort umfasst ein 15 Jahre altes ERP-Modul, einen nächtlichen Batch-Export, drei Excel-Dateien, die eine einzelne Person in der Buchhaltung pflegt, und einen FTP-Server, von dem niemand mehr weiß, wer ihn konfiguriert hat.
Das KI-Projekt ist nicht an der KI gescheitert. Es ist auf den Legacy-Stack aufgelaufen.
Der echte Blocker ist nicht KI — sondern die Schicht darunter
Die meisten Gespräche über KI-Readiness drehen sich um Modelle, Prompts und Tooling. Das sind weitgehend gelöste Probleme: Ein gutes Modell anzubinden ist heute eine Frage von Tagen, nicht von Quartalen. Das ungelöste Problem in den meisten Mittelstandsunternehmen liegt eine Ebene tiefer — bei den Systemen, die Daten halten, Prozesse ausführen und die Geschäftslogik miteinander verbinden.
Wenn wir Discovery-Engagements durchführen, ist die erste Dimension, die wir bewerten, die Datenzugänglichkeit. Nicht Datenqualität im Abstrakten — sondern die schlichte Frage, ob die relevanten Daten in einem vertretbaren Zeitrahmen extrahiert, transformiert und in einen Workflow eingespeist werden können. In einer ernüchternd großen Zahl der Fälle lautet die Antwort: nicht, ohne vorher den Legacy-Stack anzufassen.
Das ist keine Randnotiz für die IT. Es ist die Variable, die über Tempo, Kosten und Risiko der gesamten KI-Initiative entscheidet — und sie wird in Vorstandsvorlagen fast immer unterschätzt.
Was „Legacy" für KI tatsächlich bedeutet
Legacy hat nichts mit dem Alter zu tun. Eine 20 Jahre alte SAP-Installation mit sauberen APIs und dokumentierten Schnittstellen ist in keiner relevanten Hinsicht Legacy. Eine drei Jahre alte Eigenentwicklung mit hardcodierten Business-Regeln, ohne Testabdeckung und mit manuellen Deployments dagegen sehr wohl.
Für KI-Zwecke wird ein System dann zum Legacy-System, wenn die Daten eingesperrt sind: keine APIs, keine Webhooks, keine Event-Streams. Daten herauszubekommen heißt dann Screen Scraping, Datenbank-Views, die brechen, sobald jemand einen Spaltennamen ändert, oder das Bitten jener einen Person, die den Export-Prozess noch im Kopf hat. Es wird zum Legacy-System, wenn die Prozesslogik implizit ist — wenn Business-Regeln in Stored Procedures, Spreadsheet-Makros oder den Köpfen langjähriger Mitarbeitender leben und sich nicht verstehen lassen, ohne das System auszuführen. Es wird zum Legacy-System, wenn Änderungen gefährlich sind, weil jede Modifikation wochenlange Planung, manuelle Tests und ein Deployment-Fenster am Sonntagabend erfordert, ohne Staging-Umgebung und ohne Rollback. Und es wird zum Legacy-System, wenn die Integration fragil ist: Punkt-zu-Punkt-Verbindungen über File-Drops, geteilte Datenbanken oder Middleware, deren letztes Update Jahre zurückliegt.
Sobald KI-Workflows aus solchen Systemen lesen, in sie schreiben oder mit ihnen integrieren müssen, kommt die Initiative zum Stillstand — nicht wegen KI-Limitierungen, sondern weil das Fundament die Last nicht trägt.
Das Modernisierungsspektrum
Der Reflex bei Legacy-Systemen ist, eine große Migration zu planen: alles ersetzen, in die Cloud gehen, neu anfangen. Für eine KI-getriebene Modernisierung ist das fast immer falsch — teuer, langsam und mit einem Risikoprofil, das in keinem Verhältnis zum eigentlichen Engpass steht. Statt eines Programms arbeiten wir über ein Spektrum von Interventionen, jeweils gewählt auf Basis des konkreten Blockers.
Stabilisieren (Wochen, nicht Monate). Oft muss das Legacy-System gar nicht ersetzt werden. Es braucht eine stabile Schnittstelle: einen API-Wrapper um eine Datenbank-View, eine Message Queue, die das Legacy-System von nachgelagerten Konsumenten entkoppelt, eine Datenpipeline, die extrahiert, was der KI-Workflow braucht, ohne den Kern anzufassen. Das ist die häufigste und zugleich die am meisten unterschätzte Intervention. Stabilisierung repariert das Legacy-System nicht — sie macht es überlebbar, während der KI-Workflow produktiv läuft.
Entkoppeln (1–3 Monate). Wenn das Legacy-System eng an andere Systeme gekoppelt ist — geteilte Datenbanken, synchrone Aufrufe, hardcodierte Integrationen —, ist der Blocker nicht das System selbst, sondern das Abhängigkeitsnetz. Entkopplung führt Integrationsschichten, eventgetriebene Muster oder API-Gateways ein, die dem KI-Workflow unabhängiges Arbeiten ermöglichen. Das Legacy-System läuft weiter wie bisher; eine neue Integrationsschicht sitzt daneben; der KI-Workflow verbindet sich mit dieser Schicht, nicht direkt mit dem Altsystem.
Selektiv modernisieren (3–6 Monate). Manche Komponenten müssen neu gebaut werden — aber nur diejenigen, die die KI-Initiative direkt blockieren. Das ist keine Full-Migration, sondern chirurgische Modernisierung: das Intake-Modul ersetzen, weil der KI-Workflow strukturierte Daten daraus braucht, aber das dahinterliegende Verwaltungssystem in Ruhe lassen, weil kein Workflow es berührt.
Migrieren (6–18 Monate, paralleler Track). Eine vollständige Migration ist manchmal nötig — aber sie sollte parallel zur KI-Delivery laufen, nicht als deren Voraussetzung. Die Initiative darf nicht 18 Monate auf eine saubere Plattform warten. Modernisierung und Workflow laufen gleichzeitig, wobei Stabilisierung und Entkopplung die Brücke bilden. Für Unternehmen, die diesen Weg erwägen, wird die Frage traditionelle Migration vs. KI-Shift-Timing zunehmend relevant.
Modernisierung ist kein Nice-to-have mehr — sie wird reguliert
Bis vor Kurzem ließ sich Legacy-Modernisierung als reine Kostenfrage führen und damit endlos vertagen. Das stimmt 2026 nicht mehr. Zwei europäische Regelwerke verschieben die Rechnung.
Mit dem EU AI Act gelten die Kernpflichten für Hochrisiko-KI-Systeme nach den Artikeln 8 bis 15 ab dem 2. August 2026. Dazu zählen ein dokumentiertes Risikomanagement, belastbare Daten-Governance, technische Dokumentation, automatisches Logging und menschliche Aufsicht über den gesamten Lebenszyklus. Wer einen KI-Workflow aus undokumentierten Stored Procedures und manuellen Excel-Anpassungen speist, kann eine solche Daten-Governance schlicht nicht nachweisen — nicht weil das Modell schlecht ist, sondern weil das Fundament keine Nachvollziehbarkeit zulässt. Saubere, auditierbare Datenpfade sind damit von einer Hygiene- zu einer Compliance-Anforderung geworden.
Parallel hat Deutschland die NIS2-Richtlinie umgesetzt: Das novellierte BSI-Gesetz ist seit dem 6. Dezember 2025 bindend, und es zieht den Kreis der betroffenen Unternehmen drastisch weiter. Nach Angaben des BSI fallen nun mehr als 29.500 Unternehmen unter das BSIG — rund fünfmal so viele wie zuvor —, weil neue Sektoren wie das verarbeitende Gewerbe ausdrücklich erfasst sind. Für den industriellen Mittelstand heißt das: Risikomanagement, Meldepflichten und Management-Verantwortung gelten jetzt auch für genau jene fragilen Punkt-zu-Punkt-Integrationen und ungepatchte Middleware, die einen KI-Workflow blockieren. Die Registrierungsfrist beim BSI lief für bereits erfasste Einrichtungen drei Monate nach dem 6. Dezember 2025 — eine späte Registrierung bleibt möglich, ist aber selbst bußgeldbewehrt.
Der Punkt ist nicht, Angst zu schüren. Der Punkt ist, dass derselbe Legacy-Stack, der Ihre KI-Initiative ausbremst, zunehmend auch Ihr regulatorisches Risiko ist. Wer ihn im Dienste der KI-Delivery aufräumt, adressiert beides mit demselben Budget.
Das Modernisierungs-Readiness-Assessment
Bevor Sie eine Intervention wählen, müssen Sie wissen, wo der Legacy-Druck am höchsten ist. Wir bewerten sechs Dimensionen. Die Systemkomplexität und technischen Schulden — wie viel undokumentierte Logik, wie viele Abhängigkeiten, wie fragil die Deployment-Kette. Die operativen Engpässe — wo Teams warten, um das System herumarbeiten oder Einschränkungen manuell kompensieren. Die Delivery-Friction — wie lange eine Änderung von „gebaut" bis „sicher deployt" braucht. Die Integrationsabhängigkeiten — wie viele Systeme angebunden und wie viele dieser Verbindungen fragil, undokumentiert oder von einer einzelnen Person betreut sind. Die Support-Last — wie viel Aufwand in den laufenden Betrieb statt in Verbesserungen fließt. Und die Modernisierungs-Blocker — was die Organisation überhaupt zurückhält: Budget, Wissensverlust, Risikotoleranz, politische Zugehörigkeit.
Jede Dimension erhält einen Schweregrad und eine empfohlene Intervention. Das Ergebnis ist keine Roadmap, sondern ein klares Bild davon, wo man anfängt und was zuerst kommt. Die detaillierte Methodik finden Sie in unserem Legacy Readiness Check Framework.
Wie das in der Praxis aussieht
In einem Engagement im Mobilitätssektor benötigte der KI-Workflow Abrechnungsdaten von einer älteren Plattform. Die Daten existierten, aber ihre Extraktion lief über eine Kette aus mehreren Stored Procedures, manuellen Excel-Anpassungen und einem wöchentlichen Batch-Lauf — fragil, langsam und von einzelnen Personen abhängig.
Wir haben die Abrechnungsplattform nicht ersetzt. Wir haben eine Datenpipeline daneben gebaut: Change-Data-Capture-Events aus der Datenbank, die in eine Message Queue fließen und vom KI-Workflow konsumiert werden. Das Legacy-System lief unverändert weiter. Der Workflow erhielt frische Daten in kurzen Intervallen statt einmal pro Woche — und die Extraktion war zum ersten Mal nachvollziehbar protokolliert statt in Tabellenblättern verstreut.
Das ist das Muster: Die Stabilisierung dauert Wochen, nicht Monate. Die eigentliche Plattform-Migration läuft danach auf einem eigenen Track weiter — aber der KI-Workflow ist längst in Produktion und liefert Wert, während die Modernisierung im Hintergrund voranschreitet. Lassen Sie nicht zu, dass Modernisierung zur Voraussetzung für KI wird. Machen Sie sie zu einem parallelen Track und bauen Sie die Brücke, die KI laufen lässt.
Die Kosten des Wartens
Die teuerste Entscheidung ist, weder das eine noch das andere zu tun: nicht modernisieren und keine KI deployen. Jeder Monat Inaktivität verschärft das Problem. Der Legacy-Stack driftet weiter von modernen Standards ab. Die Menschen, die ihn verstehen, kommen der Rente näher. Die technischen Schulden akkumulieren Zinsen — und seit 2026 kommen regulatorische Fristen hinzu, die sich nicht verhandeln lassen.
Gleichzeitig betreiben Wettbewerber, die das Integrationsproblem gelöst haben — auch unelegant, auch mit Workarounds —, produktive KI-Workflows, deren Wertschöpfung sich Woche für Woche summiert. Die Frage ist nicht, ob modernisiert werden soll. Die Frage ist, ob strategisch modernisiert wird, im Dienste der KI-Delivery, oder reaktiv, wenn das Legacy-System endgültig versagt oder ein Audit es erzwingt.
Ein Fit Call klärt in 30 Minuten, welcher Hebel — Stabilisieren, Entkoppeln oder selektiv modernisieren — Ihre KI-Initiative am schnellsten ins Laufen bringt, bevor der Legacy-Stack zum Engpass für Delivery und Compliance zugleich wird.
Quellen: EU Artificial Intelligence Act, „Implementation Timeline" (artificialintelligenceact.eu/implementation-timeline); DLA Piper, „NIS 2 Directive Transposed in Germany — Time to Register with the BSI", 2026; Europäische Kommission, „NIS2 Directive implementation in Germany" (digital-strategy.ec.europa.eu).