Google verbindet Gemini Enterprise jetzt direkt mit BigQuery, Spanner, Cloud SQL und AlloyDB und nutzt dafür offene Protokolle wie MCP. Der föderierte Abfragemodus, der sich noch in der Vorschau befindet, belässt die Daten dort, wo sie liegen, sodass Teams auf Kopien, Pipelines und Schema-Mapping verzichten können. Jede Anfrage wird mit den eigenen Anmeldedaten des Anfragenden ausgeführt, nicht mit einem gemeinsam genutzten Admin-Konto, wodurch bestehende Berechtigungen erhalten bleiben. Veraltete Snapshots und lockere Zugriffskontrollen sind nicht mehr akzeptabel. Einrichtungsschritte, Limits und Regeln für benutzerdefinierte Server folgen für alle, die mehr erfahren möchten.
Was ist die Gemini-Enterprise-Datenbankintegration?
Die Anbindung eines KI-Assistenten an Unternehmensdaten bedeutete lange Zeit, diese Daten an einen anderen Ort zu kopieren. Die Datenbankintegration von Google Gemini Enterprise soll mit dieser Gewohnheit Schluss machen. Sie verbindet Gemini-Enterprise-Apps über Data-Cloud-Konnektoren direkt mit BigQuery, Spanner, Cloud SQL und AlloyDB für PostgreSQL, wobei jeder Konnektor von einem erstanbieter-eigenen MCP-Server betrieben wird.
Im föderierten Abfragemodus, der sich derzeit in der Vorschau befindet, bleiben die Daten dort, wo sie liegen. Teams sparen sich so die zusätzliche Kopie, die Pflege von Pipelines und das Schema-Mapping, die damit üblicherweise einhergehen.
Der Ingestion-Modus bleibt bei Bedarf weiterhin verfügbar. Jede Anfrage wird mit den eigenen IAM- oder OAuth-Anmeldedaten des Nutzers ausgeführt, sodass die bestehende Data Governance weiterhin greift und kein gemeinsam genutztes Dienstkonto unbemerkt den Zugriff ausweitet. Nutzer können Daten lesen und, sofern konfiguriert, Datenbankaktionen ausführen.
Warum ist MCP für den Datenbankzugriff wichtig?
Warum ist ein Protokoll wichtig, wenn das eigentliche Ziel einfach darin besteht, einen KI-Assistenten eine Datenbank lesen zu lassen? Weil ohne ein solches Protokoll jede Anbindung zu einer individuellen Sonderlösung wird, die für jeden Client, jeden Anbieter und jedes Team wiederholt werden muss. Protokoll-Einfachheit ändert das, indem sie maßgeschneiderte Konnektoren durch eine einzige, offene Schnittstelle ersetzt, die jeder kompatible Client nutzen kann. Die Integrationskosten sinken, da Datenbankfunktionen einmal bereitgestellt und überall wiederverwendet werden, und Clients Tools und Schemata zur Laufzeit entdecken, anstatt sich auf fest codierten Verbindungscode zu verlassen. Freiheit ist die Folge, denn offene Standards ermöglichen es Organisationen, Tools über verschiedene Ökosysteme hinweg zu kombinieren, ohne etwas neu aufbauen zu müssen. Auch die Kontrolle bleibt vollständig erhalten. Eingeschränkter Zugriff, ausdrückliche Zustimmung, RBAC und Auditing sind fester Bestandteil des Protokolls, sodass Agenten sicher auf aktuelle Unternehmensdaten zugreifen können und Benutzer nur die für sie zulässigen Daten sehen.
Welche Datenbanken sind in der Vorschau für Federated Query enthalten?
Vier Google-Cloud-Datenbanken werden in der Preview des föderierten Abfragemodus von Gemini Enterprise genannt: AlloyDB for PostgreSQL, BigQuery, Cloud SQL und Spanner.
Diese Datenbankliste ist kurz und eindeutig, daher sollte niemand mehr annehmen. Die Vorschau für föderierte Abfragen ist noch Preview und nicht GA, doch sie befreit Teams davon, Daten in einen separaten Speicher zu kopieren, denn Abfragen werden vor Ort ausgeführt, und zwar mit den eigenen Anmeldedaten des jeweiligen Nutzers.
Der BigQuery-Connector ist der empfohlene Weg und behält die IAM-Berechtigungen, einschließlich Sicherheit auf Zeilenebene, vollständig bei. Der AlloyDB-Connector, der Cloud-SQL-Connector und der Spanner-Connector bringen eine härtere Wahrheit mit sich: keine Tabelleneingrenzung, keine verifizierten Abfragen und eine Genauigkeit, die bei komplexen transaktionalen Schemas schwanken kann. Nutzer verdienen es, das zu wissen, bevor sie den Antworten vertrauen. Freiheit beginnt mit klaren Grenzen.
Wie fragt Gemini Enterprise Daten direkt am Speicherort ab?
Zu wissen, welche Datenbanken infrage kommen, ist nur die halbe Wahrheit, denn der Mechanismus hinter den Abfragen entscheidet darüber, ob die Vorschau ihr Versprechen einlöst. Gemini Enterprise sendet SQL-ähnliche Anfragen direkt an die Datenbank, sodass die Daten nie ihr Zuhause verlassen müssen. Keine Massenextraktion, keine Schattenkopien, kein separater Analysespeicher, der Ihre Informationen als Geisel hält. Offene Protokolle und Konnektoren übersetzen jede Anfrage in native Datenbankoperationen, was den Aufwand für individuellen Integrationscode beseitigt und es Teams ermöglicht, Systeme frei nach Belieben zu kombinieren. Filterung auf der Quellseite bedeutet, dass nur die notwendigen Zeilen und Spalten über das Netzwerk übertragen werden, was Verschwendung reduziert. Die Ergebnisse spiegeln die ursprünglichen Tabellen wider, daher ist Aktualität der Live-Abfragen konstruktionsbedingt garantiert und nicht von einem Synchronisierungsplan abhängig. Native Datenbankkontrollen regeln weiterhin den Zugriff.
Wie schützen Benutzeranmeldedaten den Datenbankzugriff?
Nutzeranmeldedaten bleiben die erste Barriere zwischen einem KI-Agenten und den sensibelsten Datensätzen eines Unternehmens, und da Gemini Enterprise nun Cloud-Datenbanken direkt vor Ort abfragt, darf diese Barriere nicht als Nebensache behandelt werden. Die Durchsetzung von Anmeldedaten pro Nutzer bedeutet, dass jede Anfrage unter der Identität der anfragenden Person ausgeführt wird, sodass der Agent deren rollenbasierte Berechtigungen erbt, nicht mehr und nicht weniger, anstatt ein gemeinsames Administratorkonto zu verwenden, das unbemerkt jede Tabelle offenlegt. Da die Daten die Datenbank nie verlassen, entscheiden die bestehenden Authentifizierungs- und Autorisierungsregeln und nicht eine nachträglich aufgesetzte Kopie mit schwächeren Kontrollen darüber, was der Agent sehen darf.
Durchsetzung benutzerspezifischer Anmeldedaten
Jede Anfrage, die Gemini Enterprise an eine Datenbank sendet, trägt die Identität der Person, die sie gestellt hat, und diese eine Designentscheidung bestimmt, wie der Zugriff geschützt wird. Kein gemeinsames Anwendungs-Login steht stellvertretend für jemanden, sodass niemand die Rechte einer anderen Person übernimmt und Nutzer die Kontrolle darüber behalten, worauf sie zugreifen können. So funktioniert das in der Praxis:
- Jede Person authentifiziert sich mit privaten IAM- oder OAuth-2.1-Anmeldedaten, niemals mit einem gemeinsam genutzten Schlüssel.
- Die Rotation von Anmeldedaten ersetzt das Geheimnis einer einzelnen Person, ohne jemand anderen zu beeinträchtigen, und die Sitzungsisolierung hält jede Anfrage innerhalb der zulässigen Rolle dieser Person.
- Jede Abfrage ist zurechenbar, sodass Audits den tatsächlichen Nutzer benennen, und ein kompromittiertes Konto gibt nur seine eigenen, begrenzten Daten preis.
Die Autorisierung erfolgt, bevor Daten bewegt werden, und niemand gibt standardmäßig Freiheit auf.
Daten direkt vor Ort abfragen
Wenn Gemini Enterprise Daten direkt an ihrem Speicherort abfragt, entscheidet die Datenbank und nicht die KI-Schicht darüber, was jede einzelne Person sehen darf. Diese Unterscheidung ist wichtiger als jede Marketingbehauptung zur Integration. Sicherheit zur Abfragezeit funktioniert, weil die Anmeldeinformationen des Nutzers durch die Verbindung weitergereicht werden und so zeilen- und objektbezogene Regeln in der Datenbank selbst aktivieren. Filterung und Autorisierung erfolgen, bevor Ergebnisse zurückgegeben werden, sodass Daten nicht an anderer Stelle kopiert werden müssen, wo diese Schutzmechanismen unbemerkt verloren gehen könnten.
Gemeinsam genutzte Dienstkonten sind das Gegenteil davon, und die Risiken der Wiederverwendung von Anmeldeinformationen sind real, denn ein einziger weitreichender Zugang lässt jeden Nutzer denselben Zugriff erben. Eng begrenzte, zeitlich befristete Token beschränken den Schaden erheblich, falls eines gestohlen oder missbraucht wird. Nutzer verdienen echte Kontrolle über ihre Daten, und Systeme sollten diese durchsetzen, anstatt sie nur zu versprechen.
Was können Gemini Enterprise Agents mit Live-Daten tun?
Gemini Enterprise Agents können Live-Daten dort abfragen, wo sie bereits liegen , und genau das war für die meisten Unternehmen über Jahre hinweg schwer zu erreichen. Teams sind nicht länger an kopierte Datensätze, veraltete Exporte oder SQL-Gatekeeper gebunden, und die Agents liefern Echtzeit-Einblicke, ohne eine einzige Zeile zu verschieben. Jede Anfrage bleibt innerhalb der bestehenden Sicherheitsgrenzen, da sie jeweils mit den eigenen Berechtigungen des Nutzers ausgeführt wird. In der Praxis können die Agents Folgendes:
- Über Knowledge Catalog zulässige Tabellen, Schemas und Glossarbegriffe finden und anschließend auf Grundlage dieses Kontexts SQL schreiben.
- Analytische Abfragen und autorisierte Vorgänge in BigQuery, Spanner, Cloud SQL und AlloyDB ausführen.
- Data Agents in der Agent Gallery veröffentlichen und sie mit umfassenderen Agent-to-Agent-Workflows verknüpfen.
Die Antworten kommen governt und aktuell, sodass Menschen einfach fragen und sofort handeln können.
Können Sie Ihren eigenen MCP-Server mitbringen?
Gemini Enterprise akzeptiert zwar benutzerdefinierte MCP-Server, aber nur über die Business Edition, in der ein Administrator unter Team, Team verwalten, Verbundene Apps und anschließend MCP-Server hinzufügen einen solchen Server hinzufügen kann. Der Server muss hinter einem HTTPS-Endpunkt liegen, in der Regel `/mcp`, muss StreamableHTTP unterstützen, da SSE nicht unterstützt wird, und muss als OAuth-Client mit der Weiterleitungs-URL `https://vertexaisearch.cloud.google.com/oauth-redirect` registriert sein. Diese Anforderung ermöglicht es Unternehmen, private Daten, interne Tools und MCP-konforme Drittanbietersysteme zu verbinden, doch die Funktion arbeitet mit dem Agent Designer und nicht mit dem Standard-Agenten, sodass das Versprechen, jeden Server mit jedem Agenten zu verbinden, an echte Bedingungen geknüpft ist, selbst wenn Google neben der Bring-your-own-Option weiterhin eigene validierte Konnektoren anbietet.
Unterstützung für benutzerdefinierte MCP-Server
Ja, ein Kunde kann einen bestehenden MCP-Server in Gemini Enterprise einbinden, jedoch nur zu Bedingungen, die Google fest vorgegeben hat und die kaum Verhandlungsspielraum lassen.
Der Weg führt über den Datenspeicher "Custom MCP Server”, der innerhalb der App erstellt wird, und er verlangt strikte BYO-Sicherheit sowie die Einhaltung der Endpunktanforderungen, bevor irgendeine Verbindung zustande kommt.
- Hosten Sie den Server unter einer HTTPS-URL, die auf einen MCP-Pfad wie /mcp endet.
- Verwenden Sie ausschließlich StreamableHTTP, da SSE nicht unterstützt wird.
- Legen Sie ein öffentlich vertrauenswürdiges TLS-Zertifikat vor, da selbstsignierte Zertifikate abgelehnt werden.
Die Authentifizierung ist flexibel, und keine Authentifizierung funktioniert, wenn der Server keine benötigt. Die Einschränkungen sind jedoch real: kein Private Service Connect, keine VPC Service Controls in der Preview und die Nutzung nur im Agent Designer, nicht im Standard-Agenten.
Private Daten und Werkzeuge
Sobald der Server diese Endpunktregeln erfüllt, stellt sich die schwierigere Frage, was er tatsächlich freischaltet, und die Antwort lautet: private Daten und interne Tools, die die unternehmenskontrollierte Infrastruktur nie verlassen müssen. Ja, ein Unternehmen kann seinen eigenen MCP-Server mitbringen, und das ist für alle von Bedeutung, die es leid sind, auf das beschränkt zu sein, was ein Anbieter bereitstellt.
Die Verbindung ist jedoch kein Freifahrtschein. Die von Administratoren gesteuerte Aktivierung steht an erster Stelle, da die Funktion standardmäßig deaktiviert ist und eine Änderung der Organisationsrichtlinie erfordert. Administratoren fügen dann die Server-URL und die Authentifizierungseinstellungen hinzu, und Agenten können Tools entdecken und ausführen, die auf einer vom Unternehmen kontrollierten Infrastruktur gehostet werden. Eine berechtigungsbewusste Bereitstellung hält Datenbanken und Tools durch Zugriffskontrollen voneinander getrennt, sodass die Kontrolle bei der Organisation bleibt, nicht beim Modell selbst.
Validierte Connectors neben BYO
Zwei Integrationspfade existieren nebeneinander in Gemini Enterprise, und der Unterschied zwischen ihnen ist wichtiger, als es die meisten Anbieterpräsentationen zugeben. Validierte Konnektoren sind vorgefertigt, von Google getestet und für gängige Systeme paketiert, während BYO MCP für Organisationen gedacht ist, die nicht darauf warten wollen, dass ein Anbieter ihre Tools unterstützt. Ja, ein benutzerdefinierter MCP-Server kann eingebunden werden, aber nur über die Admin-Einstellungen.
- Validierte Konnektoren decken Google Workspace, Microsoft-Dienste, ServiceNow, Jira und Confluence ab und verringern so den Einrichtungsaufwand.
- BYO MCP erfordert eine öffentliche HTTPS-URL, den StreamableHTTP-Transport und ein öffentlich vertrauenswürdiges Zertifikat; selbstsignierte Zertifikate funktionieren nicht.
- Benutzerdefinierte MCP-Server erscheinen im Agent Designer, nicht im Standard-Agenten.
Freiheit gibt es hier, aber mit Leitplanken, und Teams sollten diese verstehen, bevor sie mit dem Bauen beginnen; sie zu ignorieren verschwendet die Zeit aller.
Wo passt OpenAPI 3.0 neben MCP hinein?
OpenAPI 3.0 und MCP werden oft in einen Topf geworfen, als müsste das eine das andere ersetzen, und diese Sichtweise ist falsch. OpenAPI beschreibt, was ein REST-Dienst leisten kann, während MCP festlegt, wie ein KI-Client diese Fähigkeiten als Tools erreicht. Das Contract Mapping verbindet beides, denn jede OpenAPI-Operation kann zu einem MCP-Tool werden, ohne dass ein einziger Backend-Dienst neu geschrieben werden muss.
Google Cloud und Microsoft dokumentieren diesen Weg und behandeln OpenAPI 3.x als die vorgelagerte Spezifikation. Teams, die REST-Endpunkte bereitstellen, behalten ihre Investitionen, wählen aus, welche Operationen sie bereitstellen, und vermeiden individuelle Integrationen für jedes Modell. Dies sind Interoperabilitätsschichten, keine konkurrierenden Standards, und sie als Konkurrenten zu betrachten, führt zu Lock-in. Entwerfen Sie den Vertrag in OpenAPI, stellen Sie ausgewählte Operationen über MCP bereit und behalten Sie die Kontrolle über Ihren Stack.
Wie verbindet sich Oracle mit Gemini Enterprise?
Oracles Hauptweg zu Gemini Enterprise ist der Oracle AI Database Agent, der über den Google Cloud Marketplace verfügbar ist und für Kunden von Oracle AI Database@Google Cloud entwickelt wurde. Diese können verwaltete Daten in natürlicher Sprache abfragen, ohne sie zu verschieben oder zu duplizieren. Die Einrichtung ist nicht einfach, da ein Datenbankadministrator zunächst die A2A-Kompatibilität aktivieren muss, ein Entwickler über REST-API-Schritte einen OAuth-Client registrieren muss und sich die Benutzer anschließend mit Oracle-Datenbankanmeldedaten authentifizieren müssen, nicht mit Google- oder OCI-Konten. Jede Aussage über eine Remote-MCP-Integration muss an diesem A2A-basierten Fundament gemessen werden, da die dokumentierte Verbindung den Agenten als benutzerdefinierten Agenten behandelt, und diese Unterscheidung bestimmt, worauf sich Oracle-Kunden tatsächlich verlassen können.
Oracle AI Database Agent
Unternehmensdaten mit einem KI-Assistenten zu verbinden, bedeutete lange, sie an einen anderen Ort zu kopieren , und Oracles Agent für Gemini Enterprise soll mit dieser Gewohnheit Schluss machen.
Der im Google Cloud Marketplace verfügbare Agent fungiert als sichere Brücke zwischen Gemini Enterprise und Oracle Autonomous AI Database, sodass Nutzer Daten dort abfragen, wo sie liegen , ohne Duplizierung und ohne SQL.
Die Anwendung erfolgt in drei Schritten:
- Administratoren fügen den Agent in Gemini Enterprise hinzu und erteilen anschließend Benutzerberechtigungen.
- Nutzer autorisieren sich einmalig, indem sie ihre Oracle-Datenbank-Zugangsdaten eingeben, nicht ihre Google- oder OCI-Logins.
- Der Agent interpretiert jede Anfrage und führt anschließend die passenden Abfragen innerhalb der Datenbank aus.
Das ist kontrollierter Zugriff, keine uneingeschränkte Offenlegung: Die Ausführung bleibt datenbanklokal, die Sicherheit bleibt auf Unternehmensniveau, und mehrstufige Automatisierung ersetzt einstufige Antworten , so behalten die Teams die Kontrolle.
Remote-MCP-Integration
Benutzerdefinierte Konnektoren sind seit Langem die Steuer auf Enterprise-KI, und Oracles Antwort an Gemini Enterprise besteht darin, diese nicht länger zu zahlen. Statt maßgeschneiderter Datenbank-Anbindungen stellt Oracle einen Remote-MCP-Server über Streaming-Endpunkte bereit, einen HTTPS-/mcp-Pfad, den Gemini Enterprise als kompatibler Client aufruft. Entwickler konfigurieren den Endpunkt, und zwar ohne zusätzliche Infrastruktur.
Eine private Service-URL, die auf /mcp endet, wird über einen benutzerdefinierten MCP-Server-Datenspeicher registriert und anschließend mit der Gemini-Enterprise-Anwendung verbunden. Google OAuth liefert die Autorisierungs- und Token-URLs, wobei im dokumentierten Ablauf PKCE und HTTP-Basic-Authentifizierung zum Einsatz kommen. Die Sicherheit der Token ist entscheidend, da Remote-Server ein Zugriffstoken im Autorisierungsfeld verlangen können. Sobald die Verbindung steht, lädt Gemini benutzerdefinierte Aktionen neu und nutzt die bereitgestellten Tools. Governance ist wichtig.
Wie beginnt man damit, seine Datenbanken zu verbinden?
Wie beginnt man, eine Datenbank in Gemini Enterprise einzubinden, ohne Stunden auf dem falschen Bildschirm zu verschwenden? Die Antwort beginnt auf der Seite "Gemini Enterprise” der Google Cloud Console, wo Teams ein Projekt auswählen und Datenspeicher öffnen und dabei frei in der Wahl ihres Wegs sind.
- Wählen Sie die Quelle aus, z. B. BigQuery, Cloud SQL, Spanner oder AlloyDB, und entscheiden Sie dann zwischen föderierten Abfragen, bei denen die Daten an Ort und Stelle bleiben, oder der Einrichtung der Datenaufnahme, bei der sie in einen Datenspeicher kopiert werden.
- Definieren Sie die genauen Tabellen, legen Sie die Zugriffssteuerung fest, wählen Sie einen Synchronisierungszeitplan und entscheiden Sie sich für eine von Google verwaltete Verschlüsselung oder eine Verschlüsselung mit Cloud KMS.
- Benennen Sie den Connector, wählen Sie eine Region, erstellen Sie den Datenspeicher und verknüpfen Sie ihn mit einer App.
Wenn Sie den App-Autorisierungsablauf überspringen, kommt alles zum Stillstand. Autorisieren Sie daher Gemini Enterprise, bevor Sie eine Abfrage ausführen.
