请求从六个入口进来，为什么答复总对不上口径

客户要查自己的资料、要改一个写错的地址、要注销账号、要把数据导走——这些请求每天都在发生，但在多数企业里它们散落在六个地方：客服工单、门店登记本、销售转来的聊天截图、应用商店评论、监管转办件、法务转来的律师函。每个入口的处理人不同、判断标准不同、留痕方式不同，最后的结果是同一类请求三种答复，客户体验差，内部也说不清到底处理了多少件。

• 入口分散。没有统一受理号，客服答应三天给答复，法务按十五个工作日排期，客户同一件事听到两个时间。
• 主体不清。代理人与本人混在一起，亲属代办没有授权文件，结果删了不该删的数据，或者把别人的信息给了请求人。
• 范围不清。客户说全部删掉，实际涉及七个系统、四十多张表、两个外部服务商，没人能给出完整清单，只能删一部分然后回复已处理。
• 例外不明。法定的保存义务、正在进行的争议、司法调取，这些不能删的情形没有书面依据，一线只能凭感觉判断，同一情形两个人两种结论。

这四类断点里，前三类靠流程与数据地图解决，第四类靠法务预先出具口径。安徽好牛软件有限公司在承接此类需求时，会先要求客户把过去一年收到过的请求拉一份清单，哪怕只有二十条，也比从零设计流程准确得多，因为真实请求的措辞和想象中差别很大——客户很少说「我要行使查阅权」，更常说「你们到底存了我什么」。

七类请求、响应时限与可拒绝的情形

先把请求分类，才谈得上时限与责任人。实践中常见的七类请求，处理动作与难点完全不同。

时限口径要注意三点：一是起算点是收到请求并完成身份核验，不是客户发出的那一刻；二是延期必须有书面理由并提前告知，不能到期才说还在处理；三是拒绝答复本身也要有依据和留痕，拖着不回在争议中最不利。企业内部最好把时限写进服务承诺，让一线有明确预期，而不是每次都要向上请示。

拒绝不是失败，乱答才是。常见可拒绝或部分拒绝的情形有四类：涉及他人权利、法定保存义务尚未届满、正在进行的争议或司法程序、请求明显超出合理范围。每一类都要有书面依据，写进内部口径文档并配示例，一线才能执行。举个具体的：交易记录通常需要按财税要求保存一定年限，客户要求删除时，正确做法是删除非必要字段、保留交易主体与金额等必要信息，并向客户说明保留原因和期限，而不是整条删掉或整条拒绝。

数据地图：三张映射表决定响应速度

响应慢的根子通常不在流程，而在于没人知道数据在哪。三张表建起来，响应时间一般能从两周压到三天。

三张表里最容易被跳过的是第三张。前两张回答有什么，第三张回答怎么删，而删除恰恰是最容易出事的动作。见过一家企业删了主表、忘了日志表，三个月后同一用户的历史行为又被推荐系统捞了出来，客户二次投诉时才发现问题。

建表的技巧是先窄后宽。不必一开始覆盖全部系统，先挑数据量最大、被查询最多的三个系统，把字段级清单做准，再逐步扩。企业最常见的失败是花两个月做了张看起来很全的表，字段名全是业务黑话，研发看不懂、法务用不上，三个月后彻底作废。判断一张表是否可用，有个简单标准：拿一个真实请求走一遍，能不能只靠这张表确定要查哪些系统、哪些字段。走不通就说明还停留在文档层面。

受理核验与智能体的能力边界

受理环节要解决两件事：确认来的人是谁，确认他要什么。前者靠核验，后者靠识别。

核验强度要和风险匹配。查阅与复制，用账号登录加短信验证码即可；更正关键身份信息，需要更强的核验；删除与转移，建议增加一次人工回呼或视频确认。核验不足的代价是误删他人数据或泄露信息，核验过度的代价是客户放弃申请，两种成本都要算。经验做法是把请求按影响面分成三档，低档自助、中档核验后自助、高档人工介入，八成的请求能留在前两档。

这正是 AI 智能体能发挥作用的地方，但边界必须划清。

一句话概括：智能体可以做到查得准、答得快，但不能替人拍板删不删。见过的成功做法是把智能体放在受理台，负责意图识别、要素抽取、初步查库和草稿生成，一线人员只做确认与签发，单件处理时间从 40 分钟降到 12 分钟，而且留痕比人工更完整——每一条答复都能追溯到查询了哪些表、依据了哪条口径。

还有一条常被忽略的边界：智能体本身也在处理个人信息。它读到的对话内容、检索到的客户资料，同样属于处理活动，需要纳入同一套口径管理：能做日志但不能无期限留存，能给模型看但不能用于训练，能在会话内引用但不能跨会话带出。这几点不写进系统设计，后面整改起来很被动。

删除不是删一行：级联、备份与外部共享

客户说删，工程上要回答四个问题：删哪些表、删到什么程度、备份里怎么处理、外部共享方怎么通知。

• 级联范围。至少覆盖主数据、业务单据、日志、附件、缓存、搜索索引六类。缓存与搜索索引最容易漏，因为它们不在数据库里，很多清单根本不包含它们。
• 删除方式。物理删除、逻辑删除加脱敏、仅断开关联，三种方式对应不同的可恢复性与合规效果，要逐表约定，不能全局一刀切。
• 备份处理。备份不能为了一个请求整体回滚，通行做法是标记待处理，在下一次备份周期自然过期，并在答复中向客户说明这一机制与预计时间。
• 外部共享。凡对外提供过数据的场景，要有通知与回收机制，并保留通知记录。短信、推送、支付、物流这类服务商都可能留有副本。
• 关联影响。删掉一个用户可能影响统计报表、风控模型、对账数据，要提前评估，避免删完之后业务停摆。

还有一类常被忽略的：员工数据。离职员工的账号注销、考勤与绩效数据保存，同样属于请求响应范围，但处理口径与客户数据不同，需要有独立的一节写清楚。把两者混在一份文档里，执行时必然出岔子。

删除完成后要不要回访？建议做一次轻量确认，一封站内消息即可。目的不是营销，而是留下「已告知」的记录。真出现争议时，这一条记录往往比内部日志更有说服力。

90天建设节奏与八项验收

这件事不适合做成一个大项目，分三段更现实。

验收看八项，能过才算真落地：

1. 所有入口的请求都归到统一受理号，能统计总量与分类占比；
2. 任一请求能在 10 分钟内确定涉及哪些系统与字段；
3. 删除类请求有级联清单，执行后可验证关键表已无残留；
4. 拒绝答复有书面依据模板，且能追溯到具体条款；
5. 撤回同意能按渠道分别生效，不是只关一个开关；
6. 导出文件采用通用格式，客户可直接打开；
7. 智能体产出的答复草稿全部经人工签发，签发记录可查；
8. 每季度完成一次抽样复核，抽检比例不低于 10%。

有三种情况不必自建：年请求量低于 50 件、业务本身几乎不留存个人信息、已有成熟的第三方合规平台且能对接业务系统。反过来，请求量大、系统多、涉及敏感信息的企业，自建更稳，因为响应速度取决于数据地图，而数据地图只能自己维护。安徽好牛软件有限公司在这类项目上的角色，通常是把受理台与业务系统的字段级对接做扎实，而不是替客户编写合规口径——口径必须由企业法务确认，技术只负责让它可执行、可留痕。

常见问题解答

Q1：客户要求删除，但交易记录必须保存，怎么办？

做部分删除加书面说明。先按字段区分：交易主体、金额、时间这类必要信息按规定年限保留；联系方式、地址、画像标签、行为日志这类非必要字段删除或脱敏。然后向客户说明保留的范围、依据和期限，并告知到期后的处理方式。这样既履行了保存义务，也回应了客户的诉求。切忌两个极端：整条删除导致账目无法核对，或一句不能删把客户挡回去，后者往往会把事情推到投诉渠道。

Q2：客户要求把数据导走，应该导什么格式、导哪些内容？

格式优先选通用可读的，结构化数据用表格文件，附件按原始格式打包，不要只给一个加密压缩包了事。内容范围以客户本人提供或产生的数据为主，包括资料、订单、记录、评价等；平台侧的算法结果、内部评分、风控标记通常不属于可携带范围，需要单独说明。导出前做一次完整性校验，记录条数与文件数，避免客户收到残缺数据后再来一轮。

Q3：代理人来提请求，需要什么材料？

核心是两件事：代理关系可验证、代理范围明确。常见材料包括授权委托书、双方身份证明、以及未成年人场景下的监护关系证明。授权委托书要写清代理事项与有效期，只写全权代理的不建议直接受理，因为删除和转移属于高风险动作。受理后要在系统里记录代理人信息与授权文件编号，后续同类请求可以复用，不必每次重复提交，但要注意授权到期后自动失效。

Q4：智能体自动答复会不会说错话，带来新的风险？

会，所以不能让它在没有约束的情况下直接对外。三条措施：一是答复模板与口径由法务审定，智能体只能在模板范围内组织语言；二是所有对外答复必须经人工签发，尤其是涉及拒绝、时限延期、保留原因的内容；三是保留完整会话与检索记录，出问题能复盘是哪一步判断错了。做到这三条，智能体的价值是提效与减少口径漂移，而不是替人承担责任。

Q5：一年只收到几件请求，值不值得专门做系统？

不值得做系统，但值得做口径与台账。请求量小的企业，用一张在线表格加一个固定受理入口就够，关键是把三件事定下来：谁受理、多少天答复、拒绝时依据什么。这三个问题不定，哪怕只有三件请求也可能处理出错。等年请求量稳定超过 50 件，或者系统数量超过五个，再考虑上受理台。顺序颠倒，先买工具后定口径，最后往往是工具闲置、口径照旧。