Data-Native KI-Agenten: Warum Agenten zu Ihren Daten kommen müssen

Die meisten Enterprise-AI-Pilotprojekte nehmen dieselbe niedrige Hürde: Ein LLM wird mit Ihren Daten verknüpft, eine Vektordatenbank hinzugefügt und das Ganze der Führungsebene präsentiert. Der schwierige Teil folgt erst später. Die Sicherheitsabteilung bemängelt Governance-Lücken. Latenzzeiten bei mehrstufigen Agenten beeinträchtigen das Nutzererlebnis erheblich. Die Rechnung des Modellanbieters steigt immer weiter. Diese Probleme lassen sich meist auf eine einzige Entscheidung zurückführen: Daten aus kontrollierten Systemen zu extrahieren und in einen AI-Stack zu übertragen, der nie dafür ausgelegt war, Ihre Richtlinien durchzusetzen.

Dieser Beitrag plädiert für eine andere architektonische Richtung: Bringen Sie Modelle und Agenten zu den Daten, nicht umgekehrt. Anstatt eine parallele AI-Infrastruktur aufzubauen und diese mühsam mit Ihrem Lakehouse zu verbinden, behandeln Sie Agenten als native Workloads, die innerhalb Ihrer Datenplattform ausgeführt werden – unter denselben Governance-, Sicherheits- und Observability-Kontrollen, denen Sie bereits bei Ihren Daten vertrauen.

Das Lakehouse bietet Ihnen einen zentralen Ort für die Governance Ihrer Daten. Die nächste Frage ist, ob Ihre Agenten innerhalb oder außerhalb dieser Grenzen agieren. Es zeichnen sich zwei Paradigmen ab.

Externe Agenten

Agenten und LLMs laufen in einem separaten AI-Stack. Daten werden über das Netzwerk in externe Vektordatenbanken, SaaS-LLMs oder maßgeschneiderte Serving-Layer exportiert oder abgefragt. Governance, Sicherheit und Observability werden für AI nebenbei neu implementiert.

Daten-native Agenten

Agenten, Modelle, Tools, Retrieval und der Speicher der Agenten laufen auf derselben Plattform wie die Daten selbst, unter einer einheitlichen Governance- und Sicherheitsebene. AI wird zu einem weiteren Workload auf Ihrem bestehenden Daten-Stack.

Die versteckten Kosten externer Agenten

Daten besitzen Schwerkraft. Rechenleistung lässt sich kostengünstig verlagern, Daten hingegen nicht – insbesondere wenn das Volumen wächst und sich die Modalitäten vervielfachen. Das Extrahieren von Daten bringt eine Reihe bekannter Nachteile mit sich:

• Die Governance wird geschwächt. Die Neuimplementierung von Zugriffskontrolle, Lineage und Datenresidenz in jeder Integration führt zu Lücken, die bei Audits auffallen.
• Latenzzeiten summieren sich. Jeder Schritt zu einem externen Vektorspeicher, LLM und zurück summiert sich bei Agenten mit mehreren Tools.
• Kosten zersplittern. Egress-Gebühren, doppelte Speicherung und Token-basierte Preise verschiedener Anbieter belasten das Budget aus drei Richtungen gleichzeitig.
• Das Lifecycle-Management erfordert ständige Abstimmung zwischen Anbietern. Schemata, Indizes und Modelle weichen in Systemen ohne gemeinsame Deployment-Pipeline voneinander ab.
• Die Observability zersplittert. Die lückenlose Verfolgung einer Anfrage bedeutet, Protokolle von drei oder vier verschiedenen Tools mühsam zusammenzufügen.
• Der Geschäftskontext bleibt auf der Strecke. Metrikdefinitionen, das Business-Glossar und Domänengruppierungen befinden sich in Ihrer Governance-Ebene; ein externer Agent muss diese mühsam aus Spaltennamen rekonstruieren oder erraten.

Warum nachträgliche Governance bei Agenten scheitert

Unter all diesen Nachteilen verdient die Governance besondere Aufmerksamkeit, da sie sich nicht nachträglich korrigieren lässt. Die meisten Ansätze zur AI-Governance behandeln sie als Filter, der erst angewendet wird, nachdem der Agent bereits auf die Daten zugegriffen hat – beispielsweise durch das Unkenntlichmachen sensibler Felder in der Antwort, das Blockieren bestimmter Themen auf der Ausgabeebene oder die nachträgliche Überprüfung von Protokollen. Für einfache Q&A-Demos funktioniert das. Es scheitert jedoch in dem Moment, in dem Agenten beginnen, Berechnungen auf den Daten auszuführen.

Stellen Sie sich einen Agenten vor, der eine Finanzübersicht über Zeilen hinweg berechnet, die einer Sicherheit auf Zeilenebene (Row-Level Security) unterliegen. Die Aggregation selbst (die Summe, der Durchschnitt, der Trend) ist ein abgeleiteter Wert, der davon beeinflusst wird, welche Zeilen einbezogen werden. Wenn die Governance nicht vor dem Ausführen der Abfrage erzwungen wird, enthält das Ergebnis bereits Informationen aus Daten, auf die der Benutzer keinen Zugriff haben sollte. Keine nachträgliche Zensur kann diese Berechnung rückgängig machen. Die Richtlinienentscheidung hätte zum Zeitpunkt der Abfrageplanung getroffen werden müssen, nicht erst bei der Darstellung der Antwort.

Dies ist die grundlegende Schwachstelle einer perimeterbasierten oder nachträglichen Governance: Sie setzt voraus, dass Daten sicher zensiert werden können, nachdem sie den Agenten erreicht haben. In der Praxis geht die Governance-Absicht verloren, sobald eine Aggregation oder Transformation stattgefunden hat. Nachträgliche Kontrollen sind von Grund auf unvollständig.

Es gibt noch einen zweiten Nachteil, wenn man hier Fehler macht, und der zeigt sich auf der Rechnung. Das Problem ist nicht nur, worauf der Agent zugreifen darf, obwohl das ein Teil davon ist. Wenn die Governance nachträglich statt an der Quelle geklärt wird, muss der Agent die Abstimmung selbst vornehmen: Audit-Logs durchsuchen, Fragmente über externe Systeme hinweg zusammenführen, denselben Datensatz von verschiedenen Orten abrufen, um zu prüfen, ob er ihn verwenden darf, und jedes Teilergebnis neu bewerten. Nichts davon gehört zu seiner eigentlichen Aufgabe. Der Agent kompensiert lediglich eine kontrollierte Antwort, die ihm nicht von vornherein zur Verfügung gestellt wurde. Blockierte oder zensierte Ausgaben verschlimmern die Situation nur, da der Agent sie als Fehler interpretiert und es erneut versucht. Sitzungen ziehen sich in die Länge, jeder Schritt lädt mehr Kontext in das Modell, und eine einzige Anfrage verwandelt sich unbemerkt in Tausende von abgerechneten Token. Das ist die Token-Verschwendungsschleife, und eine nachträgliche Governance bringt sie erst richtig in Gang.

Daten-native Agenten lösen diese Herausforderungen, indem sie die Durchsetzung von Richtlinien direkt in die Abfrageplanung und -berechnung einbetten. Jedes Zwischenergebnis spiegelt dieselben Governance-Einschränkungen wider. Die Governance muss vor und während der Ausführung bewertet werden – etwas, das man sich als nachträglichen Gedanken nach Abschluss der Berechnung nicht leisten kann. Custom Guardrails im Unity AI Gateway sind die konkrete Umsetzung davon: kombinierbare, deterministische Richtlinien, die das Gateway bei jeder Anfrage und Antwort erzwingt, statt Filter, die das Modell im Nachhinein befolgen soll. Die Entscheidung über Richtlinien zum Zeitpunkt der Planung und auf der Grundlage von Daten, die sich bereits an einem kontrollierten Ort befinden, bedeutet auch, dass der Agent in einem einzigen Durchgang eine saubere Antwort erhält, anstatt Systeme durchsuchen zu müssen, um eine Antwort mühsam zusammenzustellen oder zu rechtfertigen.

Zustand und Speicher von Agenten benötigen Governance

Bislang haben wir uns darauf konzentriert, wie Agenten Daten lesen. Aber produktive Agenten schreiben auch: Konversationsverlauf, Aufgabenfortschritt, Benutzerpräferenzen, zwischengespeicherte Ergebnisse und Tool-Ausgaben für spätere Audits. Je mehr Aufgaben Agenten übernehmen, desto wichtiger wird die Zustandsebene (State Layer) im Vergleich zur Datenebene. Wenn Sie diese außerhalb der Governance-Grenzen belassen, weist jedes Versprechen einer lückenlosen Überprüfbarkeit (End-to-End Auditability) eine Lücke auf.

Der Zustand (State) ist der Kurzzeitspeicher des Agenten: die laufende Konversation, die aktuelle Aufgabe, der gerade gefüllte Cache. Der Speicher (Memory) überdauert die Sitzung: mit welchen Kunden ein Agent zu tun hatte, was ein Benutzer bevorzugt, welche früheren Ausgaben wiederverwendet werden können. Beide benötigen transaktionalen Speicher, und bei beiden geht die Governance verloren, sobald sie die Plattform verlassen. Eine Erinnerung wie „Benutzer X ist ein wertvoller EU-Kunde“ ist selbst ein sensibler Datensatz, der denselben Zugriffs- und Residenzregeln unterliegt wie der Datensatz, den er zusammenfasst. Und es handelt sich um einen transaktionalen Workload: Delta-Tabellen sind für große analytische Scans ausgelegt, aber der Zustand eines Agenten erfordert schnelle Lese- und Schreibvorgänge pro Zeile, Key-Lookups und atomare Updates.

Die übliche Behelfslösung ist ein externes Postgres oder Redis. Damit stehen Sie jedoch wieder vor dem Problem, gegen das dieser Beitrag argumentiert: Der Zustand des Agenten verlässt den kontrollierten Bereich und gelangt in ein System, das Ihre Governance-Ebene nicht einsehen kann, mit eigener Sicherheit und eigenem Lifecycle-Management. Sie haben einen daten-nativen Agenten mit einer unkontrollierten Abhängigkeit erstellt.

Und das Problem vergrößert sich, sobald aus einem Agenten viele werden. Ein Schwarm, der auf ein größeres Ziel hinarbeitet (ein Planer, der an Spezialisten delegiert, ein Supervisor, der deren Ergebnisse abstimmt), benötigt einen gemeinsamen Speicher – und genau bei der Abstimmung dieses Speichers scheitern diese Systeme. Wenn jeder Agent einen privaten Zustand beibehält und den Kontext direkt (Peer-to-Peer) weitergibt, gibt es keine Single Source of Truth. Die Agenten weichen voneinander ab, Schreibvorgänge kollidieren, und jede Übergabe ist ein weiterer unkontrollierter Kanal, der sich mit dem Wachstum des Schwarms vervielfacht. Der Austausch von Speicherinhalten erweist sich als der schwierige Teil.

Lakebase schließt diese Lücken. Es handelt sich um einen vollständig verwalteten PostgreSQL-Speicher innerhalb der Databricks-Plattform, der derselben Governance-Ebene unterliegt wie alles andere. Der Zustand des Agenten wird zu einem kontrollierten Asset: Er erbt die Zugriffskontrollen der Plattform, existiert direkt neben den Daten und Tools des Agenten und erfordert kein separates Infrastrukturteam. Und da jeder Agent in derselben transaktionalen Ebene liest und schreibt, fungiert sie gleichzeitig als Single Source of Truth des Schwarms. Der Zustand bleibt konsistent, atomare Updates verhindern, dass zwei Agenten dieselbe Aufgabe beschädigen, eine Richtlinie für die Ansicht eines Agenten überträgt sich auf das, was er für den nächsten schreibt, und jeder Speicherinhalt lässt sich durch den Schwarm zurückverfolgen: welcher Agent ihn geschrieben hat, welcher ihn gelesen hat und wie eine komplexe Schlussfolgerung zu ihrer Quelle gelangt.

Das Plädoyer für daten-native Agenten

Das Governance-Argument ist das stärkste, aber die Vorteile gehen noch weiter. Wenn Agenten innerhalb des Daten-Stacks ausgeführt werden, summieren sich die Vorteile über alle operativen Dimensionen hinweg: Sicherheit, Qualität, Observability, Deployment, Latenz und Kosten. Tools und Datenabhängigkeiten werden zusammen mit dem Modell konfiguriert und protokolliert, sodass das gesamte System standardmäßig versioniert, überprüfbar und reproduzierbar ist.

Der folgende Vergleich fasst zusammen, wie sich diese beiden Paradigmen in den Dimensionen unterscheiden, die für Produktionssysteme am wichtigsten sind:

Wie datennative Agenten auf Databricks tatsächlich aussehen

Die Data Intelligence Platform setzt dies in die Praxis um. Anstatt einen separaten "AI-Stack" aufzubauen und mit Ihren Daten zu verknüpfen, erstellen Sie AI-Agenten direkt im Daten-Stack selbst. Ein datennativer Agent auf Databricks zeichnet sich dadurch aus, dass er:

• den gesamten Modell- und Agenten-Traffic durch das Unity AI Gateway leitet, wo jede Anfrage vor der Ausführung geprüft und jede Antwort danach inspiziert wird, wobei deterministische ALLOW- / DENY- / ASK-Richtlinien die nachträgliche Best-Effort-Filterung ersetzen. Zugriffskontrolle, Ratenbegrenzung, Payload-Protokollierung und Kostenverfolgung befinden sich alle in derselben Control Plane, einschließlich der Aufrufe von externen LLM-Anbietern und Coding-Agenten.
• jedes AI-Primitiv (Modelle, Agenten, MCPs, Skills und die von ihnen aufgerufenen Tools) als ein Unity Catalog-Asset neben Tabellen und Funktionen behandelt, sodass Identität, Lineage und Zugriffskontrollen einheitlich für die gesamte AI-Oberfläche gelten.
• vollständige Anfragetraces über MLflow 3 erfasst: Jeder LLM-Aufruf, jeder Tool-Aufruf, Scores, Evals, abgerufene Dokumente und die End-to-End-Überwachungsschleife werden für die Compliance auditierbar und für das Debugging beobachtbar.
• Inferenz innerhalb Ihres Databricks-Sicherheitsbereichs auf Model Serving ausführt, ohne unkontrollierte Datenbewegungen zu AI-Stacks von Drittanbietern.
• Kontext aus Delta-basierten Indizes abruft, die Unity Catalog-ACLs berücksichtigen und automatisch die Lineage verfolgen, unterstützt durch AI Search.
• sich über Sitzungen hinweg durch Lakebase-basierten Zustand und Speicher erinnert: Kurzfristiger Konversationskontext, mehrstufiger Aufgabenfortschritt, langfristige Benutzerpräferenzen und der episodische Abruf vergangener Tool-Aufrufe existieren direkt neben den Daten, über die der Agent entscheidet.
• Schlussfolgerungen in einem geschäftlichen Kontext durch Unity Catalog Semantics (Metriken, Business-Glossar, Domänen) und Genie Ontology verankert, einem automatisch gepflegten Wissensgraphen, der aus den Tabellen, Abfragen, Dashboards und Apps extrahiert wird, die das Team bereits verwendet.
• spezialisierte Schlussfolgerungen an andere Agenten delegiert, einschließlich Genie für Fragen zu strukturierten Daten, mit domänenübergreifender, mehrstufiger Koordination innerhalb der Plattformgrenzen.
• dieselbe Governance auf Coding-Agenten über Omnigent ausweitet, ein Meta-Harness, das Claude Code, Codex und Cursor über das Unity AI Gateway mit gemeinsamen Sitzungen und einem gemeinsamen Audit-Trail leitet.

Wo Sie anfangen können

Einige Unternehmen entwickeln bereits auf diese Weise. Ihre Agenten laufen innerhalb derselben Grenzen wie ihre Daten, wobei die Unity Catalog-Richtlinien beide abdecken, der Zustand in Lakebase liegt und der Traffic über das Unity AI Gateway läuft. Keines von ihnen hat dies mit einem einzigen Re-Platforming-Projekt erreicht. Sie haben die Nahtstelle zwischen dem Lakehouse und dem AI-Stack Pilotprojekt für Pilotprojekt geschlossen und dann aufgehört, neue zu öffnen.

Für Teams, die noch am Anfang dieses Weges stehen, ist der Aufwand nicht dramatisch. Die meisten Bausteine existieren bereits auf der Plattformseite: Model Serving, Unity Catalog, Lakebase, MLflow. Was fehlt, ist die Entscheidung, sie als das Zuhause des Agenten zu betrachten und nicht nur als Datenquellen für einen parallelen Stack. Diese Entscheidung ist meist der schwierigste Teil.

Der sinnvollste Ausgangspunkt ist eine Bestandsaufnahme dessen, was bereits außerhalb des Sicherheitsbereichs läuft. Denn genau dort wird der nächste Governance-Vorfall herkommen – und diese Arbeit macht alles andere erst möglich.

Wenn Sie tiefer in die Operationalisierung datennativer Agenten mit den richtigen Guardrails und Mustern einsteigen möchten, sind diese Ressourcen ein hervorragender nächster Schritt:

• Um die Strategie in konkrete Kontrollen zu übersetzen, lesen Sie A Practical AI Governance Framework for Enterprises. Dieser Leitfaden zeigt, wie Sie übergeordnete Ziele in Rollen, Richtlinien und Workflows auf der Databricks Data Intelligence Platform umsetzen.
• Für einen breiteren Blick auf verantwortungsvolle AI in der Praxis führt Sie AI Governance Best Practices: How to Build Responsible and Effective AI Programs durch Prinzipien und Betriebsmodelle, die Sie teamübergreifend übernehmen können.

Um die in diesem Beitrag besprochenen Plattformfunktionen zu erkunden:

• Unity AI Gateway: What’s New at Data + AI Summit 2026 – eine einzige Control Plane für den gesamten Modell- und Agenten-Traffic mit deterministischen ALLOW-/DENY-/ASK-Custom-Guardrails.
• Agent Bricks: Data + AI Summit 2026 – automatisch optimierte Agenten, die als erstklassige, verwaltete Workloads auf der Plattform bereitgestellt werden.
• Omnigent: A Meta-Harness to Combine, Control and Share Your Agents – leitet Coding-Agenten (Claude Code, Codex, Cursor) über das Unity AI Gateway mit einem gemeinsamen Audit-Trail.
• Introducing Genie One, Genie Agents, and Genie Ontology – der automatisch gepflegte Wissensgraph, der Agenten in Ihrem Geschäftskontext verankert.
• Memory Scaling for AI Agents – wie Agentenzustand und -speicher auf Lakebase skalieren, verwaltet durch Unity Catalog innerhalb der Plattform.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag