Datenarchitektur für KI entwickeln im Betrieb

Eine KI-Anwendung kann fachlich überzeugen und trotzdem im Betrieb scheitern: wenn Quellsysteme widersprüchliche Informationen liefern, Berechtigungen ungeklärt sind oder niemand nachvollziehen kann, auf welcher Datengrundlage ein Ergebnis entstanden ist. Wer eine Datenarchitektur für KI entwickeln will, muss deshalb mehr planen als Speicher, Schnittstellen und Modelle. Entscheidend ist eine Datenbasis, die fachlich belastbar, technisch kontrollierbar und für den konkreten Einsatzfall angemessen abgesichert ist.

Das betrifft besonders Unternehmen mit gewachsenen SAP-Landschaften, Fachanwendungen und dezentralen Datenbeständen. In diesen Umgebungen liegen relevante Informationen häufig in S/4HANA, Data Warehouses, Dokumentenablagen, CRM-Systemen oder spezialisierten Fachsystemen. Die zentrale Aufgabe besteht nicht darin, alle Daten möglichst schnell in eine KI-Plattform zu übertragen. Sie besteht darin, die richtigen Datenflüsse für klar definierte Entscheidungen, Prozesse oder Auskünfte bereitzustellen.

Warum KI andere Anforderungen an Daten stellt

Klassische Reporting-Architekturen sind oft auf periodische Auswertungen ausgelegt. Kennzahlen werden konsolidiert, verdichtet und in festen Berichten bereitgestellt. KI-Anwendungen benötigen dagegen je nach Einsatzfall aktuelle Kontextinformationen, unstrukturierte Dokumente, nachvollziehbare Quellen und eine kontrollierte Rückgabe von Ergebnissen an operative Prozesse.

Ein Assistent für den Einkauf benötigt beispielsweise andere Daten als ein System zur Prüfung von Qualitätsabweichungen. Für den Einkaufsassistenten können freigegebene Lieferanteninformationen, Vertragsdokumente und aktuelle Bestelldaten relevant sein. Bei Qualitätsabweichungen stehen Chargeninformationen, Prüfprotokolle, Produktionsdaten und eindeutig dokumentierte Bewertungsregeln im Vordergrund. Beide Fälle verlangen Datenqualität. Die Anforderungen an Aktualität, Berechtigungen, Nachweisführung und Fehlertoleranz unterscheiden sich jedoch deutlich.

Diese Differenzierung ist wesentlich. Eine Architektur, die für alle denkbaren KI-Vorhaben dieselbe Datenhaltung und denselben Zugriffspfad vorsieht, wird entweder zu unflexibel oder zu riskant. Der Ausgangspunkt sollte daher immer der konkrete Prozess sein: Welche Entscheidung oder Tätigkeit wird unterstützt, welche Daten sind dafür erforderlich und welche Folgen hätte ein fehlerhaftes Ergebnis?

Datenarchitektur für KI entwickeln: Vom Einsatzfall rückwärts planen

Die belastbarste Vorgehensweise beginnt nicht beim Modell, sondern beim Zielbild des Fachbereichs. Projektteams sollten zunächst festlegen, welche Nutzergruppe welche Aufgabe mit KI-Unterstützung erledigen soll. Daraus ergeben sich die benötigten Informationsobjekte, die zulässigen Datenquellen und die Anforderungen an Antwortqualität.

Datenflüsse fachlich und technisch abgrenzen

Im nächsten Schritt wird der Datenfluss vom Ursprung bis zur KI-Anwendung dokumentiert. Dazu gehören operative Quellsysteme, Extraktions- und Transformationsschritte, Speicherorte, Schnittstellen, semantische Aufbereitung sowie die Ausgabe an Anwender oder Zielsysteme. Bei SAP-nahen Szenarien sollte sichtbar sein, ob Daten direkt aus S/4HANA stammen, über etablierte Integrationsschichten bereitgestellt oder zunächst in eine analytische Datenplattform überführt werden.

Diese Dokumentation darf nicht bei einer Systemübersicht stehen bleiben. Relevant sind auch Datenfelder, Aktualisierungszyklen, Schlüsselbeziehungen und fachliche Bedeutungen. Wenn etwa der Begriff "Kunde" im Vertrieb, Forderungsmanagement und Service unterschiedliche Statuslogiken enthält, kann eine KI diese Unterschiede nicht verlässlich auflösen, solange sie nicht im Datenmodell beschrieben sind.

Besondere Aufmerksamkeit verdienen unstrukturierte Inhalte. Technische Spezifikationen, Arbeitsanweisungen, Verträge oder Qualitätsberichte enthalten häufig wertvolles Wissen. Zugleich können sie veraltet sein, mehrere Freigabestände umfassen oder vertrauliche Angaben enthalten. Eine Dokumentenquelle ist daher erst dann KI-tauglich, wenn Herkunft, Gültigkeit, Version und Zugriffsberechtigung nachvollziehbar gepflegt werden.

Semantik und Verantwortlichkeit verbindlich machen

Eine KI kann Daten technisch lesen, aber keine fehlenden Fachdefinitionen ersetzen. Daher braucht die Architektur ein gemeinsames Verständnis zentraler Geschäftsobjekte, Kennzahlen und Statuswerte. Datenkataloge, Glossare und Metadaten sind dabei kein Selbstzweck. Sie machen sichtbar, welche Daten für welchen Zweck freigegeben sind und wer ihre fachliche Qualität verantwortet.

In der Praxis braucht es mindestens drei klar getrennte Rollen: Die fachliche Verantwortung entscheidet über Bedeutung und zulässige Nutzung eines Datenobjekts. Die technische Verantwortung stellt Bereitstellung, Schnittstellen und Betrieb sicher. Die KI- oder Prozessverantwortung bewertet, ob die Daten für den jeweiligen Einsatzfall geeignet bleiben. In kleineren Organisationen können einzelne Personen mehrere Rollen ausfüllen. Die Verantwortlichkeiten selbst sollten dennoch eindeutig dokumentiert sein.

Die Architektur muss Zugriffe begrenzen können

Viele KI-Projekte behandeln Berechtigungen erst kurz vor dem Pilotbetrieb. Das führt häufig zu zwei problematischen Extremen: Entweder die Anwendung erhält zu viele Daten, oder sie wird durch pauschale Einschränkungen fachlich kaum nutzbar. Eine tragfähige Datenarchitektur verbindet daher das bestehende Rollenmodell mit dem jeweiligen KI-Szenario.

Entscheidend ist nicht nur, wer eine Anwendung nutzen darf. Ebenso wichtig ist, welche Inhalte sie für diese Person abrufen, verarbeiten oder anzeigen darf. Ein KI-Assistent sollte keine Informationen aus Dokumenten ausgeben können, die der anfragenden Person im Ursprungssystem nicht zugänglich wären. Das gilt auch für abgeleitete Inhalte, Zusammenfassungen und Suchtreffer.

Technisch lässt sich dies je nach Landschaft über identitätsbasierte Zugriffe, attributbasierte Regeln, getrennte Datenräume und protokollierte Abrufe umsetzen. Welche Variante passt, hängt von Systemlandschaft, Schutzbedarf und Betriebsmodell ab. Für sensible Personal-, Vertrags-, Forschungs- oder Produktionsdaten sind getrennte Datenbereiche häufig nachvollziehbarer als ein zentraler, breit geöffneter Wissenspool.

Bei KI-Anwendungen mit erhöhtem Risikopotenzial sind zusätzlich Anforderungen aus Datenschutz, Informationssicherheit und KI-Governance frühzeitig einzuplanen. Die rechtliche Einordnung einzelner Einsatzfälle, etwa im Zusammenhang mit dem EU AI Act, erfolgt bei Bedarf durch die rechtlich eigenständige Quteco Rechtsanwaltsgesellschaft mbH. Für die technische Architektur bedeutet das vor allem: Verarbeitungszwecke, Datenherkunft, Zugriffe und Betriebsverantwortung müssen belegbar sein.

Retrieval, Training und operative Integration unterscheiden

Nicht jede KI-Anwendung benötigt ein eigenes trainiertes Modell. In vielen Unternehmensszenarien ist ein kontrollierter Abruf freigegebener Informationen sinnvoller. Bei diesem Ansatz erhält das Modell zur Laufzeit passende Dokumentenausschnitte oder Datensätze als Kontext. Der Vorteil liegt in einer schnelleren Aktualisierung und besseren Quellenbeziehbarkeit. Änderungen an Arbeitsanweisungen oder Produktinformationen können wirksam werden, ohne ein Modell neu zu trainieren.

Ein Training oder Fine-Tuning kann dagegen sinnvoll sein, wenn ein Modell dauerhaft spezifische Klassifikationen, Formulierungen oder strukturierte Entscheidungen unterstützen soll. Es erhöht jedoch die Anforderungen an Trainingsdaten, Versionierung, Testbarkeit und Rückbau. Für viele Fachbereiche ist daher ein gestufter Einstieg sinnvoll: zuerst ein klar abgegrenzter Retrieval-Anwendungsfall mit freigegebenen Quellen, anschließend eine Erweiterung auf strukturierte Prozessdaten oder automatisierte Arbeitsschritte.

Auch die Rückgabe von KI-Ergebnissen in operative Systeme sollte bewusst gestaltet werden. Eine Handlungsempfehlung kann zunächst nur angezeigt werden. Erst nach fachlicher Prüfung darf sie etwa als Vorgang, Bestellvorschlag oder Service-Ticket in ein Zielsystem übernommen werden. Vollautomatische Rückschreibungen sind möglich, setzen aber stabile Entscheidungsregeln, geeignete Kontrollen und definierte Eskalationswege voraus.

Qualität wird im Betrieb geprüft, nicht nur vor dem Go-Live

Datenqualität für KI bedeutet mehr als Vollständigkeit und Dublettenfreiheit. Relevant sind auch Aktualität, Kontext, Freigabestatus und Eignung für die konkrete Fragestellung. Ein formal korrekter Datensatz kann für eine KI ungeeignet sein, wenn er fachlich überholt ist oder wichtige Einschränkungen nur in einem nicht angebundenen Dokument stehen.

Deshalb sollten Teams Testfälle aus echten Arbeitssituationen ableiten. Sie prüfen nicht nur, ob eine Antwort plausibel klingt, sondern ob sie auf zulässigen Quellen beruht, ob sie kritische Ausnahmen erkennt und ob die Berechtigungslogik auch bei Grenzfällen funktioniert. Für produktionsnahe Anwendungen gehören dazu wiederholbare Tests bei Datenänderungen, Modellwechseln und Schnittstellenanpassungen.

Messbare Betriebskennzahlen helfen, die Architektur nachzusteuern. Dazu zählen etwa die Quote fachlich verwertbarer Antworten, die Anzahl nicht belegbarer Ausgaben, Aktualität der Quellen, Fehlerraten bei Datenpipelines und Bearbeitungszeiten für Korrekturen. Diese Kennzahlen ersetzen keine fachliche Kontrolle. Sie zeigen aber früh, ob eine Anwendung durch Datenprobleme an Verlässlichkeit verliert.

Architekturentscheidungen an der Betriebsrealität ausrichten

Eine zentrale Datenplattform kann Vorteile bieten, wenn viele Bereiche mit einheitlichen Stammdaten und vergleichbaren Governance-Regeln arbeiten. Sie ist jedoch nicht automatisch die richtige Antwort für jede KI-Initiative. Bei zeitkritischen Produktionsdaten, stark regulierten Informationen oder eigenständigen Fachdomänen kann eine föderierte Architektur mit klaren Datenprodukten besser passen.

Wichtig ist, dass der Architekturansatz den Betrieb nicht unnötig verkompliziert. Jede zusätzliche Kopie, Transformation und Schnittstelle schafft Prüf- und Wartungsaufwand. Umgekehrt kann ein direkter Zugriff auf operative Systeme deren Verfügbarkeit oder Berechtigungsmodell belasten. Die geeignete Lösung entsteht aus einer nachvollziehbaren Abwägung zwischen Aktualität, Schutzbedarf, Skalierbarkeit und Betriebsverantwortung.

Datenarchitektur vor dem Pilot belastbar prüfen

Quteco unterstützt Unternehmen mit Quick Checks und Workshops dabei, KI-Einsatzfälle, Datenflüsse, Rollenmodelle und Architekturentscheidungen strukturiert zu bewerten. In laufenden SAP-, Daten- und KI-Projekten kann daraus eine umsetzbare Roadmap mit klaren Zuständigkeiten, Testpunkten und Anforderungen für den produktionsnahen Betrieb entstehen.

Ein guter KI-Pilot beweist nicht nur, dass ein Modell Antworten erzeugen kann. Er zeigt, dass die Organisation Datenquellen, Zugriffe und Veränderungen so steuert, dass aus einem Versuch ein nachvollziehbarer Prozess werden kann.