69e5e86bca
新增: - docs/THIRD_PARTY_DISCLOSURE_TEMPLATE.md - 第三方实名披露字段模板 - 云/支付/邮件/监控/客服/SDK 六大类别 - 只披露真实启用第三方原则 - 更新与通知机制 - 快速填写模板 同步: - PRIVACY_POLICY_DRAFT.md 当前仍需补充项中挂接模板 - SERVICE_TERMS.md 当前仍需补充项中挂接模板 - LEGAL_PRIVACY_BASELINE.md 第三方披露流程引用模板 边界: - 不预填未启用第三方 - 正式上线前必须补齐名称/用途/信息类型/隐私政策链接 - 当前客服渠道仍是 lon22@qq.com, 第三方客服平台未启用
259 lines
8.2 KiB
Markdown
259 lines
8.2 KiB
Markdown
# LEGAL_PRIVACY_BASELINE
|
||
|
||
状态: 法务送审版草案（T12 上线前基线）
|
||
适用范围: `/pricing` → `/checkout` → `/api/public/orders` → `/portal/{token}` 全链路，以及后台订单处理、报告交付、渠道补录场景。
|
||
最后更新: 2026-06-25
|
||
|
||
---
|
||
|
||
## 1. 目标
|
||
|
||
本文件定义 T12 用户端 Web 自助 MVP 在法务/隐私侧的**最小上线基线**，防止以下误判：
|
||
|
||
- 代码能跑 = 可以直接收真实考生资料
|
||
- 有加密字段 = 已完成隐私合规
|
||
- 可删除数据库记录 = 已具备正式删除流程
|
||
- 有免责声明 = 已完成未成年人/监护人合规
|
||
|
||
本文件只定义当前必须落实的最低要求，不代替正式律师审阅。
|
||
|
||
---
|
||
|
||
## 2. 当前涉及的数据类型
|
||
|
||
### 2.1 用户主动提交的数据
|
||
|
||
1. 家长/联系人信息
|
||
- 称呼
|
||
- 手机号
|
||
- 微信号（可选）
|
||
2. 考生信息
|
||
- 姓名
|
||
- 省份
|
||
- 分数
|
||
- 位次
|
||
- 选科
|
||
- 兴趣方向
|
||
- 家长备注
|
||
3. 订单与交付信息
|
||
- 订单号
|
||
- 套餐版本
|
||
- 支付状态
|
||
- 报告 HTML/PDF 路径
|
||
4. 后台处理信息
|
||
- 状态流转历史
|
||
- 处理人
|
||
- 处理原因
|
||
5. 同意审计信息
|
||
- `consent_version`
|
||
- `consent_scope`
|
||
- `consent_given_at`
|
||
- `consent_operator`
|
||
- `consent_channel`
|
||
|
||
### 2.2 敏感级别分层
|
||
|
||
- S1 高敏: 手机号、身份证号（如未来启用）、支付回调标识、密钥材料
|
||
- S2 中敏: 姓名、分数、位次、选科、兴趣、家长备注
|
||
- S3 低敏: 订单号、套餐、状态、非个体化统计
|
||
|
||
---
|
||
|
||
## 3. 处理目的与边界
|
||
|
||
允许的处理目的：
|
||
|
||
1. 生成志愿填报审核/方案服务
|
||
2. 联系用户完成资料补充、状态通知、交付提醒
|
||
3. 进行售后、退款、争议处理
|
||
4. 做最小必要的审计与故障排查
|
||
|
||
禁止的处理目的：
|
||
|
||
1. 未经单独同意用于营销推送
|
||
2. 出售或共享给无关第三方
|
||
3. 用于广告画像或跨场景推荐
|
||
4. 在对外案例中展示未脱敏真实资料
|
||
|
||
---
|
||
|
||
## 4. 未成年人 / 监护人基线
|
||
|
||
项目面向高考考生场景，默认视为涉及未成年人或其监护人数据。
|
||
|
||
最低要求：
|
||
|
||
1. 前台资料提交前，应展示“监护人已知情并同意提交资料用于志愿填报服务”的确认文案
|
||
2. 同意记录至少要保存：
|
||
- `consent_version`
|
||
- `consent_scope`
|
||
- `consent_given_at`
|
||
- `consent_operator`（self/guardian/admin_import）
|
||
3. 后台人工补录渠道单时，也必须记录同意来源：
|
||
- 闲鱼/微信/学校/线下确认
|
||
4. 若发现未经监护人同意即收集未成年人信息，应具备删除/匿名化与事件留痕流程
|
||
|
||
当前状态：
|
||
|
||
- `consent_version / consent_scope / privacy_accepted / service_terms_accepted / guardian_confirmed` 已落在 `order_intakes` payload 提交链路
|
||
- `consent_given_at / privacy_accepted_at / service_terms_accepted_at / consent_channel / consent_operator` 现已在 portal 提交链路自动补齐
|
||
- 后台代录 / 外部渠道补录已在 A-2 中统一到同一审计口径
|
||
- 但正式法务确认版本、监护人前台正式挂载入口、撤回同意后的客服/SOP 仍未完成，**因此仍不可宣称“监护人同意闭环已整体完成”**
|
||
|
||
---
|
||
|
||
## 5. 对外文案最低要求
|
||
|
||
前台至少应明确告知：
|
||
|
||
1. 收集哪些信息
|
||
2. 用于什么目的
|
||
3. 不用于营销出售
|
||
4. 可申请删除/更正/查询
|
||
5. 监护人同意要求
|
||
6. 服务结果为辅助决策，不承诺录取结果
|
||
7. 联系方式与投诉渠道
|
||
8. 版本更新与生效说明
|
||
|
||
建议文案入口：
|
||
|
||
- 下单页提交前
|
||
- 资料填写页提交前
|
||
- 页脚“隐私政策 / 服务说明 / 数据删除说明”链接
|
||
|
||
---
|
||
|
||
## 6. 同意记录最小字段
|
||
|
||
上线前至少应在订单上下文保存以下字段：
|
||
|
||
- `consent_version`: 当前协议/隐私政策版本
|
||
- `privacy_accepted_at`: 隐私政策同意时间
|
||
- `service_terms_accepted_at`: 服务说明同意时间
|
||
- `guardian_confirmed`: 是否监护人确认
|
||
- `consent_channel`: web / wechat / xianyu / school
|
||
(实现侧 4 个 source；旧版文档曾列 `admin` 渠道值，因未在生产路径写入而移除，6/20 校准)
|
||
|
||
这些字段可先落在：
|
||
|
||
- `order_intakes` payload
|
||
- 或订单扩展字段 / tags
|
||
|
||
但不得只停留在前端文案、完全不落库。
|
||
|
||
---
|
||
|
||
## 7. 正式协议文本应覆盖的法务审核条款
|
||
|
||
在进入正式对外版本前，协议文本至少应覆盖以下条款：
|
||
|
||
1. **运营主体与适用范围**
|
||
- 运营主体名称
|
||
- 联系方式
|
||
- 适用产品/页面/后台场景
|
||
2. **个人信息处理规则**
|
||
- 收集字段
|
||
- 处理目的
|
||
- 委托处理/共享情形
|
||
- 保存期限与删除例外
|
||
3. **用户权利**
|
||
- 查询/更正/删除
|
||
- 撤回同意
|
||
- 投诉举报与响应方式
|
||
4. **未成年人保护**
|
||
- 监护人知情同意
|
||
- 非法收集后的删除/匿名化机制
|
||
5. **服务协议核心条款**
|
||
- 服务边界
|
||
- 免责声明
|
||
- 退款/售后
|
||
- 争议解决
|
||
- 不可抗力/服务中断
|
||
6. **版本生效管理**
|
||
- 发布日期
|
||
- 生效日期
|
||
- 重大变更再次通知机制
|
||
|
||
当前状态（2026-06-25）：
|
||
|
||
- `docs/PRIVACY_POLICY_DRAFT.md` 已升级为法务送审版草案，补齐：
|
||
- 收集信息表（必要/可选/用途）
|
||
- 使用目的表（场景/目的/信息类型）
|
||
- 第三方处理类别披露表
|
||
- 保存期限摘要表
|
||
- 用户权利与响应机制
|
||
- 未成年人/监护人专章（同意留痕 + 行权 + 误收集处置）
|
||
- 自动化分析与算法说明
|
||
- 运营主体：龙某某（个人开发者）
|
||
- 联系邮箱：lon22@qq.com
|
||
- 版本号：privacy-policy-v2026.06.25 / 生效日期：2026-06-25
|
||
- `docs/SERVICE_TERMS.md` 已同步升级为法务送审版草案，补齐：
|
||
- 服务性质与能力边界表
|
||
- 用户责任与禁止行为
|
||
- 订单/支付/退款规则表
|
||
- 知识产权与使用边界
|
||
- 免责声明与责任限制
|
||
- 智能分析与算法说明
|
||
- 法律适用与争议解决
|
||
- 协议更新分级机制
|
||
- 运营主体：龙某某（个人开发者）
|
||
- 联系邮箱：lon22@qq.com
|
||
- 版本号：service-terms-v2026.06.25 / 生效日期：2026-06-25
|
||
- **但仍待法务对争议解决口径、对外生效版本进行最终审定**
|
||
|
||
---
|
||
|
||
## 8. 当前代码与本基线的差距
|
||
|
||
已具备：
|
||
|
||
- 订单敏感字段加密/脱敏基础
|
||
- 订单删除 DAO 能力（含 OrdersDAO conn ownership 修复，T12-D）
|
||
- Portal token 访问控制基础
|
||
- 后台代录 / 外部渠道补录的同意审计统一化（A-2）
|
||
- 数据删除 SOP 的脚本化/产品化（T12-D）
|
||
- `/health`、密钥 fail-closed、操作审计、footer 入口等最小工程护栏
|
||
|
||
尚缺：
|
||
|
||
- 对外正式法务审阅与版本管理（PM/legal 拍板）
|
||
- 前台正式入口挂载（隐私政策 / 服务条款）
|
||
- `consent_version` 升级机制（当前仍需版本化管理）
|
||
- `consent_scope` 命名空间进一步统一
|
||
- 第三方 SDK/插件接入后的隐私披露流程（模板已建：`docs/THIRD_PARTY_DISCLOSURE_TEMPLATE.md`）
|
||
|
||
---
|
||
|
||
## 9. crowd_db 各省可信来源基线
|
||
|
||
为了避免把“仓库内存在 JSON 文件”误报为“已有可信省级数据”，对 crowd_db 的最低口径统一如下：
|
||
|
||
1. 各省文件必须包含可审计的可信来源元数据
|
||
2. `source_url` 不得再指向仓库自引用路径作为“来源证明”
|
||
3. 可补充 `trusted_sources` / `quality_note` 字段，明确当前数据是：
|
||
- 高置信人工整理（如湖南）
|
||
- 结构化骨架/人工摘要（其余省份）
|
||
4. 对外不得把 26 个 skeleton/usable 省份宣传为“高置信强推荐数据”
|
||
|
||
当前状态（2026-06-21）：
|
||
|
||
- 27 个省级 JSON 已补齐可信来源元数据治理字段
|
||
- 26 个非湖南省仍是 skeleton/usable 口径，**补齐的是可信来源与复核口径，不等于已经补齐高置信推荐内容**
|
||
|
||
---
|
||
|
||
## 10. T12 验收口径
|
||
|
||
只有同时满足以下条件，才可说“隐私合规基线已补齐”：
|
||
|
||
- 已有正式文档：隐私政策 + 服务条款 + 数据保留删除规则
|
||
- 前台存在可见入口
|
||
- 同意字段已落库
|
||
- 后台/运维知道如何响应删除请求
|
||
- 法务已确认运营主体、联系方式、争议解决和正式生效版本（剩余为前台挂载与页面展示落地）
|
||
|
||
在此之前，只能说：
|
||
|
||
- **已建立隐私合规草案基线并补齐法务审核内容**
|
||
- 不能说“隐私合规已整体完成”
|