3.4 行业规范（金融 / 医疗 / 电商等）
一句话
通用合规（等保 / 个保 / 数据出境）定的是所有行业的底线；行业规范定的是底线之上还差多少——它不是法务文档，而是一份别人替你写好的架构决策清单。
先分清三层：谁管你、管到什么程度
看懂行业规范，先看发文主体。层级不同，改架构的力度完全不同。
| 层级 | 典型来源 | 例子 | 违反后果 | 是否改架构 |
|---|---|---|---|---|
| 法律 | 全国人大 | 网络安全法、数据安全法、个保法、电子商务法 | 罚款、停业、刑责 | 会（数据模型、地域） |
| 行政法规 / 部门规章 | 国务院、部委 | 网络数据安全管理条例、互联网诊疗管理办法、非银行支付机构监督管理条例 | 罚款、吊销许可 | 会（业务边界） |
| 行业标准 / 规范 | 标准化委员会、行业协会 | 等保 2.0（GB/T 22239-2019）、JR/T 0197、GB/T 39725、PCI DSS | 过不了测评、拿不到牌照 | 会（技术细节） |
| 合同 / 平台规则 | 甲方、卡组织、云厂商 | 银行科技外包协议、苹果 App 审核、支付机构入网协议 | 违约、下架、终止合作 | 会（部署与审计） |
🔑 行业规范里 80% 的条款最终会变成三类东西：数据保留期、数据可见范围、部署地域。 剩下的 20% 是流程（双录、审核、备案），也会反向要求系统留痕。
一张总表：四个行业的监管与硬约束
| 行业 | 主要监管 | 核心法规 / 标准 | 最容易踩的架构红线 | 关键保留期 |
|---|---|---|---|---|
| 金融 | 央行、金融监管总局、证监会 | 等保三级、JR/T 0197（数据分级）、JR/T 0171（个人金融信息）、PCI DSS、反洗钱 | 支付卡数据不能落库、账务不可篡改、灾备分级 | 交易与身份记录 ≥ 5 年 |
| 医疗 | 卫健委、药监局、网信办 | 病历管理规定、GB/T 39725（健康医疗数据分级）、互联网诊疗管理办法、医疗器械软件注册 | 病历保存 15/30 年、诊疗边界、人类遗传资源不出境 | 门诊 ≥ 15 年，住院 ≥ 30 年 |
| 电商 | 市场监管总局 | 电子商务法、网络交易监督管理办法、消保法、广告法/价格法 | 交易信息留存 3 年、二清、七天无理由状态机 | 商品与服务信息、交易信息 ≥ 3 年；直播视频 ≥ 3 年 |
| 其它 | 各行业主管 | 双减、实名收寄、防沉迷、汽车数据规定、生成式 AI 暂行办法 | 资质准入、未成年人保护、重要数据境内存储 | 按行业单独定 |
读法：先在这一行里找到自己的行业，再看"红线"那一列——红线就是需求评审时必须先问的那几个问题。
3.4.1 金融行业
一句话
金融合规的本质是**"钱和凭证不能算错、不能丢、不能被人看到"**，所以它把架构逼向三件事：账本不可变、密钥分级、灾备分级。
监管地图：四个方向，四条不同的手
| 方向 | 管什么 | 落到架构 |
|---|---|---|
| 网络安全等级保护 | 系统本身的安全基线 | 核心系统按三级建设，三级及以上每年测评一次 |
| 数据安全（央行体系） | 数据分级、生命周期 | JR/T 0197 把金融数据分 1–5 级；JR/T 0171 把个人金融信息分 C1/C2/C3 |
| 支付卡（卡组织） | 卡数据的存储与传输 | PCI DSS，12 类要求，PAN 必须加密或截断，CVV 一律不得存储 |
| 反洗钱 / 反诈 | 谁在做交易、钱从哪来 | 客户身份资料与交易记录，自业务关系结束起保存 ≥ 5 年 |
个人金融信息的 C1/C2/C3：这张表决定了加密粒度
| 级别 | 内容 | 存储要求 | 典型架构动作 |
|---|---|---|---|
| C1 | 账户开立时间、开户机构等 | 可明文，需访问控制 | 普通库表 + RBAC |
| C2 | 姓名、手机号、证件号、卡号（不含有效期） | 传输加密，展示脱敏 | 字段级加密 + 脱敏视图 |
| C3 | 账户密码、磁道/芯片等效数据、生物识别、CVV | 不得明文存储，原则上不得出境 | 专用加密机 / HSM，独立密钥域，禁止进数据仓库 |
⚠️ C3 数据不能出现在任何"方便取用"的地方：日志、埋点、测试库、数仓宽表、离线特征平台。一次"为了方便排查把卡号打进日志"，就是一次完整的数据泄露事件。
PCI DSS：12 条要求收敛成 4 件事
PCI DSS 原文有 12 类要求、几百条细则，落到工程上只有四句话：
| 收敛后 | 具体要求 | 常见做法 |
|---|---|---|
| 别存 | CVV2/PIN/磁道数据任何形式都不得存储 | 收单走支付机构页面，卡号不进自己的库 |
| 存了就得藏 | PAN 加密或截断，密钥与数据分离 | 令牌化（tokenization），业务系统只见 token |
| 网要切开 | 持卡人数据环境（CDE）与其它网段隔离 | 独立 VPC / 子网 + 最小权限 |
| 留下证据 | 访问日志留存 12 个月，其中最近 3 个月可即时查询 | 集中日志 + WORM 存储 |
🔑 "我们加密了卡号"不等于过 PCI DSS。只要 CVV 落过一次库，就是不合格——因为它证明你的系统有能力拿到它。
账务：账本只能追加，不能修改
| 反模式 | 合规后果 | 正确做法 |
|---|---|---|
余额字段直接 UPDATE | 无法解释"钱怎么变成这个数" | 复式记账：每笔动账产生借贷两条分录，余额是分录的派生值 |
| 允许改历史流水 | 对账与审计失效 | 冲正 / 反向分录，不修改原记录 |
| 只有最终状态，没有中间态 | 纠纷时无法举证 | 状态机全量留痕 + 不可变日志（追加写，带哈希链） |
对账是合规的落地形式，不是运维的补充工作：T+1 对账差异率要能算出来、能追到单笔，差异必须进入人工处理队列而不是被静默吞掉。
灾备：分级不是选配
| 灾难恢复能力等级 | RPO | RTO | 典型架构 |
|---|---|---|---|
| 1–2 级 | 天级 | 数天 | 本地备份，异地介质 |
| 3–4 级 | 小时级 | 数小时–1 天 | 同城备份中心，数据定期传输 |
| 5 级 | 秒级–分钟级 | 分钟级–数小时 | 同城双活 + 异地异步复制 |
| 6 级 | 0 | 分钟级 | 两地三中心 / 多活，远程集群切换 |
💡 通用框架来自 GB/T 20988《信息系统灾难恢复规范》，金融业普遍要求核心系统达到 5 级以上。灾备等级不是"越高越好"，而是和这笔业务停一分钟的损失对齐——对不齐就是浪费，对齐不了就是风险。
反模式
| 反模式 | 后果 |
|---|---|
| "先上业务，合规后补" | 数据模型里没有分级字段、没有保留期，后补等于重做存储与迁移 |
| 卡号进了日志 / 埋点 / 测试数据 | 直接构成数据泄露，PCI DSS 与个保法双重违规 |
| 只用一张宽表存"用户 + 账户 + 额度" | 无法做字段级加密与权限隔离，测评必挂 |
| 把"审计日志"和"业务日志"混在一个库 | 日志可被业务侧删除，取证时无效 |
| 灾备只做备份，不做切换演练 | 真切换时 RTO 是未知数，纸面 SLA 归零 |
3.4.2 医疗行业
一句话
医疗合规的本质是**"这条数据是诊疗证据，几十年后还要能举证"**，所以它把架构逼向两件事：超长保留期 + 全链路留痕。
监管地图
| 方向 | 管什么 | 关键条款 / 数字 |
|---|---|---|
| 病历管理 | 谁能看、存多久、怎么举证 | 门诊病历自最后一次就诊起 ≥ 15 年；住院病历自最后一次出院起 ≥ 30 年；电子病历与纸质病历具有同等效力 |
| 健康医疗数据分级 | 数据敏感度 | GB/T 39725-2020 把健康医疗数据分 1–5 级，5 级最严 |
| 互联网诊疗 | 线上能做什么、不能做什么 | 只能做复诊，不得对首诊患者开展互联网诊疗；医师需 3 年以上独立临床工作经验 |
| 医疗器械软件（SaMD） | 软件本身是不是"医疗器械" | 按风险分二类 / 三类，需 NMPA 注册，注册前不能商用 |
| 人类遗传资源 | 基因数据能不能出境 | 原则上不出境，国际合作需审批/备案 |
病历保留：15 年 / 30 年是架构参数，不是运维参数
| 数据 | 保留期 | 架构含义 |
|---|---|---|
| 门诊病历 | ≥ 15 年 | 存储必须支持"冷热分层 + 在线可查"，不能只留热库 |
| 住院病历 | ≥ 30 年 | 跨越 3–4 代技术栈，格式迁移与可读性必须提前设计 |
| 处方 | 普通 1 年；毒性药品/二类精神 2 年；麻醉/一类精神 3 年 | 按类别打标签，删除任务按标签分流 |
| 医学影像 | 按病历同等对待 | 一次 CT 约 100–500 MB，一家三甲年增 数十 TB，必须对象存储 + 生命周期 |
🔑 超长保留期最大的坑不是容量，是可读性。 30 年后打开一份 2015 年的影像，需要的是"格式迁移策略 + 校验和 + 元数据独立可读"，而不是一块更大的硬盘。
诊疗边界：一张表决定你能不能上这个功能
| 能力 | 允许？ | 依据 / 条件 |
|---|---|---|
| 线上复诊、开方、续方 | ✅ | 有实体医疗机构依托，医师有 3 年以上独立临床经验 |
| 线上首诊 | ❌ | 互联网诊疗管理办法明确禁止 |
| 线上开具麻醉 / 精神 / 毒性药品 | ❌ | 明确禁止 |
| AI 辅助诊断直接出报告 | ❌ | 属医疗器械软件，需注册；未注册只能做"辅助提示 + 医师确认" |
| AI 健康咨询、导诊、病历摘要 | ⚠️ | 不构成诊断结论、不替代医师，仍需内容与资质审查 |
| 患者数据用于科研 | ⚠️ | 需伦理审查 + 去标识化 + 授权范围明确 |
这条边界不是产品边界，是牌照边界：越过它，产品性质从"工具"变成"诊疗行为"或"医疗器械"，需要重新取证。
反模式
| 反模式 | 后果 |
|---|---|
| 用"删除用户"功能处理病历 | 违反病历管理规定，且破坏举证链；正确做法是归档 + 权限收紧，而非物理删除 |
| 影像存在业务库或本地磁盘阵列 | 容量 3 年内必炸，且无法做异地副本 |
| 把 AI 结论直接写进诊断栏 | 无注册证即属违规使用医疗器械 |
| 病历正文用可编辑文档格式存储 | 无法证明"未被修改"，举证时失效（需签名/时间戳/哈希链） |
| 基因数据放在公有云默认区域 | 触碰人类遗传资源与数据出境双重红线 |
3.4.3 电商行业
一句话
电商合规的本质是**"平台对平台上的每一笔交易都要能举证、能追溯、不能碰钱"**，所以它把架构逼向两件事：全量留痕 3 年 + 资金不过平台账户。
监管地图
| 方向 | 管什么 | 关键数字 |
|---|---|---|
| 电子商务法 | 平台责任、信息留存 | 商品与服务信息、交易信息自交易完成起保存 ≥ 3 年 |
| 网络交易监督管理办法 | 经营者登记、直播带货 | 年交易额累计 ≤ 10 万元 的个人可免于市场主体登记；直播视频自直播结束起保存 ≥ 3 年 |
| 消费者权益保护法 | 七天无理由退货 | 4 类法定除外 + "商品完好"前提 |
| 价格法 / 明码标价规定 | 促销、原价、划线价 | "原价"须为促销活动前 7 日内最低成交价 |
| 支付合规（二清） | 平台能不能碰钱 | 无牌照不得归集资金再结算，必须持牌机构分账或银行存管 |
| 广告法 | 宣传用语 | 禁用"国家级""最高级""第一"等绝对化用语 |
平台责任三件套：资质、留痕、不碰钱
| 责任 | 具体动作 | 架构落点 |
|---|---|---|
| 资质核验 | 入驻商家身份、地址、联系方式、行政许可核验并建档，定期更新 | 商家主数据 + 证照 OCR + 到期提醒 + 核验操作留痕 |
| 信息留存 | 商品信息、交易信息、直播视频留存 3 年 | 冷热分层 + 对象存储生命周期 + 不可提前删除 |
| 不碰钱（二清） | 平台不得形成资金池 | 持牌支付机构分账 / 银行存管，平台只做订单与分账指令 |
🔑 "平台先收钱、再统一结算给商家"= 二清。 这是电商最容易被忽视的牌照红线，也是最贵的一次重构：资金流一旦设计成"平台账户中转"，改回来要动订单、结算、发票、对账四条链路。
七天无理由：本质是状态机，不是按钮
| 环节 | 合规要求 | 设计要点 |
|---|---|---|
| 起算点 | 自签收次日起 7 日 | 必须记录签收时间（来自物流回传），不能用下单时间 |
| 除外商品 | 定作、鲜活易腐、在线下载/拆封音像制品、报刊 | 商品维度打标，下单页显著提示并留证 |
| 前提 | 商品完好 | 质检结论作为退款/拒退依据，需留痕 |
| 退款时效 | 收到退货后 7 日内退款 | 逆向流程要有 SLA 与超时告警 |
| 与结算冲突 | 已结算给商家的订单仍可能退货 | 结算周期与售后窗口解耦，用保证金/延迟结算兜底 |
架构含义：订单状态机必须能表达"已结算但可退"，资金侧要能发起逆向结算（从商家待结算余额或保证金扣回），而不是假设"结算即终态"。
促销与价格：合规要求直接约束数据模型
- 原价校验：促销前 7 日最低成交价必须可查 → 需要保留历史价格快照，而不是只存当前价。
- 划线价/比价：无依据的划线价属价格欺诈 → 价格表要能回答"这个价格什么时候真实成交过"。
- 绝对化用语：商品标题、详情、直播话术中禁止 → 上线前的文本审核 + 词库拦截。
反模式
| 反模式 | 后果 |
|---|---|
| 交易表只存当前状态，覆盖式更新 | 3 年举证义务无法履行，纠纷时无据可依 |
| 直播视频"存 7 天就够了" | 违反 3 年留存要求，且投诉无法自证 |
| 平台账户归集货款再打给商家 | 二清，无牌照即违法经营支付业务 |
| 用下单时间算七天无理由 | 预售/长物流场景下必然算错，产生集中投诉 |
| 价格表只存当前价 | 大促前调价无法举证，"原价"被认定虚构 |
| 商家资质只做一次性审核 | 证照过期仍在售，平台承担连带责任 |
3.4.4 其它行业速查
| 行业 | 关键规范 | 一条硬约束 | 架构落点 |
|---|---|---|---|
| 教育 | 双减、校外培训监管、预付费资金监管 | 预收费不得超过 3 个月或 60 课时，资金需银行托管 | 课时/有效期双维度计费 + 托管账户对账 |
| 物流快递 | 邮件快件实名收寄管理办法 | 寄件人身份必须实名核验并留存 | 实名三要素核验 + 运单与身份分离存储 |
| 游戏 | 防沉迷、版号、抽卡概率公示 | 未成年人仅可在周五六日及法定节假日 20:00–21:00 游戏，每周 3 小时 | 实名 + 时段网关 + 概率公示接口 |
| 汽车 / 车联网 | 汽车数据安全管理若干规定（试行） | 重要数据境内存储；车外人脸、车牌默认匿名化 | 车端脱敏 + 境内 region 闭环 |
| 生成式 AI | 生成式人工智能服务管理暂行办法、AI 生成内容标识办法 | 面向公众服务需备案/安全评估，生成内容需显式 + 隐式标识 | 语料台账 + 输出水印 + 内容审核链路 |
| 招聘 / 人力资源 | 个人信息保护法（敏感信息）、人力资源市场条例 | 简历属个人信息，求职者授权范围外的用途一律禁止 | 用途绑定授权 + 到期回收 |
💡 判断自己受哪条管，只问一句："我这个业务需不需要牌照/备案？" 需要 → 行业规范就是准入条件，先于架构；不需要 → 行业规范仍是行为边界，落在数据与流程上。
3.4.5 把行业规范翻译成架构约束
四步法
| 步骤 | 动作 | 产出 |
|---|---|---|
| ① 定身份 | 我是持牌机构、平台方，还是技术服务商？ | 责任边界（谁的义务传导到我） |
| ② 找标准 | 按行业找"法规 + 国标/行标 + 平台规则"三层 | 条款清单 |
| ③ 抽硬约束 | 只保留能落成数字的：保留期、可见范围、地域、时效 | 约束表（进需求文档） |
| ④ 落架构 | 每条约束对应一个存储/权限/流程设计 + 一个验收方式 | 架构决策记录（ADR） |
约束 → 架构 → 验收
| 合规约束 | 架构动作 | 怎么验收 |
|---|---|---|
| 交易记录保留 ≥ 5 年 | 追加写账本 + 冷热分层 + 禁止硬删 | 抽查 5 年前流水可查、可导出 |
| 病历保留 ≥ 30 年 | 对象存储 + 格式迁移计划 + 校验和 | 迁移演练：打开 10 年前影像 |
| 卡号不得落库 | 令牌化，业务系统只存 token | 全库扫描：正则匹配 16 位卡号零命中 |
| 数据不得出境 | 境内 region 闭环，禁用境外 CDN/日志/AI 接口 | 出网流量审计 + 第三方 SDK 清单 |
| 操作可追溯 | 不可变审计日志（WORM / 哈希链） | 尝试删除一条审计记录应失败 |
| 双录 / 电子签名可举证 | 可信时间戳 + 存证哈希 + 原件不可改 | 随机抽一笔，能还原完整证据链 |
一个最小可用的保留策略实现
package retention
import "time"
// Record 一条同时受多部法规约束的业务记录
type Record struct {
Kind string // payment_txn / medical_record / order
CreatedAt time.Time
LegalHold bool // 诉讼、监管调查期间冻结，任何删除请求都不得穿透
}
// MinRetention 每个数据类别的最短保留期：取所有适用法规中的上界
var MinRetention = map[string]time.Duration{
"payment_txn": 5 * 365 * 24 * time.Hour, // 反洗钱：交易记录 ≥ 5 年
"medical_record": 30 * 365 * 24 * time.Hour, // 住院病历 ≥ 30 年
"order": 3 * 365 * 24 * time.Hour, // 电子商务法：交易信息 ≥ 3 年
}
// CanDelete 只有"已过保留期"且"无法务冻结"才允许物理删除
func CanDelete(r Record, now time.Time) bool {
if r.LegalHold {
return false // 法务保留优先于用户删除请求
}
keep, ok := MinRetention[r.Kind]
if !ok {
return true // 未分类数据走通用策略，此处从简
}
return now.Sub(r.CreatedAt) >= keep
}
两个必须写进需求文档的语义：
- 删除请求先过保留期闸门——"用户要求删"和"法规要求留"冲突时，正确做法是停止对外使用 + 到期自动删除，而不是当场物理删除。
- 保留期是下限不是上限——超过保留期的数据该删就删，长期无差别囤积本身就是个保法意义上的风险。
反模式
| 反模式 | 后果 |
|---|---|
| 把行业规范当法务的事，架构评审不参与 | 上线前才发现数据模型不满足，重构成本 10 倍 |
| 只满足"法条文字"，不理解监管意图 | 形式合规、实质违规，检查时一击即溃 |
| 所有行业规范同等对待 | 把"建议"当"强制"，做了大量无用设计；把"强制"当"建议"，直接违规 |
| 用一份保留策略覆盖所有数据 | 该留的删了（举证失败），该删的留了（个保违规） |
| 合规只做在应用层，不做在存储层 | 应用层可以绕过（运维、导数、备份），等于没做 |
| 第三方 SDK / 云服务不做合规清单 | 数据从"合法通道"出境，责任仍在自己 |
| 把 “行业惯例” 当 “合规要求” | 按旧惯例实现，新规一出就返工 |
三条铁律
🔑 行业规范先定"能不能做"，再谈"怎么做"。 牌照与准入是 0，技术方案是后面的 1——顺序错了，代码写得再好也是废的。
🔑 凡是"保留 N 年"的条款，都要同时设计"到期怎么删"。 只设计保留不设计删除，等于把合规风险从"缺数据"换成"多数据"。
🔑 合规约束一律不可协商，且必须写进非功能性需求并配上验收方式（见 1.1 功能性需求与非功能性需求）。写不进验收清单的合规要求，等于没提。
自检
Q1 客户说"我们只是给医院做 SaaS，不拥有病历，所以 30 年保留期跟我们无关"。这句话哪里错了？
▸ 答案：错在把责任主体和技术义务混为一谈。病历的保管责任确实在医疗机构，但系统一旦承载病历数据，保留期、不可篡改、访问审计、异地副本这些要求会通过合同与等保测评完整传导给技术方；而且"SaaS 里存了病历"就意味着数据生命周期由你的代码决定——删早了是销毁证据，删晚了是违规留存。
Q2 电商平台设计成"用户付款到平台账户，T+7 自动结算给商家"，为什么必须改？
▸ 答案：这是典型的二清（二次清算）——平台无支付牌照却归集资金、形成资金池，属违法经营支付业务。改法是资金流直连持牌机构：平台只下发分账指令，钱从买家到持牌机构再到商家，平台账户不出现沉淀资金。注意它连带影响订单、结算、发票、对账四条链路，越晚改越贵。
Q3 用户依据个保法要求删除自己的交易记录，但这笔交易受反洗钱 5 年保留约束，怎么处理？
▸ 答案：法定保留优先于删除请求，但不能因此"什么都不做"。正确做法：停止对外使用与加工（限制处理目的）、屏蔽非必要展示、进入"冻结待删"状态、到期（5 年）后自动物理删除，并把这一处理结果书面告知用户。物理删除与拒删都是错的。
Q4 订单系统用"下单时间 + 7 天"判断七天无理由，为什么在大促后会集中爆投诉？
▸ 答案：起算点是签收次日，不是下单日。预售、长物流、分批发货场景下，两者可能差 10 天以上——按下单日算会提前关窗，用户实际还在窗口内却被拒绝。必须落库"签收时间"（物流回传事件），并对分批签收按最后一批计算。
Q5 你们把卡号做了 AES 加密存储，但为了排查问题把 CVV 也一起存了。这样算过 PCI DSS 吗？
▸ 答案：不算，且这是硬性不合格。敏感认证数据（CVV2/CVC2、完整磁道、PIN）在任何情况下都不得存储，加密也不行——因为"存在"就意味着系统具备取用能力。正确路径是收单环节不经过自己的服务器（跳转/令牌化），让敏感数据根本不进入自己的系统边界。
Q6 为什么行业规范必须在需求阶段进入，而不是等上线前找合规团队过一遍？
▸ 答案：因为它改的是数据模型（分级字段、保留期、签收时间）、部署地域、资金链路、账本结构这四样东西。这些是架构的骨架，上线后修改意味着数据迁移、双写、灰度切换甚至业务停摆；而在需求阶段，它们只是表格里多几列。参照 1.1 的结论：约束不可谈，但要早谈。