WISSEN > KI INFRASTRUKTUR > KI INFRASTRUKTUR ARCHITEKTUR

Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026

KI Infrastruktur Architektur
Wie Unternehmensdaten, RAG, LLMs und KI-Anwendungen zusammenspielen

Das sollten Sie mitnehmen:

Ein LLM setzt Text fort, es speichert kein Wissen.
Überzeugend formulierte Falschaussagen sind Folge des Verfahrens, nicht ein Defekt.
Das Kontextfenster ist die zentrale Randbedingung.
Aus seiner Begrenzung folgen Chunking, Retrieval und Kontextzusammenstellung.
Drei Wege führen Wissen zum Modell.
Training, Feintuning und Kontext — im Unternehmensalltag trägt vor allem der dritte.
RAG ersetzt das Neutraining, nicht die Aktualisierung.
Der Retrieval-Index wird periodisch nachgeführt und hinkt der Quelle nach.
Berechtigungen gehören in die Architektur.
Sie wirken von der Ingestion bis zur Antwort, nicht als nachgelagerter Filter.

KI Infrastruktur Architektur

Inhaltsverzeichnis

Unternehmen verfügen meist bereits über große Mengen potenziell relevanter Daten: Dokumente auf File-Storage-Systemen, Objekte in S3-kompatiblen Speichern, Informationen in Datenbanken, Data Lakes, SaaS-Plattformen und Fachanwendungen. Ein Large Language Model kann diese Daten jedoch nicht automatisch nutzen.

Zwischen den vorhandenen Unternehmensdaten und einer produktiven KI-Anwendung entsteht deshalb eine Daten- und Integrationsarchitektur. Die Begriffe dafür sind geläufig — RAG, Vektordatenbank, Data Lake, MCP, Agent. Schwieriger zu beurteilen ist, welche Komponente welche Aufgabe übernimmt, welche zwingend erforderlich ist und welche nur eine von mehreren Möglichkeiten darstellt.

Dieser Beitrag beantwortet diese Frage von unten her: zuerst, wie ein Sprachmodell arbeitet und woraus sich seine Grenzen ergeben, dann, welche Infrastrukturkomponenten aus genau diesen Grenzen folgen.

Ein Sprachmodell setzt Text fort, es schlägt nichts nach

Ein Large Language Model ist ein statistisches Modell für Sprache. Es besteht aus einer sehr großen Zahl numerischer Parameter — Gewichte, deren Werte während des Trainings ermittelt werden. Heutige Modelle bewegen sich im Bereich von Milliarden bis mehreren hundert Milliarden Parametern.

Text wird für die Verarbeitung in Tokens zerlegt, also in Wortbestandteile. Beim Training verarbeitet das Modell sehr große Textmengen und wird darauf optimiert, aus einer gegebenen Tokenfolge das jeweils folgende Token vorherzusagen. Das ist der gesamte Trainingsvorgang im Kern. Alles, was ein Modell später zu können scheint — zusammenfassen, übersetzen, formulieren, schlussfolgern — entsteht als Nebenprodukt dieser einen Optimierungsaufgabe über hinreichend viel Text.

Für die Architekturbetrachtung ist eine Konsequenz daraus entscheidend. Das Modell erzeugt bei jeder Anfrage eine Wahrscheinlichkeitsverteilung über mögliche nächste Tokens und wählt daraus aus. Optimiert wurde also sprachliche Plausibilität, nicht sachliche Richtigkeit. Ein Modell, das eine falsche Vertragsnummer oder eine nicht existierende Norm nennt, ist nicht defekt — es tut genau das, wofür es trainiert wurde, nämlich eine plausible Fortsetzung zu erzeugen.

Deshalb ist die Frage, aus welcher Quelle eine Aussage stammt und ob sie überprüfbar ist, keine nachgelagerte Qualitätsfrage. Sie ist der Grund, warum überhaupt eine Dateninfrastruktur um das Modell herum gebaut wird.

Was das Modell während des Trainings aufgenommen hat, ist zudem in den Parametern nicht als abrufbarer Datensatz abgelegt, sondern über die Gewichte verteilt. Es lässt sich nicht gezielt einsehen, nicht gezielt löschen und nicht gezielt korrigieren. Für Unternehmensdaten, die Aufbewahrungsfristen, Löschpflichten und Zugriffsbeschränkungen unterliegen, ist das eine wesentliche Einschränkung.

Diese Darstellung bleibt bewusst bei dem, was für die Architekturbetrachtung nötig ist. Der innere Aufbau eines Modells — das Zusammenspiel von Tokenisierung, Embeddings und Attention, der Unterschied zwischen Dense- und Mixture-of-Experts-Architekturen — sowie die Frage, unter welcher Lizenz und in welchem Betriebsmodell ein bestimmtes Modell überhaupt eingesetzt werden kann, sind Gegenstand eines eigenen Beitrags.

[QV: Was ist ein Large Language Model (LLM) und wie funktioniert es? — Aufbau, Funktionsweise, Architekturen und Betriebsmodelle]

Das Kontextfenster bestimmt, was gleichzeitig berücksichtigt werden kann

Der Vorgang, bei dem ein trainiertes Modell eine konkrete Anfrage verarbeitet und eine Antwort erzeugt, heißt Inferenz. Dabei werden keine Parameter verändert. Das Modell liest eine Eingabe und erzeugt eine Ausgabe; nach der Anfrage bleibt davon im Modell nichts zurück.

Die Eingabe unterliegt einer harten Grenze: dem Kontextfenster. Es bemisst sich in Tokens und umfasst alles, was das Modell für diese eine Anfrage gleichzeitig berücksichtigen kann — Systemanweisungen, übergebene Dokumenteninhalte, die eigentliche Frage, den bisherigen Gesprächsverlauf und die entstehende Antwort. Was nicht hineinpasst, existiert für das Modell in diesem Moment nicht.

[BILD 1: Kontextfenster — welche Bestandteile um den verfügbaren Platz konkurrieren]

Aus dieser Begrenzung folgt ein erheblicher Teil der später beschriebenen Architektur. Ein Unternehmensbestand von einigen hunderttausend Dokumenten lässt sich nicht in ein Kontextfenster legen, unabhängig davon, wie groß dieses in kommenden Modellgenerationen wird. Es muss also ausgewählt werden, welche Inhalte für eine konkrete Frage übergeben werden. Genau diese Auswahl leistet ein Retrieval-System.

Damit ausgewählt werden kann, müssen die Bestände zuvor in geeignete Einheiten zerlegt worden sein — ganze Handbücher füllen das Fenster, einzelne Abschnitte nicht. Das ist der Grund für das später beschriebene Chunking. Und weil nur begrenzt viel übergeben werden kann, liefert ein Retrieval-System nicht alle passenden Treffer, sondern die besten wenigen.

Chunking, Ähnlichkeitssuche und Kontextzusammenstellung sind also keine willkürlichen Verfahrensschritte. Sie sind unmittelbare Konsequenzen der Tatsache, dass ein Modell pro Anfrage nur eine begrenzte Menge Text berücksichtigen kann.

Größere Kontextfenster verschieben diese Grenze, sie beseitigen sie nicht — und sie sind nicht kostenlos: Der Aufwand pro Anfrage steigt mit der Menge übergebenen Texts, und ausufernder Kontext verschlechtert die Antwortqualität eher, als sie zu verbessern.

Drei Wege führen Wissen zum Modell — nur einer trägt den Alltag

Damit ein Modell mit Unternehmensinformationen arbeiten kann, gibt es grundsätzlich drei Möglichkeiten. Sie unterscheiden sich nicht nur im Aufwand, sondern in ihren Eigenschaften.

Beim Training entsteht das Modell selbst. Das ist für Unternehmen praktisch keine Option: Es erfordert sehr große Datenmengen, erheblichen Rechenaufwand und liefert am Ende wieder ein Modell, dessen Wissensstand am Tag der Fertigstellung eingefroren ist.

Beim Feintuning wird ein vorhandenes Modell mit zusätzlichen, meist deutlich kleineren Datenmengen weitertrainiert. Die Parameter ändern sich dabei. Das eignet sich gut, um Verhalten zu prägen — Tonfall, Antwortformate, fachsprachliche Konventionen. Als Weg, Unternehmenswissen einzubringen, hat es dagegen ungünstige Eigenschaften: Jede Änderung an den zugrunde liegenden Dokumenten erfordert einen erneuten Durchlauf, die Herkunft einer Aussage bleibt unbelegt, und Berechtigungen lassen sich nicht abbilden. Ein feingetuntes Modell weiß entweder alles, was in den Trainingsdaten stand, oder nichts davon — eine Differenzierung nach Benutzer gibt es nicht.

Beim dritten Weg wird die Information zur Abfragezeit als Kontext übergeben. Die Parameter bleiben unverändert. Die Information ist damit so aktuell wie die Quelle zum Zeitpunkt des Abrufs, ihre Herkunft ist nachvollziehbar, sie kann pro Benutzer unterschiedlich ausfallen, und sie kann jederzeit entzogen werden.

[BILD 2: Training, Feintuning und Kontext im Vergleich — Aktualisierbarkeit, Nachvollziehbarkeit, Berechtigungsfähigkeit]

Genau hier setzt Retrieval-Augmented Generation an. Das ursprüngliche Konzept von Lewis et al. kombiniert parametrisches Wissen eines vortrainierten Modells mit einer externen, nicht-parametrischen Wissensquelle. Die Autoren begründen diesen hybriden Ansatz ausdrücklich damit, dass sich Wissen auf diesem Weg revidieren und erweitern lässt und dass das herangezogene Wissen einsehbar und interpretierbar bleibt.

Die drei Wege schließen einander nicht aus. Feintuning für das Verhalten und Kontext für die Inhalte ist eine übliche Kombination. Für die Frage, wie Unternehmensdaten zum Modell gelangen, ist jedoch der dritte Weg der tragende — und er ist derjenige, der eine Dateninfrastruktur voraussetzt.

Ein trainiertes Modell kennt Ihr Unternehmen nicht

Eine KI-Anwendung für technische Dokumentation benötigt andere Daten als ein System zur Analyse von Maschinendaten oder ein Agent, der Informationen aus einem ERP-System abfragt. Die erste Architekturfrage lautet deshalb nicht, welches Modell eingesetzt werden soll, sondern welche Informationen die Anwendung benötigt und wo diese Informationen heute liegen.

Relevante Daten sind in der Praxis über unterschiedliche Systeme verteilt: File Storage und NAS-Systeme, Global File Systems, Objektspeicher, Data Lakes und Data Warehouses, klassische Datenbanken, SaaS-Plattformen sowie ERP-, CRM- und weitere Fachanwendungen. [QV: Enterprise Storage Grundlagen — Systemlandschaft, in der Unternehmensdaten typischerweise liegen] [QV: Global File System — verteilte Dateibestände über mehrere Standorte hinweg]

Eine vollständige Zentralisierung aller Unternehmensdaten ist dafür nicht erforderlich. AWS beschreibt die eigene Lakehouse-Architektur ausdrücklich als Interoperabilitätsansatz, der den Zugriff über S3-Data-Lakes, Redshift-Data-Warehouses sowie Drittanbieter- und föderierte Quellen vereinheitlicht, und stellt dabei die Möglichkeit heraus, Daten über die Iceberg-REST-API an Ort und Stelle abzufragen. Selbst dort, wo eine Plattform angeboten wird, ist das Kopieren sämtlicher Bestände also nicht das leitende Prinzip.

Damit verschiebt sich die Fragestellung. Nicht "Wo speichern wir alle Daten?", sondern "Wie stellen wir die benötigten Daten kontrolliert für den jeweiligen KI-Workload bereit?".

Am Anfang steht der Anwendungsfall, nicht das Modell

Damit lässt sich die Ausgangslage präzise fassen. Modellwissen ist in den Parametern des trainierten Modells repräsentiert und stammt aus dessen Trainingsdaten. Unternehmensinformationen befinden sich außerhalb des Modells in den Datenbeständen und Anwendungen des Unternehmens. Ein eingesetztes LLM kennt die aktuellen Verträge, technischen Dokumentationen, Projektdaten oder ERP-Inhalte eines Unternehmens nicht.

Genau zwischen diesen beiden Ebenen entsteht die KI-Infrastruktur. Ihre Aufgabe lautet, aus den Beständen des Unternehmens für jede einzelne Anfrage die passenden und zulässigen Informationen auszuwählen und in das begrenzte Kontextfenster zu bringen.

Dafür gibt es mehrere Wege. Welcher trägt, hängt davon ab, wo die benötigten Informationen liegen, wie oft sie sich ändern und was die Anwendung mit ihnen tun soll.

Ein Retrieval-Index ist nur eine von mehreren Bezugsquellen

Steht fest, welche Informationen benötigt werden und wo sie liegen, folgt die eigentliche Architekturentscheidung: auf welchem Weg sie in das Kontextfenster gelangen. Vier Varianten sind gebräuchlich, und sie schließen einander nicht aus — größere Anwendungen kombinieren sie regelmäßig.

Der erste Weg ist der eigene Retrieval-Index. Inhalte werden aus den Quellen übernommen, aufbereitet und in einer durchsuchbaren Struktur abgelegt, aus der zur Abfragezeit ausgewählt wird. Das ist der Weg, den RAG beschreibt. Er eignet sich für große Mengen unstrukturierter Dokumente, in denen nicht vorab bekannt ist, welcher Abschnitt zu einer Frage passt. Er erfordert dafür den größten Infrastrukturaufwand und erzeugt eine zusätzlich zu betreibende Kopie.

Der zweite Weg ist der direkte Zugriff auf ein Quellsystem über dessen Schnittstelle. Eine Frage wird in eine Abfrage übersetzt, das System antwortet, das Ergebnis geht in den Kontext. Das eignet sich für strukturierte, häufig wechselnde und benutzerabhängige Werte — Bestände, Salden, Vorgangsstatus. Ein Index wäre hier nicht nur überflüssig, sondern schädlich, weil er einen veralteten Stand konservieren würde.

Der dritte Weg ist die föderierte Abfrage ohne Kopie. Die Daten verbleiben in ihren Systemen und werden über eine gemeinsame Zugriffsschicht an Ort und Stelle abgefragt. Das ist besonders dann relevant, wenn Datenlokalität, Lizenzbedingungen oder regulatorische Vorgaben gegen das Anlegen weiterer Kopien sprechen.

Der vierte Weg ist die unmittelbare Übergabe. Der Benutzer stellt das Dokument selbst bereit, über das er eine Frage hat. Das benötigt überhaupt keine Dateninfrastruktur und ist für viele Einzelfälle die angemessene Antwort — ein Punkt, der in Architekturdiskussionen häufig übergangen wird.

Die Auswahl richtet sich an wenigen Kriterien aus: Umfang und Struktur des Bestands, Änderungsfrequenz, ob die Antwort für alle Benutzer gleich lautet, wie feingranular Berechtigungen wirken müssen und ob eine Kopie der Daten überhaupt zulässig ist.

Die folgenden Kapitel behandeln den Retrieval-Weg ausführlich. Nicht, weil er der Regelfall wäre, sondern weil er von allen vier Varianten die meiste Infrastruktur verlangt und deshalb die meisten Entscheidungen erfordert. Auf die übrigen Wege kommen wir bei der Anbindung operativer Systeme zurück.

Vorhandene Daten sind noch keine nutzbaren Daten

Dass Daten vorhanden sind, bedeutet nicht, dass sie für eine KI-Anwendung sinnvoll nutzbar sind. Ein Datenbestand muss je nach Anwendungsfall unter mehreren Gesichtspunkten betrachtet werden: Auffindbarkeit und Katalogisierung, Datenformate und technische Lesbarkeit, Qualität und Vollständigkeit, Metadaten, Aktualität, Zugriffswege und Schnittstellen, Identitäten und Berechtigungen sowie Datenlokalität und regulatorische Anforderungen. [QV: Data Intelligence & Governance — Metadaten, Katalogisierung und Datenqualität als eigene Disziplin]

Diese Ebene lässt sich als AI-ready Data beschreiben.

Ein PDF auf einem Fileserver kann für einen Mitarbeiter problemlos nutzbar sein. Für eine Retrieval-Pipeline muss zusätzlich geklärt werden, wie das Dokument gefunden, gelesen, verarbeitet und aktualisiert wird und wie es mit seinen Metadaten und Berechtigungen verbunden bleibt. Ein gescanntes Dokument ohne Texterkennung etwa ist für einen Menschen lesbar und für eine Pipeline zunächst wertlos.

Die Vorbereitung der Daten ist deshalb ein eigener Bestandteil der KI-Architektur und darf nicht mit der Modell-Inferenz gleichgesetzt werden. Wir beobachten in Projekten regelmäßig, dass der Aufwand für diese Stufe unterschätzt wird, weil sie in Produktdarstellungen selten sichtbar ist.

Eine gemeinsame Datenplattform ist eine Option, keine Voraussetzung

Eine mögliche Architektur besteht darin, relevante Daten aus unterschiedlichen Quellen in einer gemeinsamen Datenplattform zusammenzuführen. Hier kommt der Begriff AI Data Lake ins Spiel.

Data Lakes können große Mengen strukturierter und unstrukturierter Daten aufnehmen und unterschiedlichen Verbrauchern zur Verfügung stellen. Moderne Architekturen ergänzen den eigentlichen Speicher um Katalogisierung, Governance, Verarbeitung und kontrollierte Zugriffsmechanismen. AWS beschreibt entsprechende Lakehouse-Architekturen auch als Grundlage für Analytics-, Machine-Learning- und generative KI-Workloads. [QV: Object Storage als Datenplattform — Objektspeicher als Basis gemeinsamer Datenplattformen] [QV: S3-Zugriffsschicht — S3 als Zugriffsprotokoll auf Objektspeicher]

Für die Gesamtarchitektur ist jedoch eine Abgrenzung notwendig. Ein AI Data Lake ist eine mögliche Datenplattform für KI-Workloads, nicht die Voraussetzung dafür, dass ein Unternehmen RAG oder andere KI-Anwendungen einsetzen kann. Eine Anwendung kann Daten ebenso über Konnektoren, föderierte Zugriffe oder Schnittstellen aus bestehenden Systemen beziehen.

Der AI Data Lake beantwortet damit primär die Frage, wie eine gemeinsame und skalierbare Datenbasis bereitgestellt werden kann. Er ist nicht mit RAG, einem Retrieval-Index oder einem LLM gleichzusetzen.

Embeddings machen Bedeutung rechenbar

Wer den Retrieval-Weg bewerten will, muss einen Begriff kennen, der in Produktdarstellungen meist vorausgesetzt wird.

Ein Embedding ist die Darstellung eines Textabschnitts als Zahlenfolge, also als Vektor. Erzeugt wird sie von einem eigenen Modell, dem Embedding-Modell, das nicht mit dem antwortenden Sprachmodell identisch ist. Die Zahlenfolge ist so beschaffen, dass inhaltlich ähnliche Texte ähnliche Vektoren erhalten. Bedeutung wird damit zu einer geometrischen Größe: Ähnlichkeit wird zu Nähe im Vektorraum und ist damit berechenbar.

Der praktische Nutzen liegt darin, dass eine Suche nicht mehr auf Wortübereinstimmung angewiesen ist. Eine Frage nach den Regeln für Dienstreisen kann einen Abschnitt finden, der durchgängig von Auswärtstätigkeit spricht, obwohl kein gemeinsames Suchwort vorkommt.

Die Grenze desselben Verfahrens ist ebenso wichtig. Ähnlichkeit ist nicht Richtigkeit, und sie ist nicht Berechtigung. Ein Abschnitt kann einer Frage semantisch sehr nahe stehen, inhaltlich veraltet sein oder aus einem Bestand stammen, den der Fragende nicht einsehen darf. Beide Punkte werden in den folgenden Kapiteln aufgegriffen.

Aus dem Verfahren folgt außerdem eine betriebliche Konsequenz: Frage und Bestand müssen mit demselben Embedding-Modell verarbeitet worden sein. Ein Wechsel des Modells oder eine Änderung der Zerlegung erfordert, den gesamten Bestand neu zu verarbeiten.

Retrieval beginnt mit der Aufbereitung, nicht mit der Abfrage

Soll ein LLM Informationen aus umfangreichen Unternehmensbeständen verwenden, ist Retrieval-Augmented Generation eine mögliche Architektur. Dabei sind zwei Datenpfade zu unterscheiden, die zeitlich weit auseinanderliegen: die Aufbereitung und Indexierung auf der einen Seite, die Abfrage und das Retrieval auf der anderen.

Der erste Pfad bereitet die Informationen vor und läuft unabhängig von jeder Benutzeranfrage. Aus einer Datenquelle werden Inhalte übernommen, geparst und extrahiert, in Einheiten zerlegt, mit Metadaten versehen, in Vektorrepräsentationen überführt und in einem Retrieval-Index abgelegt. Gao et al. beschreiben dieses Grundgerüst in drei Schritten: Beim Indexing werden Dokumente in Chunks zerlegt, in Vektoren kodiert und abgelegt; beim Retrieval werden die relevantesten Chunks nach semantischer Ähnlichkeit ermittelt; bei der Generation gehen ursprüngliche Frage und abgerufene Inhalte gemeinsam in das Modell. [QV: NAS-Migration — Erschließung gewachsener Dateibestände als Vorbedingung]

[BILD 3: Die beiden RAG-Datenpfade nebeneinander — Aufbereitung und Indexierung gegenüber Abfrage und Retrieval]

Die häufig anzutreffende Gleichsetzung von RAG mit einer Vektordatenbank ist dennoch zu eng. Vektorsuche ist eine wichtige Retrieval-Methode, aber nicht die einzige, und sie hat charakteristische Schwächen bei exakten Bezeichnern wie Artikelnummern, Normbezeichnungen oder Eigennamen. Moderne Retrieval-Systeme kombinieren deshalb Volltext- und Vektorsuche. Microsoft dokumentiert für Azure AI Search ein solches Hybrid-Search-Verfahren, bei dem Text- und Vektorabfragen parallel ausgeführt werden: BM25 für den Textanteil, HNSW oder erschöpfendes k-Nearest-Neighbor für den Vektoranteil, zusammengeführt über Reciprocal Rank Fusion.

Technologisch neutraler ist deshalb der Begriff Retrieval-Index beziehungsweise Retrieval-Schicht. Ebenso wichtig: Der Retrieval-Index ist nicht automatisch der primäre Unternehmensdatenbestand. Originaldaten können weiterhin auf File Storage, Objektspeicher, in einem Data Lake oder in anderen Quellsystemen liegen. Der Index ist eine abgeleitete, zusätzlich zu betreibende und zusätzlich zu schützende Kopie.

RAG ersetzt das Neutraining, nicht die Aktualisierung

Nach der Indexierung beginnt der zweite Datenpfad. Eine Benutzerfrage wird verarbeitet, das Retrieval-System sucht passende Informationen, die ausgewählten Inhalte werden zusammen mit der Anfrage zu einem Kontext zusammengestellt und dem Modell übergeben, das daraus eine Antwort erzeugt.

Das Modell wird also nicht bei jeder Änderung eines Unternehmensdokuments neu trainiert. Dieses Zusammenspiel von Retrieval und Generierung ist das grundlegende Prinzip von RAG.

Der Abruf erfolgt zur Abfragezeit — die Indexierung nicht. Sie läuft periodisch oder ereignisgesteuert, in keinem Fall ununterbrochen. Zwischen einer Änderung an der Quelle und ihrer Wirksamkeit im Index liegt deshalb immer eine Latenz. Ereignisgesteuerte Pipelines verkürzen sie, beseitigen sie aber nicht.

Diese Lücke hat drei Ausprägungen von sehr unterschiedlicher Tragweite. Geänderte Inhalte sind erst nach dem nächsten Durchlauf wirksam; das ist meist tolerierbar. Gelöschte Quelldokumente dagegen verschwinden nicht von selbst aus dem Index — eine Pipeline, die nur inkrementell hinzufügt, trägt den Inhalt unbegrenzt weiter. Und entzogene Berechtigungen wirken erst, wenn der Index nachgeführt wurde; bis dahin arbeitet das Retrieval mit dem alten Rechtestand.

Aktualität der Primärdaten und Aktualität des Retrieval-Index sind daher zwei unterschiedliche Größen. Die Frage, wie schnell eine Löschung oder ein Rechteentzug im Index ankommt, gehört zu den Architekturentscheidungen und nicht in den Betrieb nachgelagert.

Ein Retrieval-System muss Berechtigungen kennen, nicht nur Relevanz

Bei Unternehmensdaten reicht es nicht aus, die fachlich relevantesten Informationen zu finden. Ein Retrieval-System muss auch berücksichtigen, welche Informationen der jeweilige Benutzer verwenden darf.

Angenommen, ein Unternehmen indexiert technische Dokumentationen, Personalunterlagen und vertrauliche Projektinformationen in einer gemeinsamen Retrieval-Infrastruktur. Eine semantische Suche bewertet Inhalte nach Ähnlichkeit und könnte Treffer aus allen drei Beständen als fachlich relevant einstufen. Das bedeutet nicht, dass sie dem Benutzer als Modellkontext bereitgestellt werden dürfen.

Der Datenpfad muss deshalb um eine Autorisierungsebene ergänzt werden: Die Identität des Anfragenden bestimmt, welche Retrieval-Ergebnisse überhaupt zulässig sind, und erst diese zulässige Teilmenge gelangt in den Kontext des Modells.

[BILD 4: Autorisierungsebene als Overlay über dem Abfragepfad — Identität, zulässige Ergebnismenge, Kontext]

Eine nachgelagerte Filterung der Modellantwort genügt dafür nicht. Was einmal im Kontextfenster steht, ist in die Antwort eingegangen, und ein Modell lässt sich nicht zuverlässig anweisen, vorhandene Information zu ignorieren. Die Durchsetzung muss vor der Kontextzusammenstellung erfolgen.

Technische Plattformen implementieren hierfür dokumentbezogene Zugriffskontrollen. Microsoft beschreibt Document-Level Access Control ausdrücklich als Voraussetzung für agentischesGrounding, RAG-Anwendungen und Enterprise Search und sieht die Durchsetzung feingranularer Rechte von der Ingestion bis zur Ausführung der Abfrage vor. In derselben Architektur lassen sich Sensitivitätskennzeichnungen aus Microsoft Purview aufnehmen und durchsetzen; zur Abfragezeit werden Kennzeichnung des Dokuments, Token des Benutzers und Organisationsrichtlinie gemeinsam ausgewertet. [QV: Data Intelligence & Governance — Berechtigungsmodelle und Datenklassifizierung]

Berechtigungen sind deshalb kein nachgelagerter Zusatz einer RAG-Architektur. Sie gehören zur Daten- und Retrieval-Architektur selbst.

Hinzu kommen weitere Sicherheitsrisiken. Die NIST-Taxonomie zur adversarialen maschinellen Lernsicherheit führt für generative KI unter anderem Supply-Chain-Angriffe, direkte und indirekte Prompt Injection, Misuse Violations sowie die Sicherheit von KI-Agenten als eigene Kategorien. Bei indirekter Prompt Injection gelangen manipulierte Anweisungen über Inhalte in das System, die später abgerufen werden. Der Grund, warum das funktioniert, liegt im Verfahren selbst: Für das Modell sind Anweisung und abgerufener Inhalt beide nur Text im selben Kontextfenster. Eine RAG-Architektur öffnet damit genau den Pfad, über den ein solcher Angriff hereinkommt. [QV: Cyber Resilience — Integrität von Datenbeständen als Schutzziel]

Eine vertrauenswürdige Datenquelle allein garantiert daher noch keine vertrauenswürdige Modellantwort.

Nicht jede Information gehört in einen Index

Damit sind wir bei den Wegen, die zu Beginn neben dem Index standen. Nicht jede Unternehmensinformation muss zunächst in einen Retrieval-Index überführt werden. Eine KI-Anwendung kann auch direkt mit vorhandenen Anwendungen, Datenbanken oder Diensten kommunizieren, sofern geeignete Schnittstellen und Berechtigungen vorhanden sind.

Drei Fragen aus demselben fachlichen Umfeld verdeutlichen den Unterschied. Die Frage nach den geltenden Regeln für Dienstreisen zielt auf einen Text, der sich selten ändert und für viele Benutzer gleich lautet — sie lässt sich aus einer Dokumentensammlung per RAG beantworten. Die Frage nach dem aktuell verfügbaren Reisebudget zielt auf einen Wert, der sich täglich ändert und für jeden Benutzer verschieden ist; ihn zu indexieren wäre sinnlos, er wird direkt aus dem ERP- oder Reisekostensystem abgefragt. Und die Anweisung, ein freigegebenes Hotel zu buchen, ist überhaupt keine Informationsfrage, sondern verlangt die Ausführung einer definierten Funktion in einem operativen System.

Als Faustregel gilt: Beständiges Wissen in vielen Dokumenten spricht für einen Index, veränderliche Einzelwerte und Aktionen sprechen für einen direkten Zugriff.

Damit kommen APIs und zunehmend standardisierte Integrationsmechanismen wie das Model Context Protocol ins Spiel.

RAG und MCP sind keine Alternativen

RAG und MCP werden häufig als konkurrierende Ansätze dargestellt. Das ist irreführend, weil beide auf unterschiedlichen Architekturebenen liegen. RAG beschreibt ein Verfahren, MCP beschreibt eine Schnittstelle.

RAG bezeichnet den Ansatz, externe Informationen abzurufen und als Kontext für die Generierung zu verwenden. MCP standardisiert dagegen die Verbindung zwischen KI-Anwendungen und externen Daten beziehungsweise Fähigkeiten. Der praktische Zweck ist Aufwandsreduktion: Ohne einen solchen Standard benötigt jede Kombination aus KI-Anwendung und Zielsystem eine eigene Anbindung. Die Spezifikation stellt auf Serverseite drei Bausteine bereit — Tools als aufrufbare Funktionen, Resources als lesbare Inhalte und Prompts als vorgegebene Vorlagen.

Die einfache Gleichung, RAG stehe für statische und MCP für aktuelle Daten, ist daher nicht korrekt. Beide Konzepte können sich ergänzen. Ein MCP-Server kann eine definierte Funktion bereitstellen, mit der eine KI-Anwendung einen aktuellen Datensatz abfragt; ein anderes Tool kann eine Aktion in einem Geschäftssystem auslösen. Welche Funktionen tatsächlich verfügbar sind, bestimmen die angebundenen Systeme, die Implementierung des Servers und die Autorisierung.

Gerade die Autorisierung entwickelt sich im Standard weiter. Die Spezifikationsfassung vom 28. Juli 2026 enthält mehrere Härtungen, darunter die Pflicht für Clients, den Issuer-Parameter nach RFC 9207 zu validieren; damit wird eine Angriffsklasse adressiert, die im typischen Muster eines Clients mit vielen Servern besonders relevant ist. Für Unternehmensumgebungen existiert daneben die Erweiterung Enterprise-Managed Authorization, die seit Juni 2026 als stabil gilt. Sie führt den Identity Provider der Organisation als autoritative Entscheidungsinstanz ein: Der Client fordert dort ein Identity Assertion JWT Authorization Grant an und tauscht dieses gegen ein Zugriffstoken des jeweiligen MCP-Servers. Praktisch bedeutet das, dass Zugriffe auf angebundene Systeme zentral über die bestehende Identitätsinfrastruktur vergeben und entzogen werden können, statt pro Benutzer und pro Server einzeln.

Für die Architekturbetrachtung ist weniger das technische Detail entscheidend als die Einordnung: Die Anbindung externer Systeme wird gegenwärtig standardisiert, und die Autorisierung ist dabei der Teil, der sich am schnellsten bewegt.

Ein Agent weiß nicht mehr, er kann mehr kombinieren

Bis zu diesem Punkt besitzt eine KI-Anwendung einen festgelegten Ablauf: Eine Frage wird gestellt, eine Suche ausgeführt, Kontext zusammengestellt und eine Antwort erzeugt. Der Weg ist bei jeder Anfrage derselbe.

Agentische Systeme geben diese Festlegung auf. Das Modell entscheidet abhängig von der Aufgabe, welche Informationsquellen oder Werkzeuge es heranzieht und in welcher Reihenfolge, und kann das Ergebnis eines Schritts zur Grundlage des nächsten machen.

Ein Auftrag könnte lauten, anhand der Reiserichtlinie zu prüfen, ob für eine Konferenz ein Hotel bis zweihundert Euro gebucht werden darf, anschließend verfügbare Hotels zu ermitteln und nach Freigabe die Buchung auszuführen. Dafür spielen mehrere Funktionen zusammen: Das Retrieval-System liefert die relevante Richtlinie, ein angebundenes System liefert aktuelle Hotelinformationen, das Modell verarbeitet beides, und ein freigegebenes Tool führt die definierte Aktion aus.

Der Agent besitzt damit nicht mehr Unternehmenswissen als ein RAG-System. Er verfügt über die Möglichkeit, unterschiedliche Daten- und Funktionszugriffe innerhalb eines Arbeitsablaufs zu orchestrieren.

Genau darin liegt die veränderte Risikolage. Bei einer reinen Auskunftsanwendung führt ein manipulierter oder fehlerhafter Kontext zu einer falschen Antwort. Bei einem Agenten führt derselbe manipulierte Kontext zu einer ausgeführten Aktion in einem operativen System. Welche Aktionen ein Agent ausführen darf, ist deshalb eine Architekturentscheidung, keine

Keine einzelne Komponente erfüllt alle Anforderungen

Es gibt keine einzelne KI-Datenbank und keine einzelne KI-Infrastruktur, die sämtliche Anforderungen gleichermaßen erfüllt. Die folgende Zuordnung ordnet typische Anforderungen den jeweils zuständigen Architekturkomponenten zu.

Anforderung

Mögliche Architekturkomponente

Große Mengen Primärdaten speichern

File Storage, Object Storage, Data Lake

Daten aus verschiedenen Quellen zusammenführen

Ingestion- und Data-Pipeline, Data Lake oder Lakehouse

Daten auffindbar und verwaltbar machen

Metadaten, Katalog, Governance

Dokumentenwissen für ein LLM erschließen

RAG

Semantisch ähnliche Inhalte suchen

Embeddings und Vektorsuche

Keyword- und semantische Suche kombinieren

Hybrid Retrieval

Aktuelle Daten aus Anwendungen abrufen

API, Datenbankzugriff oder Tool

Standardisierte Integration externer Fähigkeiten

MCP

Aktionen in Anwendungen ausführen

autorisierte APIs und Tools

Mehrstufige Aufgaben koordinieren

Agent und Orchestrierung

Verhalten und Antwortformate prägen

Feintuning

Sprache verstehen und Antworten generieren

LLM

Diese Zuordnung ist bewusst keine Produktempfehlung. In realen Architekturen können mehrere Funktionen innerhalb einer Plattform zusammengefasst oder auf unterschiedliche Systeme verteilt werden.

Die Zeile zum Modell selbst bleibt dabei die knappste, weil die Modellschicht in dieser Betrachtung als gegeben vorausgesetzt wird.

[QV: Was ist ein Large Language Model (LLM) und wie funktioniert es?]

Der AI Data Lake steht nicht zwangsläufig in der Mitte

Die Gesamtbetrachtung zeigt, warum ein AI Data Lake nicht pauschal als zentrales Repository dargestellt werden sollte, in das zunächst sämtliche Unternehmensdaten kopiert werden.

Drei Varianten sind gleichermaßen tragfähig. In der ersten führen bestehende Datenquellen über eine gezielte Ingestion und Verarbeitung in eine Retrieval-Schicht und von dort in das Modell; eine gemeinsame Plattform entsteht dabei nicht. In der zweiten führen die Datenquellen zunächst in eine gemeinsame Datenplattform, die anschließend RAG, Analytics, Machine Learning und weitere Workloads gleichermaßen bedient. In der dritten verbleiben Informationen vollständig in operativen Systemen und werden ausschließlich über Schnittstellen abgefragt.

Welche Variante angemessen ist, hängt vom Datenbestand und vom Workload ab, nicht von der eingesetzten Modellfamilie.

"AI Storage" ist keine Leistungsklasse

Mit zunehmender Betrachtung der KI-Anwendung wird deutlich, dass der Begriff AI Storage keine einzelne Performance-Klasse bezeichnet. Die Anforderungen unterscheiden sich erheblich danach, welcher Datenpfad betrachtet wird.

Die Primärdaten einer RAG-Anwendung können große Mengen Office-Dokumente und PDFs umfassen. Eine Ingestion-Pipeline liest diese Bestände in großem Umfang sequenziell und erzeugt damit andere Zugriffsmuster als das spätere Retrieval, bei dem viele kleine Zugriffe mit niedriger Latenz gefragt sind. Training und Fine-Tuning erzeugen wiederum andere Anforderungen als die reine Inferenz.

Maßgeblich sind unter anderem Datenvolumen, Datei- und Objektgrößen, Parallelität, Latenz- und Durchsatzanforderungen, Zugriffsprotokolle, Datenlokalität, die Anzahl beteiligter Verarbeitungssysteme, die Menge zu bewegender Daten sowie Schutz- und Governance-Anforderungen.

Die Storage-Architektur sollte deshalb aus dem tatsächlichen Datenpfad des Workloads abgeleitet werden und nicht aus dem Begriff KI. Die Bewertung einzelner Speicherklassen, Protokolle und Plattformen ist Gegenstand eigener Beiträge. [QV: Hochperformanter Datenzugriff — Datenpfade für KI-Workloads im Detail] [QV: Hybrid Cloud Storage — Datenlokalität und Pfadplanung] [QV: Enterprise Storage Grundlagen — Einordnung der Speicherklassen]

Die Kette entsteht aus dem Anwendungsfall

Vereinfacht lässt sich die Entwicklung von Unternehmensdaten zu einer produktiven KI-Anwendung als Kette darstellen: von den Unternehmensdaten über AI-ready Data und eine Datenbereitstellung, die optional in einer gemeinsamen Plattform gebündelt wird, weiter über Ingestion und Processing zur Retrieval-Schicht, von dort zum Modell und zur eigentlichen KI-Anwendung, die schließlich über APIs, MCP und Tools mit operativen Systemen verbunden wird und agentische Abläufe ermöglicht.

[BILD 5: Gesamtarchitektur als Kette von den Unternehmensdaten bis zu agentischen Workflows, mit Querschnittsfunktionen als durchlaufende Ebene]

Über diese gesamte Kette hinweg wirken Querschnittsfunktionen: Identität, Autorisierung, Governance, Sicherheit, Monitoring und die zugrunde liegende Dateninfrastruktur.

Nicht jede KI-Anwendung benötigt jede dieser Stufen. Ein internes RAG-System über eine gepflegte Dokumentensammlung kommt mit wesentlich weniger Komponenten aus als ein Agent, der auf mehrere Unternehmenssysteme zugreift und dort Aktionen ausführt. Genau deshalb sollte die Architektur vom Anwendungsfall ausgehen und nicht von einzelnen Technologien.

Fazit

Ein LLM ist nur ein Bestandteil einer Unternehmens-KI. Es setzt Text fort und kann pro Anfrage nur eine begrenzte Menge davon berücksichtigen. Aus diesen beiden Eigenschaften folgt alles Weitere.

Damit das Modell mit Unternehmensinformationen arbeiten kann, müssen Daten zunächst identifiziert, zugänglich gemacht und entsprechend dem Anwendungsfall bereitgestellt werden. RAG kann externe Informationen für das Modell auffindbar machen. Datenplattformen können Daten verschiedener Quellen zusammenführen. APIs und MCP können operative Systeme und Funktionen anbinden. Agentische Systeme können mehrere dieser Fähigkeiten orchestrieren. Mit jeder zusätzlichen Stufe steigen jedoch die Anforderungen an Berechtigungen, Governance, Datenaktualität und Sicherheit.

Die zentrale Architekturfrage lautet deshalb nicht, welches Modell oder welcher Speicher der richtige für KI ist. Sie lautet, welche Daten die Anwendung benötigt, wo diese Daten liegen, wie die richtigen Informationen kontrolliert zum Modell gelangen und welche Systeme die KI anschließend verwenden darf.

Erst wenn dieser Datenpfad geklärt ist, lassen sich Storage, Datenplattform, Retrieval, Modell und Integration sinnvoll dimensionieren und zu einer konsistenten KI-Infrastruktur verbinden.

Quellen

Lewis, Patrick et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems 33 (2020), S. 9459–9474. Preprint: arXiv:2005.11401. Herangezogen für das ursprüngliche RAG-Konzept sowie die Begründung des hybriden Ansatzes über Revidierbarkeit und Nachvollziehbarkeit des herangezogenen Wissens.

Gao, Yunfan et al. — Retrieval-Augmented Generation for Large Language Models: A Survey. arXiv:2312.10997. Herangezogen für das dreistufige RAG-Grundgerüst aus Indexing, Retrieval und Generation. Der Beitrag ist ein vielzitierter Preprint und nicht begutachtet; er wird hier als Überblicksdarstellung eines etablierten Verfahrens verwendet, nicht als normative Quelle.

Microsoft — Hybrid search in Azure AI Search sowie Hybrid search scoring (RRF), Microsoft Learn. Herangezogen für die parallele Ausführung von Text- und Vektorabfragen, die verwendeten Ranking-Verfahren BM25, HNSW und erschöpfendes k-Nearest-Neighbor sowie die Zusammenführung über Reciprocal Rank Fusion.

Microsoft — Document-level access control in Azure AI Search, Microsoft Learn. Herangezogen für die Durchsetzung dokumentbezogener Berechtigungen von der Ingestion bis zur Ausführung der Abfrage sowie für die Auswertung von Purview-Sensitivitätskennzeichnungen zur Abfragezeit. Herstellerdokumentation; die beschriebenen Mechanismen sind produktspezifisch, das Architekturprinzip ist es nicht.

National Institute of Standards and Technology — Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, NIST AI 100-2e2025, März 2025. Herangezogen für die Einordnung indirekter Prompt Injection sowie der weiteren Angriffskategorien gegen generative KI und KI-Agenten.

National Institute of Standards and Technology — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1. Herangezogen für die übergeordnete Risikorahmung generativer KI-Systeme.

Amazon Web Services — Dokumentation zur Lakehouse-Architektur, docs.aws.amazon.com und aws.amazon.com. Herangezogen für die Beschreibung des vereinheitlichten Zugriffs über Data Lakes, Data Warehouses sowie Drittanbieter- und föderierte Quellen und für die Abfrage von Daten an Ort und Stelle. Herstellerdokumentation.

Model Context Protocol — Spezifikation in der Fassung 2026-07-28 sowie Erweiterung Enterprise-Managed Authorization, modelcontextprotocol.io. Herangezogen für die serverseitigen Bausteine Tools, Resources und Prompts, für die Autorisierungshärtung einschließlich der Issuer-Validierung nach RFC 9207 und für den delegierten Autorisierungsablauf über den Identity Provider der Organisation. Die Erweiterung gilt seit Juni 2026 als stabil und ist nicht Bestandteil der Kernspezifikation.

Weiterführende Artikel:

Edge File Services

Was ist ein Global File System?

Cyber Resilience

Welche Entscheidung steht bei Ihnen an?

Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.

Gespräch vereinbaren

Spezialist für moderne Dateninfrastruktur

ASSISTRA

Unternehmen
Services
Kontakt

WISSEN

Themen & Suche

LÖSUNGEN

Global File System
Enterprise Storage
Object Storage

KI Infrastruktur

Cloud