Google 在 2026 年 9 月 3 日宣布，为 Workspace 管理控制台加入 Gemini Notebook 审计日志。管理员可以查看操作及关联资源，把一次共享或内容生成行为与具体对象联系起来。对使用笔记本整理客户访谈、产品资料和竞品研究的团队，这提供了比成员回忆更明确的排查入口。
控制台日志默认可用，BigQuery 导出需要另行开启，具体查询能力取决于版本和管理员权限。普通成员能使用 Notebook，并不因此获得组织审计入口。官方公告
它最适合回答“谁对哪个对象做了哪项已记录操作”。是否有人读完全部资料、生成的结论是否准确、是否发生了资料外泄，都不能仅凭一个事件名称确定。
先分清五个对象，才不会把日志读错
在一项客户研究中，项目成员可能添加来源、生成报告、修改共享。它们发生在同一个笔记本里，却不是同一种动作。日志调查时，可以先按下面几类对象整理。
| 对象 | 需要辨认什么 | 容易混淆的地方 |
|---|---|---|
| 操作者 | 谁执行了记录中的动作 | 不一定是后来获得访问权的人 |
| 接收者 | 哪个用户或群组的权限被改变 | 群组名称不等于固定的个人名单 |
| 笔记及关联资源 | 具体资源ID与标题 | 同名副本可能是不同对象 |
| 来源材料 | 被引用材料的ID、名称或类型 | 与后来生成的报告不是同一份内容 |
| 生成内容 | 报告、音频等产物的标识 | 生成记录不证明产物已经外发 |
官方字段提供了这些区分所需的部分信息。例如 BigQuery 中 recipient 指权限被修改的用户或群组，source 与 studio_artifact 则分别描述来源材料和生成产物。BigQuery字段说明
先把对象区分开，会减少错误推断。甲成员执行了权限调整、乙群组得到查看资格，不能写成“甲把全部内容发给了乙群组每个人”。这句话同时混合了权限、内容传递和实际阅读，超出了单条变更记录能支持的范围。
在控制台查询时，先放宽时间，再逐步收窄
入口是管理控制台的“报告 → 审核和调查 → Gemini Notebook日志事件”，需要相应管理权限。默认查询最近七天，日期按浏览器默认时区显示。要查更早的项目交付，先调整日期，再逐步加入事件、人员和资源条件。日志查询与属性帮助
第一次没有结果时，不要立即再加更多条件。可以依次检查：是否选错时间段、是否使用了另一个资源副本、人员信息是否变化、该事件是否具备你用于筛选的字段。条件越多，可能只是把本来相关的记录排除了。
跨地区团队还要对齐时间。客户邮件写着周一上午，管理员浏览器显示的日期可能处于另一个时区。先保留完整时间与所用时区，再拼接邮件、项目记录和审计事件，避免把先后顺序颠倒。
官方也明确，不是每种事件都会报告全部属性。来源URL为空，不能单独证明没有来源；IP地址也可能对应代理或VPN。遇到字段缺失，应记录“此字段未提供”，再看是否有其他证据，而不是替空白补一个确定结论。
可以用不含客户资料的测试笔记，执行一项普通共享变化，让管理员核对实际能看到的字段。这能帮助团队熟悉自己的入口和输出，但一次测试只能验证该情境，不能证明所有操作都被完整记录。
一份“客户A研究”共享范围不对，怎样查？
以下是自拟调查情境，不是真实事故或租户测试。项目负责人发现一份“客户A研究”允许了约定之外的协作者，但团队还有同名的初稿、副本和交付版。
第一件事是确定资源。记录当前笔记链接、资源ID和负责人，再查看大致发生时间。标题方便辨认，ID更适合对齐同一个对象。若只按客户名称把所有结果合并，就可能把副本的操作误记到正式交付版上。
按资源ID排列事件，再到实际笔记复核当前权限。历史上曾开放、后来又收回，与当前是否仍可访问，需要分别记录。下面的N-A/N-B实例展示为什么不能只按同名标题合并事件。
如果权限确实不合适，应到实际产品和管理设置处理，日志出现异常不会自动替你撤销共享。允许谁使用、谁能邀请外部成员，可以继续核对Gemini Notebook外部共享控制。
同名笔记混在一起，先把证据对齐
用三条自拟记录演示上述步骤。ID、时间与事件描述仅用于教学，不是实际日志字段导出。
| 时间 | 资源 | 记录表达的动作 |
|---|---|---|
| 09:00 | N-A，客户A研究正式版 | 编辑甲调整共享，项目外群组获得查看资格 |
| 09:10 | N-B，客户A研究副本 | 编辑乙生成报告 |
| 09:20 | N-A，客户A研究正式版 | 编辑甲收回该群组查看资格 |
若只按标题搜索，会很容易写成“共享后生成了报告”。按资源ID看，生成发生在N-B，不能拿它证明N-A的新增成员使用了资料。N-A两条记录支持的是09:00至09:20之间发生过权限扩大和收回；是否有人实际阅读，还缺对应证据。
调查结论可以写为：“本轮核对N-A的共享变更，发现群组查看资格曾被授予后收回；N-B的生成记录已排除，不能用于说明N-A使用情况。当前共享状态已另行打开正式版核对。”真实工作还应补完整日期、时区和检索区间。
这份结论把资源、历史行为与当前处理接在一起，同时明确下一步该找哪类证据。若群组当时成员不明，就把成员范围列为待核实，不把今天的名单填进旧记录。
BigQuery适合持续分析，不是查看日志的必经步骤
偶尔核查一份客户笔记，控制台通常更直接。需要跨项目持续整理权限变化、重复运行查询或交给内部分析人员时，再考虑 BigQuery。
导出后，应继续保持对象和指标清楚。共享变更次数、生成内容次数与实际阅读次数不是同一个指标，不能全部合并成“客户资料访问量”。一个项目产生许多报告，也不意味着更多外部人员看到了原始材料。
字段缺失和版本变化同样需要处理。官方 schema 中相关字段允许为空，新增字段会出现在更新后生成的每日表中。跨历史表查询时，应确认各表实际列结构，不能假定旧表自动具有后来加入的字段。
启用服务日志导出还涉及受支持版本、Cloud项目、权限与计费，控制台已有日志不代表 BigQuery 已配置完成。具体设置和数据延迟应查看服务日志导出说明，并核对本组织实际保留配置。这里不需要为偶尔的一次调查先建设整套数据平台。
另外，日志数据集所在地区与 Notebook 正文存储位置不同。发布公告说明，日志遵循相应区域路由政策，而笔记、来源和聊天等用户数据当时仍为全球存储，不支持数据区域化。不能因为选择了日志地区，就向客户承诺全部研究资料只存放在那里。
把新能力接到项目交接里，才会真正用得上
团队可以为每份客户研究保留最少几项信息：项目标识、正式笔记链接或ID、资料负责人、允许的协作者范围，以及重要变更的日期。日后需要查记录时，就不必从一堆同名文件重新辨认对象。
调查结束也应保留查询范围和结论依据。知道查了哪个日期区间、哪个资源以及哪些事件，后来的人才能理解“没有发现”的具体范围。它不是对所有时间和所有访问路径的完整证明。
这项更新补充的是行为证据。研究质量仍需要另查：生成的报告是否准确引用来源、有没有把访谈意见扩大成行业结论，都不能从审计事件里判断。涉及答案依据时，应回到NotebookLM来源与引用核对这类内容检查。
对SEO和内容团队，有用的结果是遇到疑问时能够定位具体资源、还原已记录变化，并说明哪些事实尚未确认。这样日志才进入真实项目管理，而不只是控制台里多了一个报表入口。
常见问题
管理员能看到所有提问和回答吗？
本次公告和字段说明不足以支持这个结论。事件、来源名称和产物标识不等于完整聊天正文；应按具体工具、权限与数据源核对。
共享变更记录能证明资料泄露吗？
单条记录通常只能支持相应权限变化。是否被访问、复制或传出，需要其他证据，不能把获得资格等同于实际阅读。
为什么某条记录没有来源URL？
并非所有事件都报告全部字段。先检查事件类型与实际属性，将空白保留为未知，不要当成没有来源的证据。
小团队必须开启BigQuery吗？
不必。明确的一次性核查可先使用控制台；需要持续、跨项目分析时，再评估导出配置、维护人员与成本。