KI ist kein Architekt. Sie ist ein Beschleuniger — und Beschleuniger verstärken, was schon da ist: gute Strukturen genauso wie schlechte.
KI verändert nicht die Grundlagen guter Anwendungsarchitektur. Wer eine saubere Datenarchitektur hat, klar geschnittene Komponenten und eine Anwendungslandschaft, die Transformation als kontinuierlichen Prozess versteht, hat auch eine gute Ausgangslage für KI. Wer diese Grundlagen noch nicht hat, spürt es jetzt deutlicher — denn KI macht schneller sichtbar, wo eine Architektur trägt und wo nicht.
Das Problem ist kein technisches
Legacy-Systeme sind nicht das Problem. Sie sind das Ergebnis vergangener Entscheidungen — viele davon richtig, manche falsch, alle unter den damaligen Rahmenbedingungen nachvollziehbar. Das Problem entsteht, wenn KI auf diese Systeme trifft und die Erwartungen aufeinanderprallen.
Legacy-Systeme sind auf Stabilität ausgelegt: Quartalsreleases, kontrollierte Änderungen, regulierte Prozesse. KI-Komponenten funktionieren anders: neue Modelle wöchentlich, parallele Experimente, iterative Verbesserung. Fehler sind nicht Ausnahme, sondern Teil des Prozesses.
Diese unterschiedlichen Änderungsraten sind das eigentliche Spannungsfeld. Nicht KI bricht bestehende Systeme — inkompatible Änderungsraten tun es.
Der Konflikt, der daraus entsteht
Dieser Druck ist nicht abstrakt — er hat ein Gesicht, und er ist in vielen Unternehmen bereits spürbar.
Fachbereichsmitarbeiter können heute mit Hilfe von KI in kürzester Zeit Probleme lösen, die früher Wochen oder externe Unterstützung erfordert hätten: Datenanalysen, Validierungslogik, Algorithmen für Verfahren und Berechnungen — ohne tiefgehende IT-Expertise. Das ist kein grundlegend neues Phänomen. Mit Excel haben Fachbereiche das schon immer gemacht — aber jetzt mit einem Vielfachen der Leistungsfähigkeit und einem Bruchteil der bisherigen Einstiegshürde.
Der Konflikt, der daraus folgt, ist real und verständlich auf beiden Seiten.
Der Fachbereich sagt: "Das Problem habe ich längst gelöst — und die IT kann es nicht integrieren. Dafür soll ich einen IT-Kostenbeitrag leisten, der durch den tatsächlichen Nutzen nicht mehr gedeckt ist."
Die IT sagt: "KI-generierte Software erfüllt regulatorische Anforderungen nicht — Nachvollziehbarkeit, Testbarkeit, Sicherheit sind nicht gegeben."
Beide Positionen haben einen berechtigten Kern.
Der Fachbereich hat tatsächlich ein Problem gelöst — und Geschwindigkeit in der Entwicklung ist ein echter Wert. Was dabei leicht untergeht: Sie ist nicht dasselbe wie Produktionsreife in einem regulierten Umfeld. Die IT wiederum schützt zu Recht Nachvollziehbarkeit, Testbarkeit und Sicherheit. Ihr Einwand trifft allerdings nur dann vollständig zu, wenn kein Konzept für die Integration und Orchestrierung dieser Komponenten vorhanden ist. Mit einem solchen Konzept lässt sich KI-generierte Logik durchaus einbinden — nachvollziehbar, testbar, sicher.
Das Aufschlussreiche daran: Die Lösung liegt nicht auf einer der beiden Seiten. Sie liegt in der Architektur, die beide Anliegen zusammenführt — die Geschwindigkeit des Fachbereichs und die Governance-Anforderungen der IT.
Die übliche Reaktion darauf ist Integration: KI direkt in bestehende Systeme einbetten, einen weiteren Service hinzufügen, fest verdrahten. Das Ergebnis ist enge Kopplung, Angst vor Änderungen, und ein System, in dem ein fehlerhafter KI-Agent das Ganze zum Stehen bringt. Jede neue KI-Funktion wird zum strukturellen Risiko für das Bestehende.
Was eine Antwort strukturell leisten muss
Eine tragfähige Antwort auf dieses Problem ist keine Integrationsstrategie — sie ist eine Orchestrierungsstrategie. Der Unterschied ist grundlegend.
Integration bedeutet: Komponenten werden miteinander verbunden, kennen sich, hängen voneinander ab. Orchestrierung bedeutet: Eine zentrale Schicht koordiniert unabhängige Komponenten, die voneinander nichts wissen müssen.
Was eine solche Orchestrierungsschicht leisten muss:
- Isolation: Eine Komponente, die versagt, darf nichts anderes zum Versagen bringen.
- Unabhängigkeit: Neue KI-Agenten oder klassische Geschäftslogik werden registriert, nicht integriert. Das bestehende System wird nicht angefasst.
- Governance: Authentifizierung, Mandantentrennung, Audit-Trail — nicht als Nachgedanke, sondern als Kern der Architektur.
- Austauschbarkeit: Ein Modell, das sich verbessert hat, ersetzt sein Vorgänger ohne Eingriff in Workflows oder Legacy-Systeme.
Das klingt abstrakt, ist es aber nicht. Es ist eine bewusste Umkehrung der naheliegenden Reaktion: nicht enger verbinden, sondern sauber entkoppeln.
ORCHID: Ein Architekturmuster in der Praxis
Auf der PyCon DE 2026 in Darmstadt habe ich einen kurzen Vortrag gehalten und einen Prototyp vorgestellt, der dieses Prinzip umsetzt: ORCHID — eine Orchestrierungsschicht für regulierte Umgebungen.
Das Kernprinzip: Alles ist eine Komponente — ob klassische Berichtslogik, ein Risikomodell oder ein KI-Agent. Jede Komponente ist zustandslos, deklariert ihre Eingaben und Ausgaben und kennt weder Infrastruktur noch andere Komponenten. Die Orchestrierungsschicht weiß alles über den Ablauf — tut aber selbst nichts fachliches. Sie koordiniert, überwacht, sichert ab und hält den Audit-Trail.
Die Geschäftslogik — ob klassisch entwickelt oder KI-generiert — bleibt in den Komponenten: isoliert, testbar, austauschbar. Neue Komponenten werden registriert, nicht integriert. Das bestehende System wird nicht angefasst.
Das Ergebnis: Ein neuer KI-Agent kann in Tagen eingebunden werden. Fällt er aus, läuft der Rest weiter. Wird ein Modell verbessert, ersetzt es seinen Vorgänger — ohne Eingriff in Workflows oder Legacy-Systeme.
Was das mit den Grundlagen zu tun hat
Die Verbindung zu den drei Grundlagen guter Anwendungsarchitektur (Datenarchitektur, Softwarearchitektur, Transformation) ist direkt:
Eine Orchestrierungsschicht wie ORCHID funktioniert nur, wenn die Dateneigenschaften der ausgetauschten Informationen verstanden sind — die Wahl des Austauschformats ist keine beliebige Technologieentscheidung, sondern eine Konsequenz aus den Dateneigenschaften. Sie funktioniert nur, wenn die Rolle jeder Komponente explizit definiert ist — was sie leistet und was sie explizit nicht leistet. Und sie funktioniert nur, wenn Transformation als kontinuierlicher Prozess verstanden wird, der Zwischenergebnisse liefert — nicht als einmaliges Projekt mit einem fernen Zielbild.
KI fügt dieser Architektur keine neuen Grundlagen hinzu. Sie erhöht den Druck, sie ernstzunehmen.
Die eigentliche Erkenntnis
Wer eine Anwendungslandschaft hat, die auf klaren Dateneigenschaften, sauber geschnittenen Komponenten und einer belastbaren Orchestrierung aufgebaut ist, kann KI-Agenten einbinden, ohne das Bestehende zu gefährden. Die gute Nachricht: Diese Grundlagen sind nicht neu. Sie sind dieselben, die schon immer eine tragfähige Architektur ausgemacht haben — KI macht nur deutlicher, wie viel sie wert sind.
Der Unterschied liegt damit nicht in der KI selbst. Er liegt in der Anwendungsarchitektur, die sie aufnimmt — und in einem Konzept, das die Geschwindigkeit des Fachbereichs und die Governance-Anforderungen der IT in eine gemeinsame Richtung bringt, statt sie gegeneinander zu stellen.
Wer dieses Konzept hat, kann aus dem Druck, den KI erzeugt, eine echte Chance machen.
