当 Gemini Enterprise 从小范围试用扩展到全公司时，管理难题会迅速变化：团队不再只关心“有多少人在用”，还需要回答哪些部门在创建自定义智能体、NotebookLM 是否真正进入工作流、企业数据被如何检索，以及某次安全拦截究竟由什么内容触发。
产品内置仪表板适合观察日常采用率和活跃用户，但组织级治理往往需要关联 HR、部门、成本中心和安全数据。将 Gemini Enterprise 遥测通过 Cloud Logging 持续写入 BigQuery，再补充批量导出的席位与参与度指标，可以建立一套可查询、可审计、可扩展的分析底座。
两条管道，解决两类问题
完整方案不是把所有数据塞进一张宽表，而是保留两种不同节奏的数据流。
流式日志管道负责细粒度事件，包括用户提示词、模型响应、结束原因、身份信息和 grounding 文件访问路径。这类数据适合安全调查、行为分析和逐次交互取证。
批量指标管道通过 analytics:exportMetrics API 定期拉取预聚合数据，例如过去 30 天的席位购买、席位领取和参与度指标。这类数据适合管理层仪表板、采用趋势和成本分析。由于导出是异步的，生产环境应把它实现成每日调度任务，并记录任务状态、重试次数与数据日期。
BigQuery 中需要重点关注的遥测包括：
| 数据类别 | 典型目标表 | 用途 |
|---|---|---|
| 用户消息 | discoveryengine_googleapis_com_gen_ai_user_message |
用户输入的原始提示词 |
| 模型选择与响应 | discoveryengine_googleapis_com_gen_ai_choice |
模型响应、结束原因和推理相关字段 |
| 用户活动 | discoveryengine_googleapis_com_gemini_enterprise_user_activity |
IAM 身份和 grounding 文件访问路径 |
| 管理活动审计 | cloudaudit_googleapis_com_activity |
智能体创建、更新、删除等控制面变更 |
| 数据访问审计 | cloudaudit_googleapis_com_data_access |
搜索、读取和连接器查询等数据面操作 |
| 聚合指标 | 自定义批量导出表 | 席位、采用率和近 30 天参与度 |
实际表名可能受到 BigQuery 数据集、日志接收器及导出方式影响，部署后应先检查目标数据集中的真实表名和分区字段，再固化查询。
可以这样实践：配置连续日志接收器
下面的命令可以作为部署起点。运行前修改项目 ID、数据集名称和区域，并确保目标数据集已经创建。命令使用项目级 Log Router sink；如果日志来自多个项目，可以进一步改为文件夹级或组织级聚合接收器。
#!/usr/bin/env bash
set -euo pipefail
PROJECT_ID="your-project-id"
DATASET="gemini_enterprise_logs"
LOCATION="US"
bq --location="${LOCATION}" mk \
--dataset \
--description="Gemini Enterprise telemetry and audit logs" \
"${PROJECT_ID}:${DATASET}"
RUNTIME_FILTER='logName="projects/'"${PROJECT_ID}"'/logs/discoveryengine.googleapis.com%2Fgemini_enterprise_user_activity" OR
logName="projects/'"${PROJECT_ID}"'/logs/discoveryengine.googleapis.com%2Fgen_ai.user.message" OR
logName="projects/'"${PROJECT_ID}"'/logs/discoveryengine.googleapis.com%2Fgen_ai.choice"'
gcloud logging sinks create gemini-enterprise-runtime \
"bigquery.googleapis.com/projects/${PROJECT_ID}/datasets/${DATASET}" \
--project="${PROJECT_ID}" \
--log-filter="${RUNTIME_FILTER}" \
--use-partitioned-tables
AUDIT_FILTER='logName:"projects/'"${PROJECT_ID}"'/logs/cloudaudit.googleapis.com" AND
protoPayload.serviceName="discoveryengine.googleapis.com"'
gcloud logging sinks create gemini-enterprise-audit \
"bigquery.googleapis.com/projects/${PROJECT_ID}/datasets/${DATASET}" \
--project="${PROJECT_ID}" \
--log-filter="${AUDIT_FILTER}" \
--use-partitioned-tables
创建接收器后，Cloud Logging 会返回每个 sink 的 writer identity。必须把对应服务账号授予数据集写入权限，否则接收器存在但不会成功落表：
PROJECT_ID="your-project-id"
DATASET="gemini_enterprise_logs"
for SINK in gemini-enterprise-runtime gemini-enterprise-audit; do
WRITER_ID=$(gcloud logging sinks describe "${SINK}" \
--project="${PROJECT_ID}" \
--format='value(writerIdentity)')
bq add-iam-policy-binding "${PROJECT_ID}:${DATASET}" \
--member="${WRITER_ID}" \
--role="roles/bigquery.dataEditor"
done
还要在 Gemini Enterprise 管理控制台启用提示词与响应日志。Admin Activity 日志默认启用，但 Discovery Engine API 的 Data Access 日志默认可能未开启，需要在 IAM 审计日志配置中显式启用。启用后日志量和成本会上升，因此应先确定审计范围、保留期限及访问责任人。
从原始遥测变成组织指标
日志入库只是第一步。真正有价值的模型通常会加入一张受控的员工维表，例如 governance.employee_directory，包含员工邮箱、部门、成本中心和在职状态。该表应来自经过授权的 HR 数据管道，而不是临时上传的电子表格。
由于日志载荷可能使用 jsonPayload、protoPayload 或嵌套 RECORD，下面先用 BigQuery 元数据确认字段，而不是直接猜测结构：
SELECT
table_name,
column_name,
data_type
FROM `your-project-id.gemini_enterprise_logs.INFORMATION_SCHEMA.COLUMNS`
WHERE table_name LIKE '%gemini%'
OR table_name LIKE '%gen_ai%'
OR table_name LIKE '%cloudaudit%'
ORDER BY table_name, ordinal_position;
确认字段路径后，可以这样构建部门采用率。以下是可改造模板，假设用户活动表具有 timestamp 和 jsonPayload，其中邮箱位于 userIamPrincipal；请根据上一步得到的真实 schema 调整 JSON 路径：
-- Assumption: jsonPayload.userIamPrincipal contains the employee email.
WITH activity AS (
SELECT
DATE(timestamp) AS activity_date,
JSON_VALUE(TO_JSON(jsonPayload), '$.userIamPrincipal') AS user_email
FROM `your-project-id.gemini_enterprise_logs.discoveryengine_googleapis_com_gemini_enterprise_user_activity`
WHERE DATE(timestamp) >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
),
active_users AS (
SELECT DISTINCT activity_date, user_email
FROM activity
WHERE user_email IS NOT NULL
)
SELECT
e.department,
COUNT(DISTINCT a.user_email) AS active_users_30d,
COUNT(DISTINCT e.employee_email) AS employee_count,
SAFE_DIVIDE(
COUNT(DISTINCT a.user_email),
COUNT(DISTINCT e.employee_email)
) AS adoption_rate
FROM `your-project-id.governance.employee_directory` AS e
LEFT JOIN active_users AS a
ON LOWER(a.user_email) = LOWER(e.employee_email)
WHERE e.employment_status = 'ACTIVE'
GROUP BY e.department
ORDER BY adoption_rate DESC;
同样的建模方式还可以扩展到自定义智能体数量、每百名员工的智能体比例、NotebookLM 使用趋势，以及不同 grounding 连接器的访问量。对于“节省了多少工时”一类价值指标，必须明确计算假设，例如每类任务的基准耗时、人工复核比例和失败重做成本，不能只把对话次数直接换算成生产力。
BigQuery Conversational Analytics 可以根据 schema、业务元数据、经过验证的 SQL 和 UDF 生成查询。团队可以把“活跃用户”“有效会话”“自定义智能体”等词写入业务术语表，并提供经过审核的示例查询，减少不同分析人员对同一指标作出不同解释。自动生成的 SQL 仍应接受权限检查、成本检查和抽样验证。
合规调查需要比仪表板更精细
提示词、模型响应和文件访问路径可能包含个人信息、商业机密或受监管数据。将它们写入 BigQuery 扩大了可分析范围，也扩大了泄露面。生产环境至少应设置：
- 使用单独项目或数据集隔离原始遥测与汇总指标。
- 通过 IAM、授权视图和行列级策略限制原文访问。
- 为提示词、响应和审计数据设置不同的分区过期时间。
- 对邮箱、文档路径等字段应用数据分类和策略标签。
- 让普通仪表板读取脱敏聚合表，而不是直接扫描原始消息。
- 对查看原始提示词、响应及安全告警详情的行为继续保留审计记录。
调查 Model Armor 等安全过滤器产生的告警时，可以按时间范围、用户、会话 ID 和结束原因缩小数据集，再由获得授权的安全人员查看触发文本。查询必须包含分区条件，避免一次合规调查扫描全部历史消息。
Knowledge Catalog Data Profiling 与 Gemini 生成的数据洞察可以帮助识别空值率、唯一值数量、异常分布和跨表关联路径。它们适合加速理解陌生 schema，但不能替代数据所有者对字段含义、保留政策和敏感级别的确认。
上线顺序与边界
建议先建立最小可控闭环：启用所需日志，在隔离数据集中接收数据，验证字段和延迟，再发布少量经过审核的部门采用指标。随后接入 HR 或业务数据、配置业务术语表，并用 Looker Studio 等可视化工具提供管理层视图。批量导出的席位数据与流式交互日志应分别校验，因为二者的时间窗口、粒度和到达延迟不同。
上线前可以检查以下事项：
- Prompt、response 和 Data Access 日志是否经过隐私、法务与安全审批。
- Log Router sink 的 writer identity 是否只有目标数据集写权限。
- 查询是否强制使用时间分区，并设置预算与扫描告警。
- 核心指标是否有书面定义、负责人和经过验证的 SQL。
- 管理层仪表板是否只暴露完成匿名化或聚合的数据。
- 原始内容是否设置最短必要保留期，并具备删除与取证流程。
BigQuery 的价值不只是“能存很多日志”。它把产品级使用数据转化为组织自己的治理模型：IT 团队观察采用，数据团队统一指标，安全团队精确调查，管理层评估投入产出。前提是从第一天就把敏感数据边界、指标口径和查询成本纳入架构，而不是等日志规模增长后再补治理。