AGI与ASI数据主体权利保障：超级智能场景下的知情同意机制

一、知情同意的法定四要件

⚖️ "基于个人同意处理个人信息的，该同意应当由个人在充分知情的前提下自愿、明确作出。法律、行政法规规定处理个人信息应当取得个人单独同意或者书面同意的，从其规定。个人信息的处理目的、处理方式和处理的个人信息种类发生变更的，应当重新取得个人同意。"

💡 "基于个人同意处理个人信息的，个人有权撤回其同意。个人信息处理者应当提供便捷的撤回同意的方式。个人撤回同意，不影响撤回前基于个人同意已进行的个人信息处理活动的效力。"

"个人信息处理者不得以个人不同意处理其个人信息或者撤回同意为由，拒绝提供产品或者服务；处理个人信息属于提供产品或者服务所必需的除外。"

"个人信息处理者在处理个人信息前，应当以显著方式、清晰易懂的语言真实、准确、完整地向个人告知下列事项：（一）个人信息处理者的名称或者姓名和联系方式；（二）个人信息的处理目的、处理方式，处理的个人信息种类、保存期限；（三）个人行使本法规定权利的方式和程序；（四）法律、行政法规规定应当告知的其他事项。"

二、《暂行办法》对 AI 场景的三道知情同意硬约束

• 第九条：提供者依法承担个人信息处理者责任，履行个人信息保护义务；与使用者签订服务协议，明确双方权利义务
• 第十一条：对使用者的输入信息和使用记录依法履行保护义务，不得收集非必要个人信息，不得非法留存能够识别使用者身份的输入信息和使用记录，不得非法向他人提供

三、传统"一次性同意"在 AI 场景下的失灵

⚠️ "当前，传统的'一次性同意'模式已经不能满足人工智能的发展趋势，应当向持续的信息披露和动态同意机制转变。"

四、AGI 阶段的知情同意机制重构：分层分类 + 动态同意

4.1 预训练阶段：有条件概括告知

💡 "在模型预训练阶段，对于海量爬取的公开信息，如果服务提供者与信息主体缺乏直接连接，且数据用途是构建基座模型的通用能力，那么可有条件地适用前述合理利用逻辑，允许服务提供者通过公开渠道的概括性隐私声明来履行告知义务。"

• 数据来源为合法公开的个人信息
• 处理在《个保法》第 27 条"合理范围"内
• 通过公开渠道的概括性隐私声明履行告知
• 保留个人明确拒绝的权利（opt-out）
• 对个人权益有重大影响的，仍需取得同意

4.2 交互微调阶段：场景化明示同意

💡 "在交互微调阶段，服务提供者应当严守场景化的特定同意规则。当用户在对话框中输入个人信息以获取服务时，该场景应被认为具有极强的服务导向性，若服务提供者意图将此类交互数据转化为训练数据，则需严格执行《个保法》明示同意规则。"

• 不允许通过"优化服务"等模糊条款搭便车式强制授权
• 确保用户对交互过程中的个人信息去向享有实际控制权
• 用户输入转训练需独立、明确、可撤回的同意

4.3 敏感个人信息的单独同意

📌 "对个人普通信息，获得信息主体默示同意；个人敏感信息，需要获得信息主体明示同意；人脸信息、金融信息等识别特征、私密特征强的信息，需要获得信息主体明确的书面同意。"

4.4 动态同意的技术实现

• 同意验证：限制对个人数据的访问在处理者同意范围内（GDPR 第 4(1)、4(11)、5 条）
• 同意撤回：启用撤回权限以停止访问和擦除/解除身份关联（GDPR 第 7(3)、17、19 条）
• 同意续展：通过提供产品/服务使用收益，请求继续授权（GDPR 第 6(1a) 条）

💡 "If any data subject's consent has expired or been withdrawn, and the ML artifact has been utilizing the personal data for which the subject has withdrawn consent, the ML artifact must stop its use. It should revert to training ML models without utilizing the data subject's personal data. Otherwise, ML models can continue training, testing, or using."

五、ASI 智能体阶段的知情同意升级

5.1 同意颗粒度必须下沉到用途层级

⚖️ "A real opt-out has to change what happens next. It should affect future collection, future training, and any downstream sharing that would keep feeding the same system. Otherwise, it's just a preference label with no real consequence."

1. 未来收集：停止分析、个性化等 Web 信号
2. 未来训练：个人应被排除在训练运行、微调数据集、生成模型输入的特征存储之外
3. 下游共享：opted-out 数据不应悄悄成为改进他人模型的素材

5.2 同意信号必须"随数据旅行"

💡 "The safer setup is a flag that travels with the data instead of staying trapped in a UI setting. That flag needs to be recognised at collection, in the warehouse, inside training prep, and before anything is sent to a vendor."

• 在事件、转录、标识符等所有可能喂给模型的数据上附加 do_not_train 等清晰信号
• 在训练表、特征存储、供应商导出前过滤被标记的记录
• 训练任务本身应有硬停止机制，防止 opted-out 记录被下游拉回

5.3 ASI 自主决策的同意边界

5.4 持续披露与动态同意的闭环

• 隐私政策之外，在对话界面显著位置对个人信息收集类别作简明列举
• 产品界面设置明确提示，告知用户避免输入他人敏感个人信息
• 智能体调用第三方工具、跨境记忆库、外部 API 时实时告知

• 同意不是一次性取得，而是可动态调整
• 处理目的、方式、种类变更时重新取得同意（《个保法》第十四条）
• 智能体进入新的决策场景时触发新的同意请求
• 撤回同意后，信号随数据流转至全链路

六、知情同意的操作框架

AGI/ASI 知情同意机制操作框架
    │
    ├─ 第一层：分层告知
    │   ├─ 预训练阶段：公开渠道概括性隐私声明（有条件适用）
    │   ├─ 交互微调阶段：场景化特定同意（用户输入转训练需明示同意）
    │   ├─ 敏感个人信息：单独同意 / 书面同意
    │   └─ 持续披露：对话界面显著提示 + 智能体调用实时告知
    │
    ├─ 第二层：动态同意
    │   ├─ 同意取得：充分知情 + 自愿 + 明确（《个保法》第十四条）
    │   ├─ 目的变更：重新取得同意（《个保法》第十四条）
    │   ├─ 同意续展：通过产品/服务收益请求继续授权（MLOps MOSM）
    │   └─ 智能体新场景：触发新的同意请求
    │
    ├─ 第三层：便捷撤回
    │   ├─ 撤回方式：提供便捷撤回同意的方式（《个保法》第十五条）
    │   ├─ 撤回效力：不影响撤回前已进行的处理
    │   ├─ 撤回信号随数据流转：采集→仓库→训练准备→特征存储→供应商导出
    │   └─ 撤回后处理：停止未来使用 + 清理训练数据集 + 防止数据被拉回
    │
    ├─ 第四层：限制处理（撤回/删除履行不能时）
    │   ├─ 限制访问：阻断对该用户信息的检索与调用
    │   ├─ 限制使用：禁止基于该信息继续画像、推理、生成
    │   ├─ 限制传播：防止信息流向外部插件和关联服务
    │   └─ 功能等同：实现与"删除"等同的保护效果
    │
    └─ 第五层：工具性权能响应
        ├─ 查阅、复制、更正、补充、删除（《暂行办法》第十一条）
        ├─ 解释说明权
        ├─ 可携带权
        └─ 个人权利响应时限：依法及时受理和处理

七、为什么这套框架是最优解

八、简短的结论

⚠️ 必须正视的五点：

1. 同意只是七类合法性基础之一——《个保法》第十三条规定的其他六类情形（合同履行、法定义务、公共利益等）同样可构成合法性基础；但 AI 训练场景下商业利益尚未被明确列入豁免同意情形
2. 传统"一次性同意"在 AI 场景下失灵——人民网明确：必须向持续的信息披露和动态同意机制转变
3. 交互微调阶段用户输入转训练需场景化明示同意——北航学报明确禁止通过"优化服务"等模糊条款搭便车式强制授权
4. 撤回信号必须随数据流转，而非停留在 UI 设置——CookieScript 指出：仅在设置页存储偏好而管道看不到，opt-out 就是化妆式的
5. 敏感个人信息需单独同意，生物识别等强私密信息需书面同意——光明网的三级同意梯度：普通信息默示同意、敏感信息明示同意、人脸/金融信息书面同意