Wo sollten Sie die KI-Agenten bauen, die mit Ihren 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, 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.

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 über Amazon Bedrock AgentCore bis zum 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 und Databricks. 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 und Databricks 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.

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.

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.

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.

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 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.

Das ist die Haltung, die wir bei Dawiso 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 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, hat genau das getan. Das Unternehmen hat einen eigenen dialogorientierten Agenten gebaut und ihn über das Model Context Protocol mit geregeltem Kontext in Dawiso verbunden, einem offenen Standard, hinter dem inzwischen jeder große KI-Anbieter steht, 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 und Klassifizierung über die gesamte Landschaft und stellt all das über einen offenen MCP Server 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.