智能体的数据治理

C5
运维 · 治理与合规

智能体的数据治理——智能体首先是一台数据流机器。

智能体最被治理不足的性质是它在搬运数据:它从存储拉取、把数据嵌入、传给一个第三方模型、写回去、再路由给工具——往往在每一步无形地跨越信任与法域边界。经典数据治理假设数据走一条人设计的路径;智能体在运行时自创路径。本文讲对智能体而言具体改变了什么:穿过循环的血缘、同意与目的限制、PII 处理、训练与评估数据治理,以及跨境流动。

STEP 1

血缘要穿过循环,而不只是进到模型。

数据血缘通常追踪数据从源到一个已知目的地。智能体打破这一点:第 3 步检索到的一条记录可能在第 4 步落进模型上下文、在第 6 步被摘要、在第 9 步被写进一个工具,并在最终答案里浮现——一条没有任何 schema 声明过的路径。智能体数据治理需要穿过循环跟随数据的血缘:对任何输出或副作用,你必须能回答哪些来源做出了贡献。这是把 C1 溯源链拿去回答一个数据问题——没有逐步的来源追踪,你回答不了「客户 A 的数据是否到达了输出 B」,而这正是一次泄露或一个数据主体请求会逼出的那个问题。

STEP 2

同意与目的限制要存活进循环。

为一个目的收集的数据,并不会因为智能体能够到它就变得可用于任何目的。目的限制与同意依据附着在数据上,必须在检索与工具调用时执行,而非在收集时假定。现实机制是把目的/同意依据作为元数据携带,让策略引擎(C2)据以对使用做闸门:基于客服同意的数据绝不能流进一个营销行动,无论智能体怎么到那一步的。智能体创造性地重组数据的能力,正是同意检查必须住在使用点而非摄入点的原因。

# purpose binds the data; checked at point of use, not intake
rec = store.get(id)            # rec.purpose = "support"
if action.purpose not in rec.allowed_purposes:
    raise PurposeViolation(rec.id, action.purpose)
# support-consented data cannot flow into a marketing action

在摄入时给数据打上目的与同意依据标签,使运行时检查是一次查找,而非一次猜测。无标签的数据应默认为最严格的目的,而非最宽松的。

STEP 3

PII 处理:在边界之前最小化,不是之后。

最有风险的那一刻,正是最容易被忽略的:PII 跨进模型上下文,尤其是一个在你信任边界之外的第三方模型。用边界处的数据最小化来治理它——只有任务需要的字段到达模型;脱敏或令牌化推理不需要的标识符;在智能体只需行动而非阅读处,优先用引用而非原始值。「图省事把整条记录发过去」这个默认,正是 PII 最终落进供应商日志、一个嵌入索引,或一个提示词注入外泄汇的方式。最小化比你否则会需要的每一项下游管控都更便宜、更可辩护。

嵌入不是匿名化。从个人数据导出的向量仍是个人数据——一个向量库继承与源相同的同意、保留与擦除义务。

STEP 4

训练与评估数据也是被治理的数据。

如果你从真实交互做微调或构建评估集,那条管线是一个数据治理面,不是一项内部便利。生产轨迹携带 PII 与客户内容;把它们复制进一个训练或评估语料是一个新的处理目的,需要自己的依据、最小化与保留期。两种失败居多:同意泄漏——为服务交付收集的数据被悄悄复用于模型训练而无依据——以及记忆风险——在未最小化记录上训练的模型可能把它们原样吐出。用与任何其他个人数据处理相同的管控去治理那个轨迹到训练的飞轮(评估材料里熟悉的那个),并像记录模型溯源一样刻意地记录它的溯源。

STEP 5

跨境流动常常无形,且始终被治理。

调用一个托管模型可能在单次函数调用里把个人数据移过一道法域边界,没有 UI、没有日志行,也没有人知道它发生了。数据驻留与跨境传输规则不在乎那次传输隐含在一次 API 调用里。这里的治理意味着按数据类别知道它被允许在哪里处理,并据此约束模型与工具路由——区域固定的端点、区域内推理,或边界最小化使跨越的东西不再是个人数据。一个在运行时挑工具或模型端点的智能体,除非路由层本身被治理,否则能把受监管数据路由到境外。

STEP 6

诚实的取舍。

真正的数据治理会约束智能体:最小化与目的检查移除了模型本可用的上下文,区域固定缩窄了模型与工具选择,而同意元数据是多数团队会一直跳过的工程——直到一次事故或一个数据主体请求逼着做,且是昂贵地、追溯地、跨一条没文档的数据流。用使用点执行与边界最小化去治理那些携带个人或受监管数据的数据流;「就把整条记录传给模型」的便利是一项你在推迟、而非在规避的负债。