Warum KI-Architektur wichtiger wird – nicht unwichtiger

Das Problem: Schnelle Integration, langsame Konsequenzen

Stellen Sie sich ein mögliches Szenario vor: Ein Unternehmen integriert ein Sprachmodell in seinen Kundenservice. Der Test funktioniert, doch später zeigt sich, dass Modellaufrufe eng mit der Geschäftslogik verbunden und Datenflüsse nur teilweise dokumentiert sind. Ein Wechsel des Anbieters könnte dadurch mehr Anpassungen erfordern.

Das Beispiel zeigt ein mögliches Integrationsrisiko. Architekturfragen sollten vor größeren Investitions- und Produktionsentscheidungen betrachtet werden, damit Abhängigkeiten, Verantwortlichkeiten und Änderungsaufwand sichtbar sind.

Warum Architekturentscheidungen bei KI anders wirken

KI-Komponenten können sich im Verhalten von klassischer, regelbasierter Software unterscheiden. Generative Systeme können für ähnliche Eingaben unterschiedliche Ausgaben liefern; Ergebnisse hängen unter anderem von Modell, Version, Kontext und Konfiguration ab. Datenzugriff, Auswertung und Kontrollmöglichkeiten unterscheiden sich je nach Architektur.

Diese Eigenschaften machen Entscheidungen zu Schnittstellen, Zuständigkeiten, Tests und Überwachung relevant. Eine klare Trennung kann Änderungen erleichtern, verursacht aber auch eigenen Entwicklungs- und Betriebsaufwand.

Modelle, Dienste, Schnittstellen und Datenquellen können sich ändern. Ob eine Änderung Anpassungen erfordert, hängt von der konkreten Integration ab. Systeme sollten deshalb angemessen getestet und überwacht werden, besonders wenn eine Modell- oder Dienständerung erfolgt.

Architektur ist damit Teil der Planung eines KI-Einsatzes. Sie beeinflusst, wie Änderungen, Ausfälle und Qualitätsabweichungen behandelt werden können.

Typische Fehleinschätzungen

„Wir fangen klein an und skalieren dann."

Ein kleiner Pilot kann helfen, Annahmen zu prüfen. Vor einer Ausweitung sollte das Team bewerten, ob die Pilotarchitektur für Produktivbetrieb, höhere Last, Sicherheit und Wartung ausreicht. Nicht jeder Prototyp ist dafür ausgelegt.

„Das Modell ist austauschbar."

Ein Wechsel kann einfacher sein, wenn integrationsspezifischer Code und Fachlogik getrennt sind. Dennoch können unterschiedliche Fähigkeiten, Schnittstellen und Ausgaben Anpassungen und erneute Tests erforderlich machen.

„Die IT-Abteilung löst das."

KI-Architektur hat technische und organisatorische Seiten. Zuständigkeiten sollten so festgelegt werden, dass IT, Fachbereiche, Datenschutz und Informationssicherheit je nach Einsatz die relevanten Entscheidungen treffen und prüfen können.

„LLM-Architektur ist ein Spezialproblem."

Für Sprachmodelle gelten viele etablierte Architekturfragen weiter, etwa Schnittstellen, Datenflüsse und Zuständigkeiten. Je nach KI-Verfahren kommen weitere Anforderungen hinzu; eine einheitliche Architektur für alle KI-Komponenten gibt es nicht.

Was architektonische Klarheit konkret bedeutet

Eine mögliche Strukturierung unterscheidet drei Betrachtungsebenen. Sie ist ein Denkmodell; die konkrete Architektur muss zu Anwendung und bestehender Systemlandschaft passen.

Ebene 1: Fachlogik

Geschäftsregeln und Prozesse des Unternehmens. Eine Trennung von anbieterspezifischen Aufrufen kann Änderungen erleichtern. Abhängigkeiten lassen sich je nach Anwendung jedoch nicht vollständig vermeiden.

Ebene 2: Datenverarbeitung

Quellen, Formate, Zugriffsrechte und Qualitätsanforderungen der Daten. Welche Informationen in ein System fließen und wie sie verarbeitet werden, sollte für den konkreten Anwendungsfall nachvollziehbar sein.

Ebene 3: KI-Komponenten

Modelle, APIs und Dienste, die KI-Funktionalität bereitstellen. Klare Schnittstellen können den Wechsel erleichtern, garantieren aber keine Kompatibilität zwischen Anbietern oder Modellen.

Das NIST AI Risk Management Framework empfiehlt, Risiken und Kontrollen für Komponenten von Drittanbietern sowie den Einsatzkontext zu betrachten und zu dokumentieren. Daraus folgt kein bestimmtes Architekturmodell; die nötigen Maßnahmen richten sich nach dem konkreten System und seinem Risiko.

Die tatsächlichen Kosten von „schnell gebaut"

Der Zeitdruck bei KI-Projekten ist real. Wettbewerber experimentieren, Erwartungen sind hoch, Ressourcen sind begrenzt. Die Versuchung, Architekturüberlegungen zu verschieben, ist nachvollziehbar.

Ein schneller Aufbau kann spätere Arbeit verursachen, wenn Wartbarkeit, Änderungen, Zuständigkeiten oder Kontrollen nicht ausreichend berücksichtigt wurden. Wie hoch der Aufwand ist, hängt von der gewählten Lösung, ihrer Nutzung und den Anforderungen an Betrieb und Nachweisbarkeit ab.

Deshalb ist eine verhältnismäßige Prüfung vor Pilot und Produktivsetzung sinnvoll. Umfangreiche Architekturarbeit ist nicht für jeden Versuch nötig; besonders bei einer Ausweitung sollten Datenflüsse, Schnittstellen, Sicherheit und Betrieb geklärt sein. Microsofts Leitfaden zu KI-Workloads behandelt unter anderem Anwendung, Daten, Tests, Betrieb und verantwortungsvolle Nutzung als Architekturthemen.

Empfehlungen für architektonische Entscheidungen

Definieren Sie Austauschbarkeit als Anforderung.

Prüfen Sie, welche Komponenten im Fall eines Anbieterwechsels ersetzt werden müssten und welcher Aufwand akzeptabel wäre. Eine Austauschbarkeitsanforderung lohnt sich dort, wo ein Wechsel realistisch oder geschäftlich wichtig ist.

Dokumentieren Sie Datenflüsse vor der Implementierung.

Welche Daten fließen in welche Komponente, wer hat Zugriff und wie werden Änderungen nachvollzogen? Dokumentieren Sie die für Risiko und Betrieb relevanten Datenflüsse und Zuständigkeiten.

Trennen Sie Pilotprojekte von Produktionsentscheidungen.

Ein Pilot darf bewusst begrenzt sein. Vor dem Produktivbetrieb sollten Sie prüfen, ob Architektur, Datenzugriff, Überwachung und Kontrollen den Anforderungen des geplanten Einsatzes entsprechen. Fehlende Voraussetzungen können einen Umbau oder eine andere Lösung erfordern.

Beteiligen Sie Architekturkompetenz früh.

Beziehen Sie Architekturkompetenz abhängig von Umfang und Risiko rechtzeitig ein. Sie kann helfen, Abhängigkeiten und Integrationsfragen zusammen mit Fachbereich, IT-Sicherheit und Datenverantwortlichen zu prüfen.

Planen Sie für Veränderung.

Modelle und Dienste können sich ändern. Legen Sie fest, wie relevante Änderungen erkannt, getestet und in Betrieb übernommen werden. Die nötige Flexibilität sollte sich aus der Bedeutung eines Wechsels und dem erwarteten Änderungsaufwand ergeben.

Fazit

Bei KI-Anwendungen gehören Daten, Systemverhalten und Kontrollen zu den Architekturfragen. Welche davon besonders wichtig sind, hängt vom konkreten Einsatz ab.

Ein tragfähiges Konzept berücksichtigt, wie das System in bestehende Prozesse und Strukturen eingebunden, überwacht und bei Bedarf geändert werden kann. Modellwahl und Integration sollten dabei gemeinsam mit Zweck, Daten und Risiken betrachtet werden.

Der Prüfungsumfang sollte zum Vorhaben passen und spätestens vor einer Überführung in den Produktivbetrieb erneut bewertet werden.

Eine übergreifende Orientierung zu Anforderungen, Daten und Risiken bietet der Entscheidungs-Hub für KI.