Referenz-Story: KI in eine gewachsene Workplace-Landschaft bringen – warum die Architektur entscheidet

Anfang 2026 habe ich ein Mandat übernommen, das auf dem Papier nach einem klassischen Workplace-Projekt aussah. Ein Top-10-Versicherungskonzern stand vor der Frage, wie die Entwicklungsumgebungen seiner rund 370 internen Entwickler in Zukunft aussehen sollen: Die Entwickler-Arbeitsplätze - Hardware, Betriebssystem-Images, Toolchain - waren über Jahre heterogen gewachsen, und für die nächste Gerätegeneration brauchte es ein Zielbild statt einer Fortschreibung des Status quo. Der IT-Vorstand erwartete zum festen Termin eine Go/No-Go-Entscheidung auf Basis einer belegten Empfehlung mit messbarer Produktivitätswirkung.

Tatsächlich war es vor allem eine Architektur-Entscheidung, in der eine KI-Frage steckte. Drei Entscheidungen aus dem Mandat halte ich für übertragbar - und würde sie heute alle wieder so treffen.

Entscheidung 1: KI-Readiness wurde eine eigene Bewertungsdimension

Am Anfang standen zwölf mögliche Lösungswege im Raum - von Hardware-Standardisierung über WSL2 und DevContainer bis zu Cloud-Workstations. Das war bewusst noch keine Shortlist, sondern der volle Lösungsraum. Damit aus zwölf Wegen eine Empfehlung wird, die vor dem Vorstand trägt, braucht es mehr als Bauchgefühl: Wir haben die Kandidaten in einem gewichteten Framework vergleichbar gemacht - strategischer Fit, Umsetzbarkeit, Wirkung, Kosten - und so nachvollziehbar auf eine Shortlist verdichtet. So weit nichts Besonderes.

Die eigentliche Frage kam aus einem zweiten Vorhaben, das zeitgleich lief: Der Konzern wollte KI-Werkzeuge in die Software-Entwicklung bringen, und der übliche Weg dafür ist ein Tool-Rollout - Lizenzen kaufen, Plugin verteilen, fertig. Wir haben uns dagegen entschieden und stattdessen KI-Readiness als eigenständige Dimension in das Bewertungs-Framework aufgenommen, mit eigener Gewichtung.

Der Gedanke dahinter ist erstmal simpel: Ein KI-Coding-Assistent ist nur so viel wert wie die Umgebung, in der er läuft. Wenn jede Entwicklerin eine anders konfigurierte Maschine hat, wird aus dem Rollout ein Support-Fall. Die Workplace-Plattform muss die Werkzeuge strukturell tragen können - vorinstalliert, vorkonfiguriert, pro Entwicklerprofil. Damit war die Plattform-Entscheidung zugleich die KI-Entscheidung. Das hat die Rangfolge der Kandidaten sichtbar verschoben und die Empfehlung am Ende auf Cloud-Workstations gelenkt.

Entscheidung 2: Der PoC war Beleg, keine Techdemo

Vorstandsvorlagen scheitern selten an der Folienqualität, sondern eher daran, dass die Empfehlung nicht belegt ist. Deshalb haben wir den Proof of Concept nicht als nachgelagerte Techdemo geplant, sondern als Beleg für die Empfehlung: ein produktiver Pilotbetrieb mit 15 Workstations, geschichteten Images und der KI-Toolchain bereits an Bord - mit echten Entwicklern in laufenden Projekten, inklusive der Störungen, die man im Labor nie zu sehen bekommt.

Ehrlicherweise kostet das mehr als ein Laborlauf. Und es ist unbequemer, weil Findings sichtbar werden, bevor die Entscheidung überhaupt gefallen ist. Genau das war aber der Punkt: Die Vorstandsvorlage konnte auf einen laufenden Betrieb zeigen statt auf eine Annahme - auch wenn zu dem Zeitpunkt längst nicht jedes Finding gelöst war. Gerade das hat die Diskussion ehrlicher gemacht - gestritten wurde über reale Betriebserfahrung statt über Annahmen auf Folien.

Entscheidung 3: Die Compliance-Spur lief parallel, nicht sequentiell

Der Konzern hat eine gewachsene Gremienlandschaft - im konkreten Fall 13 Governance-Gremien mit Veto-Prinzip, dazu Betriebsvereinbarungen und Datenschutz-Freigaben. Häufig startet in solchen Programmen zuerst die Technik, und die Freigaben kommen erst gegen Ende auf den Tisch. Bei 13 Gremien mit Veto-Prinzip wäre der Rollout-Termin damit nicht zu halten gewesen.

Wir haben die Compliance-Artefakte deshalb von Beginn an parallel zur Technik bearbeitet, mit denselben Terminen: die Anlage zur Betriebsvereinbarung, das Datenschutz-Paket, die Sicherheitsklärung für die KI-Werkzeuge (Code-Abfluss, Geheimhaltung von Kerngeschäftslogik, DSGVO, EU AI Act). Das war zäh, und nicht jede Klärung war am Ende wirklich nötig. Aber die Vorstandsfreigabe hing an genau diesen Belegen - und die hätten sich nachträglich nicht in Wochen aufholen lassen.

Was ich daraus mitnehme

KI-Projekte scheitern selten am Modell. In diesem Mandat war so ziemlich jede echte Hürde - vom Berechtigungskonzept über die Image-Pflege bis zur Betriebsvereinbarung - eine Frage der Landschaft, nicht der KI. Wer eine gewachsene IT-Landschaft nicht lesen und verändern kann, bekommt auch die KI nicht hinein - jedenfalls nicht über den Pilotstatus hinaus.

Umgekehrt gilt das genauso: Eine Workplace-Modernisierung, die KI-Readiness nicht als Architektur-Anforderung mitdenkt, baut schlicht die nächste Altlast. Die nächste Werkzeug-Generation kommt so oder so - die Frage ist eher, ob die Plattform sie dann tragen kann.

Weiterführend aus dem Blog: Autonomiegrade von KI-Agenten und KI-Compliance nach dem AI Omnibus.

Steht bei Ihnen eine vergleichbare Architektur- oder Workplace-Entscheidung an? Genau dafür gibt es unser Cluster Architektur & Transformation im regulierten Umfeld - vom Review mit klarem Urteil bis zur Programmbegleitung. Oder direkt: Erstgespräch vereinbaren.