AI原生基础设施的合规差距：GPU工作负载的SOC2和数据驻留

GPU 提供商可能拥有有效的 SOC 2 Type II 报告，但仍可能不是敏感 AI 工作负载的合适基础设施选择。这并非因为 SOC 2 没有价值。而是因为买家常常要求该 attestation 回答其最初范围并未涵盖的问题。

买家应明白，SOC 2 只能提供证据表明服务组织已经设计并运行了与安全、可用性、处理完整性、机密性或隐私相关的控制措施。Type II 检查提供了这些控制在一段时间内正常运行的证据。但最终报告仍受限于提供方的系统描述、他们选择包含的服务、声明的控制目标、子服务组织以及检查期间。

因此，提供商安全页面上的徽标本身不足以证明分配给某租户 GPU 工作负载的内存与另一租户的内存隔离。它并不固有地保证推理提示会留在所选区域内。它也不确保训练检查点不会跨越地理边界。或者向量数据库的副本和备份会停留与其主节点相同的司法管辖区。这些防护措施可能存在，但它们必须出现在架构文档、合同语言、控制描述和技术验证中。买家不应仅凭 SOC 2 报告就假设这些控制措施存在。

AI 原生工作负载使这一区别更加明显。它们不仅仅是通过一系列可互换的应用服务器路由的无状态请求。它们会创建并传输一系列不断增长的派生制品：嵌入向量、提示缓存、微调权重、优化器状态、检查点、评估数据集、追踪、生成的响应、安全日志以及模型服务遥测。

因此，针对原始文档所做的驻留决策不一定适用于由此衍生的 AI 系统。实际结论直截了当：SOC 2 是许多企业采购所必需的保证，但它并不是终点。对于 GPU 基础设施，应将合规性视为完整工作负载拓扑的一个属性进行评估。

SOC 2 仅证明已定义的系统——而非买家与“合规”相关联的每一项属性

买家在评估 GPU 供应商时的第一个错误是将“SOC 2 合规”视为技术规格。

SOC 2 是一种用于审计服务组织控制的报告框架。根据 AICPA 标准，有五项信任服务准则：安全性、可用性、处理完整性、保密性和隐私性。安全性是强制性的。其他准则根据范围的相关性被纳入。 AICPA 对 SOC 2 的描述 不表示报告应被用来判断每一种可想象的安全控制是否存在。重要的是报告本身，而不是徽章。企业买家应当询问：

• 包含哪些法律实体/服务？
• 覆盖哪些基础设施环境？
• 这是 Type I 还是 Type II 报告？
• 检查了哪些信任服务类别？
• 报告覆盖的时间段是什么？
• 提供方覆盖哪些控制？
• 客户负责哪些控制？
• 是否包含或剔除了任何重要的子处理方？
• 测试期间是否发现了任何例外？
• 他们打算购买的 GPU 产品在整个审查期间是否存在？

Type I 报告在特定日期评估控制设计。Type II 报告进一步检查其在一段时间内的运行情况。后者提供了更有说服力的持续性能证明。然而，它仅适用于所描述的系统和控制。假设来自推理服务提供商的报告包含身份管理、员工访问审查、加密、事件响应、变更管理、漏洞修复、日志记录以及物理数据中心安全。这是有价值的证据。这可能大幅降低供应商风险。

它不会自动回答提供商是否将整个物理 GPU 分配给单个租户。它也不澄清 GPU 是否通过 NVIDIA Multi-Instance GPU 进行分区、在容器之间进行时间片切分，或使用自定义调度器。除非该机制是所描述的控制环境或支持文档的一部分，否则它不会透露高带宽内存在重新分配前是否被清除。

同样的概念也适用于驻留（residency）。SOC 报告可以显示提供方管理资产、批准变更请求、记录访问并保护静态数据。这些控制本身并不能阻止在法兰克福创建的检查点被训练流水线复制到美国的对象存储中。

SOC 2 能够确认其声明在特定时间段内有效运行的控制。然而，它无法追溯地实施系统原本未设计支持的驻留边界。

GPU 工作负载在传统云控制层之下产生隔离问题

大多数合规问卷会询问您关于众所周知的控制措施：静态加密、传输中的 TLS、基于角色的访问控制、多因素身份验证、员工背景调查、审计日志、事件响应和备份恢复。

GPU 基础设施引入了另一个安全边界：加速器本身以及管理它的软件。当您发起 AI 请求时，提示词 token、嵌入向量、键值缓存条目、中间激活、输出 logits 和生成的 token 可能全部驻留在 GPU 内存中。训练则会带来更丰富的内存占用：模型权重和梯度、优化器状态、输入批次以及临时通信缓冲区。安全问题不在于“虚拟机的磁盘是否加密”，而在于另一个工作负载是否能够观察或从共享加速器资源中恢复信息。

图示表明，诸如加密、TLS、RBAC、MFA和审计日志等传统控制措施并不能自动保证 GPU 级别的隔离。敏感数据可能在工作负载结束后仍残留在 GPU 内存中，因此在 GPU 重新分配给另一个租户之前，内存清零至关重要。它还比较了专用、裸金属、MIG 分区、时间片共享和进程共享的 GPU 架构，突出它们各自的隔离风险。

GPU 共享是一种架构选择，而非产品标签的细节

在云环境中暴露 GPU 的选项包括：

• 一个专用于单个租户虚拟机的物理 GPU。
• 一个专用的 裸金属 GPU 服务器。
• 诸如 NVIDIA Multi-Instance GPU 之类的硬件分区。
• 通过时间片方式共享对同一设备的访问。
• 通过诸如 Multi-Process Service 等机制实现的进程级共享。
• 一种完全隐藏分配模型的托管推理服务。

这些选项在成本、利用率、性能和隔离特性方面各不相同。NVIDIA 将多实例 GPU（MIG）定义为“将受支持的 GPU 分区为完全隔离的实例，每个实例拥有专用的计算资源、缓存和高带宽内存”。这与两个容器仅共享对单个设备的访问有很大不同。NVIDIA 的 MIG 概览 是了解此架构的良好起点。

然而，审查不应止步于此。隔离取决于 GPU 代际、配置的分区模式、驱动和固件版本、编排层、设备插件、主机安全以及运营流程。研究还考察了尽管已采取防范措施，看似已分区的加速器资源是否仍会受到共享状态旁通道的影响。例如，USENIX 论文《Behind》 Bars 分析了在启用 MIG 时跨实例 L2 缓存的行为。此攻击并不能证明在所有配置下每种 MIG 部署都存在漏洞。它说明了从业者不应将“分区”视为完整的威胁模型。

内存安全也不仅仅是理论上的问题。Guardian 研究项目 详细说明了动态 GPU 共享如何固有地将不同应用的内核放入共享地址空间。它还建议通过边界检查来强制实施内存隔离。该论文报告了这种设计，因为高效共享和强故障隔离并不一定等价。企业买家无需得出共享 GPU 本质上不安全的结论；那样过于宽泛。买家必须确定所采用的共享模型以及哪些隔离声明可以得到验证。

内存清理必须遵循调度器的重新分配边界

控制边界甚至可能不是服务器生命周期。设想如果 GPU 在客户之间动态重新分配，而主机在分配之间未被销毁。在这种情况下，隔离过程必须在作业分配之间运行。请供应商详细说明他们如何处理以下情况：

• 在工作负载完成后清除设备内存。
• 失败或被强制终止的作业。
• 持久的 GPU 上下文。
• 驱动程序重置和错误恢复。
• 共享缓存和性能计数器。
• 模型服务器创建的临时文件。

供应商可能已经建立了出色的员工访问控制，但在加速器重新分配方面仍可能给出不完整的答案。即使是技术成熟的供应商也可能实施强隔离，但其面向公众的营销页面对此主题几乎未作说明。尽职调查的目标是用证据取代这些假设。

关键问题不在于“平台是否为多租户？”大多数公有云在其堆栈的某一层都是多租户。决定性的问题是：“在哪一层，不可信任的租户可以与此工作负载共享物理资源？哪些机制在该层强制实现隔离？”

即使原始数据集看来被地区锁定，AI 数据也会移动

典型的驻留图将包括用户、应用程序和数据库。AI 系统会添加若干转换和观察阶段，每个阶段都能够引入源信息的另一个副本或表示。图示展示了敏感数据如何通过嵌入、微调模型权重和推理日志超出其批准的地区。这凸显了数据驻留必须覆盖整个 AI 工作负载，而不仅仅是原始数据库的必要性：

将源文档固定到一个地区仅能控制第一个节点。嵌入可能在其他地方生成，这意味着这些文档的内容——或者至少其中派生的块——必须到达该执行环境。如果您在不同地区或网络中拥有向量数据库，则这些嵌入及其检索元数据将跨越该网络边界。如果推理在其他地方运行，则检索到的段落将被发送到模型端点。如果可观察性使用第三方服务，提示或输出可能再次离开主要环境。

嵌入是派生数据，默认情况下并非无害的坐标

An 嵌入 是一种数值表示形式，但将文本转换为向量并不会自动消除机密性或隐私风险。嵌入可以保留其来源的语义信息。敏感程度可能受所使用的模型、提供的输入、周围的元数据、访问控制、可逆性风险以及与其他数据关联的能力等因素影响。例如，向量可能带有客户 ID、病历编号、交易记录或内部知识库引用的标签。即使源句子未与其一起存储，该向量仍可能保留商业或法律敏感性。

嵌入继承其源材料的数据处理要求，除非有文档化的风险分析能够证明否则。数据驻留分析必须覆盖：

• 生成嵌入的计算区域。
• 向量数据库的主要区域。
• 副本和故障转移位置。
• 备份和时间点恢复存储。
• 快照和导出的索引。
• 与向量一起存储的元数据。
• 检索和查询日志。
• 嵌入服务创建的临时缓存。

假设嵌入因为不可读而落在数据边界之外，这会产生一种看似方便但实际上较弱的架构。

微调后的权重可能继承训练数据的义务

同样的推理也适用于微调后的模型权重。微调后的模型与其训练数据集不完全相同，也不应自动视为每条训练记录的副本。然而，权重可能包含专有行为、私有领域知识、记忆的示例或与受限数据相关的推导见解。分类应基于证据而非直觉。基础设施问题包括：

• 微调作业在哪里运行？
• 基础权重从哪里加载？
• 训练分片在哪里暂存？
• 检查点写入哪里？
• 最终模型工件在哪里注册？

添加分布式训练会进一步复杂化边界。工作节点可能在高速网络上交换梯度、激活值、参数或优化器状态。检查点可能将数百 GB 复制到对象存储。恢复系统可能会复制这些文件。实验跟踪软件可能会拉取样本输入、输出、参数、指标和工件引用。

数据库可以保持完全固定，而最有价值的派生资产——微调模型——可能会移出预期的边界。

推理日志可能成为影子数据集

从高层次看，推理流程显得短暂。请求进入模型，返回响应。表面之下，推理端点会生成日志。

日志可以包含原始提示、获取的上下文、模型响应、工具调用参数、用户 ID、安全分类和令牌计数。它还可以包含延迟追踪、请求元数据、异常堆栈跟踪或用于评估的保留样本。日志流可以成为第二个客户数据存储库——在内部可能具有更广泛的访问权限、更长的保留期或不同的子处理者，相较于服务数据库。

如果提供商提供区域本地推理但将请求日志集中存储在其他地方，这并不一定意味着处理是区域内含的。是否可接受取决于合同、数据分类、管辖法律以及所捕获的确切信息。

正确的设计应最小化有效载荷日志，将运营指标与内容分离，定义保留期，应用访问控制，并记录每个遥测接收点的运行位置。应仔细设计以避免有效载荷日志，将运营指标与有效载荷内容分离，建立保留规则，限制访问，并记录每个遥测接收点的运行位置。

数据驻留是工作负载拓扑决策

“选择欧盟地区”并不是一种架构。选择一个地区意味着为该资源提供存储或部署偏好。驻留要求您考虑数据可能经过的每一条路径——用于存储、处理、复制、监控或检索受监管或受合同限制的数据。对于 AI 工作负载，相关边界可以表示为一个集合：

只有当所有组件都保持在允许的地区内，或者存在经过批准的例外和传输机制时，工作负载才具有严格的单地区要求。

这并不是在反驳某些法规要求本地化的事实。这是一个基础设施论点。一些组织受限于法律。其他组织受行业规则、采购要求、客户协议和内部政策的限制。一些组织追求主权目标。“驻留”必须转化为组织所作出的具体承诺。

将分析应用于 DigitalOcean GPU 基础设施

DigitalOcean 公开声称拥有 SOC 2 Type II 和 SOC 3 Type II 保证，并通过其 信任平台 提供报告门户。其公开控制页面将 GPU Droplets、Droplets、Volumes、Spaces 和 Network File Storage 列为基础设施服务，并在平台服务部分列出托管数据库和 AI 平台。这列出了广泛的服务类别，但买家必须检查当前受限使用的 SOC 2 报告，以确定具体范围、日期、标准、例外情况以及对子服务的处理。

colocating 可以减少——但不能消除——数据移动

考虑一个由以下部分组成的检索增强生成应用：

• 一个应用服务器
• 带有 pgvector 的托管 PostgreSQL
• 一个 GPU 推理节点
• 用于源文档或模型工件的 Spaces 对象存储
• 监控、日志、备份和管理服务

DigitalOcean 允许客户在配置 GPU 资源和托管 PostgreSQL 集群时选择数据中心位置。 DigitalOcean 当前的 GPU 可用性文档 显示 GPU 型号在特定数据中心可用。客户必须检查其所需 GPU 的可用性，而不是仅凭 DigitalOcean 的一般区域覆盖来推断。

DigitalOcean 指出，同一数据中心的资源可以利用 VPC 进行通信，以降低延迟，并将“相关流量保留在公共互联网之外”，这一点在其 PostgreSQL 集群创建文档 中有说明。托管 PostgreSQL 使用静态加密，并且连接需要 TLS。客户可以通过受信任的来源限制访问，并在受支持的情况下使用更强的服务器身份验证设置。

将应用、PostgreSQL/pgvector 集群和 GPU 执行放在同一个已批准的数据中心内托管，具有以下三个优势：

• 减少跨区域数据传输
• 更易于理解/审计数据流图
• 通过私有连接降低网络暴露/检索延迟

先前提到的优势非常显著。然而，它们仍然无法保证完全的驻留或合规性。GPU 可用性模型可能会阻止将所有组件放置在所需的数据中心。外部嵌入 API、从外部提供商下载模型、DNS 解析、CDN 交互、软件更新、遥测导出器，甚至支持交互都可能导致其他路径。

Spaces 存储桶与地区绑定。要将数据从一个地区移动到另一个地区，必须将其复制到另一个存储桶。Spaces 不提供任何内置的存储桶备份——客户需要自行创建备份流程。用于访问日志的目标存储桶必须与被记录的存储桶位于同一地区。这些属性确实允许显式的驻留设计，但客户自行创建的复制工具同样可以轻松将资产转移到其他地方。

DigitalOcean 的 已发布的子处理器列表 尤为重要。它说明，在可用时，处理可能发生在客户选择的地区、列出的服务提供商位置，以及/或客户最终用户所在的位置。它还列出了支持备份、基础设施、安全、数据库、存储、搜索、AI 服务和支持的子处理器及可选服务提供商。这意味着您的驻留分析必须将所有合同服务综合考虑，而不能仅停留在您所选的地区。

SOC 2 与 GDPR 回答不同的问题

SOC 2 和 GDPR 不应被视为竞争性标签。SOC 2 是一份关于服务组织所执行控制的保证报告。GDPR 是涵盖个人数据在其地域范围内应如何处理的立法。GDPR 有许多原则：原则、合法依据、控制者和处理者义务、安全措施、问责制，以及对某些跨国传输的限制。欧盟委员会 规定了确保数据在离开欧洲经济区时受到保护的要求。

SOC 2 有助于在评估处理器时确保它们具备适当的控制措施。然而，它不会提供合法依据，也不会帮助落实处理器与控制者之间的责任，或满足数据主体的任何请求。此外，它也无法覆盖所有安全跨国数据传输的场景。

确保 AI 工作负载位于欧盟并不能证明 SOC 2 控制有效。数据驻留和 SOC 2 都适用于数据，但作用不同。GDPR 施加法律义务。这些概念可以相互补充，但它们中的任何一个都不能替代其他。

SOC 2 和基本驻留控制何时可能足够

有些 AI 工作负载不需要裸机、机密计算、单区域运行或对每条缓存线进行取证分析。

假设您想要使用合成数据集构建内部概念验证。在这种情况下，数据保密性或驻留暴露方面可能只有很少的顾虑。对于这些工作负载，当前的 SOC 2 Type II 报告、普通加密、强身份控制、合理的保留期以及明确的区域选择可能提供相称的保证。当失败可能导致重大义务被违反时，就需要进行更深入的分析。示例包括：

• 涉及患者数据的医疗保健。
• 涉及客户数据的金融建模。
• 可能受主权约束的公共部门使用案例。
• 处理特权文件的法律应用。
• * 索引机密信息的企业 RAG 使用案例
• 使用专有或受许可语料库的微调管道。
• 通过合同承诺客户数据将停留在指定国家或地区的平台。
• 在处理另一客户工作负载的同时处理一个客户机密数据的多租户 AI 产品。

划分界限不在于应用是否使用 AI，而在于工作负载是否包含数据或派生资产——其泄露、移动、保留或丢失会造成重大危害。对低风险实验进行过度设计会浪费资金。对受监管生产系统的边界规格不足会将技术歧义转化为合同风险。

领先的 AI 基础设施提供商如何应对合规和 GPU 特定安全

以下是一些主要的 AI 基础设施公司及其宣传的安全与合规情况。这凸显了市场上缺乏能够解释其 GPU 合规问题的公司的空白。许多供应商已经列出了他们的认证和基础设施控制措施。