Kommentar von Stefan Maxones Künstliche Intelligenz – warum digitale Modernisierung oft am Unterbau scheitert

Anbieter zum Thema

Board Deutschland GmbH

Disy Informationssysteme GmbH

QUNIS GmbH

Warum liefern KI-Initiativen trotz moderner Plattformen oft keinen messbaren Mehrwert? Der Beitrag zeigt, dass die Ursachen seltener in Modellen oder Rechenleistung liegen, sondern in architektonischen und organisatorischen Entscheidungen, bei denen Analytics, Integration und Datenverantwortung nachgeordnet behandelt werden.

Künstliche Intelligenz (KI) ist in vielen Unternehmen kein Neuland mehr. Modelle sind verfügbar, Plattformen eingeführt, Budgets genehmigt. Projekte laufen, Demos funktionieren, Präsentationen überzeugen. Im Alltag ändert sich dennoch wenig. Entscheidungen bleiben vorsichtig, Automatisierungen fragmentiert, Vertrauen in Zahlen brüchig. Der Eindruck technischer Reife täuscht häufig über strukturelle Defizite hinweg. Das liegt selten an den Algorithmen. Was fehlt, ist meist schon früher entstanden – oder bewusst ausgeklammert worden: in der Architektur. In der Art, wie Daten strukturiert, integriert und verantwortet werden.

Viele heutige Datenlandschaften sind das Ergebnis jahrzehntelanger Optimierung auf operative Effizienz. Analytische Nutzbarkeit wurde dabei oft implizit angenommen, aber selten explizit gestaltet. In großen Transformationsprogrammen steht operative Stabilität im Vordergrund. Das ist nachvollziehbar. Systeme müssen laufen, Prozesse vergleichbar werden, Releases dürfen nicht eskalieren. Analytische Anforderungen werden reduziert, vereinfacht oder zeitlich verschoben. Man will erst einmal sauber live gehen. Reporting, historische Auswertungen oder datengetriebene Automatisierungen gelten als nachgelagerte Themen.

Reifegradmodell fürs Controlling

Der Weg zur KI-gestützten Unternehmenssteuerung

Nach dem Go-live zeigt sich dann, was dabei verloren ging. Historien fehlen oder sind nur eingeschränkt verfügbar. Kennzahlen sind anders definiert als früher, oft ohne dokumentierte Übergangslogik. Automatisierte Auswertungen existieren nicht mehr oder liefern andere Ergebnisse. Fachbereiche reagieren irritiert. Zahlen schwanken, ohne dass sich operativ etwas geändert hätte. Für das Management bleibt dies oft abstrakt – für Architektur- und Analytics-Teams ist es tägliche Realität.

Der Denkfehler liegt im Ansatz

Spätestens an diesem Punkt wird KI schwierig. Modelle benötigen stabile Zeitreihen, klare Logiken und reproduzierbare Grundlagen. Genau das fehlt. Der Denkfehler liegt nicht im Detail, sondern im Ansatz. Operative Architektur und analytische Architektur werden getrennt behandelt. KI gilt als spätere Ausbaustufe. Als etwas, das man oben aufsetzt, wenn alles andere steht. Architekturentscheidungen werden damit getroffen, ohne ihre analytischen Konsequenzen mitzudenken.

Relevante KI-Anwendungen entstehen jedoch fast nie in einem einzelnen System. Sie entstehen zwischen Systemen. Transaktionale Daten liefern fachlichen Kontext. Ereignis- oder Sensordaten liefern zeitliche Dynamik. Externe Daten ergänzen Markt-, Umwelt- oder Lieferketteninformationen. Diese Daten passen nicht automatisch zusammen. Zeitbezug, Granularität und Bedeutung unterscheiden sich – oft historisch gewachsen und nur implizit bekannt. Ohne saubere Entkopplung entstehen Abhängigkeiten, die im Betrieb kaum beherrschbar sind. Kleine Änderungen schlagen an unerwarteten Stellen durch. Modelle liefern andere Ergebnisse, ohne dass klar ist warum. Vertrauen geht verloren.

Kommentar von Stefan Brock, HPE

Für KI-Erfolg: 10 Designprinzipien für die datenzentrische Architektur

Technisch äußert sich das häufig in nicht versionierten Schnittstellen, fehlenden Data Contracts, impliziten Annahmen in Transformationen oder fachlich nicht dokumentierten Kennzahlenlogiken. In der technischen Umsetzung bedeutet ein Data Contract dabei weit mehr als eine bloße Schnittstellenbeschreibung. Er definiert die Qualität, das Schema und vor allem die Semantik der Daten. In einer modernen Datenarchitektur wird dieser Vertrag maschinenlesbar hinterlegt. Ändert sich beispielsweise in einem Quellsystem eine Feldlogik, schlägt das Monitoring sofort Alarm, bevor die fehlerhaften Daten das Modell erreichen. Dieser „Shift-Left“-Ansatz der Datenqualität sorgt dafür, dass Fehler dort korrigiert werden, wo sie entstehen – in den operativen Systemen – und nicht erst mühsam in der Analytics-Schicht bereinigt werden müssen.

Praxisbeispiel

Ein Beispiel aus der Praxis: In einem Instandhaltungsprojekt sollte ein Modell Maschinenausfälle vorhersagen. Technisch funktionierte alles. Die Sensorwerte liefen stabil, das Modell lernte. Nach einem Release änderten sich jedoch die Material- und Standortlogiken im ERP-System. Für die Fachbereiche blieb alles gleich. Für das Modell nicht. Vorhersagen drifteten, ohne dass ein Fehler sichtbar war. Wochenlang wurde diskutiert, ob das Modell ungeeignet sei. Tatsächlich lag die Ursache in einem Integrationsbruch. Eine fachlich relevante Änderung war nirgends versioniert oder kommuniziert worden. Niemand fühlte sich zuständig.

Generative KI verschärft dieses Problem. Sprachbasierte Modelle sind besonders abhängig von konsistentem Kontext und historisierten Informationen. Wenn Daten bei jedem Release ihre Bedeutung ändern oder nicht versioniert sind, bleiben Ergebnisse oberflächlich. Ohne stabile semantische Grundlagen wird generative KI zur rhetorischen Unterstützung, nicht zum Entscheidungsinstrument.

Kommentar von Sascha Hempe, Datadobi

Generative KI ist nur so gut wie ihr Daten-Input

Echtzeit wird in diesem Zusammenhang häufig missverstanden. Für lernende und validierende KI ist nicht die Reaktionsgeschwindigkeit entscheidend, sondern die Qualität der Persistenz. Modelle, die primär auf aktuellen Streams reagieren, verlieren historische Kontexte und saisonale Muster. Ohne reproduzierbare, historisierte Datenbasis bleibt Lernen kurzfristig und anfällig für Verzerrungen.

Altlasten

Viele Organisationen kämpfen zudem mit Legacy-Systemen, die sich nur begrenzt vereinheitlichen lassen. Oft wird versucht, dies durch den Aufbau einer „Business Data Cloud“ zu lösen. Doch ohne klare Architektur-Strategie wird die Cloud schnell zum „Data Swamp“. Der entscheidende Hebel ist hier nicht die Speichertechnologie, sondern die Fähigkeit zur Entkopplung. Eine moderne Architektur erlaubt es, operative Systeme zu aktualisieren, ohne die analytische Konsistenz zu gefährden. Das gelingt nur, wenn wir Daten als eigenständige Produkte (Data Products) mit definiertem Lebenszyklus behandeln.

Kommentar von Mandy Goram, pmOne

Künstliche Intelligenz im Mittelstand – Kosten und Voraussetzungen

Ein Punkt, der selten offen angesprochen wird, ist die Organisation. Datenverantwortung ist unklar oder projektbezogen verteilt. IT optimiert auf Systembetrieb, während Fachbereiche stabile Zahlen erwarten. Um eine echte fachliche Ownership zu verankern, müssen Rollen wie der „Data Domain Owner“ geschaffen werden. Diese Person kommt aus dem Business und trägt die Verantwortung dafür, dass die Daten ihrer Domäne korrekt und verständlich bereitgestellt werden. Das erfordert ein Umdenken: Weg von der projektbezogenen Budgetierung hin zu einer dauerhaften Produktverantwortung für Daten. Nur so entsteht eine Governance, die nicht nur auf dem Papier existiert.

Schlussfolgerungen

Für 2026 lassen sich daraus klare Schlussfolgerungen ableiten: Analytische Anforderungen müssen frühzeitig Teil von Architekturentscheidungen werden – als gleichwertige Dimension neben der operativen Stabilität. Data Contracts und explizite Semantik sind keine akademischen Konzepte, sondern praktische Voraussetzungen für verlässliche Modelle. Geschwindigkeit bleibt wichtig, ist aber selten der Engpass. Reproduzierbarkeit, Nachvollziehbarkeit und Vertrauen sind es. Wer den Unterbau jetzt aufräumt, gewinnt ein Unternehmen, das nicht nur bereit für KI ist, sondern das seine eigene Realität endlich präzise steuern kann.

(ID:50684897)