The auditor asked one question and the room went quiet. Which of our services called Gemini with customer records last March, and what did the model send back? We had dashboards, we had latency graphs, we had a monthly bill. We did not have an answer, because the log that would have held it was never turned on. That gap is what this part is about, and it is cheaper to close than you think.

What governance covers on Google Cloud

Governance is a word that means nothing until you split it into jobs. On a Gemini workload it splits cleanly into three. First, audit: an automatic record of who called which model, when, from where, and with which method. Second, provenance: a way to prove after the fact that a given image, video, or paragraph came out of your AI and not somewhere else. Third, model governance: a controlled catalog of which model versions are approved, who approved them, and what they were evaluated against before they went live. Each job has a different Google Cloud service behind it, and none of the three is on by default in a useful state.

Sitting above the three is a frame worth naming. Google publishes the Secure AI Framework, or SAIF, a reference model for securing AI across its lifecycle. Its risk map breaks an AI system into four components, data, infrastructure, model, and application, and maps common risks onto each. You do not implement SAIF as a product. You use it as a checklist so you notice the layer you forgot. Google also publishes its AI Principles, a written commitment on fairness, privacy, security, and interpretability, which matters here for one practical reason: a written principle is the thing an auditor can hold you to, so treat it as a control, not a slogan.

Which audit logs you get, and which you have to ask for

Cloud Audit Logs is the Google Cloud service that records administrative and data activity across services, Vertex AI included. It writes four kinds of log, and the difference between them is the whole game. Admin Activity logs record configuration changes, deploying an endpoint, changing a quota, editing IAM, and they are always on and free and you cannot switch them off. System Event logs record actions Google systems take on your resources, also always on. Policy Denied logs record a call that a policy blocked, again always on. Those three arrive whether you plan for them or not.

The fourth kind is the one that matters for AI and the one that is off by default. Data Access logs record data-plane calls, and on Vertex AI that means the actual model invocations: generateContent, streamGenerateContent, and predict. Until you enable them, none of those calls leave a trace. Enable them and each call writes a record, and here is the detail people get wrong: the record holds metadata, not content. You get the caller identity, the model ID, the method, the timestamp, and the source, but not the prompt text and not the model response. That is deliberate, and it is usually what you want, because logging raw prompts and completions would rain sensitive data straight into your logging bucket. If you genuinely need the bodies for a use case, you log them yourself in the application, with redaction, and you treat that store as sensitive.

Turn on Data Access logs and route them to BigQuery

Two steps make the audit trail real. First, switch on Data Access logging for the Vertex AI service in your IAM policy so the calls get recorded. Second, route those logs to somewhere you can actually query and retain them, because the default logging bucket keeps entries for only 30 days and you cannot run a proper investigation against a tail that short. BigQuery is the usual sink: a log sink copies matching entries into a dataset you can query with SQL and keep for years. The command below enables Data Read logging on Vertex AI for a project, creates the sink, and shows the query you would run when the auditor comes back.

# 1. Read the current IAM policy, add a Data Read audit config for Vertex AI,
#    then set it back. Do this in the org policy for full coverage.
gcloud projects get-iam-policy PROJECT_ID --format=json > policy.json
# edit policy.json to add, under auditConfigs:
#   { 'service': 'aiplatform.googleapis.com',
#     'auditLogConfigs': [ { 'logType': 'DATA_READ' } ] }
gcloud projects set-iam-policy PROJECT_ID policy.json

# 2. Create a log sink that ships Vertex AI Data Access logs to BigQuery
gcloud logging sinks create vertex-audit-sink 
  bigquery.googleapis.com/projects/PROJECT_ID/datasets/ai_audit 
  --log-filter='resource.type="aiplatform.googleapis.com/Endpoint" AND
    logName:"cloudaudit.googleapis.com%2Fdata_access"'

# 3. Grant the sink service account write access to the dataset, then query it
SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail AS caller,
  protopayload_auditlog.methodName                        AS method,
  resource.labels.model_id                                AS model
FROM `PROJECT_ID.ai_audit.cloudaudit_googleapis_com_data_access_*`
WHERE protopayload_auditlog.methodName LIKE '%generateContent%'
ORDER BY timestamp DESC
LIMIT 50;

Expected output: after set-iam-policy returns the updated policy, new Gemini calls begin landing in the ai_audit dataset within a minute or two, and the query returns one row per model call with the caller email, the method, and the model ID. Failure mode: if you created the sink but skipped the dataset grant, the sink shows healthy but no rows ever arrive, because the sink service account cannot write. If the query returns nothing, confirm Data Read is actually set on aiplatform.googleapis.com and that traffic has flowed since you enabled it, since logging is not retroactive.

What audit logging actually costs

People leave Data Access logs off because they assume the logs are expensive. They are not. The metadata record for a model call is small, on the order of a couple of kilobytes, so even heavy traffic produces a modest volume, and Cloud Logging gives every project a monthly free ingestion allowance before it charges. The cost that does exist sits in long retention, and that lands in BigQuery storage, which is cheap. The real cost of audit logging is never the storage bill. It is the incident you cannot reconstruct because the switch was off. That is the trade worth internalizing.

Work it through. Take a workload doing 5 million Gemini calls a month, roughly 2 kilobytes of audit metadata each. That is about 10 gigabytes of audit logs a month. Held in BigQuery, the storage cost by retention horizon looks like this.

Governing the data before it reaches the model

Audit and provenance both look at a call after it happens. Data governance is the control that acts before, on what you let flow into the prompt in the first place, and it is the layer regulated teams care about most. Sensitive Data Protection, the service most people still call Cloud DLP, is Google Cloud’s inspection and de-identification engine. It can scan text for more than a hundred built-in infotypes, names, card numbers, national IDs, health identifiers, and either flag them or redact and tokenize them. Put it in front of a Gemini call and you strip the customer’s account number out of a support prompt before the model ever sees it, which shrinks both your leak surface and the scope of what your audit logs could ever expose. It pairs naturally with Model Armor from Part 14, one screening for policy and injection, the other for sensitive fields.

The second half of data governance is location. Where a prompt is processed and where its data comes to rest are separate promises, and both show up in audits. Vertex AI lets you pin generative processing to a region so a request from a Frankfurt workload is served in-region rather than routed somewhere cheaper, which is how you meet a data-residency commitment instead of hoping. Wrap the whole project in the service perimeter and customer-managed keys from Part 10, and residency, encryption, and access all answer to controls you can show rather than a support ticket you have to trust. The order I set these up in is redaction first, because a field that never enters the prompt is the one you never have to explain, then residency, then keys.

Proving an output came from your AI

Audit logs prove a call happened. They do not prove that a specific image or paragraph in the wild came from your model, and that is a separate question a governed workload eventually has to answer. Google’s answer is SynthID, an invisible watermark that DeepMind embeds directly into content generated by Gemini images, Veo video, Lyria audio, and Gemini text. The watermark rides inside the pixels or tokens rather than in a metadata tag, so it survives the things that strip metadata: screenshots, re-compression, cropping, format conversion, and a trip through a social platform. By mid 2026 Google reported it had marked well over 100 billion pieces of content this way.

The read side is SynthID Detector, a verification portal, with a lighter check now built into the Gemini app where you upload a file and ask whether Google AI made it. For a governed workload the value is provenance: when a piece of content is disputed, you have a technical basis for saying it did or did not come from your generation pipeline. Two caveats keep this honest. SynthID marks Google-generated content, so it tells you nothing about output from a model outside that family, and watermark detection is probabilistic, not a courtroom signature. Treat it as strong evidence, not proof. This pairs with the input-side controls from Part 14 on safety filters and Model Armor, which is where prompt injection and data-leak defense live.

Model governance and who Google can see

Model governance answers a question auditors love: who approved the model version running in production, and what did they check first. Vertex AI Model Registry is the catalog that makes this answerable. It tracks model versions, their lineage, and their aliases, so the endpoint serving traffic points at a named, versioned entry rather than a mystery binary. Attach a model card, a short structured document describing what a model is for, how it was evaluated, and its known limits, and you have written evidence of intent. Tie that to an evaluation gate from Part 23 on the Gen AI evaluation service so no version reaches production without a recorded score, and approval stops being a Slack thumbs-up and becomes a record.

The other half of governance is Google itself. Enterprises ask a fair question: can Google staff see my data. Access Transparency gives you near real-time logs of when Google personnel access your content and why, and Access Approval lets you require explicit sign-off before that access can happen at all. Combine those with the encryption and network controls from earlier parts, customer-managed keys and service perimeters, and you can answer the access question with logs instead of a policy PDF. The whole governed request path, input check to watermark to audit trail, looks like this.

flowchart LR
  U[User request] --> MA[Model Armor input check]
  MA -->|clean| G[Gemini on Vertex AI]
  MA -->|blocked| R[Reject and log]
  G --> SID[SynthID watermark on output]
  G --> AL[Data Access audit log]
  SID --> APP[Application response]
  AL --> BQ[BigQuery audit dataset]
  BQ --> REV[Governance review and reporting]
  R --> BQ

My governance baseline before a Gemini workload ships

Here is what I insist on before a Gemini workload touches real users, in priority order. Enable Data Access audit logs on Vertex AI at the org level and route them to BigQuery, because it is the one control you cannot add after the fact you need it for. Put every production model behind Model Registry with a card and a recorded evaluation, so approval is documented. Turn on Access Transparency, and Access Approval if your regulator expects it, so the Google-access question has a logged answer. Keep Model Armor on the input path and rely on SynthID for output provenance. That is four switches and one catalog, and none of them is exotic.

What I would not do is treat governance as a launch gate you clear once. It is a running control. Audit logs need retention policies and someone who reads them, model cards go stale, and Access Approval only helps if the on-call actually reviews the requests. If you build one thing this week, enable Data Access logging and the BigQuery sink today, so next month the record exists whether or not anyone has asked for it yet. From here, Part 28 on LLMOps and Vertex AI Pipelines shows how to bake these gates into the deployment pipeline so they run on every release instead of by memory. For how another cloud frames the same provenance problem, the AWS responsible AI and watermarking part is the closest comparison.

References

• Vertex AI audit logging information
• Google Secure AI Framework (SAIF)
• SynthID, Google DeepMind
• Cloud Audit Logs overview

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts