--- title: "KI-Agenten dort bauen, wo Ihre Daten liegen | Dawiso Blog" description: "Alle bauen Agenten, die mit Daten sprechen. Bauen Sie sie dort, wo Daten und Rechenleistung ohnehin liegen, und bringen Sie den geregelten Kontext zu ihnen." url: "https://www.dawiso.com/de/blog-post/build-agents-where-your-data-lives" language: "de" --- # Wo sollten Sie die KI-Agenten bauen, die mit Ihren Daten sprechen? Samuel Nagy VP of Strategic Growth \4. August 2026 Alle wollen Agenten, die mit ihren Daten sprechen, vom Analyse-Copiloten bis zum Chatbot, der einer Kundin die Frage zu ihrer Bestellung beantwortet. Die Frage, die sich lohnt, ist nicht, ob man sie baut, sondern wo. Die Antwort, die immer wieder trägt, ist einfach: dort bauen, wo Ihre Daten und Ihre Rechenleistung ohnehin liegen, und den geregelten Kontext zu ihnen bringen. ## Alle bauen Agenten, die mit Daten sprechen Wo Menschen mit ihren Daten sprechen werden, ist seit Jahren eine offene Frage, und sie ist nur lauter geworden. Eine Zeit lang hieß es „talk to your data“, ein Feld für natürliche Sprache über einem Warehouse. Inzwischen ist dieselbe Idee mit einer größeren verschmolzen: dem Ansturm, **Agenten zu bauen, die im Namen eines Unternehmens mit Daten umgehen**. Es hilft, weit zu fassen, was hier zählt. Der Agent muss kein Werkzeug für Datenanalyse sein. Ein Agent im Kundenerfolg, der ein Konto nachschlägt, oder ein Chatbot im Handel, der die Frage einer Kundin zu ihrer Bestellung beantwortet, ist ebenfalls ein Agent, der mit Daten spricht. Er hat ein Backend, in dem er das Geschäft abfragen und eine Antwort zurückgeben kann. So betrachtet baut fast jedes Unternehmen mindestens einen davon, ob es ihn Agent nennt oder nicht. Das Ausmaß ist nicht hypothetisch. [Gartner erwartet](https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025), dass bis 2026 bis zu 40 % der Unternehmensanwendungen aufgabenbezogene KI-Agenten enthalten, nach weniger als 5 % ein Jahr zuvor. Die interessante Frage ist also nicht mehr, ob man sie baut. Sie lautet, **wo Sie sie bauen sollten**, denn diese Entscheidung bestimmt still Ihre Kosten, Ihre Sicherheitslage und wie stark Sie am Ende gebunden sind. ## Die drei Orte, an denen Sie KI-Agenten bauen können Es zeigt sich, dass alle der Ort sein wollen, an dem Sie diese Agenten bauen, und das Feld sortiert sich in drei Gruppen. Erstens die **Hyperscaler**. Microsoft, Amazon und Google liefern heute alle Plattformen zum Bau von Agenten und haben den Einstieg recht einfach gemacht, von [Microsoft Foundry](https://azure.microsoft.com/en-us/products/ai-foundry/) über [Amazon Bedrock AgentCore](https://aws.amazon.com/about-aws/whats-new/2025/10/amazon-bedrock-agentcore-available) bis zum [Vertex AI Agent Builder](https://cloud.google.com/blog/products/ai-machine-learning/more-ways-to-build-and-scale-ai-agents-with-vertex-ai-agent-builder) von Google. Ein Großteil Ihrer Daten und die meiste Rechenleistung liegen ohnehin bei einem von ihnen, und die Kontrollen für Sicherheit und Identität sind bereits verdrahtet. Dort einen Agenten zu bauen ist nah an der Infrastruktur. Zweitens die **Datenplattformen** wie [Snowflake](https://www.dawiso.com/de/glossary/snowflake) und [Databricks](https://www.dawiso.com/de/glossary/what-is-databricks-complete-guide-for-2025). Sie halten die Daten und betreiben die Rechenleistung, und sie wollen nun auch der Ort sein, an dem Sie die Agenten bauen, die sie nutzen, mit Angeboten wie [Snowflake data agents](https://www.snowflake.com/en/product/use-cases/data-agents/) und [Databricks Agent Bricks](https://www.databricks.com/blog/introducing-agent-bricks), sodass die Abfrage die Plattform nie verlassen muss. Drittens eine Reihe von **Werkzeugen Dritter**, die **weder die Daten noch die Rechenleistung** halten und trotzdem meinen, sie sollten der Ort sein, an dem Sie Ihre Agenten bauen. Über diese Gruppe lohnt es sich am längsten nachzudenken, denn das Angebot klingt vernünftig, bis man fragt, was das Werkzeug zum Betrieb des Agenten eigentlich beiträgt. ## Warum Hyperscaler und Datenplattformen meist gewinnen Stellt man die drei Gruppen nebeneinander, ist die Richtung des Marktes nicht schwer zu lesen. Die Hyperscaler und die Datenplattformen werden weiter Werkzeuge für Agenten bauen, und sie werden es gut tun, weil sie auf den beiden Dingen sitzen, die ein Agent am meisten braucht. Die **Daten und die Rechenleistung liegen dort bereits**, das Sicherheitsmodell steht schon, und sie können alles günstiger anbieten als ein Dritter, weil sie weder für das Verschieben von Daten noch für eine eigene Laufzeitumgebung zahlen. Versetzen Sie sich in ein Team, das entscheidet, wo gebaut wird. Wenn Ihre Daten in Databricks liegen und Ihre Identitäts- und Zugriffskontrollen dort bereits durchgesetzt werden, warum sollten Sie den Agenten auf einer dritten Plattform betreiben, der nichts davon gehört? Sie würden einen Netzwerksprung, eine zweite Sicherheitsgrenze und eine weitere Rechnung hinzufügen und dafür sehr wenig bekommen. „Bauen Sie Ihre Agenten dort, wo Daten, Rechenleistung und Sicherheit bereits liegen. Machen Sie den Kontext, den Sie ihnen bringen, zu dem, was Ihnen gehört.“ Das ist kein Vorwurf an die Werkzeuge in dieser dritten Gruppe. Viele davon sind ausgezeichnet in dem, wofür sie gebaut wurden. Der Punkt ist enger: **Die Laufzeitumgebung des Agenten zu stellen ist nicht die Stelle, an der ein Werkzeug ohne Daten und ohne Rechenleistung Wert schafft**, und die großen Plattformen werden jeden, der dort antritt, überbauen und unterbieten. ## Wann ergibt eine eigene Agentenplattform Sinn? Es gibt eine Lage, in der der Bau außerhalb der großen Plattformen ein echtes Argument hat. Das ist der Agent, der sich mit **mehreren Datenquellen zugleich** verbinden muss, wo keine einzelne Plattform alles hält, was er für eine gute Antwort braucht. Wenn die Bedeutung, die er benötigt, über ein Warehouse, ein BI-Werkzeug und ein operatives System verteilt ist, kann es reizvoll wirken, den Agenten an einem neutralen Ort zu betreiben. In der Praxis ist dieser Fall selten, und selbst wenn er auftritt, ist eine eigene Bauschicht meist die falsche Abhilfe. Der Grund, warum ein Agent über Quellen hinweg ins Straucheln gerät, ist nicht, wo er läuft. Es ist, dass die Quellen das Geschäft uneinheitlich beschreiben und niemand abgeglichen hat, was ein Begriff von einem System zum nächsten bedeutet. Die Laufzeitumgebung zu verschieben löst das nicht. Die Bedeutung abzugleichen schon. An diesem Faden lohnt es zu ziehen, denn er zeigt, wofür die dritte Gruppe tatsächlich taugt, und das ist nicht, Ihre Agenten zu beherbergen. ## Machen Sie Ihren Kontext portabel, nicht Ihre Agenten Treten Sie einen Schritt zurück und fragen Sie, was an alldem wirklich schwer nachzubauen ist. Es ist nicht der Agent. Agenten werden Monat für Monat billiger zu bauen, und die großen Plattformen machen sie schnell zur Massenware. Das schwere, langsame, wertvolle Gut ist der [geregelte Kontext](https://www.dawiso.com/de/glossary/context-store-for-ai) hinter Ihren Daten: die Definitionen, auf die sich alle geeinigt haben, wer für sie verantwortlich ist, wie Daten von der Quelle bis zum Bericht fließen und wie sie klassifiziert sind. Das ist der Teil, der Jahre gekostet hat, und der Teil, den Sie am wenigsten in einem einzelnen Anbieter gefangen sehen wollen. Damit dreht sich das Entwurfsziel um. Statt ein Werkzeug zu bitten, Ihren Agenten zu beherbergen, wollen Sie, dass **der geregelte Kontext reist und nicht der Agent**. Sie regeln die fachliche Bedeutung einmal, in einer Schicht, die Ihnen gehört, und stellen sie dann jedem Agenten bereit, der sie braucht, wo immer dieser Agent läuft. Genau hier verdient sich ein Werkzeug ohne Daten und ohne Rechenleistung seinen Platz. Seine Aufgabe ist es, Bedeutung einheitlich und portabel zu machen, nicht eine weitere Laufzeitumgebung zu sein. So gerahmt hebt sich das eigentliche Angebot der dritten Gruppe vom schwachen ab. „Bauen Sie Ihre Agenten auf unserer Plattform“ ist eine milde Form von **Vendor Lock-in**, derselbe Reflex, der einen Governance-Anbieter dazu bringt, die eigene Engine für Datenqualität zu bewerben und still von den Werkzeugen der Plattform selbst wegzulenken. „Nutzen Sie Ihren Kontext überall“ ist das Gegenteil. Das eine bindet Ihre Zukunft an eine gemietete Laufzeitumgebung. Das andere behält das teure Gut in Ihrer Hand und lässt die Laufzeitumgebung das sein, was zum jeweiligen Anwendungsfall passt. ## Agenten dort bauen, wo Ihre Daten liegen, und den Kontext zu ihnen bringen Das ist die Haltung, die wir bei [Dawiso](https://www.dawiso.com/de/context-layer) einnehmen, und sie ist bewusst gewählt. Wir wollen nicht der Ort sein, an dem Sie Ihre Agenten bauen. Wir sind der Ort, an dem Ihre [geregelte fachliche Bedeutung](https://www.dawiso.com/de/product/business-glossary) liegt, und unsere Aufgabe ist, diesen Kontext in Ihre Agenten zu bringen, wo immer Sie sie bauen, ob nativ auf einem Hyperscaler, in Databricks oder Snowflake oder in einem eigenen Agenten, den Sie selbst aufsetzen. Einer unserer Kunden, [Seznam.cz](https://www.dawiso.com/case-study/seznam), hat genau das getan. Das Unternehmen hat einen eigenen dialogorientierten Agenten gebaut und ihn über das [Model Context Protocol](https://www.dawiso.com/de/glossary/model-context-protocol-mcp) mit geregeltem Kontext in Dawiso verbunden, einem [offenen Standard, hinter dem inzwischen jeder große KI-Anbieter steht](https://blog.modelcontextprotocol.io/posts/2025-11-25-first-mcp-anniversary/), statt sich sagen zu lassen, den Agenten im Studio eines Anbieters zu bauen. Genau diese Freiheit ist es wert, geschützt zu werden. Dawiso bindet mehr als 40 Plattformen an, definiert jeden Begriff einmal mit einer verantwortlichen Person und einem Freigabeablauf, verfolgt [Lineage](https://www.dawiso.com/de/product/interactive-data-lineage) und Klassifizierung über die gesamte Landschaft und stellt all das über einen offenen [MCP Server](https://www.dawiso.com/de/product/mcp) jedem MCP-fähigen Agenten bereit. Die Empfehlung ist also kurz. Bauen Sie Ihre Agenten dort, wo die Arbeit für sie bereits eingerichtet ist, auf den Plattformen, die Ihre Daten und Ihre Rechenleistung halten. Halten Sie den Kontext in einer Schicht geregelt, die Ihnen gehört, und liefern Sie ihn diesen Agenten über ein offenes Protokoll. So kann der Markt Agenten weiter zur Massenware machen, was gut für Sie ist, während das eine Gut, das wirklich Ihnen gehört, portabel bleibt und unter Ihrer Kontrolle. ## FAQ **Sollte ich meinen KI-Agenten in meinem Datenkatalog oder meinem Governance-Werkzeug bauen?** Meist nein. Ihre Daten, Ihre Rechenleistung und Ihre Sicherheitskontrollen liegen bereits bei Ihrem Cloud-Anbieter oder auf Ihrer Datenplattform, also bedeutet der Bau des Agenten dort weniger bewegliche Teile und eine Stelle weniger, an der Daten hinausgehen können. Ein Werkzeug für Governance oder Katalog, das weder die Daten noch die Rechenleistung hält, wird zu einem zusätzlichen Umweg zwischen dem Agenten und dem, was er braucht. Die bessere Arbeitsteilung ist, den Agenten dort zu bauen, wo die Daten liegen, und die Governance-Schicht zu nutzen, um ihm geregelten Kontext zu liefern, ausgeliefert über ein offenes Protokoll wie MCP. **Wann ergibt es tatsächlich Sinn, einen Agenten auf einer eigenen Plattform zu bauen?** Der klarste Fall ist ein Agent, der über mehrere Datenquellen zugleich schlussfolgern muss, wo keine einzelne Plattform alles hält, was er braucht. Selbst dann ist eine eigene Bauschicht selten die Antwort. Ein geregelter Context Layer, über MCP bereitgestellt, gibt einem Agenten einheitliche Bedeutung und Lineage über all diese Quellen hinweg, ohne Sie zu zwingen, den Agenten auf einer Plattform zu betreiben, der keine davon gehört. In der Praxis ist der Fall mit mehreren Quellen weit seltener, als er klingt, denn die meisten Agenten sind auf eine Domäne zugeschnitten, die überwiegend auf einer Plattform liegt. **Was sollte über Plattformen hinweg portabel sein, der Agent oder der Kontext?** Der Kontext. Agenten sind billig neu zu bauen und werden von den großen Plattformen zunehmend zur Massenware gemacht. Die geregelte fachliche Bedeutung hinter Ihren Daten, also die Definitionen, die Verantwortlichkeiten, die Lineage und die Klassifizierung, ist das Teure und Langsame, das sich schwer neu herstellen lässt, und der Teil, den Sie am wenigsten an einen einzelnen Anbieter gebunden sehen wollen. Halten Sie ihn in einer Schicht, die Ihnen gehört und die Sie überall bereitstellen können, und Sie bleiben frei, Agenten dort zu bauen, wo der jeweilige Anwendungsfall am besten unterstützt wird. **Wie passt Dawiso dazu, wenn ich Agenten nativ auf Databricks oder Snowflake baue?** Dawiso ist nicht der Ort, an dem Sie den Agenten bauen. Es regelt Ihre fachliche Bedeutung einmal, über mehr als 40 Plattformen hinweg, und stellt diesen geregelten Kontext über einen offenen MCP Server jedem MCP-fähigen Agenten bereit. Sie bauen den Agenten also nativ auf Databricks, auf Snowflake, auf einem Hyperscaler oder als eigene Anwendung, und Dawiso sorgt dafür, dass er in demselben verantworteten, geprüften Kontext geerdet ist, ganz gleich, wo er läuft. [In Aktion erleben](https://www.dawiso.com/de/context-layer) Dawiso Context Layer Regeln Sie die fachliche Bedeutung einmal und stellen Sie sie dann Agenten auf jeder Plattform über ein offenes Protokoll bereit. ### Inhalt Alle bauen Agenten, die mit Daten sprechenDie drei Orte, an denen Sie KI-Agenten bauen könnenWarum Hyperscaler und Datenplattformen meist gewinnenWann ergibt eine eigene Agentenplattform Sinn?Machen Sie Ihren Kontext portabel, nicht Ihre AgentenAgenten dort bauen, wo Ihre Daten liegen, und den Kontext zu ihnen bringenFAQ ## Mehr zum Thema Lesen Sie weiter und tauchen Sie tiefer in unsere neuesten Beiträge zu Metadatenmanagement und mehr ein: ### [Ergibt ein eigenständiger Context Layer im Zeitalter der Ontologie von Genie noch Sinn?](https://www.dawiso.com/de/blog-post/standalone-context-layer-genie-ontology) Databricks Genie Ontology ist ein echter Context Layer. Wozu noch ein eigenständiger? Zwei Gründe: verantwortete Definitionen und Reichweite über Plattformen. Weiterlesen ### [Kontextsilos: Datensilos, neu geboren im KI-Zeitalter](https://www.dawiso.com/de/blog-post/context-silos-ai-era) Jedes KI-Werkzeug, von Cortex über Genie bis Frontier, baut eigenen, ungeregelten Kontext. Diese Kontextsilos sind die neuen Datensilos. Wie Sie Kontext einmal regeln und überall bereitstellen. Weiterlesen ### [Context Engineering für Enterprise-KI: die fehlende Schicht](https://www.dawiso.com/de/blog-post/context-engineering-enterprise-ai) Context Engineering entscheidet, was Ihre KI sieht, bevor sie antwortet. Ein Leitfaden zu den Schichten, zum Unterschied zu Prompt Engineering und RAG und dazu, warum geregelter Kontext das fehlende Stück ist. Weiterlesen