+150 XP

Workspace Governance und Daten

# Workspace Governance und Daten

Sobald Sie Gemini auf Unternehmensdaten richten, lautet die interessante Frage nicht mehr „was kann es", sondern „was darf es sehen, und wer hat das entschieden". Governance ist keine Fußnote eines Gemini-Rollouts. Sie ist der Rollout.

Diese Lektion behandelt die Kontrollen, die Geminis Reichweite in Google Workspace bestimmen: wo die Datengrenze tatsächlich verläuft, wie sich persönliche und Workspace-Konten in compliance-relevanter Weise unterscheiden, und was ein Admin ein- oder ausschaltet. Wir begleiten ein Unternehmen durch ein realistisches Deployment.

Die Grenze, auf die es wirklich ankommt

Eine Unterscheidung erklärt fast jede Governance-Entscheidung: ein persönliches Google-Konto versus ein verwaltetes Workspace-Konto.

Wenn ein Mitarbeiter Gemini unter gemini.google.com nutzt und dabei in einem persönlichen @gmail.com-Konto angemeldet ist, handelt es sich um ein Consumer-Produkt unter Consumer-Bedingungen. Standardmäßig können diese Konversationen von Menschen geprüft und zur Verbesserung der Google-Modelle verwendet werden. Für ein Kochrezept ist das in Ordnung. Für Ihr unveröffentlichtes Pricing-Modell nicht.

Ein verwaltetes Konto ist ein Nutzer, der vom Workspace-Admin Ihrer Organisation bereitgestellt wurde (die @ihrunternehmen.com-Identität). Hier kehren sich die Regeln um. Für Gemini in Workspace und die Gemini-App über ein verwaltetes Konto erklärt Google, dass Ihre Daten nicht zum Trainieren oder Verbessern von Modellen außerhalb Ihrer Domain verwendet, nicht zu diesem Zweck von Menschen geprüft werden und innerhalb Ihrer bestehenden Workspace-Datenschutzmaßnahmen bleiben. Prompts, generierte Inhalte und die Dateien, die Gemini liest, erben dieselbe Behandlung wie das Doc oder die E-Mail selbst.

Die praktische Folge: Ihr echtes Risiko ist die Shadow-Nutzung über persönliche Konten, nicht das offizielle Tool. Leute kopieren vertraulichen Text in einen persönlichen Gemini-Tab, weil es bequem ist. Die Lösung besteht darin, das verwaltete Konto zum Weg des geringsten Widerstands zu machen und das persönliche zu blockieren oder unattraktiv zu machen.

Die offizielle Darstellung dieser Zusagen findet sich in How Gemini for Google Workspace protects your data.

Was Gemini sehen kann (und die Regel, die es begrenzt)

Gemini in Workspace erhält keinen Generalschlüssel. Es arbeitet als der angemeldete Nutzer, mit genau dessen bestehenden Berechtigungen. Diese eine Regel löst die meisten Sorgen um „kann es Daten leaken" auf.

Wenn jemand in Gmail Gemini bittet, „den letzten Thread des Finance-Teams zusammenzufassen", kann Gemini nur lesen, was diese Person schon selbst öffnen könnte. Nutzt sie das Seitenpanel in Docs oder Drive für die Frage „was haben wir zum Q3-Launch entschieden", ruft Gemini nur Dateien ab, auf die dieser Nutzer bereits Zugriff hat. Ein Dokument, das nie mit ihm geteilt wurde, kann es nicht hervorholen.

An dieser Stelle wird Governance auch unangenehm. Gemini ist ein mächtiges *Discovery*-Tool über Daten, auf die der Nutzer technisch zugreifen darf, die er aber nie angesehen hat. Dieser überteilte Ordner aus 2021 mit Zugriff für alle in der Domain? Kein Mensch hat ihn je durchstöbert. Gemini findet ihn bereitwillig in zwei Sekunden.

Die eigentliche Vorarbeit für einen Gemini-Rollout ist also nicht, Gemini zu konfigurieren. Es ist, Ihre Drive-Berechtigungen zu bereinigen, *bevor* Sie Gemini einschalten. Das Tool erzeugt die Exposition nicht. Es zeigt die Exposition, die Sie bereits hatten.

Die tatsächlichen Kontrollen des Admins

Workspace Governance findet in der Admin-Konsole (admin.google.com) statt, und Gemini wird verwaltet wie jeder andere Google-Service: über Organisationseinheiten (OUs) und Gruppen. Eine OU ist ein Ausschnitt Ihres Verzeichnisses (etwa „Legal" oder „Praktikanten"), auf den Sie abweichende Policy anwenden.

Der Admin kann:

  • Die Gemini-App pro OU oder Gruppe ein- oder ausschalten.
  • Steuern, ob Gemini in den Workspace-Apps (Seitenpanel, „Hilf mir beim Schreiben", Meet-Funktionen) verfügbar ist, und für wen.
  • Gemini Extensions regeln, die der Gemini-App Zugriff auf Workspace-Daten (Gmail, Drive, Docs), Maps, Flights und mehr geben. Jede Verbindung ist eine explizite Fläche, die man erlauben oder einschränken kann.
  • Alpha-/Beta-Feature-Zugriff verwalten, sodass eine Pilotgruppe neue Funktionen vor dem gesamten Unternehmen erhält.

Ein übliches Muster: alles für eine Pilot-OU mit 200 Personen aktivieren, die anderen 4.000 Nutzer unberührt lassen, messen, dann ausweiten. Weil Policy OU-bezogen ist, sind das ein paar Klicks, keine Migration.

Für Data Governance im engeren Sinn liegen Gemini-Interaktionen innerhalb der bestehenden Workspace-Kontrollen. Datenregionen können Daten im Ruhezustand an eine Geografie binden. Vault-Aufbewahrung und eDiscovery gelten für relevante Gemini-Inhalte genauso wie für Mail und Drive. DLP-Regeln (Data Loss Prevention) und Access Transparency arbeiten weiter. Sie schrauben keinen neuen Compliance-Stack an. Sie erweitern den, den Sie schon betreiben.

Ein konkreter Rollout: Northwind Logistics

Northwind hat 3.000 Workspace-Nutzer und ein nervöses Legal-Team. Hier die Reihenfolge, die tatsächlich funktioniert hat.

1. Zuerst das Leck über persönliche Konten schließen. Bevor überhaupt etwas angekündigt wurde, reduzierte der Admin den Anreiz für Shadow-Nutzung, indem er die verwaltete Gemini-App verfügbar machte und eine Regel kommunizierte: Unternehmensdaten gehören ins Unternehmenstool, nie in einen persönlichen Gemini-Tab. (Workspace kann einen persönlichen Gmail-Login auf einem privaten Gerät technisch nicht blockieren, also sind Policy plus eine gute First-Party-Experience der Hebel.)

2. Drive-Sharing auditieren. Mit den Sicherheitsberichten von Drive fanden sie 40.000 Dateien, die mit „jeder im Unternehmen" geteilt waren. Die meisten waren harmlos. Rund 600 nicht (Gehaltsschreiben, ein M&A-Ordner). Die zogen sie an, *bevor* sie das Gemini-Seitenpanel aktivierten, weil Gemini sie sonst trivial auffindbar gemacht hätte.

3. Pilot in einer OU. Sie bildeten eine Gruppe gemini-pilot mit 150 Personen aus verschiedenen Abteilungen, aktivierten dafür die Gemini-App und die Workspace-Funktionen, ließen die Extensions zu Gmail und Drive an, deaktivierten aber während des Tests die eher drittanbieterartigen Extensions.

4. Die richtigen Signale beobachten. Vault erfasste die relevanten Inhalte für eDiscovery bereits. Sie bestätigten, dass Gemini-Interaktionen unter ihre bestehenden Aufbewahrungsregeln fielen und nichts ihre Datenregion verließ.

5. Ein governanced Gem bauen. Statt jeden frei Prompts basteln zu lassen, lieferten sie ein geteiltes Gem aus (eine gespeicherte, instruktionsgetunte Gemini-Konfiguration) für das Support-Team: „Northwind Support Assistant", mit festen Anweisungen zu Tonalität, Eskalation und dem Verbot, Policy zu erfinden. Ein Gem standardisiert das Verhalten, sodass Governance sich auf *einen konfigurierten Assistenten* bezieht und nicht auf tausend Ad-hoc-Prompts.

Diese Reihenfolge ist wichtig. Berechtigungen zuerst, Pilot als Zweites, Automatisierung als Drittes.

Manage Gemini for Google Workspace in the Admin console

Watch on YouTube

Wenn Automatisierung dazukommt: Apps Script und die API

Northwinds nächste Phase ging über das Seitenpanel mit Human-in-the-Loop hinaus in Richtung Automatisierung, und das verändert das Governance-Bild.

Das Ops-Team wollte einen nächtlichen Job: einen Drive-Ordner mit Berichten zu Lieferabweichungen lesen und ein Summary-Doc erzeugen. Gebaut haben sie das mit Apps Script, das die Gemini API aufruft. Der entscheidende Governance-Unterschied: Ein Skript läuft nicht „als der angemeldete Nutzer", der jemandem über die Schulter schaut. Es läuft unter der Identität und dem Key, die Sie ihm geben, nach Zeitplan, ohne dass ein Mensch jeden Output liest.

Das bedeutet drei neue Verantwortlichkeiten. Identität: Das Skript läuft als bestimmter Nutzer oder Service Account, also ist sein Datenzugriff der Zugriff dieses Kontos. Eng scopen. Key-Handling: Der API-Key ist ein Secret. Er gehört in Script Properties oder Secret Manager, nie in den Quellcode. Output-Review: Automatisierte Summaries können halluzinieren, also braucht ein generiertes Doc, das Entscheidungen steuert, einen menschlichen Checkpoint.

python
import os
from google import genai

# Key aus Environment / Secret Manager, niemals hartkodiert.
client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])

def summarize_exceptions(report_text: str) -> str:
    response = client.models.generate_content(
        model="gemini-2.5-flash",
        contents=(
            "Summarize these delivery exceptions for an ops manager. "
            "List only facts present in the text. Do not infer causes.\n\n"
            f"{report_text}"
        ),
    )
    return response.text

if __name__ == "__main__":
    with open("exceptions.txt") as f:
        print(summarize_exceptions(f.read()))

Beachten Sie die Modellwahl. Flash ist die schnelle, kosteneffiziente Stufe, richtig für Summarization in hohem Volumen; Pro ist die Stufe mit schwererem Reasoning, die Sie für komplexe Analysen reservieren. Der Prompt ist ebenfalls eine Governance-Kontrolle: „list only facts present in the text" reduziert Erfindungen.

Es gibt hier noch eine tiefere Kontounterscheidung. Keys aus Google AI Studio (aistudio.google.com) zielen auf die Gemini Developer API, ideal fürs Prototyping. Wenn Northwind in Produktion geht, werden sie wahrscheinlich zu Vertex AI (cloud.google.com/vertex-ai) wechseln, wo dieselben Modelle unter Google Cloud IAM, VPC-Kontrollen, Audit-Logging und Enterprise-Bedingungen zur Datenverarbeitung laufen. Für eine Workload, die Unternehmensdaten berührt, ist genau diese Governance-Fläche der Grund, von AI Studio auf Vertex zu wechseln.

Wissenscheck

1. Welche einzelne Unterscheidung erklärt laut der Lektion fast jede Governance-Entscheidung beim Deployment von Gemini?

2. Die Lektion argumentiert, dass das größte tatsächliche Governance-Risiko nicht das offizielle Tool, sondern „Shadow-Nutzung" ist. Was wird dagegen empfohlen?

3. Wenn ein Mitarbeiter Gemini in Workspace bittet, „den letzten Thread des Finance-Teams zusammenzufassen", was bestimmt, was Gemini tatsächlich lesen kann?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Aussagen, die korrekt beschreiben, wie Daten bei einem verwalteten Workspace-Konto mit Gemini behandelt werden. (Wählen Sie ALLE richtigen Antworten)

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Gründe, warum die Nutzung von Gemini über ein persönliches @gmail.com-Konto für Unternehmensdaten riskant ist. (Wählen Sie ALLE richtigen Antworten)

Wählen Sie alle richtigen Antworten aus.

Grounding, und woher die Antwort kommt

Noch eine Governance-Frage: Wenn Gemini antwortet, *womit* hat es geantwortet? Bei Unternehmensdaten sollte die Antwort Ihre Daten sein, nicht das offene Web, sofern Sie es nicht anders beabsichtigen.

In der Gemini-App und über das Seitenpanel sind Workspace-Inhalte per Design die Grounding-Quelle (wieder begrenzt durch die Berechtigungen des Nutzers). Wenn Sie die API aufrufen, ist Grounding eine Entscheidung, die Sie explizit treffen. Sie können Grounding with Google Search aktivieren, sodass Antworten aktuelle Web-Ergebnisse zitieren, was für aktuelle Fakten hervorragend und für Antworten, die auf interne Policy beschränkt sein müssen, furchtbar ist.

Der Governance-Instinkt: Für einen internen Assistenten grounden Sie auf *Ihrem* Korpus (über eigenes Retrieval oder Vertex AIs Grounding auf Ihren Daten) und lassen Search-Grounding aus, sofern ein Use Case das öffentliche Web nicht wirklich braucht. Beides unbedacht zu mischen ist der Weg, auf dem ein „interner" Assistent anfängt, einen beliebigen Blog zu zitieren, als wäre es Unternehmensrichtlinie. Entscheiden Sie die Source of Truth pro Use Case und machen Sie sie in der Konfiguration explizit, statt zu hoffen, dass das Modell richtig wählt.

Die Grounding-Optionen können Sie in der Gemini API grounding documentation nachlesen.

Das mentale Modell für Governance

Alles zusammengefasst in ein Modell, das Sie im Kopf behalten können:

  • Kontotyp legt den Standardvertrag zur Datenverarbeitung fest (persönlich = Consumer-Bedingungen; verwaltet = Ihre Workspace-Schutzmaßnahmen).
  • Nutzerberechtigungen legen fest, was ein interaktives Gemini sehen kann (es handelt als der Nutzer, nie über ihm).
  • Admin-Policy auf OU-/Gruppenebene legt fest, wer welche Gemini-Funktionen und Extensions erhält.
  • Bestehende Workspace-Kontrollen (Vault, DLP, Datenregionen) erstrecken sich automatisch auf Gemini.
  • Automatisierung (Apps Script, API, Vertex) bringt Sie weg von „handelt als der Nutzer" und hin zu expliziter Identität, Secrets und Output-Review.

Fast jede Frage nach dem Motto „ist das sicher" lässt sich klar einem dieser fünf Punkte zuordnen.

Key Takeaways

  • Bereinigen Sie Drive-Berechtigungen, bevor Sie Gemini aktivieren. Das Tool zeigt bestehendes Over-Sharing, es erzeugt es nicht. Auditieren Sie zuerst Dateien mit „jeder im Unternehmen".
  • Machen Sie das verwaltete Konto einfacher als das persönliche. Ihr echtes Leak-Risiko sind Mitarbeiter, die vertrauliche Daten unter Consumer-Bedingungen in einen persönlichen Gemini-Tab kopieren.
  • Regeln Sie über OUs und Gruppen und piloten Sie klein. Aktivieren Sie Gemini für eine gemischte OU, messen Sie gegen Vault und Ihre Datenregions-Einstellungen, dann weiten Sie aus.
  • Behandeln Sie Automatisierung als eigene Risikoklasse. API- und Apps-Script-Jobs laufen unter einer Identität, die Sie wählen, mit Secrets, die Sie schützen müssen, und Outputs, die ein Mensch prüfen sollte.
  • Wechseln Sie für Produktion zu Vertex AI. AI-Studio-Keys sind fürs Prototyping; Vertex gibt Ihnen IAM, Audit-Logs und Enterprise-Datenbedingungen für Workloads, die Unternehmensdaten berühren.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

  • Berechtigungen für zu breit geteilte Drive-Dateien prüfen und korrigieren, bevor Gemini aktiviert wird
Vollständiges Action Playbook ansehen

Verwandte Artikel

Aktuelle Blogartikel, die auf dieser Lektion aufbauen.