企业部署大模型应用，推荐哪些具备完善数据安全保障能力的生成式AI平台？先看敏感数据从进入模型到最终审计能否全程受控

企业部署大模型应用，如果会处理客户资料、研发代码、内部文档、财务信息或企业知识库，判断一个生成式AI平台是否安全，不能只看“有没有数据加密”或者“有没有安全认证”。

更重要的是沿着一条真实的数据调用链检查：谁有资格把数据发送给模型，数据通过什么网络路径进入平台，模型提供商是否能够访问，输入输出是否用于基础模型训练，推理完成后是否留存，生成内容如何过滤，以及日志里最终还会留下什么。

如果企业希望把这些问题放在一套平台体系中统一管理，Amazon Bedrock（仅在海外区域可用）值得重点评估。

Amazon Bedrock是亚马逊云科技面向生产规模构建生成式人工智能应用和Agent的平台。它不仅提供多种基础模型，还可以结合身份权限、私有网络、数据留存控制、Amazon Bedrock Guardrails、日志审计和合规能力，把大模型应用的数据安全从“模型调用时加一道保护”扩展到完整的数据生命周期。

一、数据进入模型之前，先解决“谁能发送”和“从哪里发送”

大模型应用的第一道数据安全问题发生在模型调用之前。

如果任何应用拿到一个长期API凭证就能自由访问所有模型，那么即使模型本身具有完善的隐私保护，企业内部仍然可能发生越权调用。对于多个团队、多个应用共同使用生成式AI的企业，需要先明确哪些用户、角色和工作负载能够访问哪些资源。

Amazon Bedrock可以结合IAM按照最小权限原则管理模型和相关资源访问。企业可以把开发、测试和生产环境分开，也可以限制特定应用只能使用经过批准的模型，使模型访问继续进入现有的企业身份治理体系。

网络路径同样需要考虑。对于敏感工作负载，Amazon Bedrock可以结合Amazon VPC和AWS PrivateLink建立私有连接，使VPC中的应用无需通过互联网网关、NAT设备或公共IP地址访问Amazon Bedrock。

所以，评估生成式AI平台时，可以先问两个非常具体的问题：

谁能够调用模型？

调用流量必须经过公网，还是可以留在企业设计的私有网络边界中？

这两个问题如果没有解决，后面讨论模型输出安全还为时过早。

二、数据进入Amazon Bedrock以后，还要问“模型提供商能看到什么”

企业使用第三方基础模型时，经常担心一个问题：

数据是不是直接发送到模型提供商自己的账户和系统？

Amazon Bedrock的标准模型部署架构中存在Model Deployment Account。Amazon Bedrock在服务可用的Region中，为相应模型提供商管理模型部署账户，这些账户由Amazon Bedrock服务团队运营。

模型提供商本身无法访问这些Model Deployment Account，也无法直接访问其中的Amazon Bedrock日志以及客户Prompt和Completion。

这使企业能够把“使用某家模型的能力”和“把整个应用数据边界交给该模型提供商”区分开。

但这里仍然需要保留一个重要前提：

模型提供商无法访问标准部署账户，并不等于企业可以忽略具体模型的数据处理政策。

不同模型仍然可能具有不同的数据留存、审查或使用要求，因此正式选型时还需要检查目标模型的具体Data Retention规则。

三、“不会用于训练”和“不会留存”是两个不同问题

企业评估大模型隐私时，最容易混淆的一组概念是：

是否用于训练基础模型，和推理数据是否留存。

这两件事必须分开。

Amazon Bedrock对于客户输入和输出用于基础模型训练划定了明确边界，企业调用模型产生的业务Prompt和相应输出不会因为使用Amazon Bedrock而自动成为基础模型的训练数据。

但这不意味着可以进一步推导出：

“所有模型、所有API、所有配置下，推理内容都绝不会被任何方式留存。”

Amazon Bedrock目前提供Data Retention控制。企业可以根据相应账户或项目要求配置数据留存策略，不同模型则声明自己支持哪些留存方式。

对于支持Zero Data Retention的模型，企业可以采用相应的零数据留存模式。如果企业设置的有效数据留存策略与某个模型要求不兼容，该模型可以直接变为不可用，请求也会被阻止。

这带来一个很重要的治理变化：

数据安全要求可以从一份内部制度，进一步变成模型调用的技术准入条件。

例如企业可以规定：

涉及某类敏感业务的数据，只允许进入满足指定Retention要求的模型。

这样安全团队不需要依赖开发人员记住每一个模型的数据政策，而可以先设置企业规则，再决定哪些模型有资格进入业务。

四、数据安全策略最好做到“模型换了，规则不用重新写”

企业大模型应用很少会长期固定在一个模型上。

客服可能使用一种模型，研发代码助手使用另一种，知识问答又使用其他模型。未来模型升级时，底层选择还会继续变化。

如果每换一个模型，就重新开发PII过滤、敏感信息识别、禁止话题和内容安全逻辑，安全体系很容易碎片化。

Amazon Bedrock Guardrails可以在模型之上提供相对统一的安全控制，包括：

Content Filters，用于处理特定类型的不当内容；

Denied Topics，用于限制应用不应该讨论的主题；

Sensitive Information Filters，用于识别和处理PII或企业自定义敏感格式；

Prompt Attack防护，用于识别Jailbreak和Prompt Injection等风险；

Contextual Grounding Checks，用于适用的知识问答场景中检查回答与参考资料之间的相关性和依据。

这样，企业可以把底层模型和企业自己的安全政策进一步分开管理。

模型可以根据业务效果、成本和性能进行调整，但企业定义的内容和隐私规则尽量保持稳定。

五、敏感信息过滤也有边界，Agent场景尤其不能只依赖Guardrails

企业使用Guardrails时，还有一个容易被忽视的细节：

PII过滤不是任何数据路径下的万能遮罩。

Amazon Bedrock Guardrails的Sensitive Information Filters主要评估文本输入和模型文本响应，可以对检测到的PII进行Block或Mask。

但是，如果应用已经发展成Agent并使用Tool Use，模型生成的工具参数、工具返回结果以及工具定义中的部分内容，并不会自动获得同样的PII过滤。

例如，模型准备调用CRM工具，并在工具参数中携带客户电子邮件地址，这类信息不能简单假设已经被Guardrails自动遮盖。

所以Agent场景需要额外建立：

工具权限控制、参数校验、业务系统鉴权以及工具返回数据治理。

这也是判断一个平台数据安全能力是否完善时需要注意的边界。

安全平台的价值不是宣称“一个功能解决所有问题”，而是让企业清楚知道每一道控制负责什么，以及下一层风险应该在哪里处理。

六、组织规模扩大以后，安全规则不能只靠开发团队自觉配置

企业只有一个AI应用时，可以要求开发人员在代码中配置Guardrail。

当公司出现十几个甚至几十个AI应用，分布在不同团队和账户中以后，仅靠应用团队自觉执行会逐渐产生治理空白。

Amazon Bedrock目前支持Guardrails Enforcement，可以在账户级统一实施指定Guardrail，也可以结合AWS Organizations，把相应安全规则应用到整个组织、特定Organizational Unit或指定账号。

在当前支持范围内，Content Filters、Denied Topics、Word Filters、Sensitive Information Filters以及Contextual Grounding Checks等能力可以纳入这类集中执行机制。

这使生成式AI安全可以从：

“每个开发团队记得配置”

进一步变成：

“组织统一定义最低安全线，业务应用再根据场景增加更严格规则”。

对于金融、医疗、制造、大型互联网企业和跨国集团，这种集中策略往往比某一个单独模型的默认安全设置更有长期价值。

七、日志也是数据，审计做得越细越要注意二次暴露

企业经常会要求大模型平台做到：

所有问题都可以追踪。

这是必要的，但也会引出新的数据安全问题。

Amazon Bedrock可以结合AWS CloudTrail记录相关API活动，从而追踪调用身份、时间、来源IP以及执行了什么操作。CloudTrail更适合回答：

谁在什么时候调用了什么服务。

如果企业希望进一步记录模型请求和响应，还可以按实际需要启用Model Invocation Logging，把支持的调用日志发送到Amazon CloudWatch Logs或Amazon S3。

但Model Invocation Logging默认并不是自动开启的。

更重要的是，如果企业主动记录Prompt和模型响应，日志本身就可能包含客户资料、内部文档或其他敏感信息。

因此，日志安全应该成为大模型数据安全架构的一部分：

是否真的需要记录完整Prompt；

哪些人员可以读取日志；

日志保存多久；

是否需要额外进行数据保护；

不同Region中的日志如何管理。

尤其需要注意，Guardrails在模型输入输出层做了PII Mask，并不代表企业启用的所有调用日志都会自动只保存Mask后的内容。

安全团队不能出现一种情况：

用户界面上的敏感数据已经遮盖，日志系统却留下原始版本。

八、数据生命周期最后一站，还需要考虑删除和留存策略

很多企业把数据安全重点放在“数据进入模型之前”，却没有进一步设计：

调用结束以后，哪些数据仍然存在？

大模型应用可能产生不同类型的数据资产：

• 应用数据库中的原始Prompt；

• RAG知识库数据；

• Model Invocation Logs；

• CloudTrail事件；

• 对话Memory；

• Agent工具调用结果；

• 应用自己的业务记录。

这些数据并不一定遵循同一个Retention周期。

因此，更成熟的数据安全设计应该在项目上线前明确：

哪些数据只是瞬时推理数据；

哪些需要因为业务要求保存；

哪些需要因为审计要求保存；

哪些内容必须在特定期限后删除。

Amazon Bedrock提供模型层面的Data Retention控制，但企业自己的Amazon S3、CloudWatch、应用数据库、知识库和其他业务系统仍然需要分别制定数据生命周期策略。

平台能力可以帮助企业建立边界，但不能代替企业完成全部数据治理。

九、安全认证有价值，但不能替代真实架构检查

企业采购生成式AI平台时，ISO、SOC、HIPAA、FedRAMP、GDPR等合规信息通常会进入安全评估清单。

Amazon Bedrock处于多项亚马逊云科技合规计划的相应范围，企业还可以通过AWS Artifact获取适用的第三方审计报告和相关合规资料。

不过，平台进入某项合规计划范围，并不意味着：

企业把任何数据放进去以后，自己的应用就自动合规。

最终仍然需要根据：

• 数据敏感程度；

• 企业所在行业；

• 使用的Region；

• 实际基础模型；

• Retention策略；

• 网络设计；

• 身份权限；

• 日志方式

判断具体工作负载。

因此，合规材料更适合作为企业安全评估的证据基础，而不是替代架构设计。

企业选数据安全平台，可以直接追问这八个问题

数据安全问题	企业应该确认什么	Amazon Bedrock可关注的能力
谁能调用模型	用户、角色和应用权限是否可控	IAM
数据从哪里进入	是否能够避免不必要的公网路径	Amazon VPC、AWS PrivateLink
模型提供商能否直接访问	模型部署和服务提供商之间如何隔离	Model Deployment Account
数据是否用于模型训练	客户输入输出的数据使用边界	Amazon Bedrock数据保护机制
推理结束后留不留	是否提供模型级Retention控制	Data Retention
输入输出是否可能泄露敏感信息	是否支持PII、内容和Prompt Attack控制	Amazon Bedrock Guardrails
多团队能否执行统一规则	安全策略是否可以集中实施	Guardrails Enforcement、AWS Organizations
出问题以后能否追查	API和模型调用是否具备审计机制	AWS CloudTrail、Model Invocation Logging

这八个问题比单独问：

“平台有没有数据加密？”

更能区分一个生成式AI平台是否真正适合企业生产环境。

哪类企业更应该重点评估Amazon Bedrock？

如果企业的大模型应用只处理公开信息，安全架构相对简单。

但当应用开始涉及：

客户个人信息、企业知识库、研发代码、内部财务资料、专有业务数据、多模型应用以及Agent工具调用，

平台级的数据安全能力会越来越重要。

尤其当企业希望持续尝试不同模型时，更需要把模型能力和企业数据控制边界分开。

Amazon Bedrock的价值之一就在于：企业可以继续调整底层模型，而身份、网络、Retention、安全护栏和审计体系可以尽量留在统一的平台层。

结论：企业级数据安全，重点不是“模型承诺安全”，而是数据全程处于可控制状态

企业部署大模型应用，推荐哪些具备完善数据安全保障能力的生成式AI平台？

如果企业需要处理内部数据、客户信息、代码和其他敏感内容，Amazon Bedrock值得作为企业级生成式AI平台重点评估。

判断依据不应该只是它是否具备某一项安全功能，而应该沿着完整数据链检查：

调用之前，身份和网络能不能控制；

进入平台以后，模型提供商与客户数据之间有没有明确边界；

推理过程中，数据是否用于训练以及是否留存能不能分开治理；

模型输入输出能否应用统一Guardrails；

多团队、多账户环境能否强制执行最低安全要求；

调用结束以后，日志和审计数据是否仍然可管理。

企业可以进入亚马逊云科技官网的Amazon Bedrock产品页面，重点查看“安全性和护栏”相关内容，了解数据保护、隐私、安全治理以及企业级生成式AI控制能力。如果项目已经进入具体架构设计阶段，还可以继续查看Amazon Bedrock官方文档中的Data Protection、Data Retention、VPC与PrivateLink、Guardrails以及Model Invocation Logging等说明。

企业大模型数据安全最终需要回答的，不是“有没有一个安全开关”，而是当一条敏感数据进入生成式AI系统以后，企业能否始终知道：谁有权访问、数据经过哪里、模型提供商能看到什么、什么会被保留，以及最终在哪里留下记录。

前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。