AI Architecture · 10 Min.
KI-Agenten Datenarchitektur: Welche Daten ein Agent wirklich braucht
Ein Agent braucht nicht mehr Daten. Er braucht die richtigen Daten, im richtigen Format, mit den richtigen Rechten und klarer Herkunft.
SYSTEMS Grafik zu KI Agenten Datenarchitektur: Data -> Agent -> Outcome. Fokus: Welche Datenarchitektur brauchen KI-Agenten, um im Unternehmen verlässlich zu arbeiten?
Kurzfassung
KI-Agenten brauchen kuratierten Kontext, keine ungefilterte Datenflut. Datenquellen müssen Herkunft, Aktualität, Rechte und Zweck sichtbar machen. RAG, Memory und Tool-Zugriff sind unterschiedliche Schichten und sollten nicht vermischt werden.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknüpfe es mit den nächsten Architekturentscheidungen.
Warum Datenarchitektur wichtiger ist als Prompting Ein guter Prompt kann schlechte Daten nicht retten. Wenn Dokumente veraltet sind, CRM-Felder fehlen oder Wissensquellen widersprüchlich sind, erzeugt der Agent plausible Unsicherheit.
Produktive Agenten brauchen deshalb eine Datenarchitektur: Welche Quellen gelten, wann werden sie genutzt, wer darf sie sehen und wie wird Aktualität geprüft?
Stand Mai 2026: Agenten brauchen eine Kontextarchitektur Moderne Agentenplattformen trennen immer stärker zwischen Runtime, Sessions, Memory, Tools, Retrieval, Tracing und Evaluation. Google Vertex AI Agent Engine nennt Sessions und Memory Bank als eigene Bausteine; OpenAI trennt File Search, Tools und Agentenlauf; MCP trennt Resources, Tools und Prompts.
Das ist die richtige Richtung: Ein Agent braucht keine Datenhalde, sondern eine Kontextarchitektur.
Die Architektur muss beantworten:
Google beschreibt für agentische Architektur explizit Auswahlentscheidungen rund um Runtime, Memory, Observability , Security, MCP und A2A . Das zeigt: Datenarchitektur endet nicht beim Vector Store. Sie entscheidet, wie Agenten mit State, Protokollen, Security und Betrieb verbunden werden.
Welche Daten sind dauerhaftes Wissen? Welche Daten sind Live-Systemzustand? Welche Daten sind Nutzer- oder Kundenmemory? Welche Daten dürfen nur gelesen, aber nie geschrieben werden? Welche Daten dürfen in Logs, Traces oder Evals landen? Kontext ist nicht gleich Daten Daten sind Rohmaterial. Kontext ist die Auswahl, die für eine Entscheidung relevant ist. Ein Agent braucht nicht alle Daten, sondern die richtige Sicht auf den aktuellen Job.
Zu viel Kontext kann die Qualität sogar senken. Der Agent findet dann mehr Text, aber weniger Wahrheit.
Die vier Datenarten Jede Art braucht eigene Regeln für Aktualität, Rechte und Nutzung.
Stammdaten: Kunden, Firmen, Projekte, Rollen, Produkte. Prozessdaten: Status, Aufgaben, Tickets, Pipeline-Stufen. Wissensdaten: Dokumente, Playbooks, FAQs, Richtlinien. Laufdaten: Agentenlogs, Korrekturen, Evals, Feedback. RAG ist kein Memory RAG holt relevante Informationen aus Wissensquellen. Memory speichert Learnings oder Präferenzen für spätere Läufe. Tool-Zugriff ruft aktuelle Systemdaten ab.
Wenn diese Schichten vermischt werden, wird der Agent schwer kontrollierbar. Ein gutes System trennt: Was ist dokumentiertes Wissen, was ist Nutzerpräferenz, was ist Live-Systemzustand?
Ein einfaches Modell:
Wer Memory als RAG missbraucht, speichert zu viel. Wer RAG als Live-Datenquelle nutzt, arbeitet mit veralteten Informationen.
RAG für dokumentiertes Wissen wie Playbooks, Richtlinien, FAQs und technische Doku. Memory für stabile Präferenzen, wiederkehrende Fakten und Verlauf zwischen Sessions. Tools für aktuelle Daten wie CRM-Status, Kalender, Tickets oder Bestellungen. State für temporäre Daten innerhalb eines laufenden Agentenlaufs. Die RAG-Pipeline muss sichtbar sein RAG ist nicht "wir laden Dokumente hoch". Eine produktive Pipeline hat klare Schritte:
OpenAI beschreibt Vector Stores als Primitive, bei dem Dateien gechunkt, eingebettet und indexiert werden. Google beschreibt für RAG ebenfalls Ingestion, Parsing, Chunking und Retrieval als Architekturfluss. Genau diese Pipeline muss ein Unternehmen besitzen, nicht nur ein Tool.
Ingestion: Welche Dokumente kommen hinein? Parsing: Wie werden PDFs, Webseiten, Tabellen oder Mails zerlegt? Chunking: Wie gross sind die Einheiten und welche Metadaten tragen sie? Embedding und Index: Wie werden Inhalte auffindbar? Retrieval: Welche Treffer kommen in den Kontext? Reranking oder Filter: Was wird verworfen? Citation und Source: Welche Quelle stützt die Antwort? Kontextbudget ist eine Architekturgrenze Tool-Definitionen, Tool-Ergebnisse, Dokumentauszuege und Chat-History verbrauchen Kontext. Anthropic beschreibt dafür praktische Gegenmittel: Tool Search, Programmatic Tool Calling, Prompt Caching und Context Editing. Das ist nicht nur Kostenoptimierung. Es ist Qualitätskontrolle.
Ein Agent sollte nicht alle Tools und alle Dokumente immer sehen. Er sollte das sehen, was für den aktuellen Schritt relevant ist.
OpenAI unterscheidet zudem zwischen OpenAI-maintained Connectors und eigenen Remote-MCP-Servern. Für Datenarchitektur ist das wichtig: Ein Connector ist nicht dasselbe wie eine selbst kontrollierte Tool- und Datenzugriffsschicht.
Permissions gehören in die Datenarchitektur Ein Agent sollte nie Daten sehen, nur weil sie technisch erreichbar sind. Er braucht denselben oder strengeren Zugriff wie der Mensch, für den er arbeitet.
Das gilt besonders in Multi-Kunden-, Admin- oder Investor-Umgebungen. Datenleckage zwischen Rollen ist ein Architekturfehler, kein Promptproblem.
Jede Datenquelle braucht deshalb einen Datenvertrag:
Zweck: Wofür darf die Quelle genutzt werden? Owner: Wer ist für Qualität verantwortlich? Frische: Wie aktuell muss sie sein? Scope: Für welche Rolle, welchen Kunden, welchen Workflow? Herkunft: Aus welchem System kommt sie? Retention: Wie lange darf sie in Logs, Memory oder Traces bleiben? Fallback: Was passiert, wenn die Quelle fehlt oder widerspricht? Datenqualität messen Gute Datenarchitektur hat Metriken: Abdeckung, Aktualität, Dubletten, Quellenkonflikte, fehlende Felder und Korrekturrate.
Wenn Agenten Fehler machen, sollte sichtbar werden, ob das Modell falsch lag oder die Datenbasis schlecht war.
Evals brauchen eigene Daten Produktive Agenten brauchen nicht nur Arbeitsdaten, sondern Testdaten. Gute Evals enthalten echte Grenzfälle: veraltete CRM-Felder, widersprüchliche Dokumente, fehlende Berechtigungen, leere Suchergebnisse, doppelte Kundendatensätze und manipulierte externe Inhalte.
Ohne Eval-Daten wird jede Datenarchitektur erst im Live-Betrieb getestet. Das ist zu spät.
Der SYSTEMS-Blick KI-Agenten brauchen keine endlose Wissensdatenbank. Sie brauchen eine klare Kontextmaschine.
Wer Datenquellen, Rechte, RAG, Memory und Live-Tools sauber trennt, baut Agenten, die weniger raten und mehr arbeiten.
