Intelligence Architecture: Informations- und Systemdesign vereinen

In vielen Organisationen sind „unsere Daten“ und „unsere Systeme“ zwei getrennte Themen: getrennte Teams, getrennte Budgets, getrennte Roadmaps. Das hat lange gut funktioniert. Bei KI-Projekten fällt diese Trennung häufig auf die Beteiligten zurück, und zwar später, als es angenehm wäre.

Der Grund ist einfach: Was ein Modell ausgeben kann, hängt davon ab, welche Informationen es erreicht und in welchem System es arbeitet. Beides wird aber meist von verschiedenen Leuten zu verschiedenen Zeitpunkten entschieden.

Warum die Trennung bei KI schwerer wiegt

Klassische Software verzeiht einiges. Ist eine Datenbank uneinheitlich gepflegt, kann die Anwendungsschicht vieles auffangen — mit Validierung, Standardwerten, Geschäftslogik. Das ist Aufwand, aber es funktioniert.

Bei KI-Systemen ist dieser Puffer kleiner. Ein Modell, das auf lückenhafte, uneinheitlich benannte oder mehrfach vorhandene Daten zugreift, gibt entsprechend uneinheitliche Antworten — und die Anwendungsschicht kann das oft nicht mehr geradebiegen, weil sie nicht weiß, welche der widersprüchlichen Angaben die richtige ist. Die Qualität der Informationsschicht wird damit im Verhalten des Systems sichtbar, für Nutzende nicht selten früher als für die Entwicklung.

Was dabei zusammengehört

Was die Daten bedeuten. Nicht nur, wo sie liegen, sondern was sie aussagen: Ist „aktiver Kunde“ in allen Systemen dasselbe? Welches System gilt für welche Angabe als maßgeblich, wenn zwei sich widersprechen? Und ist erkennbar, woher eine Angabe stammt und wie verlässlich sie ist? Ein Modell, das zwei Systeme abfragt, die denselben Begriff unterschiedlich definieren, liefert Antworten, die je für sich stimmen und zusammen nicht.

Wie die Daten zum Modell kommen. Als nächtlicher Abzug, über eine Schnittstelle in Echtzeit, oder durch Nachschlagen zum Zeitpunkt der Anfrage — das ist eine Entscheidung mit Folgen für Antwortzeit, Aktualität und Kosten. Sie lässt sich nachträglich ändern, aber selten billig: Eine Architektur, die für monatliche Auswertungen gebaut wurde, auf Abfragen im Sekundentakt umzustellen, ist meist der teurere Weg.

Wo die Grenzen verlaufen. Welches System ist für welche Entscheidung zuständig? Was geschieht mit dem, was das KI-System erzeugt — fließt es zurück in die Quellsysteme, und wenn ja, wie gekennzeichnet? Und wer entscheidet, wenn KI-Ausgabe und Quellsystem sich widersprechen? Bleiben diese Fragen offen, wird die KI-Ausgabe mit der Zeit stillschweigend zur Referenz, an der sich Leute orientieren — auch dort, wo sie es nicht sollte.

Was die Schichten verbindet. Schnittstellen und vereinbarte Datenformate, damit sich Informations- und Anwendungsschicht unabhängig weiterentwickeln können, ohne einander zu beschädigen. Das ist dieselbe Disziplin, die gute Softwarearchitektur immer verlangt hat — hier zusätzlich angewandt auf die Frage, wie ein Modell Informationen aufnimmt und was es zurückgibt.

Gemeinsam entwerfen heißt: früher reden

Organisationen, die aus KI dauerhaft Nutzen ziehen, behandeln Informations- und Anwendungsarchitektur oft als eine Aufgabe statt als zwei aufeinanderfolgende Projekte. Praktisch heißt das weniger, als es klingt: Die Leute, die für die Datenstruktur zuständig sind, und die, die das System bauen, sehen sich dieselben Anwendungsfälle gemeinsam an — bevor eine Seite sich festlegt.

Der Aufwand dafür liegt am Anfang und ist überschaubar. Was er erspart, zeigt sich erst später, und das macht die Sache im Projektalltag nicht leichter: Ein Termin, dessen Nutzen erst im nächsten Jahr sichtbar wird, verliert gegen jeden dringenden.

Was es bringt

Der Ertrag zeigt sich selten beim ersten Anwendungsfall. Er zeigt sich bei den folgenden — wenn die Informationsschicht so gebaut wurde, dass der nächste Fall sie mitbenutzen kann, statt sich seine eigene zu bauen.

Ob sich das für eine Organisation rechnet, lässt sich vorab schwer ausrechnen, aber gut eingrenzen: Wie viele KI-Anwendungen sind in den nächsten Jahren realistisch geplant? Und wie viel von der Datenarbeit, die für die erste anfällt, wäre für die zweite ohnehin nötig? Bleibt es bei einer einzelnen Anwendung, ist die gemeinsame Architektur womöglich Überbau. Sind mehrere absehbar, wird jede einzeln gebaute Datenstrecke zu einer, die später jemand pflegen muss.