1. 文档目的
本文用于说明 Audlis 当前的数据合规边界、数据治理原则、用户权利处理机制与后续治理方向。
这份文档关注的是：
- 系统处理了哪些数据
- 为什么处理这些数据
- 数据如何分类、保存、访问和删除
- 合规能力如何落到具体系统功能
它不是法律意见文档，而是系统设计与运营执行文档。
2. 为什么这份文档重要
对跨境电商来说，合规不是附属功能，而是正式运营能力的一部分。
Audlis 当前已经具备以下现实场景：
- 用户注册、登录、下单、收货
- 地址、邮箱、订单、物流数据被持续处理
- AI 客服会接收用户输入
- 营销系统会围绕商品、用户行为和渠道进行内容生成与落地页切换
只要系统处理这些数据，就必须明确：
- 数据的用途
- 数据的边界
- 数据的保留方式
- 用户权利如何行使
3. 数据治理目标
Audlis 当前的数据治理目标分为四层：
3.1 透明
让用户知道系统处理了什么数据、用于什么目的。
3.2 最小化
只处理完成业务所必需的数据，不把所有信息都无限制留存。
3.3 可执行
不是只写隐私政策，而是要把导出、删除、更正等能力做成真正的系统能力。
3.4 可追踪
系统要知道：
- 谁提交了请求
- 请求状态是什么
- 是否已处理
- 处理结果是什么
4. 当前数据域划分
Audlis 当前主要处理以下数据域：
4.1 账户数据
包括：
- 用户 ID
- 邮箱
- 登录状态
- 基础资料
- 密码相关信息（不明文保存）
用途：
- 身份识别
- 登录与账户服务
4.2 客户资料与地址数据
包括：
- 姓名
- 电话
- 收货地址
- 国家 / 省市 / 邮编
用途：
- 订单收货
- 物流查询
- 客服核对
4.3 订单与支付相关数据
包括：
- 订单号
- 商品项
- 金额
- 支付状态
- Stripe 相关标识
用途：
- 交易成立
- 履约与退款处理
- 财务对账
注意：
- 支付卡敏感数据不应由 Audlis 自己保存
- 支付事实以 Stripe 为主
4.4 物流数据
包括：
- tracking number
- carrier
- tracking events
- shipping exceptions
用途：
- 履约跟踪
- 用户查询
- 售后处理
4.5 客服与咨询数据
包括：
- inquiry 内容
- support conversation
- AI 客服消息
- 转人工记录
用途：
- 售前答疑
- 售后分流
- 人工客服跟进
4.6 营销与行为数据
包括：
- 渠道包应用记录
- 营销 landing 配置
- 生成历史
- 营销资产
用途：
- 内容生产
- 营销展示
- 站内增长实验
4.7 系统配置与供应商连接数据
包括：
- app_config
- supplier token 缓存
- AI 模型配置
用途：
- 系统运行
- 外部服务访问
5. 当前系统里的合规能力
Audlis 当前已落地的合规能力主要包括：
5.1 隐私政策页面
前台提供：
- 隐私政策说明
- 数据处理范围说明
- 联系与请求入口说明
5.2 账户删除
用户可以发起账户删除相关动作。
5.3 数据导出
系统支持用户导出自身数据。
5.4 隐私请求工作流
系统已有：
data_subject_requests- 用户侧提交接口
- 后台
Privacy Requests工作区
支持的请求类型包括：
- 数据导出
- 删除请求
- 更正 / 人工处理请求
5.5 后台管理视图
管理员可以在后台查看：
- 请求列表
- 请求状态
- 请求处理结果
6. AI 场景下的合规边界
AI 是 Audlis 当前最容易扩大数据处理边界的部分，所以需要单独说明。
6.1 商品编辑 AI
输入主要来自商品数据，不涉及高敏感个人数据，风险相对较低。
主要边界：
- 不应虚构事实
- 不应把外部敏感数据混入商品内容
6.2 AI 客服
AI 客服处理的是用户输入，因此风险更高。
边界必须包括：
- 不接受支付卡等敏感支付信息
- 不要求用户上传不必要的证件类信息
- 不对退款、补发等高风险动作作自动承诺
- 无法确认时转人工
6.3 营销 AI
营销系统主要处理商品与内容资产数据，风险低于客服，但仍需控制：
- 不凭空生成误导性宣传
- 不制造虚假物流或售后承诺
- 不把用户个体敏感信息直接用于内容生成
7. 当前治理原则
Audlis 当前系统设计应遵循以下治理原则：
7.1 权限最小化
- 用户接口只访问当前用户自己的数据
- 后台接口要求管理员权限
- 不能信任前端传入的
userId
7.2 配置与密钥分离
- 敏感 key 不进入仓库
- 使用 secret / env
- 数据库里只缓存必要 token
7.3 原始事实保留
订单、物流、客服、供应商原始数据应尽量保留事实层，而不是只保留加工结果。
7.4 人工接管机制
在 AI 无法可靠处理时，必须能转人工，不应强行自动决策。
7.5 合规能力前后台一体化
隐私政策、用户请求、后台处理和数据导出必须是一条闭环，而不是各自孤立。
8. 当前仍需继续补强的点
虽然基础能力已建立，但合规治理仍有待继续完善：
8.1 保留策略自动化
目前文案层已说明部分保留策略，但系统层还缺：
- 自动清理
- 自动归档
- 到期标记
8.2 更清晰的请求分类
当前 DSAR 能力已可用，但后续可继续细分：
- access
- export
- delete
- correct
- restrict / manual review
8.3 审计日志
对于高风险处理动作，后续应补充：
- 谁处理了请求
- 何时处理
- 做了什么动作
8.4 AI 场景敏感信息拦截
当前已有边界设计，但仍可进一步强化：
- 规则拦截
- 风险提示
- 更清晰的人工接管触发条件
9. 系统内的合规职责边界
Audlis 应承担的，是“第一方电商系统”的合规责任，包括：
- 用户数据访问与导出
- 用户删除与更正请求处理
- 订单和物流相关数据的正当处理
- 客服和 AI 的边界控制
- 配置和密钥治理
Audlis 不应在当前阶段承担的，是：
- 自建复杂法务平台
- 替代律师完成完整合规判断
- 替代支付平台承担卡数据合规责任
10. 后续演进建议
从工程角度，合规治理下一步最值得做的有三件事：
10.1 补自动保留策略
基于定时任务处理：
- 过期聊天记录
- 过期日志
- 过期草稿数据
10.2 补合规审计轨迹
至少对以下动作留下记录：
- 删除处理
- 导出处理
- 人工客服接管
- 供应商连接敏感操作
10.3 把合规文案与后台动作彻底对齐
即：
- 前台承诺了什么
- 后台就必须真正能做什么
11. 一句话总结
Audlis 当前的数据合规能力已经从“写一页隐私政策”升级为“前台说明、用户请求、后台处理、AI 边界和配置治理”组成的实际系统能力。
它还不算终局，但已经具备继续扩展为正式治理体系的基础。