Gemini Enterprise Compliance Rests on Evidence You Generate Yourself
Google documents that Gemini for Google Cloud does not use customer prompts or responses to train its models, and that prompt data is encrypted in transit to the underlying model. Those are provider-side commitments. A compliance file still needs enterprise-side evidence: which identity sent which prompt, what data class it carried, which policy was in force and what the decision was. This article separates the two and shows what each regime asks for.
Google's data governance documentation for Gemini for Google Cloud states plainly that "Gemini doesn't use your prompts or its responses as data to train its models," and that when you submit a prompt "your data is encrypted in-transit as input to the underlying model in Gemini." Those commitments answer a procurement question. Gemini Enterprise compliance asks a different one, because an auditor reviewing an AI control is looking for records of what your people and agents actually did with the service.
The division of labour splits at the wire. Google is accountable for how the service handles data it receives. The enterprise is accountable for which identities were allowed to send that data, what was in it and whether a policy was applied before it left.
TL;DR
- Google documents that Gemini for Google Cloud does not train on customer prompts or responses, with a narrow exception for the Trusted Tester Program, where shared data is used for product improvements.
- Provider commitments cover the provider side. Identity, data classification and per-request policy evidence remain the enterprise obligation.
- Build the compliance file around request records that name the user or agent, the data class, the destination model and the decision.
- Keep Gemini traffic from managed enterprise paths separate from personal Google accounts in any coverage claim.
What Google documents and what it leaves to you
The Gemini for Google Cloud data governance page defines prompts as "the questions that you ask Gemini, including any input information or code that you submit to Gemini to analyze or complete," and responses as the answers or code completions returned. Against that definition it sets out the training commitment and the in-transit encryption behavior. It also names one exception: participants in the Gemini for Google Cloud Trusted Tester Program can optionally share data, and that data is used for product improvements rather than model training.
Read as a control narrative, that document discharges a specific risk: secondary use of customer content by the provider. It says nothing about whether the finance analyst in your organization was authorized to paste a customer list into a prompt last Tuesday. No provider document can, because the provider never sees your role model.
The AI governance framework sets out the ownership split in general terms. For a Google deployment the practical version is that provider attestations go in the vendor file and request evidence goes in the control file.
The regimes ask about requests, not vendors
EU AI Act Article 12 requires automatic recording of events over the lifetime of a high-risk system so that operation is traceable, including the period of use, the input data and identification of the natural persons involved. A vendor attestation does not produce any of those three fields. They exist only in records created at the point the request was made.
The NIST AI Risk Management Framework organizes the same work under GOVERN, MAP, MEASURE and MANAGE. MEASURE asks for evidence that controls operate, which in practice means a test population, an execution date and a result. MANAGE asks for documented treatment of identified risk, which means a named owner and a closure condition.
AI audit trail requirements by regulation lays out which fields each regime names. The pattern holds across them: identity, time, input, decision and retention.
Four fields that carry most of the weight
A per-request record for Gemini traffic earns its place in an audit when it carries four things. The first is the authenticated identity of the user or agent that issued the request, taken from the enterprise directory rather than a shared service account. The second is a classification of the content in the prompt, evaluated before the request left. Third comes the resolved destination, which distinguishes a managed Gemini endpoint from a personal browser session. Last is the policy version and outcome, so a reviewer can tell whether the control was in force at that moment.
Picture the audit room version of this. An examiner points at one line in a sample and asks who sent it and under what rule. A dashboard showing "Gemini: enabled" answers neither question, and I have never seen that slide survive a second follow-up.
AI policy enforcement at the HTTP layer describes where those fields can be captured on managed request paths.
Shared service accounts destroy the identity field
The most common way a Gemini compliance file fails is architectural rather than procedural. An internal application authenticates to Google with one service account and sends every user's prompts through it. The provider-side logs then attribute all traffic to that single principal, and the natural-person identification that Article 12 asks for never existed anywhere.
Fixing this means the calling application attaches the end-user identity to each request and an enforcement point records it alongside the decision. Retrofitting identity after the fact is not possible, because the information was discarded at the moment of the call.
The same defect undermines data-subject access requests under GDPR. Answering "what did this person submit to an AI system" requires a per-person index that a shared credential prevents you from building.
Coverage claims need a named denominator
A statement like "all Gemini use is governed" is only meaningful with a population attached. Define the population as managed enterprise routes to Gemini endpoints registered to named business services. Then state how many of those are forced through the enforcement point, how that was tested and on what date.
Exclusions belong in the same paragraph as the number. Personal Google accounts reached through a browser, Gemini features embedded inside third-party SaaS products and any direct calls that bypass the managed route are separate populations with separate evidence. Google Gemini Enterprise security covers the control surface, and Google Gemini Enterprise audit logs covers what the platform's own logging does and does not include.
DeepInspect
DeepInspect is a stateless proxy for authenticated HTTP traffic between enterprise users or agents and LLM endpoints, including Gemini. It evaluates application-supplied identity, request classification, approved destination and policy before forwarding, and it writes a signed per-decision record outside the calling application's write path.
For a Gemini deployment, that produces the enterprise-side half of the compliance file: who asked, what the request carried, which endpoint received it and which rule decided. DeepInspect does not replace Google's own attestations, and it leaves personal account use, SaaS-embedded inference, model quality and contractual terms with the enterprise and its suppliers. Book a demo today.
Frequently asked questions
- Does Google train on Gemini Enterprise prompts?
Google's data governance documentation states that Gemini does not use customer prompts or responses as training data for its models. The documented exception is the Gemini for Google Cloud Trusted Tester Program, where participants can optionally share data that is used for product improvements rather than model training. Confirm which program and contract terms apply to your tenant, and file the documentation reference with the vendor assessment.
- Are Google's platform logs enough for an AI audit?
They cover administrative and service-level activity in the Google environment. An AI control audit also asks for the end-user identity behind each prompt, the data classification applied before the request left your network and the policy decision that permitted it. Those three originate on the enterprise side of the boundary, so they need a record created there.
- How should shadow Gemini use be reported?
As a separate exposure population, not as a gap in the managed coverage number. Identify personal account usage through network and endpoint telemetry, report the count and the detection method, and track remediation as its own item. Mixing the two populations into one percentage conceals the part that lacks request-level evidence.
- What evidence closes an Article 12 finding?
A sample of per-request records covering the period under review, each naming the natural person or agent identity, the timestamp, the input classification, the destination model and the policy outcome, plus the retention configuration and the test that confirmed records were being written during that period.