Agent读到的数据有PII、有跨境数据，合规怎么做？

源系统(业务库/工单/文档)
   │ ① 检索/工具调用：Agent 拿到了哪些字段？
   ▼
模型上下文
   │ ② 发送给模型服务：服务部署在哪里？会不会被留存或用于训练？
   ▼
模型输出 → 返回给用户  ③ 输出里有没有泄露用户无权看的信息？
   │
   ├─▶ ④ 对话日志 / Trace：原文存了多久？谁能看？
   ├─▶ ⑤ 长期记忆：有没有把敏感信息记下来？
   ├─▶ ⑥ 评测集 / 微调数据：线上样本进入评测集前脱敏了吗？
   └─▶ ⑦ 缓存：缓存键里有没有带上权限维度？

-- 字段级分类分级元数据：作为 Agent 访问控制和脱敏的依据
CREATE TABLE meta_column_classification (
  table_name     STRING,
  column_name    STRING,
  data_category  STRING,     -- 联系方式/身份标识/金融/健康/业务
  level          STRING,     -- L1/L2/L3/L4
  mask_rule      STRING,     -- 手机号保留前3后4 / 全部替换 / 令牌化
  agent_policy   STRING,     -- allow / mask / deny
  region         STRING,     -- 数据产生的区域，用于跨境判断
  updated_by     STRING,
  updated_at     TIMESTAMP
);
-- 工具层查询前读取该表：deny 的列直接拒绝，mask 的列自动套用脱敏函数

展开三：发送前脱敏与可逆令牌化

有些场景 Agent 确实需要处理含个人信息的数据，比如客服 Agent 要帮用户查订单。这时可以用可逆令牌化：发送给模型之前把敏感信息替换成令牌，模型基于令牌推理，返回结果时再把令牌还原。

# 发送给模型前做识别和令牌化，返回后还原
def protect(text: str, vault: TokenVault) -> str:
    for match in pii_detector.find(text):           # 手机号、邮箱、证件号等
        token = vault.tokenize(match.value, match.type)  # 如 <PHONE_1>
        text = text.replace(match.value, token)
    return text
 
def restore(text: str, vault: TokenVault, user_ctx) -> str:
    for token in vault.tokens_in(text):
        if user_ctx.can_view(token.type):            # 只对有权限的用户还原
            text = text.replace(token.key, vault.reveal(token))
    return text
 
prompt = protect(raw_context, vault)                 # 模型只看到令牌
answer = restore(llm.chat(prompt), vault, user_ctx)  # 用户看到还原后的结果
log.write(prompt, answer_masked=protect(answer, vault))  # 日志只存令牌化版本

注意最后一行：日志里存的是令牌化之后的版本。这样即使日志被更多人访问，也不会泄露原始的个人信息。令牌和原文的映射存在单独的、权限严格的令牌库里，并设置较短的保留期。

展开四：日志、记忆、评测集——容易被遗忘的角落

环节	风险	控制措施
对话日志	原文永久保存，排查时被大范围查看	分级存储（第 13 题）、原文短保留期、访问审批
长期记忆	Agent 把用户的证件号“记住了”	写入记忆前过滤敏感信息，用户可查看和删除自己的记忆
评测集	线上真实样本带着个人信息进入评测集，被很多人反复查看	入库前强制脱敏，记录样本来源
缓存	A 用户的结果被 B 用户命中	缓存键包含权限维度，敏感结果不缓存
模型服务	数据被服务商留存或用于训练	确认服务条款，选择不留存或企业级协议，敏感场景考虑私有化部署

还要考虑删除权：用户要求删除个人数据时，不仅要删业务库，还要删对话日志、记忆、评测集里的相关数据，以及向量索引里的相关 Chunk。这就要求从一开始就在这些数据里保留 user_id 等可追溯的标识，否则根本找不到要删什么。

展开五：跨境数据的基本原则

做出海业务的数据开发，对跨境数据问题应该都不陌生：不同国家和地区对个人信息的处理和出境都有各自的法规要求，比如欧盟的 GDPR、中国的《个人信息保护法》及数据出境相关规定等。Agent 场景下，跨境问题最容易出现在“把数据发给哪里的模型服务”这一步。

• 数据驻留：按数据产生的区域选择同区域部署的模型服务和存储，比如欧洲用户的数据用部署在欧洲的服务处理。

• 路由控制：在网关层根据数据的 region 标签决定请求发往哪个区域的模型服务，而不是所有请求都发往同一个默认端点。

• 出境合规流程：确实需要跨境处理的，按当地法规要求做评估、告知、签署相应合同，具体要求以法务和合规团队的意见为准。

• 留存证据：记录每次数据处理发生的区域和服务，审计时可以证明合规。

面试时有一个很重要的表达技巧：承认法律细节不是你的专业领域，但强调你能把合规要求转化为技术控制。“具体条款我会和法务确认，我负责的是让这些要求在数据链路上可执行、可审计”——这句话比背法条更显专业。

追问链

追问一：脱敏会不会影响 Agent 的效果？

会有一定影响，比如地址脱敏后 Agent 无法按地址做精细分析。所以要按场景设计：大部分分析场景只需要聚合结果或分类信息，不需要原文，脱敏几乎不影响效果；确实需要原文的场景（比如客服查具体订单），用可逆令牌化，模型基于令牌推理，用户端还原。另外脱敏规则要保留分析需要的信息，比如手机号保留号段、地址保留到城市级别。

追问二：怎么检测模型输出里有没有泄露敏感信息？

在输出端也加一道识别：模型返回的内容在发给用户之前，过一遍敏感信息检测，如果出现了该用户无权查看的类型（比如普通员工的回答里出现了完整身份证号），就拦截或脱敏后再返回，同时告警。输入端和输出端双向检测，加上底层的权限控制，形成纵深防御。

追问三：你们怎么证明自己是合规的？

靠审计数据。每次敏感数据访问记录谁、通过哪个 Agent、访问了什么级别的数据、是否经过脱敏、发往了哪个区域的模型服务。这些审计日志本身要防篡改、长期保留。定期出合规报告：敏感数据访问量、拦截次数、删除请求的处理时效等。

加分说法 vs 减分说法

✔ 加分说法	✘ 减分说法
画出 Agent 链路的完整数据流向	我们用的是正规模型服务，应该没问题
字段级分类分级，作为访问控制的输入	只管查询权限，不管日志和记忆
发送前脱敏，可逆令牌化，日志存令牌版本	所有数据原文直接发给模型
日志、记忆、评测集、缓存都要管	背一堆法条但讲不出技术方案
合规要求转化为可执行、可审计的技术控制	不考虑用户的删除请求

怎么挂到你的项目上

话术模板：“Agent 的合规我会先画数据流向：检索、发送模型、日志、记忆、评测集、缓存，每个节点都有控制。基础是字段级分类分级，高敏数据默认不进 Agent 可见范围，敏感数据发送前令牌化，日志只存令牌版本。跨境方面按数据产生区域路由到同区域的模型服务，具体条款和法务确认，我负责让要求在链路上可执行、可审计。”

总结

合规题的核心是数据流向 + 分类分级 + 技术控制。Agent 让数据多了“发给模型、进日志、进记忆、进评测集”这些新路径，每条路径都要有控制。不需要背法条，但要能把合规要求变成可执行、可审计的工程方案。这一题答完，第三轮工程深挖就结束了。

下一篇进入最后一轮：面试官问“你平时怎么用 AI 写代码？AI 写的 SQL 你敢直接上线吗？”应该怎么答？

你们的 AI 应用会把用户数据发给外部模型服务吗？有做脱敏吗？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长