为什么受监管行业需要不同的 AI 基础设施——而不仅仅是不同的提示词

受监管的 AI 部署中，最常见的合规错误是把合规当成提示词问题来解决。

常见的思路是这样：在系统提示词里加上几条指令，比如“输出中不得包含 PHI”“遵守律师与客户之间的保密特权规则”“不得依据受保护特征作出信贷决定”，然后默认模型会照做；再签一份业务伙伴协议（BAA）或数据处理协议，这件事就算收工了。

这条路走不通。受监管领域的合规需要一整套属性，而任何模型靠自身都提供不了这些属性，指令写得再周密也一样。合规是基础设施层面的属性，而不是提示词层面的属性。

提示词工程的误区实际让你付出什么代价

把话说具体。假设你是一家医疗机构，正在用云端 AI 辅助临床文书工作，并且已经在提示词里要求模型不要在输出中包含 PHI。下面这几件事，是这条指令管不住的。

你作为上下文提交的患者数据，在模型开始处理之前就已经传到了供应商的服务器上。无论模型最终输出什么，数据都已经出境。BAA 也许覆盖了这次传输，但数据确实离开了你的环境。对某些类别的敏感健康信息，即便传输本身符合 BAA，也可能与专门监管这类数据的具体规则相冲突。由 Part 2 项目持有的物质使用障碍治疗记录适用 42 CFR Part 2，其要求比标准的 HIPAA 更严格；精神健康记录和 HIV 感染状态则由 HIPAA 加上各州法律共同管辖，而州法各不相同。

模型仍然可能把 PHI 写进输出。语言模型遵循指令的方式是概率性的，而不是确定性的。碰到边缘情况、异常的输入格式或者复杂的多步提示词时，“不要包含 PHI”这条指令偶尔就会失效。没有任何一条提示词能提供硬性保证。

处理过程中究竟发生了什么，你手上没有审计追踪。你知道自己送进去了什么，也知道返回了什么。中间做了哪些计算、是哪个版本的模型处理了这次请求、模型内部对这份数据形成了怎样的表示，这些你都无从得知。一旦某位患者的数据被错误处理，而他要求你出具一份披露记录说明（accounting of disclosures），你拿不出完整的那一份。

这些问题，没有一个能靠把提示词写得更好来解决。

受监管行业真正需要的五项基础设施差异

1. 真正的数据驻留与出境控制

这里要的是从技术上真正阻止数据离开环境。BAA 是一份合同承诺，约定第三方会妥善处理你的数据，它的效力止步于合同层面，落到技术层面并不能拦住数据出境。对那些确实不能离开本地的数据，比如涉密信息、受出口管制的数据、受合同保密协议约束的数据，或者处在断网临床环境里的数据，BAA 从一开始就是用错了工具。

真正的数据驻留意味着算力跑在数据所在的地方。这要么需要本地部署的基础设施，要么需要具备真实网络隔离的私有云部署。云厂商勾选框上的那种“数据驻留”，也就是“我们在欧盟区域处理你的数据”，属于另外一回事。

2. 覆盖每一个处理步骤的审计追踪

受监管的决策需要把决策过程本身记录下来，输入和输出只是其中的一部分。具体包括：哪个版本的模型处理了这次请求、对输入数据做了哪些预处理、产生了哪些中间输出、人在其中做了哪些操作、最终决定是什么。

具体到 AI 数据准备，也就是把原始数据集变成可用于训练的数据的那条流水线，审计追踪的要求会延伸到每一次转换：哪些文档被摄入、哪些被过滤掉、施加了哪些清洗操作、标签是怎么分配的、跑了哪些数据增强。EU AI Act 第 10 条要求提供训练数据治理方面的文档。流水线本身不记录这些，文档就无从产出。

3. 带显式版本控制的确定性行为

受监管的决策需要可重现。如果 11 月作出的一笔信贷决定在次年 3 月被提出异议，你需要精确还原出当时是哪个系统作的决定、它对输入数据做了什么。这需要版本锁定的模型、带版本的提示词，以及有文档记录的数据流水线配置。

云端 AI 部署通常会在不通知的情况下更新模型。你 11 月用的那个模型，到 3 月可能已经不存在了。如果供应商的 API 不提供显式的模型版本标识（以及按需锁定到特定版本的能力），可重现性在结构上就无法实现。

这是很现实的问题。美国的 ECOA 要求放贷机构必须能解释不利行动的理由。GDPR 第 22 条赋予个人一项权利：对其产生法律效力或类似重大影响的决策，不得完全由自动化处理作出；第 13 至 15 条则要求提供关于其中所涉逻辑的有意义信息。EU AI Act 第 11 条要求提供 AI 系统的技术文档，涵盖其架构和训练方法。底层模型在你不知情的情况下发生变化，上述要求就一条也满足不了。

4. 领域专家无需 ML 工程中介即可参与

在受监管行业里，真正理解监管要求的是医生、律师、金融分析师和合规官，他们必须能直接参与 AI 系统的配置与验证。如果对 AI 系统的每一处改动都要由机器学习工程师来实现，监管专家就会长期依赖技术中介，验证周期也会拖长到不具备可操作性的程度。

这是一个由基础设施来解决的工作流问题。一个带有领域专家界面的 AI 数据准备平台，让临床数据科学家不写 Python 就能直接配置标注方案、检查标注输出、验证清洗操作，可以把专家的反馈闭环从数周压缩到数小时。

5. 物理隔离（air-gap）能力

有些环境的连接性要求没有商量余地。涉密的政府系统不能连接商业云服务。医疗机构里的部分临床环境有网络隔离要求。部分金融交易系统需要靠物理隔离来防范网络攻击。

云端 AI 按其定义就服务不了这类环境，而本地安装、断网也能运行的原生桌面应用可以。这是一条门类级别的准入要求，它直接把某些架构路线整个排除在外。

云 AI 为什么在每一项要求上都不达标

把这五项要求对照云端 API 形态的 AI 逐条走一遍。

云 AI 提供不了真正的出境控制。数据必须先传到供应商的服务器才能被处理，就这么简单。BAA 改变的是法律层面的处境，技术层面的事实照旧。

云 AI 最多只能提供部分审计追踪。供应商提供的日志覆盖的是 API 调用层面的信息：时间戳、token 数量、延迟。至于模型内部发生了什么、中间计算是怎样的、具体是哪个版本的模型在跑，这些都达不到监管文档所需要的粒度。

云 AI 通常不支持版本锁定的确定性行为。多数供应商会周期性更新模型权重，行为随版本变化。要做到可重现，你必须显式固定到带版本号的模型发布，并测试其行为是否稳定，而实践中很少有企业这样做。

云 AI 的多数配置改动都需要工程中介。修改系统提示词、调整数据预处理流水线、重新配置输出格式，都要占用工程时间并走一遍发布流程，领域专家无法直接改动。

云 AI 无法在物理隔离环境中运行。调用 API 必须联网。对涉密或连接受限的环境来说，这一条就是一票否决。

自托管 Web 应用解决了一部分问题，又带来新的问题

在自己的服务器上跑开源模型（LLaMA、Mistral 等）确实解决了数据出境和模型版本控制这两个问题：模型和算力都归你掌控。

但自托管 Web 应用会带出属于自己的合规面：多数受监管行业的团队并不具备的 DevOps 投入、需要持续做安全加固的网络暴露面、横跨企业各类角色的访问控制复杂度，以及需要 ML 基础设施经验才管得好的模型权重。

对一个需要放射科医生和临床信息学专家去使用 AI 流水线的医院系统来说，一套架在 Linux 服务器上、对外只有 Python API 的自托管 Web 应用算不上现实的部署选项。安全运行它所需的专业能力，加上 Web 应用这一层带来的合规开销（认证、授权、网络安全、打补丁），已经超出这类组织能长期承担的范围。

原生桌面应用为什么能同时满足这五项

原生桌面应用像企业软件一样安装。它不联网也能运行，也不对外暴露网络服务。它可以通过标准的企业软件管理工具（SCCM、Intune、Jamf）分发部署。审计日志留在本地，持续保存，并且能够察觉篡改。用户界面是为领域专家设计的，而不是为工程师设计的。

Ertas Data Suite 走的就是这条架构路线：一个用于 AI 数据准备的 Tauri 2.0 原生桌面应用。它可以装在 Windows、Mac 或 Linux 上，完全离线运行。摄入、清洗、标注、增强、导出，每一步操作都会连同时间戳、操作者 ID 和参数集一起记入日志。审计日志可以直接导出为适用于 EU AI Act 第 12 条记录保存要求的格式。

工程与建筑行业也是同一个逻辑：一家手里握着 700GB 专有技术图纸、规格书和合同的公司，没法把这些数据送进云 API。竞争层面的保密要求和合同里的保密协议都不允许。跑在公司自有硬件上的原生桌面应用是唯一可行的路径。

各垂直行业的例子

医疗：把 PHI 用于 AI 训练数据的处理，需要完整的数据血缘（数据从哪来、对它做了什么、谁碰过它）、数据集级别的访问控制，以及支持 HIPAA 披露记录说明的审计能力。云 API 流水线提供不了这些。

法律：受律师与客户保密特权保护的文档，在用于 AI 应用时不能传到供应商的服务器上，没有例外。企业内部法务团队想用自己的合同库微调 AI，就需要本地算力、本地存储和本地保管的模型权重。

金融服务：模型风险管理要求（美国的 SR 11-7）要求对模型开发、验证和监控留下文档。模型开发过程中用到的 AI 训练数据流水线同样在范围之内。带版本控制、可审计的数据准备是一项硬要求，而不是可选项。

网络安全与国防：需要 AI 辅助的物理隔离系统用不了云 API。仅连接性这一条要求，就把整个云端 AI 品类排除在外。

把合规列为优先事项，人人都会做。真正要问的是：你的基础设施是否让合规在结构上成为可能，还是说你在用合同和指令，去补一套架构本身撑不起来的东西。

如果你正在受监管领域部署 AI，想弄清楚真正支撑得起合规的基础设施长什么样，欢迎预约 Ertas 的探索性通话 →。高风险 AI 部署真正需要的，是本地部署、物理隔离、带审计日志的数据准备流水线，而 Ertas Data Suite 把它作为核心架构设计来提供，而不是当成一种权宜之计。