# Workspace governance and data
The moment you point Gemini at company data, the interesting question stops being "what can it do" and becomes "what is it allowed to see, and who decided that." Governance is not a footnote to a Gemini rollout. It is the rollout.
This lesson covers the controls that determine Gemini's reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.Voir la définition complète → inside Google Workspace: where the data boundary actually sits, how personal and Workspace accounts differ in ways that matter for compliance, and what an admin turns on or off. We will follow one company through a realistic deployment.
There is one distinction that explains almost every governance decision: a personal Google account versus a managed Workspace account.
When an employee uses Gemini at gemini.google.com while signed into a personal @gmail.com account, that is a consumer product governed by consumer terms. By default, those conversations may be reviewed by humans and used to improve Google's models. That is fine for a recipe. It is not fine for your unreleased pricing model.
A managed account is a user provisioned by your organization's Workspace admin (the @yourcompany.com identity). Here the rules invert. For Gemini in Workspace and the Gemini app accessed through a managed account, Google states that your data is not used to train or improve models outside your domain, is not reviewed by humans for that purpose, and stays within your existing Workspace data protections. Prompts, generated content, and the files Gemini reads inherit the same handling as the Doc or email itself.
The practical consequence: shadow usage on personal accounts is your real risk, not the official tool. People paste confidential text into a personal Gemini tab because it is convenient. The fix is to make the managed account the path of least resistance, and to block or discourage the personal one.
The official statement of these commitments lives in How Gemini for Google Workspace protects your data.
Gemini in Workspace does not get a master key. It operates as the signed-in user, with exactly that user's existing permissions. This single rule resolves most "can it leak data" fears.
When someone in Gmail asks Gemini to "summarize the latest thread from the finance team," Gemini can only read what that person could already open. When they use the side panel in Docs or Drive to ask "what did we decide about the Q3 launch," Gemini retrieves only files that user already has access to. It cannot surface a document they were never shared on.
This is also where governance gets uncomfortable. Gemini is a powerful *discovery* tool over data the user technically can access but never actually looked at. That over-shared folder from 2021 with everyone-in-domain access? A human never browsed it. Gemini will happily find it in two seconds.
So the real prep work for a Gemini rollout is not configuring Gemini. It is fixing your Drive permissions *before* you turn Gemini on. The tool does not create the exposure. It reveals the exposure you already had.
Workspace governance happens in the Admin console (admin.google.com), and Gemini is administered the way every other Google service is: through organizational units (OUs) and groups. An OU is a slice of your directory (say, "Legal" or "Interns") to which you apply different policy.
The admin can:
A common pattern: enable everything for a 200-person pilot OU, leave the other 4,000 users untouched, measure, then expand. Because policy is OU-scoped, this is a few clicks, not a migration.
For data governancedata governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.Voir la définition complète → proper, Gemini interactions sit inside existing Workspace controls. Data regions can pin data at rest to a geography. Vault retention and eDiscovery apply to relevant Gemini content the same way they apply to mail and Drive. DLP (data loss prevention) rules and Access Transparency continue to operate. You are not bolting on a new compliance stack. You are extending the one you already run.
Northwind has 3,000 Workspace users and a nervous legal team. Here is the sequence that actually worked.
1. Lock the personal-account leak first. Before announcing anything, the admin reduced the incentive for shadow usage by making the managed Gemini app available and communicating one rule: company data goes in the company tool, never a personal Gemini tab. (Workspace cannot technically block a personal Gmail login on a personal device, so policy plus a good first-party experience is the lever.)
2. Audit Drive sharing. Using Drive's security reports, they found 40,000 files shared "anyone in the company." Most were harmless. About 600 were not (salary letters, an M&A folder). They tightened those *before* enabling the Gemini side panel, because Gemini would otherwise make them trivially findable.
3. Pilot in one OU. They created a gemini-pilot group of 150 people across departments, enabled the Gemini app and Workspace features for it, and left Extensions to Gmail and Drive on, but disabled third-party-ish Extensions during the trial.
4. Watch the right signals. Vault was already capturing the relevant content for eDiscovery. They confirmed Gemini interactions fell under their existing retention rules and that nothing escaped their data region.
5. Build a governed Gem. Instead of letting everyone freelance prompts, they shipped a shared Gem (a saved, instruction-tuned configuration of Gemini) for the support team: "Northwind Support Assistant," with fixed instructions about tone, escalation, and never inventing policy. A Gem standardizes behavior so governance is about *one configured assistant*, not a thousand ad hoc prompts.
This ordering matters. Permissions first, pilot second, automation third.
Northwind's next phase moved beyond the human-in-the-loop side panel into automation, and that changes the governance picture.
Their ops team wanted a nightly job: read a Drive folder of delivery exception reports and produce a summary Doc. They built it with Apps Script, calling the Gemini API. The key governance shift: a script does not run "as the signed-in user" looking over someone's shoulder. It runs under whatever identity and key you give it, on a schedule, with no human reading each output.
That means three new responsibilities. Identity: the script runs as a specific user or service account, so its data access is that account's access. Scope it tightly. Key handling: the APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Voir la définition complète → key is a secret. It belongs in Script Properties or Secret Manager, never in source. Output review: automated summaries can hallucinate, so a generated Doc that drives decisions needs a human checkpoint.
import os
from google import genai
# Key from environment / secret manager, never hardcoded.
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()))Note the model choice. Flash is the fast, cost-efficient tier, right for high-volume summarization; Pro is the heavier-reasoning tier you reserve for complex analysis. The prompt is also a governance control: "list only facts present in the text" reduces fabricationfabricationA hallucination is when an AI model generates output that is fluent and confident but factually wrong, fabricated, or unsupported by its source data.Voir la définition complète →.
There is a deeper account distinction here too. Keys from Google AI Studio (aistudio.google.com) target the Gemini Developer APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Voir la définition complète →, great for prototyping. When Northwind productionizes, they will likely move to Vertex AI (cloud.google.com/vertex-ai), where the same models run under Google Cloud IAM, VPC controls, audit logging, and enterprise data-handling terms. For a workload touching company data, that governance surface is the reason to graduate from AI Studio to Vertex.
Vérification des acquis
1. According to the lesson, what is the single distinction that explains almost every Gemini governance decision in a company?
2. When an employee uses Gemini through a managed Workspace account, what does Google state about their data?
3. In Google Workspace, who is responsible for provisioning a managed account and configuring its Gemini controls?
4. Select ALL correct answers about the risks and behavior of personal Google accounts using Gemini described in the lesson.
Sélectionnez toutes les réponses correctes.
5. Select ALL correct answers about how data is handled for Gemini in Workspace via a managed account.
Sélectionnez toutes les réponses correctes.
One more governance question: when Gemini answers, *what did it use to answer*? For company data, the answer should be your data, not the open web, unless you intend otherwise.
In the Gemini app and via the side panel, Workspace content is the grounding source by design (constrained, again, by the user's permissions). When you call the APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Voir la définition complète →, grounding is a choice you make explicitly. You can enable grounding with Google Search so answers cite live web results, which is excellent for current facts and terrible if you need answers confined to internal policy.
The governance instinct: for an internal assistant, ground on *your* corpus (via your own retrieval, or Vertex AI's grounding on your data), and leave Search grounding off unless a use case genuinely needs the public web. Mixing the two without thought is how an "internal" assistant starts quoting a random blog as if it were company policy. Decide the source of truth per use case, and make it explicit in configuration rather than hoping the model picks correctly.
You can read the grounding options in the Gemini API grounding documentation.
Pull it together into one model you can hold in your head:
Almost every "is this safe" question maps cleanly onto one of those five.