Die IT zur eigenen KI-Entwicklung befähigen

Ein großes Wohnungs­unternehmen hat in einem halben Jahr seine Regeln für den Umgang mit KI aufgebaut, und die nächste Schwierigkeit steht schon daneben. Struktur allein schafft keinen Nutzen. Die IT- und Prozess­landschaft ist von zwei großen Standard­systemen geprägt, die Kernprozesse laufen, und genau darin liegt das Problem — sie laufen gut genug, dass niemand sie anfasst, und schlecht genug, dass erhebliche Automatisierungs­potenziale offen bleiben. Verlangt sind deshalb drei Dinge gleichzeitig: quantifizierbare Mehrwerte, die den Mitarbeitenden kurzfristig helfen; eine Infrastruktur, auf der KI-Anwendungen dauerhaft betrieben und erweitert werden können; und der Aufbau der Fähigkeit, das künftig selbst zu tun. Das Ziel ist ausdrücklich Befähigung statt Abhängigkeit von externen Dienstleistern.

Die Begriffe zuerst, und das war keine Pedanterie. Der Grundlagenworkshop begann mit der Trennung von Rahmenwerk, Plattform, Architektur und Verzeichnis, weil diese Begriffe in der bisherigen Diskussion vermischt worden waren. Solange sie durcheinandergehen, führt jede Architektur­diskussion zu Scheinkonflikten: Zwei Beteiligte sind sich einig und benutzen verschiedene Wörter, zwei andere benutzen dasselbe Wort und meinen Unvereinbares.

Ein bestehendes Rahmenwerk erproben, statt eines zu entwickeln — und die Infrastruktur zuletzt. Für den Aufbau eigener Agenten wurde bewusst kein Eigenbau gewählt, sondern ein vorhandenes Rahmenwerk, zunächst zur Erprobung. Die Infra­struktur­entscheidung wurde ausdrücklich nachgelagert, weil sie sich nach der Ausgestaltung von Architektur und Rahmenwerk richtet. Die umgekehrte Reihenfolge — erst Infrastruktur beschaffen, dann herausfinden, was darauf laufen soll — ist der häufigste und teuerste Fehler dieser Projektart.

Die Referenz­architektur ist ein Startpunkt und wird instanziiert. Wir bringen eine Referenz­architektur und einen Technologie­stack mit; beide werden nicht übernommen, sondern in einem eigenen Schritt mit den realen Quellsystemen, Schnittstellen und Komponenten des Hauses gefüllt und anschließend in ein Lückenbild überführt. Erst dieses Lückenbild sagt, was zu tun ist. Eine Referenz­architektur, die als Zielbild an die Wand gehängt wird, hat noch keine einzige Entscheidung getroffen.

Entwickelt wird spezifikations­getrieben, und der Code entsteht KI-gestützt. Am Anfang jeder Umsetzung steht eine Spezifikation: ein versioniertes Dokument, das wie Code geprüft wird, für Technik und Fachbereich gleichermaßen lesbar, in dem Entscheidungen, Sonderfälle und Abwägungen geklärt sind, bevor eine Zeile entsteht. Die Architektur wird nach einem etablierten Rahmenwerk dokumentiert. Der Grund für diese Reihenfolge ist nicht Ordnungsliebe, sondern Prüfbarkeit: Erzeugter Code wächst schneller, als die Zeit reicht, ihn zu lesen. Wer einem Modell nur beschreibt, was er ungefähr will, bekommt schnell Code und bei jedem Durchlauf einen anderen. Die Spezifikation ist zugleich die Dokumentation, die sonst am Ende fehlt — und weil die eigene IT die Anwendungen später weiterentwickeln soll, ist sie zugleich das, was übergeben wird.

Der erste Anwendungs­fall ist Teil der Befähigung, nicht ihr Beweis am Ende. Er wird gemeinsam mit den Fachbereichen entwickelt und in der neu definierten Infrastruktur produktiv umgesetzt — mit der eigenen IT als aktivem Mitgestalter, die Entwicklung und Betrieb schrittweise übernimmt. Der Zweck ist doppelt: ein Nutzen, den man zeigen kann, und eine Mannschaft, die den zweiten Fall ohne uns entwickelt.

Jeder Anwendungs­fall startet aus einem bewerteten Problem, nicht aus einer technischen Gelegenheit. Das ist die Verbindung zur vorangegangenen Erhebung: Bereits identifizierte oder prototypisch gebaute Fälle werden in die definierte Infrastruktur überführt und dort skalierbar betrieben, statt neu erfunden zu werden. So zahlt jeder Fall auf dieselbe Plattform ein — und macht den nächsten schneller, günstiger und sicherer.

Die Regeln des internen Gremiums sind ab dem ersten Tag Teil der Architektur. Governance, Datenschutz, Informations­sicherheit und Betriebs­fähigkeit werden bei jeder Architektur­entscheidung mitgedacht, nicht am Ende geprüft. Das ist der Grund, warum die Reihenfolge dieses Kunden funktioniert hat: Erst das Gremium, dann die Plattform. Umgekehrt hätte die Governance die erste Plattform nachträglich in Frage stellen müssen.