Planungsteams behandeln „LLM“, „Copilot“, „Agent“ und „Verbund-KI-System“ oft als austauschbare Begriffe. Das sind sie nicht. Jeder Begriff bezieht sich auf eine andere Architektur mit unterschiedlichen Kostenprofilen und Fehlermodi. Diese Verwechslung führt zu kostspieligen Planungsfehlern.

Ein Beispiel ist die Zuweisung eines hochmodernen Reasoning-Modells für eine Ticket-Klassifizierungsaufgabe, die ein feinabgestimmtes 8B-Modell zu einem Bruchteil der Kosten bewältigen könnte. Ein weiteres Beispiel ist die Planung einer RAG-Funktion als kurzen Sprint, nur um dann ein ganzes Quartal mit der Chunking-Strategie, der Aktualität der Metadaten und der Retrieval-Evaluierung zu verbringen, bevor sie in Produktion geht.

Das in der Praxis bewährte Unternehmensmuster ist spezifischer: Verbundsysteme, bei denen mehrere Modelle, Retriever und Validierungsschichten unter deterministischer Steuerungslogik arbeiten. In diesen Systemen ist die Modellwahl wichtig, aber nur ein Teil des Aufwands. Die meiste Entwicklungszeit fließt in den Entwurf und die Wartung des Systems um das Modell herum, und hier entscheiden sich Projekte meist über Erfolg oder Misserfolg.

Was Verbund-KI-Systeme sind

Ein Verbund-KI-System ist eine modulare Architektur, die mehrere KI- und Nicht-KI-Komponenten kombiniert, um Aufgaben zu lösen, die ein einzelnes Modell nicht zuverlässig oder effizient bewältigen kann. Anstatt einem einfachen Eingabe → Modell → Ausgabe-Muster zu folgen, ist ein Verbundsystem über fünf funktionale Schichten strukturiert.

Modelle

Ein oder mehrere LLMs übernehmen Schlussfolgerungen, Generierung oder Klassifizierung. In der Produktion verwenden Systeme oft mehrere Modelle unterschiedlicher Kostenstufen. Ein kleineres, schnelleres Modell kann die eingehende Anfrage klassifizieren, während ein größeres Modell den komplexeren Schlussfolgerungsschritt übernimmt. Das Routing zwischen ihnen hilft, sowohl Latenz als auch Kosten zu kontrollieren.

Abruf und Kontext

Vektordatenbanken, Suchindizes oder direkte API-Abfragen stellen unternehmensspezifische Daten zur Inferenzzeit bereit. Ohne diese Schicht arbeitet das Modell nur mit seinen Trainingsdaten, was veraltetes Wissen und keine Kenntnis interner Systeme bedeutet.

Tools und Integrationen

Externe APIs, Code-Interpreter oder Regelwerke ermöglichen es dem System, über die Textgenerierung hinaus Aktionen auszuführen. Wenn ein Workflow einen Datensatz aktualisieren oder eine Berechnung mit aktuellen Finanzdaten durchführen muss, kann das Modell bestimmen, was geschehen soll, aber die Tool-Integration führt die Aufgabe aus.

Workflow-Logik

Traditioneller Anwendungscode oder Orchestrierungs-Frameworks definieren, welche Komponenten in welcher Reihenfolge und unter welchen Bedingungen ausgeführt werden. Diese Schicht trennt ein Verbundsystem von einem Chatbot.

Validierung und Schutzmechanismen

Sekundäre Prüfungen bewerten Modellausgaben, bevor sie den Endbenutzer erreichen. Diese können von regelbasierten Compliance-Filtern bis hin zu einem separaten LLM reichen, das als Kritiker fungiert. In regulierten Branchen ist hier auch die Auditierbarkeit angesiedelt.

Diese Schichten agieren als System, nicht als isolierte Teile. Der Abruf prägt, was das Modell sieht. Die Workflow-Logik bestimmt, wann und wie oft das Modell läuft. Die Validierung kann eine Ausgabe ablehnen und einen erneuten Versuch auslösen. In der Praxis verbringen Entwicklungsteams die meiste Zeit mit diesen Interaktionen und nicht mit dem Modell selbst.

Warum ein Einzelmodell-Ansatz in realen Produkten scheitert

Zu Beginn vieler KI-Initiativen gehen Teams davon aus, dass ein besseres Modell ihre Produktionsprobleme lösen wird. Ein leistungsfähigeres Modell halluziniert möglicherweise weniger, befolgt Anweisungen zuverlässiger und bewältigt mehr Grenzfälle. Diese Annahme wird jedoch deutlich schwächer, sobald das System mit realen Geschäftsdaten und echten Verantwortlichkeitsanforderungen arbeiten muss.

Vier Fehlermodi treten wiederholt auf, wenn Teams von der Pilotphase zur Produktion übergehen.

Das Modell weiß nicht, was gestern passiert ist

LLMs werden mit statischen Schnappschüssen trainiert. Sie kennen weder interne Dokumentationen, CRM-Daten noch die letzte Woche veröffentlichte Richtlinienaktualisierung. Im Produktivbetrieb führt dies dazu, dass Systeme mit veralteten Informationen antworten oder ohne Kenntnis der aktuellen internen Realität agieren. Das Hinzufügen von mehr Prompt-Kontext hilft nur bis zu einem gewissen Grad und erhöht Kosten und Latenz. Retrieval löst das Problem auf Systemebene, indem es zur Inferenzzeit aktuelle, relevante Daten bereitstellt.

Das Modell folgt Ihrem Prozess nicht

LLMs sind probabilistisch. Sie können ein Modell anweisen, einem mehrstufigen Genehmigungsprozess zu folgen, und es wird dies meistens tun. Im Produktivbetrieb ist „meistens“ nicht ausreichend. In Workflows wie Rückerstattungen oder Compliance-Prüfungen kann selbst eine geringe Fehlerrate zu Audit-Risiken führen. Verbundsysteme lösen dies, indem sie die Prozesslogik im Anwendungscode platzieren, wo jeder Schritt in einer definierten Reihenfolge abläuft und das Modell innerhalb eines begrenzten Bereichs agiert.

Das Modell kann Zugriffsbarrieren nicht durchsetzen

Ein einzelnes Modell hat kein natives Verständnis von Berechtigungen. Wenn die Retrieval-Pipeline Informationen aus der gesamten Organisation weiterleitet, wird das Modell diese nutzen. Es kann nicht eigenständig bestimmen, welche Datensätze ein bestimmter Benutzer sehen darf. In Multi-Tenant-SaaS- und regulierten Umgebungen muss die Zugriffskontrolle in den Retrieval- und Filterebenen erfolgen, bevor das Modell aufgerufen wird.

Die Kosten entwickeln sich in die falsche Richtung

Teams versuchen oft, architektonische Lücken mit längeren Prompts zu kompensieren: mehr Anweisungen, mehr Beispiele und mehr Kontext. Das mag im Test akzeptabel erscheinen, aber bei Produktionsvolumen vervielfacht es sowohl Kosten als auch Latenz bei jeder Anfrage. Retrieval- und Speicherarchitekturen, die pro Abfrage nur den relevanten Kontext bereitstellen, sind deutlich effizienter. In Workflows mit hohem Volumen wie Support-Triage, Dokumentenverarbeitung und interner Suche kann dieser Unterschied darüber entscheiden, ob die Funktion finanziell tragfähig ist.

Wann Unternehmen Verbund-KI-Systeme benötigen und wann nicht

Nicht jede KI-Funktion erfordert die Komplexität einer Verbundarchitektur. Die Entscheidung sollte von geschäftlichen Zwängen und nicht von technologischer Neuheit bestimmt werden.

Wann Verbund-KI-Systeme erforderlich sind

Kontext aus mehreren Quellen

Die Aufgabe hängt von Informationen ab, die über mehrere Systeme wie CRM, E-Mail und proprietäre Datenbanken verteilt sind.

Systemübergreifende Aktionen

Der Workflow erfordert, dass das KI-System mit internen Tools oder externen APIs interagiert, um eine Transaktion abzuschließen.

Entscheidungen mit hohen Risiken

Die Ausgabe beeinflusst Umsatz, Compliance oder Kundensicherheit und erfordert daher Validierung und menschliche Überwachung (Human-in-the-Loop).

Strenge Prüfbarkeit

Die Organisation muss nachvollziehen können, warum eine bestimmte Antwort gegeben wurde, einschließlich der abgerufenen Beweise und der Begründungsspuren.

Wann Verbund-KI-Systeme wahrscheinlich überdimensioniert sind

Entwurfserstellung mit geringem Risiko

Aufgaben wie die Erstellung von Entwürfen oder Zusammenfassungen, bei denen ein menschlicher Prüfer der Hauptnutzer ist und der Kontext begrenzt ist.

Einstufige Frage-Antwort-Systeme

Einfache Anfragen über einen begrenzten, statischen Korpus, bei denen ein einfaches RAG oder ein Single-Shot-Prompt ausreicht.

Explorative Pilotprojekte

Frühe Experimente, bei denen der Nachweis der reinen Modellfähigkeit wichtiger ist als die betriebliche Zuverlässigkeit.

Häufige Anwendungsfälle für zusammengesetzte KI-Systeme

Erfolgreiche Unternehmensimplementierungen lassen sich im Allgemeinen in vier hochwertige Kategorien einteilen.

Internes Wissen und Entscheidungsunterstützung

Diese Systeme integrieren Abrufsysteme aus Rechts-, Steuer- oder technischer Dokumentation. Sie priorisieren die Nachvollziehbarkeit von Antworten und die regionale Berechtigungsvergabe, um sicherzustellen, dass Benutzer in einer Abteilung keine sensiblen Daten aus einer anderen Abteilung abrufen können.

Workflow-Copiloten für interne Teams

Eingesetzt in Funktionen wie Vertrieb, Finanzen und Engineering, verbinden diese Systeme mehrere Tools wie Jira, Salesforce und interne ERP-Systeme. Sie bewältigen mehrstufige Aufgaben, indem sie Modellaufrufe verketten, um Datensätze abzurufen, zu analysieren und zu aktualisieren.

Kundenorientierte Support-Workflows

Diese Workflows erfordern hohe Präzision und ausfallsichere Logik. Ein zusammengesetztes System kann ein kleines, schnelles Modell verwenden, um ein eingehendes Ticket zu klassifizieren, ein Abrufsystem, um die wahrscheinliche Lösung zu identifizieren, und ein größeres Kritiker-Modell, um die Antwort zu überprüfen, bevor sie gesendet wird.

Regulierte operative Workflows

In Branchen wie HealthTech und FinTech können zusammengesetzte Systeme Aufgaben wie Vorabgenehmigungen oder Gutschriften automatisieren. Diese Architekturen verknüpfen Fachdaten mit Regeln und teilen die Arbeit in Unteraufgaben auf, die einzelne Modelle allein nicht so zuverlässig bewältigen können.

Zusammengesetzte KI-Systeme vs. KI-Agenten

Es gibt eine erhebliche Marktverwirrung zwischen „agentischen Systemen“ und „autonomen Agenten“. Während alle Multi-Agenten-Systeme zusammengesetzte Systeme sind, trifft das Umgekehrte nicht zu.

Zusammengesetzte KI-Systeme

Zusammengesetzte KI-Systeme sind typischerweise für strukturierte Ausführung und Zuverlässigkeit optimiert. Sie verwenden vordefinierte Workflows, bei denen die Steuerungslogik im Code liegt, was sie vorhersehbarer und einfacher zu testen macht.

KI-Agenten

KI-Agenten fügen eine Ebene dynamischer Entscheidungsfindung hinzu. Das LLM steuert seinen eigenen Prozess und die Werkzeugnutzung Schritt für Schritt und wählt dabei den weiteren Weg. Diese Flexibilität ist nützlich, wenn die korrekte Abfolge nicht im Voraus bekannt ist, führt aber auch zu höherer Latenz, Kosten und geringerer Vorhersagbarkeit.

Wie das praktische Produktionsmuster aussieht

Für die meisten Produktionsanwendungsfälle ist das praktische Muster die begrenzte Agentenfunktion (bounded agency): ein agentischer Schritt, der innerhalb eines Verbundsystems ausgeführt wird. Der gesamte Workflow bleibt vordefiniert und code-gesteuert. An einem bestimmten Schritt, wo der Pfad wirklich unvorhersehbar ist, erhält das Modell eine begrenzte Autonomie, um Werkzeuge auszuwählen oder zu bestimmen, wie viele Abrufdurchläufe ausgeführt werden sollen. Das umgebende System erzwingt weiterhin ein Timeout, eine maximale Anzahl von Tool-Aufrufen und eine Validierungsprüfung der Ausgabe.

So funktionieren viele Produktions-„Agenten“ in der Praxis tatsächlich. Die Schnittstelle mag einen autonomen Agenten beschreiben, aber die Architektur besteht oft aus einem Verbundsystem mit einem agentischen Knoten innerhalb einer deterministischen Pipeline, plus einer Fallback-Route zu einem Menschen, falls dieser Schritt seine Grenzen überschreitet.

Wenn ein Team evaluiert, ob es agentische Fähigkeiten hinzufügen soll, helfen zwei Fragen, die Entscheidung zu strukturieren. Erstens: Gibt es einen Schritt, bei dem die korrekte Abfolge von Aktionen nicht im Voraus definiert werden kann, weil die richtige Aktion von Zwischenergebnissen abhängt? Zweitens: Können für diesen Schritt klare Einschränkungen definiert werden, einschließlich maximaler Tool-Aufrufe, Timeout-Limits und einer Validierungsprüfung der Ausgabe? Wenn beides zutrifft, könnte eine begrenzte Agentenfunktion (bounded agency) passen. Wenn nicht, benötigt der Schritt wahrscheinlich mehr Entwicklungsarbeit, bevor er produktionsreif ist.

Herausforderungen bei der Implementierung von Verbund-KI-Systemen

Verbundsysteme lösen Probleme, die einzelne Modelle nicht lösen können, führen aber auch zu technischen Herausforderungen, die viele Teams in der Planungsphase unterschätzen. Die Schwierigkeit besteht darin, die Komponenten unter Produktionsbedingungen zusammenarbeiten zu lassen.

Orchestrierungs-Anfälligkeit

Die Verkettung mehrerer nicht-deterministischer Komponenten kann zu Fehlerakkumulation führen. Wenn ein Klassifikator im ersten Schritt fehlschlägt, kann der Rest der Kette trotzdem fortfahren und ein halluziniertes Ergebnis produzieren.

Aktualität von Daten und Kontext

Eine zuverlässige Retrieval-Pipeline aufrechtzuerhalten, ist oft schwieriger als das Modell zu optimieren. Schlechte Segmentierung (Chunking) oder veraltete Metadaten können selbst ein fortschrittliches Reasoning-Modell untergraben.

Latenz- und Kostenmanagement

Jeder zusätzliche Modellaufruf erzeugt zusätzliche Roundtrips. Entwicklungsteams müssen Frontier-Modelle mit kleineren, spezialisierten Modellen ausbalancieren, um die Leistung dort zu steuern, wo geringe Latenz weiterhin wichtig ist.

Evaluierung und Beobachtbarkeit

Traditionelles Unit-Testing ist nicht ausreichend. Teams benötigen aufgabenspezifische Evaluierungspipelines, die Fehler der richtigen Komponente zuordnen können, z. B. einem leistungsschwachen Retriever im Vergleich zu einem halluzinierenden Generator.

Teams, die mit Verbundsystemen erfolgreich sind, investieren entweder in die disziplinübergreifende Weiterbildung oder arbeiten mit einer Engineering-Organisation zusammen, die den gesamten Stack abdecken kann. Die Entscheidung „selbst entwickeln oder Partner suchen“ sollte frühzeitig evaluiert werden, da das Entdecken einer Fähigkeitslücke mitten in der Implementierung teurer ist, als das Team von Anfang an richtig zu dimensionieren.

Was man fragen sollte, bevor man eines baut

Wenn ein Verbundsystem die richtige Architektur zu sein scheint, ist der nächste Schritt nicht die Implementierung. Es ist die Umfangsdefinition. Die Quelle legt fünf Fragen dar, die Zeitplan, Teamanforderungen und Budget beeinflussen.

Wie viele Systeme müssen verbunden werden?

Zählen Sie die Datenquellen und externen Dienste, die das Feature ansprechen muss. Ein System, das Daten aus einer internen Datenbank abruft, ist ein ganz anderes Projekt als eines, das ein CRM, eine Dokumentenplattform und mehrere Drittanbieter-APIs integriert. Jede Integration fügt ein zu wartendes System, ein zu normalisierendes Format und einen neuen Fehlerfall hinzu, der behandelt werden muss. Die Anzahl der Integrationen ist einer der stärksten Prädiktoren für den gesamten Engineering-Aufwand.

Was kostet eine falsche Ausgabe?

Ein schwaches Entwurfswerkzeug kann Zeit verschwenden. Ein klinisches Empfehlungssystem, das eine Kontraindikation übersieht, birgt Risiken für Patienten. Unterschiedliche Fehlerszenarien erfordern unterschiedliche Validierungsarchitekturen und unterschiedliche Investitionen in Tests.

Kann ein einfacherer Ansatz Sie zuerst in die Produktion bringen?

Bevor Sie sich für eine Mehrkomponenten-Architektur entscheiden, prototypisieren Sie die Aufgabe mit einem einzelnen Modellaufruf oder einem einfachen Retrieval-Setup. Wenn das Modell in einer einfachen Umgebung keine nützlichen Ergebnisse mit gutem Kontext liefern kann, wird zusätzliche Orchestrierung die zugrunde liegende Lücke nicht schließen. Wenn der einfache Ansatz funktioniert, aber Mängel bei Genauigkeit, Aktualität oder Zugriffskontrolle aufweist, erhalten Sie einen klaren Fahrplan, welche komplexen Schichten als Nächstes hinzugefügt werden müssen.

Verfügt Ihr Team über die richtigen Fähigkeiten, oder benötigen Sie einen Partner?

Ein komplexes System erfordert Retrieval-Engineering, Backend-Architektur, Modellmanagement und domänenspezifische Logik. Fehlt eine Fähigkeit, mag das eine überschaubare Lücke sein. Fehlen mehrere, gerät die interne Entwicklung in der Integrationsphase eher ins Stocken.

Können Sie das System nach dem Start warten?

Komplexe Systeme erfordern laufende operative Arbeit. Anbieter aktualisieren Modelle, Quelldaten ändern sich, Retrieval-Indizes müssen neu verarbeitet werden, und Evaluierungspipelines benötigen gepflegte Testdatensätze, die reale Produktionsmuster widerspiegeln. Ein System, das startet und sich dann verschlechtert, weil niemand das Retrieval oder die Evaluierung pflegt, ist schlechter als ein einfacheres System, das zuverlässig bleibt.

Fazit

Die entscheidende Wende in der generativen KI ist der Übergang von isolierten Modellausgaben zu operativen Systemen, die auf reale geschäftliche Anforderungen zugeschnitten sind. Komplexe KI-Systeme spiegeln eine praktische Realität wider: Intelligenz mag reichlich vorhanden sein, aber Zuverlässigkeit, Kontext und Kontrolle sind es nicht. In diesem Umfeld wird die Architektur zum primären Unterscheidungsmerkmal. Unternehmen, die den Unterschied zwischen einem Modell als Fähigkeit und einem System als Produkt verstehen, sind besser aufgestellt, um KI zu entwickeln, die schneller, kostengünstiger, sicherer und skalierbarer ist. Die zentrale Frage für technische Führungskräfte ist nicht mehr, ob KI hinzugefügt werden soll, sondern welche Art von System ein spezifischer Workflow tatsächlich erfordert.