人事数据的保留与删除，是一个用结构就能讲清、用年限却永远讲不清的问题。想知道某个地区要求保存多久，答案取决于当地适用规则；想让系统不因为这个问题出事，答案却只取决于数据被怎么分类、期限被写在哪里、删除有没有覆盖全链路。以下四件事按这个顺序展开。
人事数据要保留多久?
本文不给任何地区、任何类别数据的年限数字，因为这确实因司法辖区而异，由各服务方按其适用的规则与自身业务需要决定。能给的是结构建议：把「期限」从人的记忆和文档里，搬到系统的配置里。
具体来说，期限需要三个要素才能落地——数据类别、期限取值、到期后的动作。三者分开配置，改动时才不需要动代码。期限取值本身应当是策略声明，而不是散落在各处判断语句里的常量；到期后的动作要明确是删除、匿名化还是转入受限归档，这三种结果完全不同，不能靠默认行为决定。
还有一条容易被跳过：期限的起点也需要定义。从数据产生、从流程结束、还是从关系终止起算，会得出完全不同的清理时间。起点不写清，期限配置就只是一串无法执行的数字。
删除人事数据为什么比想象中难?
因为副本比原始记录多。除了主库里的那一条，通常还存在：备份与快照、应用与访问日志、导出文件与报表、数据仓库或分析副本、邮件与消息通知、以及第三方处理方持有的副本。在主库执行一次删除，这些位置大多不受影响。
这就引出「删除要覆盖全链路」的要求。工程上可行的做法是先做一次数据地图：把某个字段从写入到最终消失会经过哪些系统列出来，再逐个确认删除或到期清理的动作。地图不做，删除就只是心理安慰。
同时要承认两个现实。第一，备份通常不能被逐条修改，可行的做法是让备份随保留周期自然过期，并在恢复流程里补做删除。第二，删除操作本身需要留证：谁在什么时候按哪条策略删了什么范围。可问责这条原则，靠的就是这类证据，而不是口头承诺。
几类人事数据的处理差异
同在人事域内，不同类别的数据在用途与敏感度上差别很大，处理时限通常也不同。把它们混成一条策略，是设计阶段最常见的简化。
| 数据类别 | 主要用途 | 处理上的差异 |
|---|---|---|
| 在职期间档案 | 雇佣管理 | 通常在关系存续期间持续维护 |
| 离职后历史记录 | 结算、争议应对、历史核对 | 关系终止后进入独立的清理节奏 |
| 落选候选人材料 | 本次申请评估 | 超出本次流程目的后即应处理 |
| 面试评价与笔记 | 评估与复盘 | 主观性强、敏感度高，通常最短 |
| 汇总统计结果 | 分析 | 需确认无法回溯到个人 |
一个实用判断是：越偏离最初收集目的的数据，越应该早处理。目的限制与最小化收集这两条原则，落实到这里就是「当初为什么收，后来就只能用到哪里」。
落选候选人的材料怎么处理
这是最容易积压的一类数据，因为它没有明确的结束信号——流程结束了，但没有任何人负责收尾。处理它的关键是把收尾写进流程：流程一结束就触发处理动作，而不是等下一次盘点。
如果希望把材料保留下来用于后续机会，这属于超出原始目的的使用，应当向当事人明确说明并取得同意，同时约定保留的边界与撤回方式。没有这层说明，长期保留就失去了依据。
还要注意材料里的连带内容：面试笔记、内部讨论、评分表往往比简历本身更敏感，而且更缺乏格式规范。这类自由文本最容易被漏掉，也最容易在导出与检索时被意外带出。
测试环境为什么不能放真实人事数据
因为测试与演示环境的访问控制、审计与生命周期通常都弱于生产环境，而数据一旦复制出去，删除它就需要把前面那张数据地图再走一遍。默认使用生产数据做测试，等于把风险复制了一份，还削弱了控制。
需要真实分布时，正确做法是使用合成数据。合成数据要求内容自洽、一眼可辨是构造的，并且不指向任何真实个人。这里有一条常见误解值得点明：删掉姓名不等于匿名化——职位、地区、时间、薪资这些字段组合起来，往往足以缩小到很小的范围。可识别的风险来自组合，而不是单个字段。
给开发者：保留策略的落地方式
落地时建议把策略做成一张可读的配置：数据类别、期限起点、期限取值、到期动作、责任方。类别取值受控，到期动作只允许删除、匿名化、转入受限归档这几种，配置变更走评审而不是直接改生产环境。
执行侧要注意三件事。定时任务要幂等，重复执行不能产生副作用；每个批次的处理范围要留下记录，便于回答「这条数据为什么还在」；删除动作要先覆盖派生数据再删主记录，否则中间状态会被下游缓存住。
还要给误删留一道闸。可行的顺序是先标记为待删除，经确认后再执行物理删除，并确保标记状态不会被检索、导出或统计当成有效数据。策略本身也应当被测：断言某类数据到期后确实执行了对应动作，比断言某个函数被调用过更有意义。
还有一个容易被低估的点：策略要能回答历史问题。三个月后如果有人问某条记录当时为什么还留着，答案应当来自当时的策略版本与执行记录，而不是现在的配置。因此策略变更要留版本，执行结果要留范围与时间，这两样加起来才构成可追责的证据链。少了它们，一次检查就只能靠口头说明，而口头说明无法被复核。
本文涉及的档案字段与一致性约束，见职业档案测试数据怎么造；薪资这类高敏感字段的表示与边界，见薪资的币种和周期怎么写；字段口径统一的通用做法见测试数据里的字段一致性。需要一个不含真实个人的档案样本时，可以用职业档案生成器生成。
测试与演示环境不应当使用真实人事数据；本文描述的删除与保留口径针对的是合成内容，删除动作也需要覆盖备份、日志与导出等全链路，而不是只删主库那一行。本文涉及的记录均为合成内容，不对应任何真实个人，也不得用于冒充真实人事资料或通过背景核查。
下一步
写一份数据地图：列出人事域内的数据类别、去向系统与到期动作；再给每类数据指定一个期限起点。然后挑一条最敏感的数据，实际走一遍从主库到备份与日志的删除路径。走通一次之后，剩下的类别只是重复同样的动作。