了解隐私、访问控制、保留策略、可审计性、提示注入以及监管约束如何塑造企业 AI 部署。
最需要前沿部署工程师的客户，往往也是约束最严苛的客户：银行、医院、国防、制造商。对他们而言，AI 系统再聪明也无济于事，除非它先通过安全审查，而这项审查往往是整个部署的关口。把安全和合规当作别人负责阶段的 FDE 永远无法交付。本页讨论的正是决定你的系统是否被允许存在的那道约束。
为什么这就是这份工作本身
个人效率类 AI 完全无视这一切——而这恰恰是它不能算作证据的原因。面向真实客户的生产级 AI 必须活在客户的规则之内：他们的数据不能离开他们的区域，他们的监管机构必须能够审计某项决策，他们的安全团队必须在任何用户使用之前签字放行。跨过这道门槛是工程工作，而且是只做过演示的 AI 工程师从未做过的工程工作。Morgan Stanley 的合作项目清楚地说明了这一点：“零数据保留政策……确保 Morgan Stanley 的专有数据保持私密”是这笔交易的关键支撑，是让合作得以达成的条款之一。
在继续阅读之前： 一家银行想要一个基于其内部文档的助手，其安全团队问道：“我们的数据去了哪里，你能证明吗？”如果你的回答是“数据被发送给了模型提供商”，你刚刚失去了什么？
你很可能已经失去了这笔交易，或者至少失去了接下来的六个月——除非你能准确说出数据流向何处、保留了什么、以及如何隔离。“数据发给了 API”是从未通过过安全审查的人才会给出的答案。
从第一个箱子开始就要为什么而设计
数据驻留与保留
了解数据实际存放在哪里、存放多久。受监管的客户通常要求数据留在特定区域内、绝不用于训练第三方的模型，并且只按政策允许的期限保留。可选方案从提供商的零保留、区域内 API 层级，一直到完全本地部署或气隙隔离部署、不进行任何外部调用。这个选择约束着下游的一切，所以要先把它定下来。
敏感数据处理
个人身份信息和其他敏感数据在到达模型或日志之前，需要被最小化、脱敏或令牌化——而“日志”很重要，因为评测轨迹或调试转储正是敏感数据泄露的地方。敏感信息泄露是 OWASP LLM 应用十大风险中列明的风险之一；要把每一个存储或发送数据的地方——包括你自己的可观测性系统——都视为在范围内。
访问控制与隔离
AI 系统会继承客户的权限模型——用户不能通过助手获取他们无法直接打开的文档。这意味着检索和生成必须尊重按用户的访问控制，而且客户数据通常按租户隔离。一个忽略权限的检索系统就是一个带着友好界面的数据泄露引擎。
可审计性
在受监管的环境中，必须有人能够还原系统为何产生某个输出：检索了什么、使用了什么提示词、谁看过、什么时候看的。这就是作为审计记录保存的可观测性追踪。“模型自己决定的”不是监管者能接受的答案；审计轨迹才是让 AI 决策站得住脚的依据。
各监管体系及其强制要求
上述约束在实际客户那里都是具体而明确的。四种监管体系覆盖了大多数合作场景，每一种都会把本课程已经讲授的设计习惯转化为法律或合同义务。下表给出整体框架，表后的段落则包含客户的法务或安全团队会期望你了解的具体细节。
| 监管体系 | 是什么 | 对 AI 部署的强制要求 |
|---|---|---|
| GDPR | 欧盟《通用数据保护条例》，规范个人数据 | 合法依据、数据最小化、通过索引实现删除路径、对自动化决策的人工干预、传输条件 |
| HIPAA | 美国《健康保险可携性与责任法案》，规范健康信息 | 在健康数据流动前签署供应商协议、访问控制、审计轨迹 |
| SOC 2 | 针对服务组织控制措施的审计师鉴证报告 | 有文档记录且实际运行的控制措施：访问、变更管理、监控 |
| EU AI Act | 欧盟对 AI 系统按风险分级的监管 | 高风险系统需进行全生命周期事件日志记录和人工监督，并有明确的截止期限 |
通用数据保护条例（GDPR，欧盟法规 2016/679）要求在处理个人数据之前必须有合法依据（第 6 条），并要求所处理的数据“充分、相关且仅限于必要的范围”（第 5 条）——即数据最小化，这正是本页已经讲授的裁剪与脱敏，只不过以法律形式重申。其中两条条款对 AI 系统有直接影响。删除权要求“无不适当延迟”地删除（第 17 条），这触及检索索引：一旦个人数据被嵌入并建立索引，响应删除请求就需要一条重新索引的路径，而这条路径必须从第一天起就设计进去，否则当请求到来时它就不存在。此外，第 22 条赋予个人针对仅自动化决策（具有法律或类似重大影响）的权利，包括获得“人工干预”的权利——因此在某些部署中，人在回路不仅是建立信任的做法，更是法律要求。高风险处理在开始之前必须进行数据保护影响评估（第 35 条），跨境传输仅在特定条件下才被允许（第 44 条）——这正是本页开头提到的数据驻留要求背后的条款。
《健康保险可携性与责任法案》（HIPAA）管辖美国的受保护健康信息（PHI）。对 AI 部署影响最直接的规则是：PHI 只有在商业伙伴协议（BAA）之下才能交给供应商——“通过书面合同提供……满意的保证”（45 CFR 164.502(e)）——因此，在哪怕一条患者记录接触 API 之前，模型提供商必须签署 BAA，而不愿签署的提供商无论其模型多好都会被排除。HIPAA 的技术保障措施随后要求实施访问控制，将系统限制在已授予的访问权限内，并实施审计控制，“记录并检查包含或使用电子受保护健康信息的信息系统中的活动”（45 CFR 164.312）。这一审计控制要求正是按请求追踪的再次体现，只不过这次是法规所要求的。
SOC 2（系统与组织控制 2）是一种认证而非法律：审计师依据美国注册会计师协会（AICPA）发布的2017 年信任服务准则及 2022 年修订的要点，从安全性、可用性、处理完整性、保密性和隐私性等方面审查服务组织的控制措施。在实践中，审计师希望看到访问控制、变更管理和监控等领域有文档化且实际运行的控制措施。对于 AI 部署而言，这直接对应本节已经讲授的机制：部署页面上的版本化、带门禁的发布就是变更管理的证据，而监控证据则是可观测性体系——SOC 2 审计在很大程度上就是要求这些规范确实存在并留下书面记录。
欧盟 AI 法案按风险对 AI 系统进行监管，分为四个层级，从被禁止的做法到最低风险不等。对于高风险系统，有两条规定读起来就像把本课程的生产页面重述成了法律：系统必须“在技术上允许在系统整个生命周期内自动记录事件（日志）"（第 12 条），并且必须设计成“可由自然人有效监督"（第 14 条）。时间线是二手材料最容易出错的地方，所以要精确表述，截至 2026 年 7 月：禁令自 2025 年 2 月起生效，通用模型规则自 2025 年 8 月起生效；透明度义务（第 50 条）自 2026 年 8 月起适用；高风险制度因 2026 年年中达成的修正案而推迟——独立系统（附件 III）推迟至 2027 年 12 月，嵌入受监管产品中的 AI（附件 I）推迟至 2028 年 8 月——依据是各律所对修正案的追踪（Gibson Dunn、Travers Smith）。这些是律所的摘要；在依赖这些日期之前，请查阅《官方公报》。如此新鲜的截止日期，正是 FDE 在项目开始时会重新核实的那类事实，因为对它们的记忆很快就会过时。
把四行内容放在一起读，规律就很明显：生产部分已经讲授的那些要求——日志与追踪、人工监督、访问控制、版本化发布——在这里以法律要求的形式出现。适用哪种制度取决于客户，并在需求调研中显现出来。FDE 的职责是弄清楚哪个制度适用于本次项目，并从第一个框开始就围绕它进行设计。
差 / 好 / 卓越 — “你们如何处理他们的数据？"
差 — “我们把它发送给模型 API；供应商很安全。" 你把答案外包给了一个会否决它的安全团队，并且表明你不知道数据流向哪里。
好 — “我们使用零保留层级，对 PII 进行脱敏，并限制访问。" 对最重要的三点有真实、正确的直觉——扎实的中级水平。差距在于：没有提到可审计性、检索中的按用户权限，或者在客户要求时提供本地部署的选项。
卓越 — “我会先确定数据驻留和保留策略——区域内零保留 API，或者在客户要求时采用本地部署/物理隔离——在检索中强制执行客户的访问模型，使助手无法呈现用户无权打开的内容，在敏感数据进入模型或任何日志之前对其进行脱敏，并保留每次检索和输出的审计轨迹，以便能够重建决策。而且我会在需求调研中提出所有这些，因为它决定了架构。" 你从第一个框开始就为环境进行了设计，并使系统可审计——这才是真正能通过评审的答案。
面试中要带上的东西
当设计提示涉及受监管领域——金融、医疗、政府——时，不要等到被问及安全问题才提。应尽早主动提出，并让它影响架构设计：说明数据存放在哪里、如何实施按用户的访问控制，以及如何对决策进行审计。从第一个框图开始就把合规当作一等设计驱动因素，这正是“只能演示的系统”与“客户获准部署的系统”之间的区别。
相关： 护栏与安全、可观测性与调试（审计追踪），以及 推动采用（为什么达到门槛能赢得信任）。
下一篇： 部署与 MLOps——把它交付到客户的生产环境中，并保持其健康运行。