164 lines
4.0 KiB
Markdown
164 lines
4.0 KiB
Markdown
# LEGAL_PRIVACY_BASELINE
|
||
|
||
状态: 草案（T12 上线前基线）
|
||
适用范围: `/pricing` → `/checkout` → `/api/public/orders` → `/portal/{token}` 全链路，以及后台订单处理、报告交付、渠道补录场景。
|
||
最后更新: 2026-06-14
|
||
|
||
---
|
||
|
||
## 1. 目标
|
||
|
||
本文件定义 T12 用户端 Web 自助 MVP 在法务/隐私侧的**最小上线基线**，防止以下误判：
|
||
|
||
- 代码能跑 = 可以直接收真实考生资料
|
||
- 有加密字段 = 已完成隐私合规
|
||
- 可删除数据库记录 = 已具备正式删除流程
|
||
|
||
本文件只定义当前必须落实的最低要求，不代替正式律师审阅。
|
||
|
||
---
|
||
|
||
## 2. 当前涉及的数据类型
|
||
|
||
### 2.1 用户主动提交的数据
|
||
|
||
1. 家长/联系人信息
|
||
- 称呼
|
||
- 手机号
|
||
- 微信号（可选）
|
||
2. 考生信息
|
||
- 姓名
|
||
- 省份
|
||
- 分数
|
||
- 位次
|
||
- 选科
|
||
- 兴趣方向
|
||
- 家长备注
|
||
3. 订单与交付信息
|
||
- 订单号
|
||
- 套餐版本
|
||
- 支付状态
|
||
- 报告 HTML/PDF 路径
|
||
4. 后台处理信息
|
||
- 状态流转历史
|
||
- 处理人
|
||
- 处理原因
|
||
|
||
### 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. 后台人工补录渠道单时，也必须记录同意来源：
|
||
- 闲鱼/微信/学校/线下确认
|
||
|
||
当前状态:
|
||
|
||
- 代码中尚未落地上述 consent 字段
|
||
- 因此当前仅可视为**待补基线**，不可宣称“已完成监护人同意闭环”
|
||
|
||
---
|
||
|
||
## 5. 对外文案最低要求
|
||
|
||
前台至少应明确告知：
|
||
|
||
1. 收集哪些信息
|
||
2. 用于什么目的
|
||
3. 不用于营销出售
|
||
4. 可申请删除
|
||
5. 监护人同意要求
|
||
6. 服务结果为辅助决策，不承诺录取结果
|
||
|
||
建议文案入口：
|
||
|
||
- 下单页提交前
|
||
- 资料填写页提交前
|
||
- 页脚“隐私政策 / 数据删除说明”链接
|
||
|
||
---
|
||
|
||
## 6. 同意记录最小字段
|
||
|
||
上线前至少应在订单上下文保存以下字段：
|
||
|
||
- `consent_version`: 当前协议/隐私政策版本
|
||
- `privacy_accepted_at`: 隐私政策同意时间
|
||
- `service_terms_accepted_at`: 服务说明同意时间
|
||
- `guardian_confirmed`: 是否监护人确认
|
||
- `consent_channel`: web / wechat / xianyu / school / admin
|
||
|
||
这些字段可先落在：
|
||
|
||
- `order_intakes` payload
|
||
- 或订单扩展字段 / tags
|
||
|
||
但不得只停留在前端文案、完全不落库。
|
||
|
||
---
|
||
|
||
## 7. 当前代码与本基线的差距
|
||
|
||
已具备：
|
||
|
||
- 订单敏感字段加密/脱敏基础
|
||
- 订单删除 DAO 能力
|
||
- Portal token 访问控制基础
|
||
|
||
尚缺：
|
||
|
||
- 正式隐私政策页面
|
||
- 数据保留与删除规则文档
|
||
- 监护人同意落库字段
|
||
- 数据删除 SOP
|
||
- 服务条款/免责声明独立文案
|
||
|
||
---
|
||
|
||
## 8. T12 验收口径
|
||
|
||
只有同时满足以下条件，才可说“隐私合规基线已补齐”：
|
||
|
||
- 已有正式文档：隐私政策 + 数据保留删除规则
|
||
- 前台存在可见入口
|
||
- 同意字段已落库
|
||
- 后台/运维知道如何响应删除请求
|
||
|
||
在此之前，只能说：
|
||
|
||
- **已建立隐私合规草案基线**
|
||
- 不能说“隐私合规已整体完成”
|