怎么做一次数据流梳理How to map a data flow

数据流梳理是把一条链路上的字段走向画成能核对的图。 它的价值在把「我们不看客户数据」这类说法变成可检查的条目。 本篇按一次梳理的粒度写：源头、传输、处理、存储、删除。 模型与工具只是链路上的一类节点，不要单独跳过。

A data-flow map draws where each field travels, so that the drawing can be checked. Its value is turning claims such as "we do not look at customer data" into items you can verify. This guide works at the granularity of one pass: origin, transfer, processing, storage, deletion. Models and tools are just one kind of node on the chain; do not skip them.

• 要接一个 AI 服务，但不清楚数据在哪一步离开自己的边界。
• 需要回答法务或客户的尽调问题：哪些字段被存、存多久。
• 上线材料里要写「是否用于训练」「是否跨境」「谁可访问」。
• 已有多个系统与 agent 混合编排，没人画得出全图。

不适合：纯粹的性能或成本估算。那张图要画的不是数据，是调用量。

• You are about to integrate an AI service and do not know at which step data leaves your boundary.
• Legal or customer due diligence asks which fields are stored, where, and for how long.
• Release material must answer: is training used, does data cross borders, who can access it.
• Several systems and agents are wired together and nobody can draw the whole picture.

Not a fit: estimating performance or cost, which tracks calls rather than data fields.

1. 一个具体场景，而不是「整个系统」。选一条日常在跑的链路。
2. 能问到三方的联系人：模型服务、托管平台、外包标注（如有）。
3. 字段清单的来源：表结构、日志样例或接口文档，至少一种。
4. 记录口径：同一张表里写清「谁写的、依据哪个页面、核验日期」。

框架层面对照可以用自愿文件搭结构。 NIST Privacy Framework 官方页说明它供组织自愿使用，帮助管理隐私风险。 本站不判断你是否必须采用某一框架，那是辖区与业务的问题。

1. One concrete scenario, not "the whole system". Pick the chain you run daily.
2. Contacts at each third party: model provider, hosting platform, any outsourced labelling.
3. A source of field lists: table schemas, a log sample or the API contract — at least one.
4. A recording convention: the same table notes who wrote the row, which page it relies on, and the verification date.

Voluntary documents can supply the structure. The NIST Privacy Framework page describes it as a voluntary tool that helps organisations manage privacy risk. This guide does not judge whether you must adopt a framework; that is a jurisdiction and business question.

第三方条款里能直接抄进表的，是「用途」与「保留」两类句子。 AWS 数据隐私常见问题页写明， 官方原文（英文）："We do not access or use your content for any purpose without your agreement." Anthropic 隐私政策在训练用途上有一句可直接引用： 官方原文（英文）："We disassociate Inputs and Outputs from your user ID to use them for training and improving our models."

这句只描述政策里的做法，不覆盖你签约的具体档位； 消费端与企业端的差别要按当期条款另查，本页未逐项核对。

Two kinds of sentences in third-party terms can be copied straight into the table: purpose and retention. The AWS data-privacy FAQ states: "We do not access or use your content for any purpose without your agreement." On training use, the Anthropic privacy policy offers one quotable sentence: "We disassociate Inputs and Outputs from your user ID to use them for training and improving our models." That sentence describes a practice in the policy, not the tier you signed for. Differences between consumer and business tiers must be checked against current terms; they were not itemised here.

1. 定边界：画出「自己管的」与「别人管的」两块，边界线要能指着说。
2. 列字段：只列敏感或有业务含义的字段，避免整表照抄。
3. 标去向：每个字段标出它在链路上被谁读过、写进过哪里。
4. 查留痕：确认是否真有日志。审计日志默认开关各处不同—— Google 该文档记载提示与响应日志默认关闭，数据访问审计需在日志服务里开启（站内既有来源，2026-11-03 复核）。
5. 定保留：写出保留期与删除触发方式，注明来源页面。
6. 做核对：拿一条真实请求的样本，把它的字段沿图走一遍。

第 6 步能抓出大部分错图。第 4 步能抓出「以为有日志，其实没开」。

1. Draw the boundary: what you administer versus what someone else administers, and be able to point at the line.
2. List fields: only sensitive or business-meaningful ones, not a whole schema dump.
3. Mark destinations: for each field, who read it and where it was written.
4. Check the trail: confirm logs really exist. Audit defaults differ — the Google document records that prompt and response logging is off by default and data-access auditing must be enabled in the logging service (in-repo source, rechecked 2026-11-03).
5. Set retention: write the period and the deletion trigger, with the source page noted.
6. Walk one real request through the diagram, field by field.

Step 6 catches most wrong diagrams. Step 4 catches "we assumed logging was on".

情境为示例，字段与数字是虚构假设，用来说明画法。

• 输入：一条指令「把上月退款金额按区域汇总」，来自分析师账号。
• 处理：链路上有四个节点——内部数仓、检索层、模型 API、结果邮件服务。 梳理表逐字段记录：客户邮箱（进入检索层与提示词）、订单号（进入模型 API 请求体）、 汇总结果（写进邮件正文与工单系统）。
• 结果判断：图上有一处对不上——遥测上报把查询文本带出去了，原图漏画这一段。 同时发现「删除」段为空：邮件服务里的结果没有保留期说明。
• 失败后下一步： 补上遥测节点并把查询文本改写字段名后再上报； 向邮件服务管理员确认保留策略并写回表格，标注依据页面与核验日期； 在图上加一条「未知」标记，而不是留空——留空会被读成已确认无风险。

判据一句话：图上每一条边，都能指出它依据哪个页面或哪次实测。 指不出来的边，就画成虚线并标未知。

The scenario is illustrative; the fields and numbers are invented assumptions used to show the drawing method.

• Input: one instruction, "summarise last month's refund amounts by region", from an analyst account.
• Processing: four nodes on the chain — internal warehouse, retrieval layer, model API, result mail service. The table records each field: customer email (enters retrieval and the prompt), order id (enters the API request body), the summary (written into the mail body and the ticketing system).
• Judging the result: one edge does not match reality — telemetry shipped the query text, and the original diagram missed that segment. The deletion segment is also empty: no retention statement for results kept by the mail service.
• What to do after a failure: Add the telemetry node and hash the query-text field before shipping; confirm the retention policy with the mail service administrator and write it back with source page and verification date; mark the gap as "unknown" on the diagram rather than leaving it blank — blank reads as "confirmed no risk".

One test for the map: every edge can be traced to a page or an observation you actually made. Edges you cannot trace get drawn dashed and labelled unknown.

• [ ] 一张图覆盖源头到删除五段，没有空白段
• [ ] 字段表每个敏感字段都有去向、保留期与依据来源
• [ ] 至少一条真实请求沿图走通，差异被记录
• [ ] 未确认项以「未知」显式标注，而不是留空
• [ ] 谁在什么时间可以访问，与角色表能对上
• [ ] 复核日期写在图上，过期后有人负责重画

• [ ] One diagram covers all five segments, with none left blank
• [ ] Every sensitive field has a destination, retention period and cited source
• [ ] At least one real request was walked through the map, with differences recorded
• [ ] Unconfirmed items are labelled "unknown" instead of left empty
• [ ] Access timing and roles match the permission table
• [ ] A review date sits on the diagram and someone owns the redraw

• 图画得比实际粗：多半是把「服务」当节点，改成以字段的一次读写为节点。
• 说法与配置对不上：以能改的配置为准，把条款措辞与开关状态分列记录。
• 日志找不到：确认审计开关与保留设置；限流类错误（429）与权限类错误（401 / 403）要分开归因。
• 元数据工具里的血缘缺失：Microsoft Purview 文档指出，血缘抽取可关闭， 扫描范围与频率需要按计划设置——工具里的图不等于你手工梳理的图。
• 供应商改口：条款页更新后要重画，核验日期跟着更新。
• 一张图想覆盖所有场景：拆成多张，每张只讲一条链路。

• The map is coarser than reality: you drew services as nodes; draw one read or write of a field as the node.
• Claims contradict configuration: trust the setting you can change, and record terms wording and switch state in separate columns.
• Logs cannot be found: check audit switches and retention; attribute permission errors (401 / 403) separately from rate limits (429).
• Lineage is missing in the metadata tool: the Purview documentation notes that lineage extraction can be disabled and that scan scope and frequency are plan-dependent — a tool's graph is not your hand-drawn map.
• The vendor changes its story: redraw after terms pages update, and move the verification date with it.
• One diagram tries to cover every scenario: split it, one chain per diagram.

1. 把梳理表里的「未知」条目转成对供应商的书面追问。
2. 需要估合规投入时，用梳理表的工作量项作为基数（见对应指南）。
3. 上线前检查：图上每个外发节点是否都有拦截或脱敏策略。
4. 建立周期性重画机制，频率按业务变更速度定，不套用通用周期。

1. Turn the unknown cells into written questions for the vendor.
2. When estimating compliance effort, use the workload items from this table as the base (see the matching guide).
3. Pre-release check: every outbound node on the map has a blocking or masking policy.
4. Set a redraw cadence from your own change rate rather than a generic interval.

2026-11-06 直抓了四处官方来源：NIST Privacy Framework 页、 Microsoft Purview Data Map 文档、Anthropic 隐私政策、AWS 合规与数据隐私常见问题页。 第五条为站内既有来源，沿用 2026-11-03 的复核记录，本次未重抓。

以下未知：

• 你所在辖区要求保留哪些记录、保留多久——本页不作法律判断，需按当期法规与合同核对。
• 各条款页对不同产品档位（消费端、企业端、API）的差异化表述——本次只记录抓到的句子。
• Purview 或其他元数据工具在你环境里的血缘覆盖度——依赖扫描配置与实际数据源，未实测。

On 2026-11-06 four official sources were fetched directly: the NIST Privacy Framework page, the Microsoft Purview Data Map documentation, the Anthropic privacy policy and the AWS compliance data-privacy FAQ. The fifth source is an in-repo entry that keeps its 2026-11-03 recheck record and was not refetched today.

Unknowns:

• Which records and retention periods your jurisdiction requires — this guide makes no legal judgement; check current law and contract.
• How terms pages differ across product tiers (consumer, enterprise, API) — only the fetched sentences are recorded here.
• How much lineage coverage a metadata tool gives in your environment — it depends on scan settings and actual sources, and was not measured.