Zum Hauptinhalt springen
Alle Beiträge
KI & Daten11 Min. Lesezeit

Echtzeit-KI mit Fabric Eventhouse und MCP-Connector

Wie der Eventhouse-MCP-Connector KI-Agenten live per KQL abfragen lässt — Architektur, Muster und Governance für Real-Time Intelligence in Microsoft Fabric.

Veröffentlicht Aktualisiert: 31. Mai 2026

Die meisten „Echtzeit-KI"-Demos sind gar nicht in Echtzeit. Sie beantworten Fragen zu Daten, die vor Stunden im Lake gelandet sind, garniert mit einem Chatfenster. Das wirklich schwierige Problem — einen autonomen Agenten sicher und mit Nachweispflicht über Telemetrie nachdenken zu lassen, die nur Sekunden alt ist — löst genau der Eventhouse-MCP-Connector in Microsoft Fabric.

Dieses Muster setzen wir bei CC Conceptualise ein, wenn Kunden Agenten benötigen, die auf Live-Signalen statt auf der Batch-Historie von gestern handeln. Es ist zugleich eine der folgenreichsten Erweiterungen des Fabric-KI-Stacks im Jahr 2026, denn es schließt die Lücke zwischen Streaming-Analytik und agentischer Ausführung.

TL;DR / Die wichtigsten Erkenntnisse

  • Eventhouse MCP macht live per KQL abfragbare Telemetrie zu einem Werkzeug für jeden KI-Agenten. Der Agent fragt in natürlicher Sprache; der MCP-Server erzeugt und führt KQL gegen Echtzeitdaten aus und liefert strukturierte Ergebnisse.
  • Das Eventhouse ist der heiße Pfad, OneLake die governte Historie. Nutzen Sie das Eventhouse für Subsekunden-Analysen aktueller Ereignisse und die Medallion-Schichten für kuratierte, dauerhafte Historie.
  • Die Schemaqualität bestimmt die Antwortqualität. Das Sprachmodell stützt sein KQL auf Ihre Tabellen- und Spaltenmetadaten — ein sauber modelliertes, dokumentiertes Eventhouse ist daher unverzichtbar.
  • Behandeln Sie den MCP-Endpunkt vom ersten Tag an als Produktionsschnittstelle. Least-Privilege-Identitäten, Zeilen-/Spaltensicherheit und Abfrageprotokollierung sind Go-Live-Anforderungen, keine späteren Aufräumarbeiten.
  • Es ist das Echtzeit-Werkzeug für Fabric Data Agents und Copilot Cowork. Agenten rufen Eventhouse MCP auf, wenn ein Workflow Live-Signale braucht, und korrelieren dann mit Gold-Layer-Daten.

Warum Echtzeit die Gleichung für Agenten verändert

Batch-Analytik und Echtzeitanalyse sind nicht dasselbe Problem in unterschiedlicher Geschwindigkeit, sondern verschiedene Probleme. Batch beantwortet „was geschehen ist" über einen abgeschlossenen, kuratierten Datenbestand. Echtzeit beantwortet „was gerade geschieht" über ein bewegliches Ziel, bei dem die Daten, die Sie vor einer Sekunde abgefragt haben, bereits überholt sind. Für einen KI-Agenten ist diese Unterscheidung entscheidend: Ein Agent, der nur die Historie sieht, kann ein Problem beschreiben, aber ein Agent, der Live-Telemetrie sieht, kann eingreifen, solange es noch zählt.

Das Hindernis war stets die Schnittstelle. Echtzeitspeicher wie ein Fabric Eventhouse werden mit KQL abgefragt — einer mächtigen, aber spezialisierten Sprache. Einen Agenten an einen Echtzeitspeicher anzubinden bedeutete bisher entweder, einen festen Satz an Abfragen vorzubacken — was den Sinn eines autonomen Agenten zunichtemacht — oder dem Agenten zuzutrauen, korrektes KQL ohne Erdung zu schreiben, was selbstbewussten Unsinn produziert. Der Eventhouse-Remote-MCP-Connector löst das, indem er einen Model-Context-Protocol-Server vor das Eventhouse stellt. Der Agent formuliert seine Absicht in natürlicher Sprache; der Server, geerdet im Eventhouse-Schema, erzeugt und führt das KQL aus und gibt typisierte Ergebnisse zurück.

Das ist relevant, weil MCP 2026 die Lingua franca des Agenten-Toolings ist. Jeder MCP-fähige Agent — ein Fabric Data Agent, eine Copilot-Cowork-Sitzung oder ein eigener Azure-AI-Foundry-Agent — kann Ihren Real-Time-Intelligence-Bestand nun ohne maßgeschneiderten Integrationscode als erstklassiges Werkzeug behandeln.

Wo das Eventhouse im Fabric-Bestand sitzt

Es lohnt sich, bei der Schichtung präzise zu sein, denn das Vermischen dieser Workloads ist der häufigste Architekturfehler, den wir sehen.

WorkloadSpeicherAbfragespracheAm besten fürLatenzprofil
Real-Time IntelligenceEventhouseKQLSchnelllebige Ereignisse, Zeitreihen, Logs, IoT-TelemetrieSubsekunde über aktuelle Daten
Kuratierte AnalytikLakehouse / Warehouse (OneLake)SQL / SparkHistorische, governte, Medallion-geschichtete DatenSekunden bis Minuten
Streaming-IngestEventstreamn. z. (Pipeline)Routing und Aufbereitung von Ereignissen ins EventhouseKontinuierlich
Semantik / BIPower-BI-SemantikmodellDAXGovernte Kennzahlen und ReportingInteraktiv

Das Eventhouse ist der heiße Pfad. Es nimmt schnelllebige Ereignisse auf — häufig über Eventstream — und bedient KQL-Abfragen im Subsekundenbereich über das jüngste Zeitfenster. OneLake bleibt der einheitliche Data Lake, der Ihre dauerhafte, governte Historie über die Bronze-, Silber- und Gold-Schichten hält. Ein reifes Design nutzt beides: Der Agent greift für Live-Signale ins Eventhouse und für den kuratierten Kontext, der diesem Signal Bedeutung gibt, in die Gold-Schicht.

Eine durchgespielte Architektur

Ein typischer Echtzeit-Agentenfluss, den wir umsetzen, sieht so aus:

Loading diagram...
  1. Aufnahme. Telemetrie — Anwendungsereignisse, Gerätesignale, Transaktionsströme — landet über Eventstream im Eventhouse, mit minimaler Transformation auf dem heißen Pfad.
  2. Bereitstellung. Das Eventhouse wird über seinen Remote-MCP-Endpunkt veröffentlicht, beschränkt auf eine dedizierte Agenten-Identität mit Lesezugriff auf einen definierten Satz von Tabellen.
  3. Erdung. Tabellen- und Spaltennamen werden bewusst modelliert und dokumentiert, damit die KQL-Generierung des MCP-Servers präzise ist.
  4. Abfrage. Ein Agent — ein Fabric Data Agent oder ein Foundry-Agent — ruft das MCP-Werkzeug mit einer natürlichsprachigen Frage auf. Der Server erzeugt KQL, führt es aus und liefert strukturierte Zeilen zurück.
  5. Korrelation. Der Agent verknüpft das Live-Ergebnis mit Gold-Layer-Kontext aus OneLake (Kundensegment, Asset-Kritikalität, SLA-Schwellen), um zu entscheiden, was das Signal bedeutet.
  6. Handeln. Der Agent löst eine nachgelagerte Aktion aus — eine Warnung, ein Ticket, einen Remediation-Workflow — und der gesamte Durchlauf, einschließlich jeder erzeugten KQL-Anweisung, wird protokolliert.

Bei Schritt 5 lohnt es sich zu verweilen. Live-Telemetrie für sich genommen ist Rauschen; eine Anomalie zählt nur relativ zum Kontext. Die Kombination aus Eventhouse MCP für den heißen Pfad und OneLake-Gold für den Kontext macht die Schlussfolgerungen des Agenten fundiert statt bloß reaktiv.

Die Governance ist das Schwierige, nicht die KQL-Generierung

Die Technik, KQL aus natürlicher Sprache zu erzeugen, ist beeindruckend, aber sie ist nicht der Punkt, an dem Produktionsprogramme scheitern. Sie scheitern an der Governance. Drei Maßnahmen sind unverzichtbar, bevor Sie ein Eventhouse für Agenten öffnen.

Identität und minimale Rechte. Der MCP-Endpunkt muss über eine dedizierte Identität nach dem Least-Privilege-Prinzip erreicht werden — niemals über einen breiten Dienstprinzipal mit bestandsweitem Zugriff. Beschränken Sie ihn auf genau die Tabellen, die ein Agent benötigt, und nicht mehr. Eine natürlichsprachige Schnittstelle über einer überprivilegierten Identität ist ein Prompt-Injection-Verstärker: Aus einer manipulierten Frage wird eine manipulierte Abfrage gegen alles.

Zeilen- und Spaltensicherheit. Erzwingen Sie Datenzugriffsrichtlinien im Eventhouse selbst, nicht im Prompt des Agenten. Das Modell darf niemals die Sicherheitsgrenze sein. Wenn eine Abfrage bestimmte Zeilen oder Spalten für eine Identität nicht zurückgeben darf, gehört diese Einschränkung in die Plattform, wo sie prüfbar ist und nicht umgeredet werden kann.

Protokollierung und Beobachtbarkeit. Jede erzeugte KQL-Anweisung, ihre Parameter und ihre Ergebnis-Metadaten müssen protokolliert werden. Das ist Ihre Nachweisbasis, Ihr Debugging-Werkzeug und Ihr Audit-Trail. Wenn ein Agent auf Live-Daten eine Entscheidung trifft, müssen Sie exakt rekonstruieren können, welche Abfrage das Signal erzeugt hat, auf das er gehandelt hat. Diese Disziplin entspricht jener, die wir auf den gesamten Lake anwenden; unsere Hinweise zu OneLake-Governance und -Sicherheit übertragen sich direkt auf die Echtzeit-Ebene.

Diese Maßnahmen passen zudem sauber zu den europäischen aufsichtsrechtlichen Erwartungen. Wo Agenten in Umgebungen wesentlicher Einrichtungen personenbezogene oder operative Daten berühren, verlangen NIS2, DSGVO und DORA allesamt Nachvollziehbarkeit, Zugriffskontrolle und die Fähigkeit, menschliche Aufsicht nachzuweisen. Abfrageprotokollierung und Least-Privilege-Beschränkung von Beginn an einzubauen, verwandelt eine Compliance-Last in Nachweise, die Sie bereits besitzen.

Wie es zu Data Agents und Copilot Cowork passt

Der Eventhouse-MCP-Connector ist kein eigenständiges Produkt, sondern das Echtzeit-Werkzeug in einem größeren agentischen Fabric-Stack. Fabric Data Agents orchestrieren autonome, mehrstufige Datenworkflows, und Copilot Cowork führt Arbeit über die Plattform hinweg aus. Beide greifen auf den Eventhouse-MCP-Endpunkt zurück, wenn ein Workflow aktuelle Signale statt abgeschlossener Historie braucht.

Ein konkretes Beispiel: Ein Data Agent, der eine Zahlungsplattform überwacht, ruft über Eventhouse MCP die Transaktionstelemetrie der letzten Minuten ab, korreliert die Fehlerraten mit Händlersegmenten und SLA-Schwellen aus der Gold-Schicht in OneLake und eröffnet — falls eine Schwelle überschritten wird — einen Vorfall und benachrichtigt das Bereitschaftsteam, wobei jede KQL-Anweisung und Entscheidung protokolliert wird. Die Architektur und Orchestrierung solcher Agenten behandeln wir ausführlich in unserem Beitrag zur Architektur von Microsoft Fabric Data Agents.

Hier wird auch der Rest der Fabric-MLOps-Geschichte von 2026 wichtig. Das workspaceübergreifende MLflow-Logging erlaubt es, in Azure Databricks oder Azure ML trainierte Modelle nach Fabric zu bringen, sodass das Modell, mit dem ein Agent eine Live-Anomalie bewertet, im selben Bestand wie die bewerteten Daten governt, versioniert und prüfbar ist. Real-Time Intelligence, agentische Ausführung und MLOps hören damit auf, getrennte Inseln zu sein.

Eine pragmatische Einführungsreihenfolge

Wenn Sie Agenten in Ihren Echtzeit-Bestand bringen, ordnen Sie es so, dass die Governance vorangeht und der Umfang folgt.

  1. Modellieren und dokumentieren Sie das Eventhouse-Schema. Bewusste Namen und klare Dokumentation sind das, worauf der MCP-Server sein KQL erdet. Das ist der wirksamste Einzelschritt.
  2. Definieren Sie die Sicherheitsgrenze. Legen Sie dedizierte Agenten-Identitäten an, beschränken Sie sie auf bestimmte schreibgeschützte Tabellen und erzwingen Sie Zeilen-/Spaltensicherheit in der Plattform.
  3. Aktivieren Sie die Abfrageprotokollierung, bevor sich ein Agent verbindet. Der Audit-Trail soll von der ersten Abfrage an stehen, nicht nach einem Vorfall nachgerüstet werden.
  4. Pilotieren Sie schreibgeschützt gegen unkritische Tabellen. Prüfen Sie Abfragegenauigkeit und Antwortqualität an risikoarmen Daten, bevor Sie den Umfang erweitern.
  5. Ergänzen Sie die Korrelation mit OneLake-Gold. Binden Sie den kuratierten Kontext ein, der aus rohem Signal eine sinnvolle Entscheidung macht.
  6. Führen Sie Aktionen nur mit menschlichen Aufsichtsschranken ein. Lassen Sie den Agenten empfehlen, bevor er autonom handelt, und behalten Sie einen Freigabeschritt, wo die regulatorische Einstufung es verlangt.

Die Versuchung ist groß, mit dem beeindruckenden Teil zu beginnen — einem Agenten, der Live-Fragen beantwortet — und die Governance später anzuschrauben. Wir haben durchgängig festgestellt, dass die umgekehrte Reihenfolge insgesamt schneller ist, denn Zugriffskontrolle und Audit-Protokollierung auf ein laufendes agentisches System nachzurüsten, ist weit teurer, als sie von vornherein einzubauen.

Fazit

Der Eventhouse-MCP-Connector ist ein echter Sprung für Real-Time Intelligence in Fabric: Er macht live per KQL abfragbare Telemetrie zu einem aufrufbaren Werkzeug für jeden MCP-fähigen Agenten — ohne maßgeschneiderte Integration und ohne vorgebackene Abfragen. Worauf es ingenieurtechnisch ankommt, ist nicht die Übersetzung von natürlicher Sprache nach KQL — das hat Microsoft gelöst —, sondern die Architektur und Governance darum herum: das Eventhouse als heißen Pfad und OneLake als governte Historie zu halten, die Generierung in einem sauber modellierten Schema zu erden und den MCP-Endpunkt als Produktionsschnittstelle mit Least-Privilege-Identität, plattformseitig durchgesetzter Sicherheit und vollständiger Abfrageprotokollierung zu behandeln.

Wenn dieses Fundament stimmt, haben Sie Agenten, die auf das handeln, was gerade geschieht, statt auf das, was geschehen ist — sicher und mit einem Audit-Trail, den sowohl Ihr CISO als auch Ihre Aufsicht akzeptieren.

Wenn Sie Real-Time-Intelligence- oder agentische Fabric-Workloads entwerfen und einen Partner suchen, der sie unter europäischen aufsichtsrechtlichen Auflagen geliefert hat, spricht unser Team für KI und Datenplattformen gern Ihre Architektur durch.

FAQ

Was ist der Eventhouse-MCP-Connector in Microsoft Fabric?

Es handelt sich um einen Remote-Endpunkt nach dem Model Context Protocol, der ein Fabric Eventhouse für KI-Agenten zugänglich macht. Statt Abfragen von Hand zu schreiben, stellt ein Agent eine Frage in natürlicher Sprache, der MCP-Server übersetzt die Absicht in KQL, führt sie gegen die Echtzeitdaten im Eventhouse aus und liefert strukturierte Ergebnisse zurück. Damit wird operative Live-Telemetrie zu einem Werkzeug, das jeder MCP-fähige Agent aufrufen kann.

Worin unterscheidet sich ein Eventhouse von einem Lakehouse oder Warehouse in Fabric?

Ein Eventhouse ist speziell für hochvolumige, schnelllebige Ereignis- und Zeitreihendaten gebaut und wird mit KQL abgefragt, optimiert auf Analysen im Subsekundenbereich über aktuelle Telemetrie. Lakehouse und Warehouse liegen auf OneLake für Batch- und Verlaufsanalysen über die Medallion-Schichten. In der Praxis nutzt man das Eventhouse für den heißen Streaming-Pfad und OneLake für die kuratierte, governte Historie; sie ergänzen sich, statt sich zu ersetzen.

Müssen KI-Agenten KQL beherrschen, um Eventhouse MCP zu nutzen?

Nein. Der Sinn des MCP-Connectors ist, dass der Agent in natürlicher Sprache arbeitet und der Server das KQL erzeugt und ausführt. Allerdings steigt die Antwortqualität erheblich, wenn das Eventhouse-Schema sauber modelliert, klar benannt und dokumentiert ist, denn das Sprachmodell stützt seine Abfragegenerierung auf diese Metadaten. Ein schlechtes Schema erzeugt plausible, aber falsche Abfragen.

Ist die Abfrage von Echtzeitdaten per natürlicher Sprache produktionstauglich?

Mit den richtigen Schutzmaßnahmen ja. Beschränken Sie den MCP-Endpunkt auf Identitäten nach dem Least-Privilege-Prinzip, setzen Sie Zeilen- und Spaltensicherheit im Eventhouse durch, protokollieren Sie jede erzeugte Abfrage zu Nachweiszwecken und behandeln Sie Eingaben in natürlicher Sprache als nicht vertrauenswürdig, um Prompt Injection abzuwehren. Das Risiko ist nicht die KQL-Generierung selbst, sondern zu weit gefasste Zugriffe und nicht protokollierte Aktionen — Governance-Probleme, die man wie bei jedem Datenwerkzeug löst.

Wie fügt sich Eventhouse MCP in Fabric Data Agents und Copilot Cowork ein?

Fabric Data Agents orchestrieren autonome Datenworkflows und Copilot Cowork führt mehrstufige Arbeit aus; der Eventhouse-MCP-Connector ist das Echtzeit-Werkzeug, das diese Agenten aufrufen, wenn ein Workflow Live-Signale statt Batch-Historie braucht. Ein Data Agent kann aktuelle Telemetrie über Eventhouse MCP abrufen, sie mit kuratierten Gold-Layer-Daten korrelieren und eine Aktion auslösen — alles in einem nachvollziehbaren Durchlauf.

Was empfiehlt CC Conceptualise, bevor man ein Eventhouse für Agenten öffnet?

Modellieren und dokumentieren Sie zuerst das Schema, definieren Sie die Sicherheitsgrenze und die Agenten-Identitäten, aktivieren Sie die Abfrageprotokollierung und pilotieren Sie zunächst schreibgeschützt gegen unkritische Tabellen, bevor Sie den Umfang erweitern. Wir behandeln den MCP-Endpunkt vom ersten Tag an als Produktionsschnittstelle — mit derselben Identitäts-, Beobachtbarkeits- und Least-Privilege-Disziplin wie bei jedem anderen Datendienst.

Themen

Fabric EventhouseEventhouse MCPReal-Time Intelligence FabricKQL KI-AgentenEchtzeitanalyse FabricMicrosoft Fabric AgentenEventhouse Remote MCP

Häufig gestellte Fragen

Es handelt sich um einen Remote-Endpunkt nach dem Model Context Protocol, der ein Fabric Eventhouse für KI-Agenten zugänglich macht. Statt Abfragen von Hand zu schreiben, stellt ein Agent eine Frage in natürlicher Sprache, der MCP-Server übersetzt die Absicht in KQL, führt sie gegen die Echtzeitdaten im Eventhouse aus und liefert strukturierte Ergebnisse zurück. Damit wird operative Live-Telemetrie zu einem Werkzeug, das jeder MCP-fähige Agent aufrufen kann.

Expert engagement

Brauchen Sie Expertenberatung?

Unser Team ist spezialisiert auf Cloud-Architektur, Security, KI-Plattformen und DevSecOps. Lassen Sie uns besprechen, wie wir Ihrem Unternehmen helfen können.

Kontakt aufnehmenNo commitment · No sales pressure

Verwandte Artikel

Alle Beiträge