AI助理接入邮箱日历前要做哪些权限检查
AI 助理接入邮箱日历前，应检查读写发送权限、委托与应用权限、数据范围、数据流向、代行动作、模型输入、撤权删除和小范围试点。
AI 助理接入邮箱和日历，听起来很自然。它可以帮你整理会议、总结邮件、提醒待办、起草回复、找出冲突时间、生成日程建议。对个人和团队来说，这些都是高频场景。
但邮箱和日历不是普通资料。邮箱里可能有客户合同、账单、验证码、招聘沟通、医疗记录、家庭信息、登录提醒、附件和隐私对话；日历里可能有会议主题、参与人、地点、客户名称、面试安排、请假记录和个人行程。AI 助理一旦接入，就不只是“读一段文本”，而是获得了对个人工作节奏和关系网络的入口。
所以，在接入邮箱日历之前，更该先问的不是“AI 能做什么”，而是“它到底拿到了什么权限、保存什么数据、能做哪些动作、出错时怎么撤权”。
这篇文章面向个人与团队，整理一份权限检查清单。它不是法律意见，也不是某个平台配置手册，而是一组接入前要问清楚的问题。
第一件事：分清读、写、发送和删除
很多用户看到授权页面时，只注意到“邮箱”“日历”这几个大词，却忽略了权限粒度。对 AI 助理来说，不同权限代表完全不同的风险。
以邮箱为例，读邮件、查看邮件元数据、修改标签、创建草稿、发送邮件、删除邮件、管理邮箱设置，都不是一回事。一个只做“邮件摘要”的助理，通常不应该一开始就拿发送邮件或修改设置的权限。一个只做“会议纪要整理”的助理，也不一定需要读取所有历史邮件。
Gmail API 的 scopes 文档把权限分成不同范围，并说明 restricted scopes 会提供对 Google 用户数据的广泛访问，需要 restricted scope OAuth App Verification；如果在服务器上保存或传输 restricted scope 数据，还可能需要安全评估。Google 的 OAuth scopes 总表也提醒，应该尽量使用不敏感的 scope，并参考具体 API 文档选择方法所需权限。
日历也一样。读取日历事件、创建事件、修改事件、删除事件、查看空闲忙碌信息、访问辅助日历，风险不同。Google Calendar API 的 scopes 文档说明，授权 scope 是 OAuth 2.0 URI 字符串，用来描述应用请求访问哪类 Google Workspace 数据、以及访问级别。
Microsoft Graph 也有类似区分。Microsoft Graph permissions reference 说明，Graph 暴露了细粒度权限，控制应用对用户、群组、邮件等资源的访问；文档还明确建议请求应用正确运行所需的最低权限，申请超出需要的权限是不好的安全实践。
检查清单的第一行就应该写清：AI 助理只是读，还是会写？只是生成草稿，还是能直接发送？只是读取空闲时间，还是能看到会议标题和参会人？只是创建建议，还是能直接改你的日程？
第二件事：区分委托权限和应用权限
对团队来说，另一个容易被忽略的点是 delegated permissions 和 application permissions。
委托权限通常表示应用代表一个已登录用户访问数据。用户能访问什么，应用在这个用户上下文里访问什么。应用权限则可能在没有已登录用户的情况下访问组织资源，常见于后台服务或自动化任务。两者的影响范围不同，审批要求也不同。
Microsoft Graph permissions overview 解释了委托访问场景，并提醒并非所有 delegated permissions 都适用于个人 Microsoft 账户；permissions reference 则列出每个权限是否需要管理员同意。对组织管理员来说，这不是细节：一个只服务个人助理的工具，不应不加区分地申请组织级应用权限。
接入前可以问四个问题：
1. 这个 AI 助理是代表用户本人工作，还是以组织应用身份工作？ 2. 它能访问单个用户的数据，还是可能访问多个邮箱和日历？ 3. 权限需要用户同意，还是需要管理员同意？ 4. 管理员能不能限制它只访问指定用户、指定邮箱或指定范围？
如果这些问题回答不清楚，就不要急着把它接入生产邮箱或团队日历。
第三件事：检查数据范围
权限名称只说明“能访问什么类型的数据”，还不能说明“实际会处理哪些数据”。AI 助理接入邮箱日历前，还要检查数据范围。
邮箱侧至少要问：
1. 是否读取正文，还是只读取发件人、主题和时间？ 2. 是否读取附件？ 3. 是否读取历史邮件，还是只处理新邮件？ 4. 是否读取垃圾邮件、归档邮件、已删除邮件？ 5. 是否会访问验证码、账单、合同、招聘、医疗或家庭相关邮件？ 6. 是否会把邮件内容发送给第三方模型或外部服务？
日历侧至少要问：
1. 是否读取会议标题、参会人、地点和说明？ 2. 是否读取私密日历或共享日历？ 3. 是否只读取空闲忙碌，还是读取完整事件详情？ 4. 是否能创建、修改、取消会议？ 5. 是否能邀请外部参会人？ 6. 是否会读取历史日程和未来全部日程？
个人用户容易低估日历敏感度。一次会议标题可能暴露客户、项目、面试、病假和谈判进度。团队更要关注共享日历和会议室日历，因为一个授权错误可能影响不止一个人。
第四件事：看数据流向和保存时间
AI 助理不是只在浏览器里看一眼数据。它可能把邮件片段、会议标题、附件摘要、联系人、向量索引、日志和模型输入输出保存在不同地方。
Google API Services User Data Policy 适用于请求访问 Google 用户数据的开发者，强调使用 Google API 数据时需要符合数据使用、透明通知、控制、隐私和安全要求。它还包含 Limited Use 要求，限制用户数据的使用和转移方式。
这类政策提醒我们：权限检查不只看授权页面，还要看数据处理链路。
接入前应该画一张数据流图：
1. 用户授权后，token 存在哪里？ 2. 邮件或日历数据是实时读取，还是同步到服务器？ 3. 是否生成向量索引、缓存、摘要或任务记录？ 4. 数据会传给哪些模型、插件、云服务或子处理系统？ 5. 日志里是否包含邮件正文、参会人、附件名或会议链接？ 6. 数据保存多久？用户撤权后是否删除衍生数据？ 7. 管理员和支持人员能否看到用户内容？
对个人用户来说，可以优先选择不保存原文、只保存本地设置、提供明确删除入口的工具。对团队来说，需要把数据流图放进安全评审和供应商审查。
第五件事：检查“代你行动”的权限
很多 AI 助理吸引人的地方，是可以代你行动：发送邮件、回复客户、创建会议、修改日程、邀请参会人、取消会议、标记邮件、归档邮件。
这类动作不只是读取数据，而是改变外部世界。权限检查要把“建议”和“执行”分开。
可以使用三级模型：
第一层：只读和总结。AI 可以读取有限资料，生成摘要或建议，不改变邮箱日历。
第二层：生成草稿。AI 可以创建邮件草稿或会议草案，但发送、邀请、取消、修改必须由用户确认。
第三层：有限自动执行。只在低风险、可撤销、范围明确的场景中自动执行，例如给自己创建提醒，或把某类低风险邮件打标签。即便如此，也需要日志和撤权入口。
很多事故不是来自 AI 不会写，而是来自它在错误上下文里替用户点击了“发送”。所以，只要涉及发送邮件、邀请外部人员、修改会议、删除内容，就应该默认需要人工确认。
第六件事：检查提示词和模型输入
有些团队只审 API scope，不审模型输入。这样还不够。
AI 助理读取邮箱日历后，往往会把内容拼进提示词或工具调用：邮件主题、正文片段、联系人、会议说明、附件摘要、历史上下文和用户偏好。如果提示词或日志保存不当，敏感数据会出现在模型调用记录、调试面板或第三方服务里。
检查时可以问：
1. 提示词里是否包含完整邮件正文？ 2. 是否对验证码、身份证号、银行卡、地址、会议链接做了过滤？ 3. 是否把多个用户的上下文混在一起？ 4. 是否允许模型根据邮件内容训练通用模型？ 5. 是否能关闭日志原文记录？ 6. 是否能查看和删除 AI 记住的偏好或摘要？
这里要区分事实和建议。事实是：邮箱和日历数据一旦进入模型上下文，就可能被用于生成回答、日志、缓存或索引。建议是：尽量减少原文进入模型，优先传入与任务相关的片段，并对高敏信息做遮蔽或转人工处理。
第七件事：准备撤权与恢复路径
用户和管理员要能随时停用 AI 助理。撤权不是放在帮助中心角落里的小字，而是权限设计的一部分。
撤权清单至少包括：
1. 用户可以在应用内断开邮箱或日历连接。 2. 用户可以在 Google 或 Microsoft 账户授权页面移除第三方访问。 3. 管理员可以撤销组织级同意。 4. 撤权后 token 立即失效或不可再用。 5. 已同步数据、缓存、向量索引和摘要有删除策略。 6. 邮件草稿、已创建会议、自动规则有恢复或人工处理办法。 7. 审计日志能显示撤权前后发生了什么。
这里尤其要注意“断开连接”和“删除数据”不是一回事。断开连接只是停止继续访问；历史同步的数据、摘要和索引可能还在。接入前要问清楚：撤权后会删除哪些数据，保留哪些审计记录，用户能否发起删除请求。
第八件事：小范围试点
个人用户可以先用一个不含敏感历史资料的测试邮箱试用。团队可以先用测试租户、测试日历或少量志愿用户试点，不要一开始就接入全员邮箱。
试点阶段看四类指标：
1. 权限是否符合任务需要。 2. AI 是否只读取必要数据。 3. 发送、改会、删改等动作是否需要确认。 4. 撤权、删除和审计是否可操作。
试点还应该记录用户感受：授权页面能不能看懂？AI 做了什么是否透明？误操作之后能不能恢复？用户是否知道如何停用？
一份接入前检查表
下面这份表适合个人、团队和产品负责人一起使用：
| 检查项 | 要问的问题 | 理想结果 | | --- | --- | --- | | 任务目标 | AI 助理到底要完成什么？ | 只为明确任务申请权限 | | 邮箱权限 | 是否需要读正文、附件、标签、草稿、发送？ | 优先只读，写入和发送需确认 | | 日历权限 | 是否只看空闲忙碌，还是看事件详情？ | 从最小日历权限开始 | | 权限类型 | 是委托权限还是应用权限？ | 个人场景优先委托，组织场景需管理员评审 | | 数据范围 | 是否读取历史、附件、共享日历？ | 限制时间、标签、文件夹和日历范围 | | 数据流向 | 数据是否传到模型、缓存、日志、索引？ | 有数据流图和保存期限 | | 模型输入 | 是否过滤验证码、身份信息、会议链接？ | 高敏信息遮蔽或不进入模型 | | 代行动作 | 是否能发送邮件、改会、取消会议？ | 默认人工确认 | | 撤权删除 | 用户能否断开连接并删除衍生数据？ | 有可见入口和审计留痕 | | 试点范围 | 是否先在测试账号或小团队试用？ | 先试点，再扩展 |
结尾：权限是一种产品体验
AI 助理接入邮箱日历，不只是技术集成，也是信任设计。一个值得使用的助理，应该清楚告诉用户：它要访问什么、为什么需要、会保存多久、会不会代你行动、如何撤权。
如果一个工具一上来就要求读取全部邮箱、修改日历、发送邮件、保存历史内容，却说不清数据流向和撤权办法，那就应该先停下来。
更稳妥的接入不是权限越多越方便，而是权限刚好够用、动作可确认、记录可追溯、撤权可操作。邮箱和日历离人的工作生活很近，AI 助理要进入这里，先把权限检查做好，才配得上用户把钥匙交给它。