Marico's space
这两年 LLM（大语言模型）和 GenAI（生成式人工智能）火得一塌糊涂，很多团队都在往产品里塞 AI 功能。但说实话，大多数人在数据安全这件事上还没想清楚——先把功能跑起来再说，安全以后再补。这种心态迟早要出问题。这篇把我踩过的坑和总结的经验梳理一下，覆盖输入输出过滤、RAG（检索增强生成）数据最小化、微调数据集清理、密钥管理、运行时监控这些具体实践。
AI 系统的攻击面跟传统软件完全不同。SQL 注入漏洞藏在一个地方，但 prompt injection（提示词注入）可以在任何用户可控字符串到达 LLM 的位置出现。数据泄露的风险不只在数据库层——还涉及模型的上下文窗口、训练数据、工具调用输出，以及中间推理步骤（如果你在记录那些的话）。搞清楚数据在 AI 系统里的流向，是做安全防护的前提。
AI 的应用速度已经甩开安全能力好几条街了。根据 Gartner 2025 年 AI 技术成熟度曲线报告，超过 55% 的企业已经在生产环境部署了至少一个生成式 AI 应用，但实现正式 AI 安全控制的还不到 20%。这个差距就是事故发生的温床。2025 年 OWASP LLM Top 10 把 prompt injection 和敏感信息泄露列为两大最高风险——说白了都是数据安全问题。
已经曝光的安全事件有个共同模式：开发者把 LLM 接入内部系统，用户构造一个输入让模型通过输出泄露数据，然后组织通过第三方才发现泄露。2023 年某大厂工程师把内部代码粘贴到 AI 助手里这件事大家都知道了——问题就在于 AI 工具接入了敏感数据却没有任何防护措施。大多数情况下，事情不会发展到被发现那一步。
监管压力也在同步增加。欧盟 AI 法案、NIST AI 风险管理框架，以及美国各州陆续出台的 AI 法规，都对部署高风险 AI 系统的组织提出了数据治理要求。安全团队以前专注于应用和基础设施安全，现在必须理解 AI 特有的攻击向量，否则就会对一大块风险视而不见。
第一步不是上工具，而是搞清楚你的 AI 系统能访问什么数据、对这些数据做了什么、输出去了哪里。对于典型的 RAG 应用，这意味着要列出向量数据库里有哪些文档、了解用户查询长什么样、确认检索到的上下文有没有被记录、追踪生成的回答显示或存储在哪里。如果你连系统里有什么都不清楚，就别想写出有用的数据分类策略。
特别要注意工具调用和函数调用。当 LLM 可以访问代码解释器、文件系统、数据库查询接口或 API 客户端时，数据安全边界就急剧扩大了。每个工具连接都是一个潜在的数据泄露通道——如果攻击者能控制驱动工具调用的 prompt。
Prompt injection 是已部署 LLM 应用中数据泄露最直接的路径。攻击者如果能把指令注入到模型的上下文中，就能让模型忽略之前的指令、泄露系统 prompt 内容，或者通过看似正常的回答窃取检索到的文档。防御需要双管齐下：结构控制和运行时检测。
输出过滤同样重要。在广泛互联网数据上训练的模型，在某些条件下会逐字复现训练数据——Google DeepMind 和普林斯顿的研究都记录过这种现象。生产系统应该在响应到达用户之前，扫描输出中是否存在训练数据记忆、PII（个人身份信息）泄露或凭证泄露的迹象。
LLM 应该只能访问执行预期功能所需的数据，多一点都不行。这听起来是废话，但实践中经常被违反。开发内部工具时，开发者经常把 LLM 接到范围很广的数据库视图，或者给它们生产级权限的 API 密钥——因为这样开发更快。后果是，一次成功的 prompt injection 就能让攻击者读取模型能触达的所有数据。
对于 RAG 系统尤其如此：按敏感级别分割文档存储，根据已认证用户的权限在检索时实施访问控制，在上下文进入模型 prompt 之前审计检索到的内容。不要让模型广泛的知识访问能力代替proper的数据访问控制。
喂进微调数据集的东西，在某种程度上会从模型里跑出来。在内部数据——客服日志、代码仓库、内部文档——上进行微调而不先审计敏感内容，就等于训练了一个会泄露这些内容的模型。PII、凭证、内部系统名称、商业机密逻辑，都在有记录的研究案例中出现在过微调模型输出里。
在任何微调之前，用自动化 PII 检测工具（如微软 Presidio 或自定义分类器）跑一遍候选数据集，删除所有凭证或 API 密钥，审计可能造成法律或竞争风险的内容。这不是可选项，而是微调工作流的最低安全检查。
工具生态已经相当成熟了。对于 prompt injection 检测和输出过滤，LLM Guard（来自 Protect AI）和 Rebuff 提供了开源方案，生产环境性能也不错。微软的 Prompt Shields，现在是 Azure AI Content Safety 的一部分，提供托管服务方案，有公开的误报率数据。
对于 AI 可访问数据存储中的密钥和凭证扫描，GitLeaks 和 TruffleHog 可以集成到 CI/CD 流水线，在文档被索引到向量存储之前扫描。对于推理时的 PII 检测和脱敏，Presidio 仍然是最灵活的开源选项，Nightfall 和 Private AI 等商业替代方案提供托管 API。
AI 应用的运行时监控是大多数组织最大的短板。传统 APM 工具捕捉不到模型输入输出的语义——它们看到的是字节，不是含义。专门构建的 AI 可观测性平台提供检测异常检索模式、异常输出量或生产流量中 prompt injection 尝试所需的可见性。
你没有记录的东西没法调查。AI 系统应该记录 prompt 输入、检索到的上下文（RAG 场景）、工具调用及其参数、模型输出——保留策略要与合规义务保持一致。这创造了支持安全调查和模型行为审计的审计跟踪。实施日志访问控制要像对待任何敏感数据存储一样谨慎，因为 AI 交互日志按定义经常包含敏感信息。
静态安全评审会错过动态攻击模式。安排定期对抗性测试，让你的安全团队（或外部团队）针对你的生产 AI 应用尝试 prompt injection、通过间接渠道提取数据、越狱技术。OWASP LLM Top 10 提供了测试什么的有用起点。记录发现的问题并跟踪修复——这创造了监管框架越来越要求的持续安全尽职调查证据。
基础模型会收到安全相关的更新，包装它们的库和框架也一样。Langchain、LlamaIndex 及类似框架在最近版本中都修复过安全相关漏洞。把 AI 框架依赖当作其他生产依赖一样严格对待——自动化漏洞扫描、及时更新、关键漏洞披露时的紧急修补流程。
LLM 和 GenAI 数据安全最佳实践指的是在大语言模型和生成式 AI 系统全生命周期——从训练数据整理到部署和持续运营——保护敏感数据的技术控制、策略和架构模式。它涵盖 prompt injection 防御、输出过滤、AI 可访问数据的访问控制、微调数据集卫生、密钥管理和数据泄露运行时监控。
AI 系统安全在多个层面同时运作。在输入层，过滤和验证在对抗指令到达模型之前检测它们。在数据访问层，最小权限控制限制模型能检索或交互的信息。在输出层，自动化扫描在响应到达用户之前捕获 PII、凭证泄露或记忆的训练数据。日志和监控把这些层面串联起来，提供对运行时实际系统行为的可见性，能够检测静态控制会漏掉的攻击或策略违规。
防止 prompt injection 需要结构和运行时控制协同工作。从结构上：用分隔符或系统/用户消息分离来分离指令通道和用户可控数据通道；对模型可访问的所有工具实施最小权限；永远不允许用户可控内容设置安全相关指令。在运行时：实现输入分类器，在注入尝试到达模型之前标记它们；记录所有输入用于事后分析；定期用已知注入载荷测试你的生产应用。没有单一控制是足够的——防御需要多层。
至少要排除：任何形式的 PII（姓名、邮箱、电话、地址、身份证号）、认证凭证和 API 密钥、内部系统名称和网络拓扑信息、法律特权通信，以及泄露会造成竞争或监管风险的机密商业数据。实际操作规则是：如果你不希望这些信息能被微调模型的用户检索到，就不应该在训练数据里。在任何微调之前用 PII 检测工具跑自动化扫描——单独靠人工审查无法扩展到实践中使用的数据集规模。
最常见的失误：为了开发快就把 AI 系统接到权限过大的生产数据存储；因为增加延迟就跳过输出过滤；记录 AI 交互但不保护日志本身；把微调当作模型问题而不是数据安全问题；以为模型供应商的安全措施能替代应用层安全控制。供应商安全措施应对的是不同威胁模型，不是生产数据安全——它们不等价。把 AI 应用当作处理敏感数据的其他系统一样严格对待，构建专门的控制，而不是依赖缺乏 AI 特定覆盖的通用安全工具。