Cloud-Architektur und KI-Readiness Ist Ihre Cloud-Architektur KI-fähig? Ein Praxis-Check für hybride IT-Landschaften

Anbieter zum Thema

Flexera Software GmbH

Yorizon GmbH & Co. KG

Viele KI-Initiativen funktionieren im Pilot, geraten jedoch im produktiven Betrieb ins Stocken. Ursache sind selten Modelle oder Rechenleistung, sondern strukturelle Schwächen in Cloud- und Datenarchitekturen. Der Beitrag zeigt anhand konkreter Prüffragen, woran IT-Verantwortliche diese frühzeitig erkennen können.

Künstliche Intelligenz scheitert selten am Modell

Viele Unternehmen haben in den vergangenen Jahren erheblich in künstliche Intelligenz (KI) investiert – in Plattformen, Modelle, Lizenzen und Data-Science-Teams. Die Ergebnisse in Pilotprojekten sind häufig überzeugend. Der Übergang in den produktiven Betrieb verläuft dann oft deutlich holpriger als erwartet.

Ein typisches Beispiel: Ein Predictive-Maintenance-Modell erkennt im Pilotbetrieb Maschinenausfälle zuverlässig. Im produktiven Betrieb sollen zusätzlich Wartungsdaten aus dem SAP-System angebunden werden – Instandhaltungsprotokolle, Ersatzteilinformationen, Servicemeldungen. Die Integration allein dauert Monate. Das Modell wartet auf Daten, die eigentlich längst vorhanden sind.

Das Problem liegt nicht im Algorithmus. Es liegt in der Architektur dahinter. Der Engpass entsteht an den Verbindungsstellen zwischen Systemen, in manuellen Datenprozessen und in einer Infrastruktur, die nicht für datengetriebene Workloads ausgelegt wurde.

Der Pilot-Trugschluss

Der Grund, warum dieser Engpass so oft überraschend kommt, liegt in der Natur von Pilotprojekten. PoC-Umgebungen sind per Definition kontrolliert. Daten werden für den Test aufbereitet, Systeme sind isoliert, Aktualisierungszyklen spielen keine Rolle.

Im Betrieb kommen Daten aus ERP-Systemen, CRM-Plattformen, IoT-Sensoren und externen Quellen zusammen. Jede dieser Quellen hat eigene Aktualisierungszyklen, eigene Qualitätsstandards und eigene Abhängigkeiten. Sensordaten, Instandhaltungsprotokolle und Ersatzteilinformationen werden zu unterschiedlichen Zeiten und in unterschiedlicher Granularität bereitgestellt. Im Pilot ist das irrelevant – im Betrieb führt es dazu, dass Modelle mit unvollständigen Daten rechnen.

Das ist kein Modellproblem. Es ist ein Architekturproblem, das im Pilotbetrieb schlicht unsichtbar bleibt.

Warum Cloud-Migration allein nicht reicht

Cloud-Migration modernisiert Infrastruktur – nicht automatisch Architektur. Ein konkretes Beispiel: Ein Unternehmen migriert sein ERP-System nach S/4HANA Cloud und baut parallel eine moderne Cloud-Datenplattform auf. Neue Datenquellen müssen weiterhin individuell integriert werden, weil kein zentraler Integrationslayer existiert. Jede neue Quelle wird zum eigenständigen Projekt.

Das gleiche Muster zeigt sich in komplexeren Szenarien: Wenn Sensordaten aus einer Produktionsanlage, ERP-Wartungsdaten und externe Wetterdaten kombiniert werden sollen, laufen diese Informationsströme nach der Cloud-Migration weiterhin in getrennten Silos. Der Ort hat sich verändert, die strukturellen Abhängigkeiten sind geblieben.

Typische Architekturdefizite – wiederkehrende Muster aus der Praxis

In vielen gewachsenen IT-Landschaften zeigen sich beim Übergang zu produktiven KI-Anwendungen immer wieder dieselben strukturellen Schwächen. Sie entstehen nicht durch schlechte Planung, sondern weil Architekturen über Jahre auf operative Effizienz optimiert wurden, nicht auf analytische Nutzung.

Das häufigste Muster sind Punktintegrationen. Statt eines zentralen Integrationslayers existieren dutzende, manchmal hunderte direkte Schnittstellen zwischen ERP-Systemen, CRM-Plattformen, BI-Tools und Datenplattformen. Wird ein Feld im ERP geändert, können mehrere Pipelines gleichzeitig betroffen sein – oft ohne dass dokumentiert ist, welche Systeme abhängig sind. KI-Initiativen machen diese Abhängigkeiten sichtbar.

Ein weiteres verbreitetes Defizit ist die fehlende Trennung von Trainings- und Produktionsumgebungen. In einem Projekt im Automobilbereich liefen Trainingsläufe für ML-Modelle direkt auf denselben Datenbanken wie operative Reports und Steuerungssysteme. Die Analysejobs erzeugten Lastspitzen, die den produktiven Betrieb störten. Die Lösung war keine technische Innovation – sie war eine Architekturentscheidung, die von Beginn an hätte getroffen werden müssen.

Hinzu kommt ein Monitoring-Defizit, das in vielen Projekten erst spät sichtbar wird: Systeme werden überwacht, Daten nicht. IT-Teams wissen zuverlässig, ob ein Server läuft – aber nicht, ob die Daten, die dieser Server liefert, noch die erwartete Qualität haben. Für KI-Systeme ist das ein strukturelles Risiko.

Ein weiteres Muster betrifft Wissen, nicht Technologie: Integrationswissen ist in vielen Organisationen personengebunden. Wer die Schnittstellen kennt, wer weiß, welche Systeme voneinander abhängen und warum – das ist oft implizites Wissen einzelner Mitarbeiter, nicht dokumentierte Architektur. Fällt diese Person aus oder wechselt die Stelle, stockt der Betrieb.

Solche Muster bleiben im Tagesgeschäft oft unbemerkt. KI-Initiativen bringen sie an die Oberfläche.

Cloud-Architektur und KI-Transformation

Warum künstliche Intelligenz nicht ohne Architektur skaliert

Architekturprinzipien für KI-fähige Plattformen

Diese Defizite sind behebbar. Sie erfordern keine vollständige Neuentwicklung bestehender Systeme, sondern gezielte Architekturentscheidungen, die KI-Workloads von Beginn an mitdenken. Das zentrale Prinzip ist ein definierter Integrationslayer. Statt direkter Punktintegrationen zwischen Systemen werden APIs und Event-Streams als standardisierte Schnittstellen eingeführt. Neue Systeme können Daten abonnieren, ohne bestehende Verbindungen zu verändern. Eng damit verbunden ist das Prinzip der Entkopplung. Systeme und Datenflüsse werden so gestaltet, dass Änderungen in einem Bereich nicht automatisch andere Bereiche betreffen.

Für KI-Workloads ist darüber hinaus eine elastische Infrastruktur notwendig, die Training und Inferenz getrennt betrachtet. Trainingsjobs und produktive Inferenzmodelle haben unterschiedliche Ressourcenanforderungen und unterschiedliche Kritikalität. Wer beide auf derselben Infrastruktur betreibt, schafft Abhängigkeiten, die den Betrieb gefährden.

Schließlich gehört Governance nicht als nachgelagerte Compliance-Aufgabe in KI-Architekturen – sie muss technisch verankert sein. Rollenmodelle, Zugriffsrechte und Audit-Logs sind keine Dokumentationsaufgabe, sondern Bestandteil des Plattformdesigns.

Workforce Readiness statt Tech-Fokus

Wie CIOs künstliche Intelligenz aus der Pilotfalle führen

Architektur-Check: Fünf Prüffragen für IT-Verantwortliche

Die strukturellen Schwächen, die KI-Projekte im produktiven Betrieb ausbremsen, lassen sich mit wenigen gezielten Fragen sichtbar machen. Kein Beratungsauftrag, keine aufwändige Analyse – sondern eine ehrliche Bestandsaufnahme:

• Können neue Datenquellen ohne ein eigenständiges Integrationsprojekt angebunden werden? Wenn die Antwort nein ist, fehlt ein zentraler Integrationslayer. Jede neue Datenquelle wird zum Einzelprojekt – und das skaliert nicht.

• Lassen sich Trainings- und Inferenz-Workloads unabhängig voneinander skalieren? Wenn Trainingsläufe denselben Ressourcenpool nutzen wie produktive Systeme, ist das Plattformdesign nicht auf KI-Workloads ausgelegt.

• Gibt es automatisiertes Monitoring für Datenqualität und Modellperformance? Systemmonitoring ist kein Ersatz für Datenmonitoring. Wenn Qualitätsprobleme erst sichtbar werden, wenn Modelle falsche Ergebnisse liefern, ist das Monitoring zu spät angesetzt.

• Sind Governance-Vorgaben technisch implementiert – Rollen, Zugriffe, Audit-Logs? Governance, die nur in Dokumenten existiert, ist keine Governance. Sie muss in der Plattform selbst verankert sein.

• Ist Integrationswissen dokumentiert und nicht personenabhängig? Wenn der Betrieb stockt, sobald eine bestimmte Person nicht erreichbar ist, ist das Architekturwissen nicht institutionalisiert.

Wer mehrere dieser Fragen nicht klar mit Ja beantworten kann, hat kein Modellproblem – sondern ein Architekturproblem.

Fazit

KI ist heute kein isoliertes Innovationsprojekt mehr. Sie ist ein Bestandteil der IT-Architektur – und sie funktioniert nur so gut wie die Struktur, auf der sie aufsetzt.

Die Unternehmen, die KI dauerhaft produktiv nutzen, haben eines gemeinsam: Sie haben nicht zuerst in Modelle investiert, sondern in Integrationsarchitektur, Datenstruktur und Governance.

KI-Initiativen scheitern selten an Algorithmen. Sie scheitern an Architekturen, die nicht für datengetriebene Systeme gebaut wurden. Wer KI skalieren will, muss deshalb nicht zuerst Modelle verbessern – sondern die Struktur darunter.

(ID:50829940)