## 用户数据请求响应跟踪 {.case data-case-id="052"} | 字段 | 值 | | --- | --- | | 案例编号 | `052` | | 行业 / 部门 | 互联网 / 法务合规 | | 角色 | DPO（数据保护负责人） | | 难度 | `复杂` | | 调用来源 | `manual`（收到用户数据请求后由法务发起一次手动调用，带入请求登记的令牌化条目——请求编号、节点状态与时间戳） | 用户行使数据权利的请求有时限，逾期就是违规。目标：收到请求后由法务发起一次手动调用，带入请求登记，按法定时限跟踪"验证身份、数据定位、法务审核、导出或删除执行确认"四个节点；节点按时完成发回执，临期或逾期强制升级 DPO 人工确认后处理。设一条最高优先级红线：临期或逾期一律强制升级，绝不自动跳过法务审核。时限判定只用登记的系统时间戳，全程证据留痕；用户个人数据不进入 Agent 消息与运行记录，也不出现在回执，Agent 只见请求编号、状态、法定时限与时间戳。指标：法定时限内办结率 100%；红线命中后自动跳过审核 0 例。 - **覆盖**：手动发起一次性请求跟踪、按法定时限跟踪四个节点、按时完成发回执、临期或逾期强制升级 DPO、登记系统不可达按取数失败处理、登记信息缺失告警要求新开调用。 - **不覆盖**：自动验证用户身份、自动定位与导出数据、自动执行删除、自动生成正式答复文书。 - **假设**：请求登记含请求编号、请求类型、受理时间戳、法定时限；App/Extension 在读取侧完成脱敏，Agent 只接收白名单字段；各节点完成时间戳取自登记的系统记录，缺失标"待确认"单列；实际操作由业务与法务人员在既有系统完成。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：收到用户数据请求后由法务发起一次手动调用，带入请求登记（请求编号、请求类型、受理时间戳、法定时限、各节点时间戳），按法定时限跟踪四个节点：验证身份 → 数据定位 → 法务审核 → 导出或删除执行确认，逐节点核对完成状态并返回（请求编号、节点、状态、时间戳、操作人角色代号）。源头脱敏：App/Extension 在读取侧即完成聚合与脱敏，Agent 只接收请求编号、节点状态、法定时限、时间戳与操作人角色代号等白名单字段，用户个人数据与操作人姓名原文不进入 Agent 消息与运行记录。证据留痕：每步留时间戳与操作人角色代号；用户个人数据不出现在回执，只有请求编号与状态。 触发：手动发起一次调用，调用时带入请求登记的令牌化条目（请求编号、请求类型、法定时限、各节点时间戳）、团队频道、审批人。 时限判定：只用登记的系统时间戳，时间戳缺失的节点标"待确认"单列，由人工补全后再判，不猜。 结果分流（临期或逾期是最高优先级红线，先判红线再判进度）： 临期或逾期（临近法定时限或已逾期）：无论各节点进度如何，一律强制升级 DPO 人工确认后处理，绝不自动跳过法务审核——命中即短路，优先于一切进度路径；升级与处理决定都留审计时间戳。 按时推进：节点完成即发回执并留时间戳与操作人角色代号；四节点全部按时完成发办结回执并留审计。 登记系统不可达（系统连不上、查询失败）：取数失败，告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道；不当作"按时推进"，也不当作登记不完整。 登记信息缺失（系统查得到但受理时间戳或法定时限字段缺失）：这是业务数据缺失不是系统故障，告警并留审计时间戳，通知调用方补全登记后新开一次调用，本流程不重试、不用估计值补时限。 审批：临期或逾期的处理路径必须经 DPO 人工确认；审批为二值确认或驳回，不设自动超时，无默认通过/否决；确认或驳回都留审计时间戳，不自动跳过法务审核。 异常：跟踪 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发；登记时间戳缺失的节点一律单列"待确认"，不猜；登记系统不可达与登记信息缺失分开处理，不互相顶替。 完成：办结回执或升级处理留审计时间戳后结束。 ``` ![案例 052 用户数据请求响应跟踪：法务手动发起一次调用带入请求登记，按法定时限跟踪验证身份、数据定位、法务审核、导出或删除执行确认四节点；临期或逾期无论进度强制升级 DPO 人工确认、绝不自动跳过法务审核，按时推进节点完成发回执留时间戳与操作人角色代号，四节点办结发回执；时间戳缺失标待确认单列，登记系统不可达按取数失败告警重试升级、登记信息缺失告警留审计新开调用不重试；用户个人数据不进入 Agent 消息与回执，只有请求编号与状态](../../../media/cases/fig-case-052-01-flow.svg){#fig-case-052-01 width=92%} 如上图所示，正常路径、人工决策与异常同时可见： 1. **手动触发**：收到用户数据请求后由法务发起一次调用，带入请求登记（请求编号、请求类型、受理时间戳、法定时限、各节点时间戳）、团队频道与审批人。 2. **逐节点跟踪**：App/Extension 在读取侧完成脱敏，Agent 只接收白名单字段，按法定时限核对"验证身份 → 数据定位 → 法务审核 → 导出或删除执行确认"四节点的完成状态并回传（请求编号、节点、状态、时间戳、操作人角色代号）；回传结构不合要求时停在原等待点，等其重新提交，不自动重跑。 3. **五路分流（先判红线）**： - **临期或逾期（红线）**：临近法定时限或已逾期，无论各节点进度如何，强制升级 DPO 人工确认后处理，绝不自动跳过法务审核；升级与处理决定都留审计时间戳。 - **按时推进**：节点完成即发回执并留时间戳与操作人角色代号；四节点全部按时完成发办结回执并留审计。 - **时间戳缺失·待确认**：登记时间戳缺失的节点单列，由人工补全后再判，不并入按时也不并入逾期。 - **登记系统不可达**：系统连不上、查询失败，取数失败，告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道；不当作"按时推进"，也不当作登记信息缺失。 - **登记信息缺失**：系统查得到但缺受理时间戳或法定时限，告警、留审计时间戳，通知调用方补全登记后新开一次调用，不重试、不用估计值补时限。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"手动调用 + 逐节点时限跟踪 + 红线强制升级"五路分流流程——它知道"核对节点"需要一个发消息并等待回调的 Agent 环节、"先判红线再判进度"需要一个条件路由且红线优先级最高、"DPO 确认"需要一个审批环节、"回执与升级"各需要一个发消息环节。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。 - **临期或逾期被静默吞掉**：这是最危险的失败。靠两层兜底——把"临期或逾期"设为永远强制升级 DPO 的红线，命中即短路；回执逐条附时间戳与操作人角色代号，事后抽查可回溯，发现漏判即人工补升级并留审计。 - **为赶时限跳过法务审核**：即使逾期，法务审核节点也不能被自动标记为完成——宁可带着逾期记录走人工处理，也不能用违规换时限。 - **登记系统不可达**：系统连不上、查询失败，告警失败、留审计时间戳，按重试上限重试，仍失败则升级值班频道；这是取数失败，不是登记信息缺失，也不是"按时推进"。 - **登记信息缺失**：系统查得到但缺受理时间戳或法定时限时告警、留审计时间戳，通知调用方补全登记后新开一次调用，本流程不重试——时限算不出来，跟踪无从谈起，也不用估计值补。 - **节点时间戳缺失**：不猜，单列"待确认"由人工补全后再判；不并入按时也不并入逾期。 - **通知发送失败**：按重试上限重试投递；超过上限则升级值班频道，并保留待发内容供人工补发。 - **跟踪 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其重新提交，不自动重跑。 - **长时间无人审批**：审批本身不设自动超时，流程停在等待状态。若要时限提醒，由另一条定时检查的 Workflow（或值班人员）扫出超时项并通知 DPO。 临期或逾期的处理路径必须经 DPO 人工确认。确认时 DPO 能看到请求编号、当前节点、剩余或超出时限、已完成节点的时间戳与操作人角色代号，所以是"有依据的快速决策"而非盲目拍板。审批为二值确认或驳回，不设自动超时，无默认通过/否决；要改派处理人属于驳回后由 DPO 在系统侧另行指派，流程侧按驳回留审计，没有"AI 自动改判"。按时推进的请求不需要审批，节点回执直接发出。若监管要求更严（如删除类请求全程逐节点确认），在提示词里写明，AI 会在每个节点后各加一个审批环节。 本工作流对各节点完成状态的核对由获授权 Agent 通过 App/Extension 读取请求登记系统完成，工作流本身不直接调用外部系统。请求登记作为调用输入提供；登记系统的访问凭据用 `` 占位，由 Agent 运行时从密钥引用。登记系统不可达按取数失败处理：告警、留审计时间戳，按重试上限重试，仍失败则升级值班频道，不当作"按时推进"。回执遵循最小披露：用户个人数据不出现在回执，只有请求编号与状态，全程每步留时间戳与操作人角色代号。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段以白名单为准（请求编号、节点状态、法定时限、时间戳、操作人角色代号，仅令牌化/白名单字段，原值不进入以上任何一层），用户个人数据与操作人姓名原文在源头即被脱敏，并按 10% 抽查四层实际记录；登记系统不可达与登记信息缺失分别走取数失败与告警新开调用。 - **回放集与基准**：取最近 6 个月 60 条请求登记（含按时办结、临期、逾期、时间戳缺失样本）回放，人工基准为按法定时限判定的节点进度与应升级清单；进度判定与基准一致率 ≥ 95%。 - **红线防线**：基准为临期或逾期的请求 100% 升级 DPO，自动跳过法务审核 0 例；法定时限内办结率 100%。 - **证据留痕**：每步 100% 留时间戳与操作人角色代号，抽查 10 步与登记记录一致，判定可回溯。 - **口径纪律**：时限判定只用登记系统时间戳 100%；时间戳缺失节点 100% 单列"待确认"，被猜成按时或逾期 0 例。 - **最小披露**：回执 100% 不含用户个人数据，按 10% 抽样核对只有请求编号与状态。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（仅令牌化/白名单字段，原值不进入以上任何一层），用户个人数据原文出现 0 次，按 10% 抽查四层实际记录。 - **失败与缺失分开**：登记系统不可达 100% 按取数失败重试升级、登记信息缺失 100% 告警新开调用，两者被互相顶替 0 例。 - **结果可见**：节点回执、办结回执、升级处理、登记信息缺失、取数失败五类结果 100% 各有可见回执；一致率分母为回放请求总数；每次运行记录跟踪与升级时间戳。 ### 复用与变体 - **同构迁移**：监管投诉答复时限跟踪、执法调证响应跟踪、子处理者审计整改跟踪。 - **分级时限**：删除类请求时限更短、红线阈值更紧，在提示词里写明，AI 会按请求类型分别路由。 - **写回登记系统**：办结后再加一个 Agent 环节，把办结结论与时间戳写回请求登记；写回须是获授权 Agent 经 App/Extension 的幂等动作（幂等键=请求编号+节点），响应未知先查后写、按重试上限有限重试、失败升级值班并置"待处理"保留补偿，全程留审计。若不需要写侧能力，改为只读汇总或仅留 Loop 回执更安全。