作者：来自 Elastic Sean MacKirdy

探索用于生成式 AI 沙箱的配方，为开发者提供一个安全的环境来部署应用原型，同时实现隐私和创新。

动手体验 Elasticsearch：深入了解我们的示例 notebooks，开始一个免费的 cloud 试用，或者现在就在你的本地机器上尝试 Elastic。

---

构建生成式 AI（GenAI）应用正在风靡一时，而上下文工程（context engineering），也就是为大型语言模型（large language model - LLM）提供所需的提示结构和数据，使其在不自行补全缺失信息的情况下返回具体且相关的答案，是过去 24 个月中出现的最受欢迎的模式之一。上下文工程中的一个重要子集是检索增强生成（RAG），它通过利用基于自然语言的搜索能力，根据语义而非关键词，从私有数据集中检索最相关的结果，从而为 LLM 交互提供额外的上下文。

随着上下文工程的迅猛发展，如何确保快速原型项目不会将业务或任务关键数据暴露给未授权的接收方，成为一个重要关注点。对于同时关注技术和政策的受众来说，我一直在倡导 “隐私优先” 的 GenAI 沙箱概念，下面我将其简称为沙箱。在本文中，沙箱指的是一个自助式、安全的原型设计空间（类似儿童的沙坑，木质边缘可以防止沙子外泄），它允许组织成员安全地测试其自定义的上下文工程应用，而不会有泄露机密数据的风险。

生产级 GenAI 沙箱 = 实现隐私

GenAI，从像 ChatGPT、Claude 和 Gemini 这样的文本生成工具，到像 Google 的 Nano Banana、OpenAI 的 DALL-E 和 Midjourney 这样的图像生成工具，在过去两年里引发了无处不在的讨论：在课堂上、在餐桌旁、在监管圈、在法庭上，以及在董事会会议室中。

我有幸与客户分享 Elastic 在上下文工程方面的方法，尤其是 RAG，这些客户包括开发者和 C-suite 高管，也包括我的一些联系人，从朋友和家人到立法者。可以将上下文工程理解为一名图书管理员，它负责查找并提供上下文数据，用来增强文本、音频或图像 GenAI 应用，使其补充其训练数据中原本不具备、但完成目标任务所需的信息；例如，查询体育比分和新闻标题，来帮助一个文本生成应用回答 “昨天国家冰球联盟发生了什么？” 这个问题。

如果你不熟悉这个概念并希望进一步阅读，Elasticsearch Labs 在这里提供了关于上下文工程的优秀入门材料，在这里也提供了关于 RAG 的介绍。

隐私优先的方法可以确保上下文工程为 GenAI 应用提供受保护的、经过选择的或敏感的数据，从而生成比仅使用公共信息更充分、更相关的响应。一个例子是，为大学生提供一个由 GenAI 驱动的交互式文本聊天体验（chatbot），用于获取与其个人背景相关的助学金和奖学金信息，同时避免将诸如社会安全号码或出生日期等个人可识别信息（PII）暴露给恶意攻击者，防止其通过常见漏洞（例如 OWASP Top 10）或通过 LLM 本身进行信息提取。

部署沙箱背后的核心逻辑原则如下：

1. 用户无论其组织是否提供相关工具，都会找到将 GenAI 融入其日常工作流程的方法。即使在现实中防止此类 “shadow IT” 并不现实或几乎不可能的组织中，提供并监控访问以防止组织敏感数据泄露仍然至关重要；而沙箱正是释放这些工具的理想场所。
2. 提供一个内置 Application Performance Monitoring（APM）和信息安全（InfoSec）最佳实践的沙箱来部署应用，可以让组织在保护隐私的同时，洞察 GenAI 的潜在使用场景，实现对 GenAI 使用的审计和问责，并建立集中化的成本管理。
3. 组织的沙箱应支持自助式或低接触方式部署经过同行评审的 GenAI 应用，以便让有意愿自行开发应用的人在最小摩擦下进行最大程度的实验。
4. 如果正确实施并限制在组织受控的边界内，沙箱可以在不触发因未经授权或非预期的外部共享、或其他受保护数据（如 PII）泄露而产生责任的情况下，利用组织现有的数据资产——例如加州 CCPA，或欧盟 / 英国 GDPR。

本文不会重点介绍如何构建 GenAI 应用；在 Elasticsearch Labs 中已经有大量优秀示例。相反，我将重点介绍部署一个沙箱所需的配方，该沙箱能够提供实现上述第 3 条原则所需的安全性和可用性。

基础要素

要使沙箱被认为是生产级，需要考虑以下基础要素：

让我们来探讨为什么每个要素在沙箱配方中都起着关键作用。在此过程中，请注意，我下面列出的品牌选择基于个人经验，并不代表 Elastic 对任何技术的认可。就像任何配方一样，这些形成了我偏好的要素。当然，你可以在每个环节替换，以使配方符合你的需求：

1. 容器化平台

沙箱配方的第一个要素是选择容器化平台。这些平台在概念上类似于过去 15 年企业 IT 的虚拟机，但在应用打包和部署方式上有显著演进。它们旨在实现快速部署、无服务中断的升级，以及在本地和云计算环境中的原生分发，同时提供更高的可测试性、基础设施验证和可审计性。你选择的平台，通常通过基础设施即代码（IaC）进行管理，以确保可复现性和一致性，是实现 GenAI 应用敏捷性和可扩展性的基础。

容器化平台的关键组件

健壮的容器化平台由几个关键组件构成：

• 容器运行时（Container runtime）：执行容器并管理其生命周期的软件。一个常见示例是 Docker，它提供构建、共享和运行容器镜像的工具。
• 镜像构建基础设施（Image build infrastructure）：用于从应用源代码创建容器镜像的过程和工具。像 Dockerfiles 这样的工具提供了一种清晰、可重复的方法来定义镜像内的环境、依赖和应用代码，确保开发、测试和生产环境的一致性。
• 编排引擎（Orchestration engine）：在生产级环境中，你需要一个系统来自动化容器的部署、扩展和管理。Kubernetes（k8s）是行业标准，提供强大的负载均衡、自我修复和服务发现功能。下面在要素 #2 中会详细介绍。

1.1 基础设施即代码（Infrastructure as code）

为了确保沙箱的可复现性和可维护性，容器化平台应使用 IaC 原则进行管理。这意味着，你不是手动配置平台，而是通过代码文件定义基础设施（例如 Kubernetes 集群、网络规则、安全策略），可以使用 Terraform 或 Pulumi 等工具。该方法提供了多个好处：

• 版本控制（Version control）：你的基础设施可以像其他代码一样处理，允许跟踪更改、回滚到以前版本，并通过 Git 与团队协作。
• 一致性（Consistency）：IaC 大幅减少人为错误，确保沙箱环境可以在任何云或本地位置完全复现。
• 自动化（Automation）：它使你能够自动化整个搭建和拆除过程，轻松为特定项目或测试创建临时沙箱。

2. 托管与编排

正如在 “容器化平台” 部分介绍的那样，我们需要一个强大的编排引擎来大规模管理容器。为此，k8s 是编排生产级沙箱的事实标准。如果你不熟悉，可以查看 Cloud Native Computing Foundation（CNCF）提供的 k8s 入门资料。无论是在云端还是本地运行，Kubernetes 都提供了部署、扩展和管理容器化应用生命周期所需的稳健框架。主要云提供商，如 Google Cloud（Google Kubernetes Engine [GKE]）、Amazon Web Services（Elastic Kubernetes Service [EKS]）和 Microsoft Azure（Azure Kubernetes Service [AKS]），都提供成熟的托管 Kubernetes 服务，处理底层复杂性，特别是合同保障和独立认证的合规性，符合法定隐私和信息安全要求，让团队可以专注于构建和部署应用。

对于 GenAI 沙箱，Kubernetes 尤其有价值，因为它可以高效管理和扩展 GPU 资源，而 GPU 往往是 GenAI 技术栈两个关键组件所必需的：1）私有托管的 LLM；2）驱动它们的推理过程（在要素 #6 和 #7 中会详细讨论）。它自动化部署和资源管理的能力，确保快速原型开发者可以在不成为基础设施专家的情况下，尝试不同的模型和应用，所有操作都在你定义的安全隔离区域中进行，这在 k8s 中称为 namespace。这个抽象是沙箱成功的关键，它在保持集中控制的同时，赋能创新。

3. 代码仓库 / 镜像仓库

集中式代码仓库是一个安全且协作的 GenAI 沙箱的核心要素。它为开发者提供了一个统一、受控的环境来存储、管理和版本化代码，防止敏感信息在不同、不安全的位置扩散。通过建立集中仓库，组织可以执行安全策略、监控漏洞，并保持所有代码变更的清晰审计记录，这对于在沙箱环境中维护数据隐私和完整性至关重要。

例如，当像 GitHub 这样的服务与组织的身份和访问管理（identity and access management - IAM）及单点登录（SSO）解决方案（见下面的要素 #4）集成时，它成为执行最小权限原则的强大工具。这种集成确保只有经过身份验证和授权的开发者才能访问特定代码仓库。你可以创建团队并应用精细化权限，限制对敏感项目的访问，防止未经授权的代码修改。这在 GenAI 场景中尤为重要，因为代码可能包含专有算法、敏感数据连接器，甚至在某些情况下包含组织或用户级凭证或其他机密信息。

此外，现代仓库平台提供自动化安全扫描功能。这些工具会持续扫描代码，检测已知漏洞、不安全的编码实践以及暴露的密钥。如果开发者意外提交了密码或 API key，系统可以自动标记并通知安全团队。这种主动的安全方法对于防止数据泄露、执行法律要求和保密合同义务，以及确保在沙箱中开发的 GenAI 应用的整体完整性至关重要。通过强制所有开发在集中且安全的仓库中进行，你为创新创建了透明、可审计且安全的基础，让开发者可以自由实验而不影响组织安全。

4. 身份和访问管理

IAM 是安全、隐私优先的 GenAI 环境的核心组件。它为确保只有授权的个人和服务能够访问敏感数据和强大 AI 模型提供基础。一个健壮的 IAM 框架能够执行最小权限原则，为用户或服务授予执行其功能所需的最低访问权限。

4.1 单点登录（Single sign-on）

SSO 通过允许用户一次身份验证即可访问多个应用和服务，而无需重复输入凭证，从而简化了用户访问。在沙箱环境中，SSO 简化了开发者、数据科学家和业务用户的使用体验，他们需要与 AI 生态系统中的各个组件进行交互，例如数据仓库、建模工作台和部署管道。通过集中认证，SSO 还增强了安全性，减少了可能被泄露的密码数量，并提供了执行认证策略的单一入口点。重要的是，它降低了经验较少的开发者正确保护沙箱中数据的门槛，从而防止敏感信息被内部人员或外部人员意外泄露。

4.2 基于角色的访问控制（Role-based access control）

RBAC 是一种根据组织内用户角色限制网络访问的方法。在 GenAI 沙箱的背景下，RBAC 用于定义和执行不同用户角色的权限。例如，数据科学家角色可能对特定数据集具有读/写权限，并能够应用机器学习模型，而业务分析师角色可能只能对这些模型的输出进行只读访问。这确保了职责清晰分离，并防止未经授权访问或修改敏感数据和 AI 资产。

4.3 基于属性的访问控制（Attribute-based access control）

ABAC 提供比传统 RBAC 更细粒度和动态的访问控制方法。ABAC 基于用户、被访问资源以及环境的属性组合来做出访问决策。例如，访问一个特别敏感的数据集可以限制为：用户属于数据科学家团队（用户属性）、访问被标记为 PII 的资源（资源属性）、并且是在工作时间从公司网络访问（环境属性）。这种细粒度控制在 GenAI 沙箱中对于执行复杂的数据治理和隐私要求至关重要。稍后在讨论搜索 AI 数据存储时，我们会再次提到。

4.4 访问可审计性（Access auditability）

一个健壮的 IAM 框架还确保所有访问权限的授予、使用、审查和撤销都被精细地记录、可发现和可审计，这样在任何疑似或确认的事件发生时，响应人员可以快速了解发生了什么、遏制事件、评估其范围，并全面补救其后果。这不仅对组织自身的安全至关重要，也有助于遵守可能触发的任何事件报告和泄露通知要求。

5. 密钥管理

在我们配方中的所有要素中，密钥管理或许是最重要的，但也是最常被忽视的。就像少量藏红花就能显著改变一道菜的风味一样，一个处理不当的 secret 也可能对组织的安全和声誉造成巨大且毁灭性的影响。在我们的场景中，secret 指任何应用运行所需的敏感信息：用于第一方或第三方服务的 API keys、数据库密码、信任证书，或用于认证 LLM 的 tokens。

当这些 secrets 被硬编码在源代码中或留在明文配置文件中时，就会产生巨大的漏洞。泄露的 API key 或暴露的数据库凭证可以绕过其他所有安全措施，为攻击者提供直接访问敏感数据和系统的途径。这在 GenAI 沙箱中尤为关键，因为开发者经常需要连接各种数据源和外部模型提供者。如果没有健全的密钥管理策略，你就相当于把通往王国的钥匙散落在数字环境中，将你的创新沙箱变成潜在的数据泄露源。

为妥善保护这些 secrets，专用的密钥管理平台是必不可少的要素。这些工具提供集中加密的 vault 来存储 secrets，并具备强大的访问控制、审计和动态轮换功能。无论你选择自托管解决方案，如 HashiCorp Vault，还是托管云服务，如 Google Cloud 的 Secret Manager 或 AWS Key Management Service（KMS），原则都是相同的：在运行时以编程方式将 secrets 注入到应用中。此做法确保 secrets 永远不会在代码中暴露，保护你最有价值的凭证，并保障沙箱环境的安全。

这不仅仅是最佳实践：由于密钥管理技术已经成熟并被广泛使用，它构成了某些隐私法律和监管机构所参考的“最先进”标准，用以评估组织的信息安全状况。未能使用最新技术保护组织最重要的 secrets，不仅是错失良机，也可能构成监管不合规，因为执法机构和法院常会追究。

6. 私有 LLM 部署

在现代 GenAI 兴起初期，使用托管服务（如 Azure OpenAI）的主要动因是保证客户的 prompts 和数据不会被用于重新训练公共模型。这是企业采用的关键第一步。然而，随着该领域的发展，讨论焦点已发生转变。虽然数据隐私仍然至关重要，但使用私有 LLM 实例（无论是来自主要云提供商还是自托管）的决定，现在同样受到对保证吞吐量、可预测延迟以及对模型运行环境的精细控制的需求驱动，以支持生产级应用。

这个关键要素有三种不同形式，每种都有其有效使用场景及权衡：

A. 云托管 SaaS

这是最常见且最易获取的方式。像 OpenAI Enterprise、Azure OpenAI、Google Cloud 的 Vertex AI 以及 AWS Bedrock 这样的服务，通过托管 API 提供访问强大、最先进模型的能力。

• 优点：该方式提供最快的上市时间。云提供商处理所有底层基础设施、扩展和维护，让团队可以专注于应用开发。它提供简单的按需付费模式，并可访问多样的专有及开源模型库。
• 缺点：对底层基础设施的控制最少，可能在高峰需求时出现性能波动。在极高使用量下成本可能更高，并且依赖提供商的路线图和模型可用性。同时，由于数据离开客户环境，增加了应用的潜在漏洞面，这对高度监管或强调数据主权的客户来说是一个挑战。

B. 云托管 GPU + 容器化 LLM

这种方式是在云提供商的虚拟化 GPU 基础设施上运行开源 LLM（如 Mistral 或 Meta 的 Llama 系列模型）。通常使用我们之前讨论的容器化和 Kubernetes 编排管理，并结合高性能推理服务器，如 vLLM。

• 优点：提供了控制与灵活性的强大平衡。你可以直接控制资源分配、模型版本和服务配置，从而实现显著的性能调优。在高并发场景下，优化良好的推理服务器可显著提高吞吐量。例如，基准测试显示，像 vLLM 的推理引擎在高负载下相比非生产导向服务器提供更高的 tokens-per-second 和更低延迟 [Red Hat, 2025]。
• 缺点：运营负担更重。团队需要管理 GPU 实例、容器镜像和推理服务器配置。这需要更深的机器学习运维（MLOps）和基础设施管理技术，以有效实施和维护。

C. 本地 GPU + 容器化 LLM

最可控且通常最复杂的方式是在自己的数据中心内部署容器化 LLM。这种设置在功能上类似于第二种方式，但去除了对公共云提供商硬件层的依赖。

• 优点：提供最高的安全性、控制力和数据主权。对于需要完全隔离环境、数据不离开物理场所的组织，这是唯一选择。对于大规模、可预测的工作负载，长期来看可以通过避免云数据出站费用和按交易收费而更具成本效益。
• 缺点：购买和维护高端 GPU 硬件的初始资本支出巨大。需要高度专业化的团队来管理物理基础设施、网络和整个软件栈。这种方式更难扩展，因为需要物理采购和安装新硬件。

7. 搜索 AI 数据存储

如果 LLM 是我们 GenAI 应用的大脑，那么数据存储就是它的心脏，为推理提供相关且富含上下文的信息。为了让 RAG 应用真正有效，它不能仅依赖简单的向量数据库。基础数据通常非常复杂，包含非结构化文本、结构化元数据以及各种数据类型。因此，你选择的数据存储必须具备独特的特性，以在大规模下处理这种复杂性。

支撑整个过程的是向量嵌入（vector embeddings）的创建，它是相对于该嵌入空间知识集的数据的数值表示。为了实现语义搜索，你的数据必须首先通过推理模型转换为这些数值表示。一个灵活的数据存储不仅应存储这些向量，还应能够承载推理过程本身。关键是，它应允许你使用所选择的模型，无论是最先进的多语言模型、针对特定领域（如金融或法律）微调的模型、为高速度结果构建的紧凑模型，还是能够处理图像的模型。通过管理推理，该平台确保数据被一致且高效地向量化，为后续强大的搜索功能奠定基础。

首先，它必须掌握混合搜索（hybrid search）。最优秀的检索系统不会强迫你在传统关键词搜索（如 BM25，擅长查找特定关键词）和现代向量搜索（擅长通过语义意义，即自然语言查找结果）之间做选择。一个真正强大的数据存储允许你在单个查询中同时使用两者。这确保你既可以找到匹配精确产品代码或缩略词的文档，也可以找到概念上相关的文档，为 LLM 提供最相关的上下文。

其次，它需要一种智能结果重排序（intelligent result reranking）的高级方法。当你运行结合多种方法的混合搜索时，需要一种方式将不同结果集合并成单一且连贯的排序。倒数排序融合（reciprocal rank fusion, RRF）等技术在这里至关重要，它们智能地结合来自不同查询的相关性分数，生成的最终列表比任何单一方法单独提供的结果都更准确、更相关。

最后，面向搜索 AI 的数据存储必须是一个统一的引擎，并内置安全性。对于企业级 RAG，仅仅找到相似向量是不够的。你必须能够在搜索之前对数据应用安全和访问控制。前述的 RBAC 和 ABAC 功能允许在搜索时对内容进行预筛选，确保向量搜索只在用户有权限访问的数据上执行。这降低了通过沙箱意外或恶意规避访问控制的风险，同时保持可证明的隐私和保密合规性。这种能力将过滤、全文搜索和向量搜索结合在单一可扩展平台中，是真正能够为安全、隐私优先的 GenAI 沙箱提供支持的数据存储的关键特征。

8. APM 与安全

我们配方中的最后一个要素确保整个沙箱的健康、安全和性能：一个统一的平台，用于 APM 和安全信息与事件监控（SIEM）。一个真正多功能的搜索 AI 数据存储的关键特性在于，它不仅能为你的 RAG 应用提供 R，同时还能作为所有由基础设施和应用生成的日志、指标和追踪的标准化存储库。通过将这些运维数据整合到同一个强大的数据存储中，你就创建了一个单一视图的可观测性和安全平台。

这种方法提供了若干关键能力。在基础设施层面，你可以监控托管沙箱的 k8s 集群和为 LLM 提供支持的 GPU 的性能和资源使用情况，从而主动识别瓶颈或故障。在应用层面，APM 提供详细的追踪，用于诊断 GenAI 原型中的延迟问题或错误。在安全方面，这个集中式数据存储成为你的 SIEM，将登录事件、应用日志和网络流量关联起来，以检测沙箱内的异常行为或潜在威胁。

最重要的是，这个统一平台让你能够深入了解 GenAI 应用本身的使用情况。通过收集和分析应用遥测数据，其中应包括在许可范围内用户提交的 prompts（可对 PII 进行脱敏处理），你可以识别趋势、了解用户提出的问题类型，并发现热门使用场景。这为改进你的 RAG 应用提供了宝贵的反馈循环，并展示了使用单一可扩展数据存储来保障、监控和优化整个 GenAI 生态系统的强大能力。

制作配方

在所有要素就位后，让我们看看如何将它们组合成一个生产级 GenAI 沙箱。

就像任何食谱一样，先来看成品效果的示意图：这是最终架构可能的样子。

如图所示的整体环境包括一个 Kubernetes 集群，用于托管你的沙箱 AI 应用（为持续集成和持续部署 [CI/CD] 管道设置 dev/preprod/prod 命名空间）、用于认证的 IAM 基础设施、若干 GenAI 应用、代码和容器镜像仓库，以及覆盖整个沙箱的 APM 和网络安全监控层。

配方步骤 0：策略基线

在开始混合任何要素之前，每个优秀的厨师都会进行 mise en place（准备工作），也就是为成功做好准备。在我们的配方中，这意味着要为沙箱的使用建立清晰的策略。这是基础步骤，你需要决定 “厨房规则”。开发者是否可以使用内部生产数据，或者经过假名化（pseudonymization）、差分隐私（differential privacy）处理的生产数据，或者类似真实的合成数据，还是仅使用公开数据？沙箱是完全自助的平台，还是带有护栏的托管服务？应用更新是否需要正式的变更审查委员会（Change Review Board），还是同行评审即可？这些问题高度依赖组织的具体背景和目的。提前回答这些问题至关重要，因为这些策略决策会直接影响你如何配置配方中的其他要素。

配方步骤 1：信息安全基线（InfoSec baseline）

如 “要素” 部分所述，IAM 是配方中不可或缺的一部分。在允许任何人进入 “厨房” 之前，你必须确保外围安全，只允许佩戴经批准的制服和符合要求的防护装备的授权厨师访问工具和原料。这意味着从第一天起就要直接与信息安全团队合作，在强安全原则的基础上构建沙箱。对数据存储、代码仓库、Kubernetes 托管环境以及应用本身的访问都必须遵循既定的最佳实践进行限制。

在环境中执行组织的 IAM 策略后，一个实际的身份验证流程可能如图 3 所示。

如图所示，在 Kubernetes 生产命名空间中的应用之间，任何通信都必须先通过 OAuth 代理（如 Vouch）。这确保每个用户都通过中央认证提供者（如 Okta）进行身份验证，并强制执行双因素认证等策略。在此模型中，关键的用户上下文信息（如用户名和 IP 地址）可以随每个请求传递，从而在应用层实现强有力的审计和不可否认性。

配方步骤 2：容器配置基线

假设许多快速原型开发者是充满热情的创新者，但未必是经验丰富的软件工程师或经过法律培训的数据合规专家，那么提供基线配置至关重要，以确保他们的成功与安全，同时避免无意中违反任何规则或策略。可以将此步骤视为提供一张主配方卡，以保证一致性。至少，你应该提供关于如何构建容器镜像、将其部署到 Kubernetes 集群，以及测试所有连接是否安全的清晰文档。

更进一步，你可以在代码仓库中创建一个 “Clone This Starter App” 模板。这样开发者就有一个预配置、经过安全验证的起点，包含 Dockerfiles 和管道脚本，他们可以立即 fork 开始试验，大幅降低入门门槛，同时从一开始就强制执行最佳实践。

此外，许多实际的 GenAI 使用场景不可避免地涉及某种形式的 PII 处理，或者可能产生对个人（如你的员工、消费者或客户的员工）产生实质影响的输出。在这种情况下，越来越多的州、联邦和国际法律要求在实际工作开始前完成各种风险评估。这些评估如果逐案进行，不仅繁琐，还难以规模化。使用 “Clone This Starter App” 方法也有助于防止这些合规要求成为创新的瓶颈，因为在大多数法律要求下，只需为模板完成一次所需评估，任何不超出最初定义参数的克隆不必重复。

配方步骤 3：部署用户应用

在策略明确、信息安全基线建立、开发者模板就绪后，终于可以 “上菜” 了。无论你选择自助还是托管部署模式，都可以自信地邀请组织中的快速原型开发者开始在沙箱中进行创作。

由于你从一开始就包含了 APM 和安全日志（要素 #8），你具备必要的可观测性来监控应用性能和用户活动。这里就是魔力所在：你可以从用户构建的应用中学习，发现强大的新用例，并收集真实世界的数据来改进平台，同时保障组织数据安全。顺带一提，这种方法还允许你自然收集可能需要记录、向用户披露或向审计员和监管机构共享的信息，以展示你的 GenAI 应用的透明性、问责性和可解释性，在构建过程中就完成许多合规要求，而不是事后处理 —— 这是隐私设计（Privacy by Design）的典型最佳实践。

下一步怎么做？

我们现在已经浏览完整本配方书，从挑选新鲜要素到逐步执行配方。我们讨论的大多数领域（容器化、APM、IAM 等）本身就是独立的 “烹饪专长”。

结论

本配方书旨在提供一个清晰的制作生产级 GenAI 沙箱的 “食谱”。通过仔细挑选每一个基础要素，从容器化平台和 Kubernetes 编排，到搜索 AI 数据存储和统一 APM，你可以确保最终成品既成功又安全。遵循配方可确保这个强大的环境从第一天起就建立在安全和周全策略的基础上。

目标是赋能你的快速原型开发者，而不是限制他们，同时培养负责任的创新文化。通过提供一个安全、可观测且设备齐全的“厨房”进行实验，你可以抢占先机，促进负责任的创新文化。这种主动方法让你能够利用整个组织的创造力，将出色的想法转化为可落地的原型，同时防止“影子 AI”的出现。你已经完成了这顿创新大餐，现在可以享受它带来的成果。

如果你想讨论本内容或任何与 Elasticsearch 相关的话题，欢迎加入我们的 Discuss 论坛。

原文：https://www.elastic.co/search-labs/blog/generative-ai-sandbox-data-privacy