KI in bestehende Systeme integrieren: Warum Kontext die Architektur entscheidet

Viele KI-Initiativen beginnen mit einem einzelnen Anwendungsfall. Häufig geht es dabei um einen internen Wissensassistenten oder die Analyse von Dokumenten. In anderen Fällen erfolgt der Einstieg im Kundenservice, beispielsweise durch die Unterstützung bei wiederkehrenden Anfragen. Die eigentlichen Geschäftsprozesse laufen parallel weiter. CRM und Ticketing bleiben produktiv. Dokumentenplattformen, Fachanwendungen und ältere Systeme sind oft tief in Abläufe eingebunden, die nicht einfach angehalten oder neu aufgebaut werden können. Ihre Backlogs sind in der Regel ohnehin voll.               

An dieser Stelle entscheidet sich, ob KI im Unternehmen über Pilotprojekte hinauskommt. Der Chatbot ist nicht der Kern der Architektur. Ausschlaggebend ist, wie Modelle auf vorhandene Systeme zugreifen und dabei den richtigen Kontext nutzen.

Das technische Umfeld verändert sich schnell. Neue Modellgenerationen verändern das Machbare. Agentische Workflows verschieben zusätzlich die Frage, wie viel Handlungsspielraum ein System erhalten soll. Damit steigt nicht nur das Potenzial, sondern auch der Integrationsaufwand.

Wer KI dauerhaft nutzen will, muss zuerst den Kontext begrenzen. Welche Informationen sind für einen Prozess relevant? Im nächsten Schritt stellt sich die Frage, welche Aktionen ein KI-System ausführen darf und über welche bestehenden Dienste diese Aktionen kontrolliert bereitgestellt werden. Leistungsfähige KI-Systeme entstehen nicht allein durch bessere Modelle. Maßgeblich ist, wie Informationen ausgewählt und bereitgestellt werden. Auf diese Weise wird Context Engineering zu einer Architekturaufgabe.

Die meisten Unternehmen starten nicht bei null. Im Laufe der Zeit haben sich Systemlandschaften entwickelt, die bereits viele fachliche Funktionen bereitstellen. CRM-Systeme können beispielsweise Kundendaten lesen oder aktualisieren. Ticketing-Tools können Incidents erstellen und Dokumentenplattformen Inhalte verwalten. Fachsysteme wiederum berechnen Preise oder prüfen Vertragsdaten.

Der erste Schritt besteht daher keineswegs darin, einen zusätzlichen KI-Schicht über alles zu legen. Sinnvoller ist es, die vorhandenen Fähigkeiten sichtbar zu machen.

Diese Fähigkeiten lassen sich als Capabilities beschreiben: klar abgegrenzte Aktionen, die ein System ausführen kann. Dazu gehören beispielsweise ein Ticket erstellen, einen Vertrag abrufen, Kundendaten aktualisieren, eine Bestellung prüfen oder einen Incident priorisieren.

In klassischen Architekturen werden solche Funktionen häufig über REST-APIs oder Service-Endpunkte bereitgestellt. Für KI-Systeme sind sie besonders relevant, da sie beschreiben, was ein Modell in einem Prozesskontext tatsächlich tun kann. Informationen abrufen oder Aktionen auslösen.

Die erste Architekturfrage beschäftigt sich mit den bereits vorhandenen Capabilities, ihrer Lage und den Bedingungen für ihre Nutzung.

Wie bereits beschrieben, arbeitet jede Capability mit bestimmten Daten. Bei KI-gestützten Prozessen müssen Fähigkeiten und Daten daher zusammen betrachtet werden. Ihre Zuordnung definiert den Kontext, innerhalb dessen ein KI-System sinnvoll operieren kann.

Ein Beispiel macht das greifbar: Ein KI-gestützter Prozess soll Support-Tickets analysieren und Lösungsvorschläge erstellen. Dafür reicht die Ticketbeschreibung nicht aus. Benötigt werden aktuelle Ticketdaten, vergleichbare historische Tickets, relevante Wissensartikel und Produktinformationen aus einem Fachsystem. Erst wenn all diese Quellen und Capabilities sauber zugeordnet sind, lässt sich der Kontext präzise zusammenstellen.

Dieser Schritt hat direkten Einfluss auf die Qualität der Ergebnisse. Ein Modell kann nur dann belastbare Vorschläge liefern, wenn es den passenden Ausschnitt der Systemlandschaft sieht. Zu wenig Kontext führt zu oberflächlichen Antworten. Zu viel Kontext erhöht die Kosten, die Latenz und die Fehlerrisiken. Gezielt bereitgestellter Kontext hat deshalb einen praktischen Nebeneffekt: In vielen Fällen lassen sich kleinere, effizientere Modelle einsetzen. Dadurch sinken Tokenverbrauch, Antwortzeiten und Betriebskosten, ohne dass die Architektur künstlich aufgebläht wird.

Anstatt von Chatbots oder isolierten Anwendungen auszugehen, sollte der Fokus auf dem Prozess liegen. Welche Schritte sind enthalten? Welche Systeme liefern Daten? Welche Capabilities müssen ausgeführt werden? Welche Entscheidungen benötigen eine Freigabe durch einen Menschen?

Das Ergebnis ist eine Capability-Map für den jeweiligen Prozess. Sie zeigt, welche Funktionen und Datenquellen den jeweiligen Kontext gemeinsam bilden. Wer diese Zusammenhänge sauber modelliert, landet schnell wieder bei klassischen Architekturwerkzeugen. Manchmal reicht dafür sogar UML.

Die Capability-Map macht sichtbar, welche Teile eines Prozesses durch KI unterstützt werden können und welche Abhängigkeiten dabei entstehen. Auf dieser Grundlage lässt sich entscheiden, ob ein Chat die geeignete Oberfläche ist. In vielen Fällen ist eine UI-Maske näher am Arbeitskontext. Für andere Prozessschritte eignet sich eine automatisierte Prozesslogik im Hintergrund besser.

Damit AI-Systeme vorhandene Capabilities nutzen können, müssen sie diese zunächst verstehen und kontrolliert einsetzen können. Genau hier setzen zwei derzeit intensiv diskutierte Konzepte an.

MCP (Model Context Protocol) beschreibt, wie ein KI-Modell externe Tools und Datenquellen nutzen kann. Es legt fest, welche Fähigkeiten verfügbar sind, welche Parameter benötigt werden und wie Ergebnisse zurückfließen. Kurz gesagt schafft MCP einen Schnittstellenstandard zwischen Modell und Tooling.

Agent-to-Agent (A2A) adressiert die Kommunikation zwischen spezialisierten KI-Komponenten, wenn Aufgaben nicht von einem einzelnen Agenten bearbeitet werden können. Mit anderen Worten handelt es sich um ein Protokoll für die Zusammenarbeit zwischen Agenten.

Sowohl MCP als auch A2A versuchen, eine gemeinsame Sprache zwischen KI-Systemen und klassischen Softwarediensten zu etablieren. Trotzdem ist ein nüchterner Blick erforderlich. In vielen Organisationen existieren bereits hunderte APIs, oft als REST-Services. Diese Schnittstellen bieten genau die Funktionen, die ArtificiaI-Intelligence-Systeme nutzen sollen.

Es wäre unrealistisch zu erwarten, dass jedes bestehende System kurzfristig zusätzlich einen eigenen MCP-Server betreibt. Maßgeblicher ist die Überlegung, wie sich bestehende Services so zugänglich machen lassen, dass künstliche Intelligenz sie kontrolliert nutzen kann. In manchen Fällen kann MCP als Beschreibungsschicht für Capabilities helfen. In anderen Fällen genügt es, vorhandene APIs sauber zu modellieren und über einen Orchestrierungs-Layer bereitzustellen. Das konkrete Protokoll ist dabei weniger entscheidend als das zugrunde liegende Architekturprinzip. Capabilities müssen für KI-Systeme verständlich beschrieben und mit klaren Zugriffen verbunden sein.

Sind die Capabilities und Datenquellen für einen Prozess sauber modelliert, ergibt sich daraus ein klarer Kontext für die KI-Unterstützung. Erst danach stellt sich die Frage nach der Benutzeroberfläche.

Manche Szenarien lassen sich am besten über klassische Anwendungen oder Prozessmasken lösen. Andere lassen sich wiederum hervorragend über eine Chat-Interaktion lösen. Wieder andere laufen vollständig automatisiert im Hintergrund.

Eine mögliche Ausprägung ist eine sogenannte Companion-App, also ein zentraler KI-Assistent für Mitarbeitende. In einer serviceorientierten Architektur kann ein solcher Assistent auf unterschiedliche Funktionen zugreifen, beispielsweise Tickets erstellen, Dokumente zusammenfassen, Prozesse anstoßen oder Informationen aus mehreren Systemen zusammenführen.

Voraussetzung dafür ist jedoch eine belastbare Grundlage in Form eines klaren Modells der verfügbaren Fähigkeiten, einer nachvollziehbaren Datenperspektive sowie eines Sicherheits- und Rollenmodells, das Tool-Zugriffe begrenzt. Ohne diese Basis bleibt künstliche Intelligenz ein Experiment neben der bestehenden Prozesslandschaft. Mit ihr kann KI Teil der Prozessarchitektur werden.

Die Diskussion über KI in Unternehmen kreist oft um Modelle, Tools und Chatbots. Allerdings wird dabei ein entscheidender Punkt übersehen. KI muss in bestehende Prozessarchitekturen integriert und darf nicht daneben gestellt werden.

Wer die richtigen Fragen stellt, schafft die Grundlage für belastbare KI-Anwendungen. Welche Capabilities sind vorhanden? Welche Daten fließen in welche Prozesse? Welcher Kontext entsteht daraus? Welche Zugriffe müssen kontrolliert werden? Die eigentliche Entscheidung liegt in der Architektur der Prozesse und Systeme. Ob künstliche Intelligenz (KI) bei einzelnen Piloten stehen bleibt oder dauerhaft in produktive Prozesse eingebunden wird, entscheidet sich genau dort.

Die Architekturleitlinien der großen Cloud-Provider stützen diese Perspektive: Anstelle von reinen Chatbots definieren sie AI-Systeme als orchestrierte Systeme, die Modelle, Tools, Datenquellen, Workflows, Kontext und Governance zusammenführen. Die Unterschiede liegen im Detail.

Die gemeinsame Linie ist klar definiert. Die Benutzeroberfläche ist nicht der Ausgangspunkt. Entscheidend ist die Struktur darunter. AI braucht klar beschriebene Capabilities und einen begrenzten, kontrolliert bereitgestellten Kontext.