Benefits of Vertex AI Audit Logs for IT Service Management

The incident ticket says the assistant started giving odd answers at 02:10. The change log says nothing changed. Vertex AI audit logs settle that argument with evidence instead of memory, and the setup is short once you know which half is on by default.

What Vertex AI audit logs record by default

Google's Vertex AI audit logging page (now titled "Agent Platform audit logging information") describes three log types, all under the service name aiplatform.googleapis.com:

• Admin Activity: admin write operations such as endpoints.deployModel, models.upload and pipelineJobs.create. Always on, and you can't disable it.
• Data Access: admin reads, plus data reads and writes on user-provided data. Off by default, so nothing is written until you enable it.
• System Event: automated Google Cloud actions that change resource configuration. Always on.

Benefits of Vertex AI audit logs for service management

A change record nobody has to write. Admin Activity is always on, so deploying a model to an endpoint or creating a pipeline job leaves an entry with the caller's identity, even if nobody filed a ticket. When a change review asks who touched the endpoint before the incident, you run a query instead of interviewing people.

A real answer to "who called which endpoint, and when". Once Data Access logs are on, endpoints.predict, endpoints.rawPredict and endpoints.predictLongRunning are written as DATA_READ entries. "Someone is hammering the model" becomes a principal, a timestamp and a resource name you can paste into the incident record.

Evidence in a format auditors already know. These are standard Cloud Audit Logs: structured entries you can query in Logs Explorer, attach to a change or incident record, and route with a log sink to wherever your ITSM or SIEM tooling reads. Reading the Data Access stream needs the Private Logs Viewer role (roles/logging.privateLogViewer), so you can limit it to the people who need it.

A clean split between "who" and "what was said". Audit logs record the call, not the conversation. Request-response logging fills that gap by sampling full requests and responses into BigQuery. You choose the sampling rate, so you collect content only where an incident review needs it.

Turn on Data Access audit logs for Vertex AI

In the console, open IAM & Admin, then Audit Logs, pick the project, select the Vertex AI service and tick the log types. Google's Data Access configuration guide also shows the CLI route: read the IAM policy, edit only the auditConfigs block, write it back.

gcloud projects get-iam-policy <your-project-id> > /tmp/policy.yaml
# edit /tmp/policy.yaml: add the block below, keep bindings and etag
gcloud projects set-iam-policy <your-project-id> /tmp/policy.yaml

auditConfigs:
- auditLogConfigs:
  - logType: ADMIN_READ
  - logType: DATA_READ
  - logType: DATA_WRITE
  service: aiplatform.googleapis.com

Leave bindings and etag untouched: Google warns that dropping bindings can lock every principal out of the project. You need resourcemanager.projects.setIamPolicy to write the change.

Make one test call, then check it arrived in Logs Explorer:

protoPayload.serviceName="aiplatform.googleapis.com"
logName:"cloudaudit.googleapis.com%2Fdata_access"

The documented DATA_READ list names predict-style methods, so test the exact API your apps use (for example Gemini's generateContent) before you promise auditors coverage.

Add Vertex AI request-response logging for the content

This feature is in Preview. It covers Gemini models called through generateContent or streamGenerateContent, and Anthropic Claude through rawPredict or streamRawPredict (REST only for Claude). The call below turns it on for a Gemini model, logging 10% of requests to BigQuery:

curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json; charset=utf-8" \
  -d '{
    "publisherModelConfig": {
      "loggingConfig": {
        "enabled": true,
        "samplingRate": 0.1,
        "bigqueryDestination": {"outputUri": "bq://<your-project-id>.<dataset>.<table>"}
      }
    }
  }' \
  "https://us-central1-aiplatform.googleapis.com/v1beta1/projects/<your-project-id>/locations/us-central1/publishers/google/models/<model-id>:setPublisherModelConfig"

Changes can take a few minutes to apply. With a regional endpoint and only a project ID, Google creates the dataset for you; on the global endpoint the dataset must already exist. If you omit the table name, rows go to request_response_logging. Then pull the window around the incident:

SELECT logging_time, model, api_method, full_request, full_response
FROM `<your-project-id>.<dataset>.request_response_logging`
WHERE logging_time BETWEEN TIMESTAMP('<incident-start>') AND TIMESTAMP('<incident-end>')
ORDER BY logging_time;

When it's not worth it

• Low-stakes prototypes. Admin Activity is already on. Google notes Data Access logs can be high in volume and may add Cloud Logging charges, so skip them until someone actually needs call-level evidence.
• Sensitive prompts. Request-response logging copies full prompts and responses into BigQuery, which makes a new store of personal data or customer secrets. Sample low, lock down the dataset, and restrict the aiplatform.endpoints.setPublisherModelConfig permission so nobody switches it on unnoticed. Pairs over BigQuery's 10 MB row limit aren't recorded at all.

Gotchas

• Gemini Enterprise has its own trail under a different service name, discoveryengine.googleapis.com. Filter on protoPayload.serviceName="discoveryengine.googleapis.com", as shown in the Gemini Enterprise audit logging docs. Its separate usage audit logs are a different feature again.
• Data Access logs land in the _Default bucket unless you route them elsewhere, so check that retention matches your record-keeping policy.

If you run AI in production, turning these on before the first incident is what lets you answer who, which endpoint and when while the ticket is still open.