Das Auge des Sturms
In der norddeutschen Seefahrt weiß man: Ein Sturm ist kein Grund zur Panik, solange das Schiff seetüchtig ist und klar ist, wer was zu tun hat. Was viele IT-Organisationen im gehobenen Mittelstand gerade erleben, ist kein Sturm aus einer Richtung. Es ist eine Wetterlage, in der mehrere Fronten gleichzeitig aufziehen.
Regulatorische Anforderungen auf der einen Seite. KI-Druck aus den Fachbereichen auf der anderen. Dazwischen: eine Infrastruktur, die seit Jahren nur noch im laufenden Betrieb stabil gehalten wird, weil für echte Modernisierung nie der richtige Moment kam.
Das trifft auf IT-Leitungen, die keine freie Hand mehr haben. Betrieb, Sicherheit, Projekte, Tagesgeschäft – alles bindet, was da ist. Die eigentliche Frage ist deshalb nicht mehr, wie schnell man reagiert. Sie lautet: Ist das Schiff noch steuerbar?
Was Regulatorik wirklich verlangt
NIS2, AI Act, TISAX, branchenspezifische Audits – was sich auf der Oberfläche wie ein aufeinanderfolgender Anforderungsschwall liest, hat im Kern eine gemeinsame Logik: Unternehmen sollen IT-Risiken kennen, steuern und im Ernstfall handeln können. Wer das kann, besteht auch eine Prüfung. Wer das nicht kann, besteht sie auch mit der besten Dokumentation nicht.
Die ehrliche Lage in vielen mittelständischen IT-Organisationen sieht so aus: Es gibt guten Willen, aber kein belastbares Lagebild. Verantwortlichkeiten sind gewachsen, nicht definiert. Systeme und Prozesse, die für Compliance relevant wären, sind nicht vollständig inventarisiert – geschweige denn bewertet. Wer in dieser Situation mit NIS2 anfängt, stochert im Dunkeln.
Das eigentliche Governance-Thema ist deshalb nicht: welchen Paragrafen erfülle ich als nächstes? Die Fragen, die wirklich zählen, lauten:
- Wer trägt im Unternehmen erkennbar Verantwortung für IT-Risiken – nicht auf dem Papier, sondern im Alltag?
- Welche Systeme und Daten sind für den Betrieb wirklich kritisch – und wie belastbar ist das dokumentiert?
- Nach welchen Kriterien werden Maßnahmen priorisiert, wenn alles gleichzeitig als dringend gilt?
Wer diese Fragen beantworten kann, hat eine Governance-Basis. Regulatorische Anforderungen werden dann zum Kalibrierungsrahmen, nicht zum Selbstzweck. Wer sie nicht beantworten kann, sollte genau dort anfangen – und nicht bei der Auswahl eines Compliance-Tools.
Legacy: Was im Maschinenraum wirklich läuft
Altsysteme sind nicht automatisch ein Problem. Kritisch werden sie, wenn sie den heutigen Anforderungen an Sicherheit, Integrationsfähigkeit und Änderungstempo nicht mehr genügen – und trotzdem jeden Monat einen erheblichen Teil des IT-Budgets binden.
Das Muster ist in vielen Organisationen vertraut: Ein großer Teil der IT-Kapazität fließt in Wartung, Spezial-Support und Workarounds rund um Plattformen, für die es keine regulären Updates mehr gibt. Was an Modernisierung übrig bleibt, läuft unter Bedingungen, die kaum geregelte Wartungsfenster, knappe Ressourcen und konkurrierende Projekte kombinieren. Ampeln sind offiziell grün. Gefühlt nicht.
Typische Ausprägungen, die sich in der Praxis immer wiederholen:
- Betriebssysteme, die nur noch gegen Aufpreis mit Sicherheitsupdates versorgt werden, weil eine reguläre Ablösung immer wieder verschoben wurde – Jahr für Jahr, aus nachvollziehbaren Gründen, bis der Aufpreis zum Normalzustand wird
- Fachanwendungen, deren einzige Dokumentation im Kopf einzelner Mitarbeitender steckt – und die damit bei jedem Personalwechsel zum echten Risiko werden
- Schnittstellenketten zwischen Systemen, die niemand mehr vollständig überblickt, aber täglich produktionskritische Daten transportieren
Was viele unterschätzen: Viele Systeme, die heute als Legacy gelten, sind erst wenige Jahre alt – aber nicht konsequent gepflegt worden. IT-Investitionen, die nach einmaliger Einführung für sich laufen sollen, landen zwangsläufig wieder in derselben Falle. Aus einem frischen System wird über drei, vier Jahre ein gepflegtes Problem.
Der direkte Zusammenhang zur Governance ist nicht abstrakt: Wer nicht weiß, welche Systeme wirklich kritisch sind, kann keine Modernisierungsreihenfolge entwickeln, die trägt. Und wer keine Modernisierungsreihenfolge hat, kann auch keine belastbare Antwort auf Compliance-Fragen geben. Beides hängt am selben Haken.
IT und OT: Die unsichtbare Front
Im produzierenden Mittelstand kommt ein weiterer Faktor dazu, der in Governance- und Modernisierungsüberlegungen regelmäßig zu spät auftaucht: die Grenze zwischen IT und OT verschwimmt – und mit ihr die Verantwortung.
Wo früher Steuerungsanlagen in sich geschlossene Welten waren, sind heute Maschinen, Scanner, Sensoren und Spezialrechner fest mit ERP-Systemen, Cloud-Diensten und internen Netzwerken verbunden. Das schafft neue Möglichkeiten – und neue Einfallstore. Vor allem aber: organisatorische Graubereiche, die im Tagesgeschäft niemanden stören, bis es zu spät ist.
Die eigentlich heiße Frage ist nicht technischer Natur. Sie lautet: Wer ist verantwortlich, wenn eine vernetzte Anlage mit einem Betriebssystem ohne aktuelle Sicherheitsupdates zur Schwachstelle wird? IT? OT? Der Maschinenhersteller? Die Produktion? In der Praxis ist die Antwort häufig: niemand so richtig.
Was diese Lage so zäh macht: Produktionsanlagen laufen nicht selten 15 bis 20 Jahre. IT-Komponenten fallen nach wenigen Jahren aus dem Support. Wer diese unterschiedlichen Lebenszyklen nicht aktiv managt – mit abgestimmten Zuständigkeiten, geregelten Patchfenstern und einem gemeinsamen Bild über Netzwerksegmentierung – schiebt das Risiko vor sich her. Quartal für Quartal.
Für Regulatoren ist es unerheblich, ob eine Schwachstelle im Rechenzentrum oder an der Fräsmaschine sitzt. Die Organisation trägt die Verantwortung für beides. An der IT/OT-Schnittstelle entscheidet sich deshalb oft, ob Governance-Anforderungen in der Realität ankommen – oder an Abteilungsgrenzen scheitern.
KI im Mittelstand: Das Reihenfolge-Problem
KI-Tools, Copilot-Funktionen, automatisierte Assistenten – der Druck aus den Fachbereichen ist real und wächst. Controlling will Analysen schneller. Marketing will Texte in Minuten. Vertrieb will Zusammenfassungen auf Knopfdruck. Der Wunsch ist berechtigt.
Das Problem ist nicht die Idee. Das Problem ist die Reihenfolge.
KI-Einführungen im Mittelstand passieren häufig so: Ein Fachbereich testet ein Tool. Es funktioniert gut genug, also bleibt es. Irgendwann laufen fünf solcher Tools parallel, in unterschiedlichen Abteilungen, mit unterschiedlichen Daten – und ohne dass eine zentrale Stelle weiß, was überhaupt läuft. Die IT erfährt davon beim nächsten Audit, bei einem Sicherheitsvorfall, oder wenn jemand fragt, welche Unternehmensdaten eigentlich über externe Dienste laufen.
Was dann entsteht, ist Schatten-KI: unkontrollierte Nutzung, unklare Datenflüsse, keine dokumentierten Zuständigkeiten. Ein Governance-Rückstand, der sich mit jedem weiteren Tool still vergrößert.
Belastbare KI-Governance im Mittelstand ist kein Konzernprojekt. Es braucht drei Dinge: ein aktuelles Inventar der genutzten KI-Anwendungen, klare Verantwortlichkeiten für Freigabe und Überprüfung, und eine verständliche Richtlinie, die Mitarbeitenden tatsächlich erklärt, was erlaubt ist und was nicht. Wer mit diesen drei Dingen anfängt, hat eine handhabbare Basis. Keine Stabsstelle. Kein Steering Committee. Nur Klarheit darüber, was läuft – und wer dafür den Kopf hinhält.
Drei Beschleuniger, ein überlastetes System
Stellt man diese Stränge nebeneinander, ergibt sich ein konsistentes Bild:
Regulatorik erhöht den Druck auf Transparenz, dokumentierte Verantwortung und Nachweisbarkeit. KI erhöht das Tempo der Erwartungen – aus den Fachbereichen, vom Markt, von der Geschäftsführung. Legacy-Landschaften und IT/OT-Verflechtungen begrenzen die tatsächliche Beweglichkeit, binden Kapazitäten und erschweren jede strukturelle Änderung.
Das Ergebnis: IT-Leitungen verbringen den größten Teil ihrer Zeit damit, den Betrieb stabil zu halten, kurzfristige Risiken abzufangen und auf Ad-hoc-Anforderungen zu reagieren. Zu viele Vorhaben laufen parallel, greifen auf dieselben Schlüsselpersonen zu – und niemand verantwortet das Gesamtlastbild. Raum für strukturierte Modernisierung und sauberen KI-Aufbau bleibt kaum.
Das ist kein technisches Versagen. Es ist ein Führungs- und Governance-Thema.
Eine übervolle Projektliste ist noch keine Strategie. Alles ist wichtig, nichts kommt in eine tragfähige Reihenfolge – und Entscheidungen werden vertagt, solange der Betrieb irgendwie läuft. Der Moment, in dem das kippt, kommt in der Regel unangekündigt: ein Sicherheitsvorfall, ein Systemausfall, ein Audit, das zeigt, was nicht dokumentiert ist. Bis dahin hat man meistens zu viel Zeit damit verbracht, auf die falsche Frage zu antworten.
Vom Projektstapel zur steuerbaren Roadmap
Der Weg aus dieser Gleichzeitigkeit führt nicht über einen weiteren Plan, der oben auf die bestehende Projektliste gesattelt wird. Er führt über ein nüchternes Lagebild – und die Bereitschaft, Vorhaben bewusst zu stoppen, zu verschieben oder neu zuzuschneiden.
In der Praxis hat sich ein dreistufiges Vorgehen bewährt:
Erstens: Lage sichtbar machen – ehrlich, nicht schöngerechnet.
Nicht im stillen Kämmerlein, sondern im Austausch zwischen IT, OT-Verantwortlichen, Fachbereichen und Management. Welche Systeme wären bei Ausfall wirklich kritisch? Wo liegen die größten Risiken durch technische Schulden oder ungeklärte Zuständigkeiten an der IT/OT-Grenze? Welche KI-Nutzungen laufen bereits – und unter welchen Bedingungen? Wer dabei mitmacht, muss aushalten, dass das Bild unbequem wird. Das ist keine Schwäche. Das ist der einzig sinnvolle Ausgangspunkt.
Zweitens: Wenige, aber wirksame Handlungsstränge definieren.
Statt zehn parallele Initiativen obendraufzustarten, werden aus dem Lagebild drei bis fünf Handlungsstränge abgeleitet, die den größten Hebel haben:
- Mindest-Governance und Resilienz: sicherstellen, dass das Unternehmen einen ernsthaften Sicherheitsvorfall übersteht, ohne die Geschäftsfähigkeit zu verlieren – mit Backup- und Recovery-Konzept, klar definierten Incident-Prozessen und eindeutigen Rollen
- Fokussierte Legacy-Reduktion: nicht alle Altsysteme gleichzeitig, sondern die wenigen Plattformen identifizieren, deren Ausfall oder Wissensverlust wirklich existenziell wäre – und dafür einen konkreten Pfad entwickeln, der auch unter Betriebsdruck durchhaltbar ist
- Schlanke KI-Governance mit einem bewusst gewählten Piloten: einen für das Geschäft relevanten Anwendungsfall sauber einbetten, Verantwortlichkeiten klären, Datenflüsse verstehen – und daraus ein einfaches Governance-Modell ableiten, das danach skaliert
Jeder Strang braucht einen klaren Auftrag, eine verantwortliche Rolle und grobe Meilensteine. Alles andere wird bewusst zurückgestellt – oder gestoppt.
Drittens: Entscheidungsroutinen einführen, die tatsächlich funktionieren.
Wer priorisiert, wenn Ressourcen knapp sind? Wer entscheidet, wenn zwei Vorhaben dieselben Schlüsselpersonen gleichzeitig beanspruchen? In welchem Rhythmus wird der Fortschritt nicht nur berichtet, sondern bewertet – und von wem? Das braucht kein aufwendiges PMO-Setup. Wichtig ist, dass es verbindlich gelebt wird. Nicht auf der Folie. Im Alltag.
Was jetzt konkret zählt
Der Druck auf mittelständische IT-Organisationen wird nicht abnehmen. Regulatorische Anforderungen folgen aufeinander, die Erwartungen an KI-Nutzung steigen weiter, und Legacy-Schulden verzinsen sich – in Form von Wartungskosten, Sicherheitsrisiken und eingeschränkter Handlungsfähigkeit.
Sinnvolle nächste Schritte:
- Relevanz und Verantwortlichkeiten klären. In welchen Regulierungsrahmen fällt das Unternehmen tatsächlich – inklusive OT-Anteil? Und wer trägt erkennbar Verantwortung dafür – nicht auf dem Papier, sondern im Alltag?
- Kritische Systeme und Schatten-KI inventarisieren. Welche Systeme wären bei Ausfall existenziell? Welche KI-Tools laufen bereits in Fachbereichen – und wer weiß das überhaupt?
- Lagebild und Roadmap aufsetzen. Aus diesen Erkenntnissen ein kompaktes Bild ableiten: Risiken, laufende Vorhaben, geplante Maßnahmen – und daraus drei bis fünf priorisierte Handlungsstränge, die wirklich geführt werden. Nicht verwaltet. Geführt.
- Einen verbindlichen Steuerungstakt einführen. Monatliche Entscheidungsrunden, in denen Projekte nicht nur berichtet, sondern aktiv priorisiert werden – mit klaren Kriterien, wer was entscheidet.
Wer so vorgeht, verlässt die Rolle des Getriebenen. Nicht weil alle Probleme gelöst wären, sondern weil das Schiff wieder einen Kurs hat – und weil klar ist, wer dafür die Hand hebt.
In der Seefahrt heißt das: nicht auf besseres Wetter warten, sondern die Segel richtig setzen.
EFFICAS begleitet CIOs, IT-Leitungen und Programmverantwortliche im gehobenen Mittelstand dabei, aus unübersichtlichen IT-Lagen steuerbare Strukturen zu machen – durch Interim IT-Management, methodische IT-Projektleitung und strategische IT-Beratung.