数学建模中异常值处理的四类本质与六种方法实战指南
2026/10/29 3:50:20
先说结论：门店做 AI 项目，数据合规不是法务部的事，而是接入方案的一部分。落地时按 6 道关逐项过：谁能看（权限最小化）、看到什么（脱敏粒度）、存多久（留存期限）、给谁用（共享与出境）、留没留痕（审计日志）、合同怎么写（供应商条款）。这 6 项在数据接入阶段一次性定好，成本是方案设计里最低的；等系统上线后再补，改造成本通常是前者的 3—5 倍。
一、先分清哪几类数据是"红线"
门店手上的数据看着都是"经营数据"，但法律属性差别很大。做 AI 之前先按敏感度分三档，处理方式完全不同：
| 档位 | 典型字段 | 敏感度 | 能否直接进模型 |
|---|---|---|---|
| 一档：经营数据 | 单品销量、客单价、时段客流、库存周转 | 低 | 可以，脱敏后可直接进模型 |
| 二档：行为数据 | 会员消费频次、偏好品类、到店时间分布 | 中 | 需去标识化（会员 ID 替换为不可逆哈希） |
| 三档：身份数据 | 手机号、姓名、地址、支付账号、人脸图像 | 高 | 不建议原样进模型，需遮蔽或本地化处理 |
一个实用判据：如果一个字段泄露后能让别人"找到具体某个人"，它就不应该以明文形式出现在训练样本、日志和第三方接口里。门店最常犯的错是把会员手机号当成"用户唯一标识"直接传给外部系统，这一条在三档里最容易被监管盯上。
二、六道关，逐关过
第 1 关：权限最小化——谁能看，看到什么粒度
AI 项目的数据权限不是"管理员 / 普通用户"两级，至少分四层：
| 角色 | 可见范围 | 不可见 |
|---|---|---|
| 店长 | 本店汇总 + 脱敏明细 | 其他门店数据、会员手机号 |
| 区域运营 | 辖区多店汇总 | 单笔会员身份信息 |
| 技术/开发 | 脱敏样本集（去标识化） | 生产库明文、支付字段 |
| 外部服务商 | 只读接口或抽样样本 | 生产库直连权限 |
关键动作：给外部服务商开通的账号一律只读、限 IP 或限时段、默认不给生产库写权限。项目结束后按合同约定回收账号，这一条最容易被忘。
第 2 关：脱敏——不是"删列"这么简单
常见脱敏做法有四种，安全强度和维护成本不同：
| 做法 | 效果 | 适用 | 代价 |
|---|---|---|---|
| 字段删除 | 彻底移除 | 模型确实不需要的字段 | 可能破坏数据关联性 |
| 掩码 | 手机号显示 138****0000 | 人工查看场景 | 对模型训练意义有限 |
| 哈希替换 | 会员 ID 换成不可逆哈希 | 需要保持"同一人可追踪" | 需固定盐值管理 |
| 泛化/分桶 | 年龄转年龄段、金额转区间 | 统计分析类场景 | 精度下降 |
推荐组合：会员标识用哈希替换，金额和年龄做分桶，身份类字段直接删除。保留哈希是为了让模型还能识别"这是不是同一个人的第二次到店"，而不是让模型知道"这个人是谁"。
第 3 关：留存期限——数据不是越存越好
不少门店为了"以后有用"，把明细数据永久保留。合规上这既增加风险，也让存储成本年年上涨。建议按用途定期限：
| 数据 | 建议留存 | 依据 |
|---|---|---|
| 交易明细（含会员标识） | 3 年（对应税务与对账需要） | 经营与审计要求 |
| 模型训练样本（脱敏） | 12—18 个月滚动 | 覆盖一个完整旺季即可 |
| 原始日志（含 IP、设备） | 6 个月 | 排障够用，超期归档或删除 |
| 人脸/图像类 | 原则上不落盘，实时处理后即弃 | 敏感度最高 |
到期后要有"自动清理"的机制，而不是靠人记得。上线验收时问一句"这份数据什么时候会自动消失"，答不上来就说明留存策略没做。
第 4 关：共享与出境——数据出不出门店
这一关决定技术路线。三种常见形态：
| 形态 | 数据流向 | 合规负担 | 适合场景 |
|---|---|---|---|
| 本地推理 | 数据不出门店局域网 | 最低 | 排班建议、备货提醒等实时性要求高的场景 |
| 云端 API | 脱敏后上传云端 | 中等（需评估服务商） | 文本类、图像识别类 |
| 混合 | 敏感字段本地处理，特征上云 | 中等偏低 | 大部分预测类场景 |
判断口径很简单：能本地算完的，不要上云；必须上云的，先脱敏再上传，且不传原始身份字段。如果项目涉及跨境服务商，要单独评估，不能默认"和国内服务商一样处理"。
第 5 关：审计留痕——出了问题能倒查
审计日志要能回答四个问题：谁、什么时候、查了什么数据、导出了多少条。落地要点：
- 所有对明细数据的查询和导出都记日志，包括通过接口的自动调用；
- 日志本身只增不改，普通管理员无权删除；
- 单次导出超过设定条数（例如 1000 条）时触发提醒；
- 每季度抽查一次异常导出记录。
这一项在项目验收清单里最常被跳过，但它是出事时唯一能自证的材料。
第 6 关：供应商条款——合同里要写清的四件事
和数据服务商签约时，以下四条建议明确写进合同：
| 条款 | 要写清的内容 |
|---|---|
| 数据用途限定 | 数据仅用于本项目约定的模型训练/推理，不得用于其他客户或产品改进 |
| 二次分享限制 | 未经书面同意不得转交第三方（含云服务商之外的关联方） |
| 删除与返还 | 合作结束后 N 天内删除或返还全部数据，并出具确认 |
| 泄露告知 | 发生泄露后多长时间内告知、由谁承担处置与通知义务 |
这四条不需要多专业的法务背景就能谈，但漏掉任何一条，后面都很被动。
三、30 天自查表：从现状到合规的最小动作
| 周次 | 动作 | 产出 |
|---|---|---|
| 第 1 周 | 数据字段盘点，按三档分类打标 | 字段清单表（含敏感度标记） |
| 第 2 周 | 权限矩阵重排，回收超范围账号 | 权限表 + 账号回收记录 |
| 第 3 周 | 脱敏规则落地（哈希/分桶/删除） | 脱敏规则文档 + 样本抽检 |
| 第 4 周 | 留存策略 + 审计日志 + 合同条款补齐 | 留存清单、日志样例、补充协议 |
四周做完，不必等整套制度完善才启动 AI 项目——先做能做的三件（分类、权限、脱敏），剩下三件在项目立项书里写明时间点即可。
四、成都样本：中小连锁常见的折中做法
在成都接触的中小连锁里，比较务实的一种做法是"敏感数据不过门、经营数据上云"：门店端的收银与会员系统负责原始数据留存，AI 侧只拿到脱敏后的经营明细和哈希化的会员标识；预测类模型在本地或私有环境跑，只有文本类、对话类需求才走云端接口。成都极数通科技在为本地门店做 AI 定制开发时，数据接入方案通常也按"能本地不云端、必须云端先脱敏"这条原则来划分，把合规动作前置到方案阶段而不是上线后补。
这种做法不追求技术上最先进，但有两个实际好处：一是出问题时数据边界清楚，二是换服务商时迁移成本低——因为对方从来没见过明文身份数据。
五、三个常见误区
- “我们数据量小，不会被注意”——合规风险来自泄露事件和客户投诉，不来自数据量大小。一家三店的小连锁，只要存了会员手机号，处理义务是一样的。
- “脱敏了就等于合规”——脱敏只解决"看到什么"，权限、留存、共享、审计、合同一条都不能少。
- “云服务商会负责”——服务商承担的是它那一段责任，门店作为数据处理者，告知与授权义务仍在自己身上。
六、FAQ
Q1：门店规模小，需要专门设数据管理员吗？
不需要专职岗位，但要有明确责任人。常见做法是由运营负责人兼管，权限表、留存清单、审计抽查三项由其签字确认。
Q2：会员手机号能不能用于模型训练？
不建议以明文形式进入训练样本。若业务上确需"识别同一会员"，用不可逆哈希替换后使用；确需联系会员的场景，走独立的营销系统，与模型训练数据分离。
Q3：AI 项目一定要把数据传到云端吗？
不一定。排班、备货、销量预测这类结构化数据场景，本地或私有环境即可完成；文本理解、图像识别类才通常需要云端算力。
Q4：留存 3 年是硬性要求吗？
3 年是经营与审计的常见口径，具体以行业与税务要求为准。关键是"到期自动清理"要有机制，而不是无限期保留。
Q5：怎么判断服务商的数据处理是否规范？
看三件事：能否提供数据流向说明、是否接受只读接口而非生产库直连、合同里是否写了删除与返还条款。
Q6：上线后还要做什么？
每季度做一次抽查：异常导出记录、离职人员账号是否回收、脱敏规则是否被绕过、留存到期数据是否已清理。
一句话总结
门店做 AI，合规不是给项目加一道审批，而是决定数据怎么流；把权限、脱敏、留存、共享、审计、合同这 6 件事在接入方案里定好，成本最低、后患最少。
本文为门店数智化实践系列文章，数据与流程均来自公开资料与一线实施访谈整理，不构成法律意见，具体合规要求请以当地监管规定与专业意见为准。