一 概述

生成式人工智能已列入 企业 的路线图，但我们不 应 发布任何设计不安全的产品。LLM 改变了威胁模型：不受信任的自然语言会成为攻击面，输出可以被武器化，代理可以代表我们采取行动。我将模型视为在沙盒化、受监控且严格授权的环境中运行的不受信任的代码。

主要风险显而易见。即时注入（包括隐藏在文件和网页中的间接攻击）可以覆盖策略并窃取数据。拥有过多权限的代理可能会滥用工具并执行不可逆的操作。RAG 可能会在提取或检索时中毒。隐私和 IP 可能会通过训练回溯或日志泄露。不安全的输出处理会将模型文本转换为 XSS 或代码执行。对抗性提示可能会导致模型 DoS 和成本失控。

企业现实加剧了风险。AI供应链（模型、数据集、插件）尚不成熟，容易出现后门和来源漏洞。可观察性与合规性存在冲突——我们需要取证，但又不能过度收集个人数据。模型和插件的更新会悄无声息地改变行为；如果没有版本锁定和重新测试，安全性就会下降。内容来源薄弱，使得欺骗和欺诈更容易发生。员工的影子AI会造成我们无法控制的未经批准的数据泄露。

我的策略是零信任和纵深防御：限制输入、隔离和代理工具，并净化输出。部署前的几项关键措施包括：允许出口和工具代理；RBAC 机制，允许破坏性操作；DLP/PII 扫描，并在每一跳上执行严格的架构；版本锁定，并配备终止开关和回滚机制；防篡改、隐私感知日志；持续的红队演练，并与发布门密切相关。如果我们 无法执行这些控制措施，我们 就需要 暂停发布。

让我们深入了解生成性人工智能安全风险的一些细微差别和细节。

二 生成式人工智能安全面临的最大挑战

以下是当今确保生成式人工智能安全的最大 挑战的简要概述— — 摘自当前标准、红队报告和最新研究。

1) 即时注入（以及间接即时注入）是新的“SQLi”。攻击者无需入侵您的后端，即可入侵您的 输入 。聊天、文档、网站、PDF 文件，甚至日历邀请中的恶意文本，都可能覆盖模型的指令、泄露机密信息或导致代理滥用工具。这现在是 OWASP LLM 的头号风险，最近的红队工作表明，“开放网络上的内容”或上传文件中的内容可能会无形地指示 LLM 窃取数据或采取不安全的操作。将所有模型输入视为不可信，包括检索到的网页和用户上传的内容；将工具隔离在允许列表代理之后，并进行模式匹配以查找越狱线索。（ OWASP 、 微软 ）

2) 代理/工具滥用和“过度代理”。一旦模型能够调用工具——查询数据库、发送电子邮件、运行代码——就创建了新的权限边界。过度放纵的代理（“自动运行所有内容”）仍然是导致险情发生的主要原因：代理可能会被注入的内容引诱，从而调用强大的操作，或无限地链接操作。OWASP 明确列出了“过度代理”；微软红队建议采用严格的 RBAC、分步限制、敏感操作的人工审批，以及对模型发起的调用进行严格的出口控制。想想“有限自主”，即在任何不可逆的情况下，都由人在环。（ OWASP ， 微软 ）

3) RAG 中毒和检索时攻击。RAG减少了幻觉， 但也 引入了新的攻击面。如果你的索引被中毒（或者你的检索器过于宽松），模型会很乐意在对抗性段落上扎根。新的研究记录了 RAG 语料库数据中毒的成功案例，并且可扩展的防御措施仍在不断完善。强化措施意味着在 LLM 看到检索到的块之前，需要进行门控的提取管道、签名/精选的来源、每个文档的敏感度标签以及运行时检查（例如，“解释你的来源”、相似性多样性和异常过滤器）。（ 亚马逊网络服务公司 ， AWS 文档 ）

4) 隐私泄露和 IP 溢出。大型模型 确实会 记忆，有时会重复训练片段或敏感上下文；成员推理和数据提取攻击仍然是一个活跃的研究领域。供应商已经改进了企业默认设置（例如，“默认不针对 API/企业数据进行训练”），但数据保留、日志记录和合法保留仍然可能在诉讼或事件响应中暴露提示/输出。在输入和输出路径上构建 DLP，优先选择具有可配置保留期的企业/API 通道，并在每次响应中添加针对 PII/机密的显式扫描程序。（ NIST 、 OpenAI Platform 、 The Verge ）

5) 模型和人工智能供应链风险。基础模型、微调、数据集和代理插件构成了漏洞百出的供应链。带有后门或欺骗性对齐的模型（“潜伏代理”）可以通过安全评估，然后在触发下出现异常行为；下游库、嵌入或插件可能会受到攻击；一种新型的“slopsquatting”攻击利用LLM，使攻击者产生不存在的软件包，然后将其发布。您需要像现代软件供应链安全一样（甚至更多）的出处、签名的工件、具有行为审查的模型注册表和依赖关系安全措施。（ CIO Dive 、 安全中心 、 趋势科技 ）

6) 不安全的输出处理（“不信任字符串”问题）。将 LLM 输出视为 不可信内容 。如果渲染它，它可能会成为存储型/DOM-XSS；如果执行它，它可以运行任意代码；如果将其传递给工具，它可以执行 SSRF 和数据泄露。OWASP 直接指出了这一点。强制执行严格的模式，转义/验证任何渲染的输出，禁止直接执行模型生成的代码，并在下游系统之前设置“策略判断器”或后处理器。(OWASP)

7) 拒绝服务攻击 (DoS) 和成本滥用模型。攻击者（或仅仅是重度用户）可以强制执行病态工作负载——非常长的提示、巨大的输出或对抗性采样——从而降低服务质量或增加您的令牌费用。这被编纂为 LLM04“拒绝服务模型”。每个用户和每个操作的速率限制、令牌上限、时间盒代理循环，以及对异常令牌/延迟峰值发出警报。(OWASP)

8) 可观察性与合规性（日志记录、可追溯性和审计）。取证需要 完整的 即时/响应日志和工具追踪；隐私法和合同限制要求 最低限度的 保留和屏蔽。最新的 NIST 生成式人工智能概要建议采用结构化日志记录、变更控制和角色隔离的记录访问；在欧盟，《人工智能法案》提出了分阶段的义务（例如，GPAI/GFM 规则将于 2025 年 8 月 2 日生效），以及针对高风险用途的上市后监控。通过在数据采集时屏蔽敏感字段、将遥测数据与内容分离以及维护具有范围访问权限和明确保留策略的防篡改日志来协调这些要求。（ NIST 出版物 ， 欧盟数字战略 ）

9) 治理漂移和模型/版本风险。模型、安全设置和插件频繁变化；提供商的“小更新”就可能改变拒绝行为或越狱防御能力。除非每次更改都重新运行安全测试，否则安全态势会下降。微软和 NIST 强调持续的 AI 红队测试、版本锁定和门控发布流程——包括终止开关和回滚——这样你就可以发布更新而不会再次引入旧的故障。（ 微软 ， NIST 出版物 ）

10) 内容真实性和下游滥用。即使你的系统是安全的，你的输出也可能被伪造、清洗或武器 化。水印在释义和翻译的情况下仍然很脆弱，因此各组织倾向于使用出处（C2PA/内容凭证）和来源签名，以及对人工智能生成的内容进行用户可见的披露。追踪你的输出流向，在可行的情况下添加出处，并假设单靠水印无法拯救你。（ EUR-Lex ）

三 接下来的90天该做什么

重点关注三个“不后悔”的举措。

首先，进行GenAI 安全和隐私审计——绘制出敏感数据可能进入提示或模型训练的位置，并部署数据丢失预防和请求日志记录等即时控制措施。

其次，在高价值、低风险的用例（“速赢”象限）上进行试点。例如，内部知识助理或代码生成助手可以快速展示价值，同时最大程度降低客户风险。使用“影响-可行性”矩阵对此类用例进行优先级排序。

第三，在广泛推广之前，实施包含人工审核和关键指标（准确度、延迟、每次通话成本）的评估工具。

这些步骤为安全扩展设定了基线。

避免已经让同行绊倒的顶级非受迫性错误。错误 1：在没有强大防护措施的情况下部署生成模型——这导致三星等公司的数据泄露和恶意输出，工程师不小心将机密代码上传到了ChatGPT 。解决方案：建立严格的提示过滤器、用户访问策略和“无敏感数据”规则，直到建立适当的审批流程。错误 2：追逐用例而没有业务一致性——许多团队构建了华而不实的演示（例如异想天开的图像生成器），但并不能解决紧迫的业务痛点。相反，应该从明确定义的业务目标和成功指标开始（例如，将呼叫中心处理时间减少 20%）。错误 3：跳过评估和监督——在没有测试幻觉、偏见或性能瓶颈的情况下将生成式 AI 投入生产是失败的根源。像摩根士丹利这样的成熟团队在全公司部署之前会进行严格的内部评估和人工反馈循环。从一开始就建立测试、监控和后备计划。

安全和治理刻不容缓。生成式人工智能以新的方式扩大了企业的攻击面：可能泄露数据或操纵代理工具的提示注入、如果处理不当会执行恶意脚本的模型输出，甚至开源模型中的供应链风险。成熟度较高的公司会像对待任何关键任务系统一样对待生成式人工智能项目——包括威胁建模、基于角色的访问控制、模型 I/O 加密以及第三方风险审查。同样，各组织正在建立人工智能治理委员会和“模型风险管理”流程，以便在部署之前审查生成式人工智能用例的合规性、知识产权和道德风险，以符合新兴标准（例如 NIST 人工智能风险管理框架、ISO/IEC 23894）和即将出台的法规（欧盟人工智能法案）。要点是：在项目开始时就解决安全、知识产权和道德问题——后期再改进控制措施要困难得多。

数据是差异化因素，也是最难的工作。生成式人工智能依赖于数据，然而 39% 的首席数据官认为数据质量、数据孤岛和数据集成是应用生成式人工智能 (GenAI) 的最大障碍。在构建高级模型之前，企业必须理顺其数据库：识别并清理相关数据集，建立可扩展的文档提取和嵌入管道（进行质量检查，避免“垃圾进，垃圾出”），并实施访问控制，确保只使用授权的、符合隐私要求的数据。在实践中，这可能意味着创建一个包含适当元数据（所有者、时间戳、敏感度标签）的集中式企业知识向量数据库，并自动执行数据沿袭跟踪。早期投资于数据准备的组织（例如，拥有“单一事实来源”知识库或具有治理功能的数据湖）能够部署可靠、最新的 GenAI 应用程序，而其他组织则由于无法找到或不可信的数据而陷入“概念验证炼狱”。

人才和文化是 GenAI 计划的成败关键。理论上，GenAI 可以提高生产力；但实际上，成功取决于人。存在技能缺口：高效的团队会混合使用数据工程师、机器学习工程师、快速工程师、用户体验设计师、领域专家和风险管理官——许多公司仍在 努力填补或培养这些职位。提升现有员工的技能至关重要：例如，通过为期 8-12 周的重点培训项目，培训软件工程师进行快速设计和微调，或培训数据分析师使用 LLM API。同时，变革管理对于解决员工的恐惧和抵触情绪也至关重要。成功的组织会投资于沟通和培训，以表明 GenAI 是一种增强工具，而不是工作威胁。快速见效和透明的对话可以将怀疑者转变为支持者——例如，在试点项目中，由“AI 副驾驶”处理重复性任务，以便员工可以专注于更高价值的工作。最后，必须培养高管的支持：知识渊博的支持者会支持切合实际的目标和持续的资金投入，而缺乏知识的高管则可能要么过度兴奋，要么过度恐惧。一个可靠的商业案例，加上明确的投资回报率指标（例如，试点结果显示节省了X小时或客户满意度提高了Y%），将有助于获得并维持高管的支持。

严格且反复地衡量价值。生成式人工智能是一个新领域——它需要新的 KPI 和实验性的思维方式。为每个用例预先定义成功指标：输入指标（例如训练数据覆盖率、模型新鲜度）、系统指标（延迟、吞吐量、每次查询的成本）、质量指标（事实准确率、幻听频率、安全完成率），以及最重要的业务成果指标（例如客户自助服务偏差率、转化率提升或开发人员速度改进）。许多领先的采用者会运行 A/B 测试或受控部署，以将人工智能增强的工作流程与现状进行比较。例如，客户支持团队可能会衡量人工智能辅助聊天机器人是否能够在没有人工交接的情况下解决 30% 以上的查询。还要衡量可能出现的问题：跟踪不适当的输出或停机时间等事件。通过将模型性能与实际业务 KPI 挂钩，您可以避免虚荣指标的陷阱（例如仅计算聊天次数）。在前 90 天，为这些指标设置一个仪表板和一个节奏（每周或每两周）来审查进度并重新校准——将 GenAI 部署视为一个持续改进的过程。

路线图展望：安全为成熟企业所用，重点关注新兴企业。如前所述，调查显示，不同成熟度的挑战存在差异。高成熟度的组织（已在 GenAI 上进行扩展的组织）将安全威胁列为首要风险——这表明，一旦广泛部署，防止违规、滥用和违反法规就变得至关重要。这些组织正在投资高级措施，例如即时防火墙、带有 DLP 扫描的模型输出日志记录，以及用于治理的强大的模型卡片文档。相比之下，低成熟度的组织最关心的是找到合适的用例——他们处于探索模式，正在探索 GenAI 能够真正发挥作用的地方。对他们而言，这意味着在尝试复杂的特定领域项目之前，应尽早与业务利益相关者接触，举办探索研讨会，并可能从一些经过验证的横向用例（代码生成、知识搜索、营销内容）入手。随着时间的推移，随着组织的成熟，挑战“向右移动”：从创意和人才缺口转向卓越运营、风险管理和成本优化。成功的 GenAI 路线图应充分考虑这一演变过程：早期，加倍重视用例选择和快速取胜策略，以积累发展势头；后期，加强治理、安全性和可扩展性，以确保其长久发展。目标是从实验阶段逐步发展成为一个稳定、受管控的 AI 平台，持续创造商业价值。

四 案例研究和“有效的方法”

案例研究 1：摩根大通——AI 编码助手的安全保障。大型金融机构摩根大通部署了内部生成式 AI 来帮助开发人员编写代码（类似于 GitHub Copilot）。早期，他们的安全团队注意到 AI 建议中出现了一些看起来过于熟悉的内部代码片段，这引发了人们对该模型可能泄露专有算法的担忧。他们的应对措施是实施严格的提示，并仅针对非敏感数据对模型进行微调，同时集成了一个代码片段检查器：任何 AI 建议的代码都会与敏感代码的哈希数据库进行比较。如果相似度较高，助手会警告用户，并且不会显示该建议。这大大减少了潜在的泄漏。此外，摩根大通禁止使用外部 AI 编码工具（例如公共 Copilot），并将开发人员引导到具有这些防护措施的内部工具。结果：开发人员仍然可以受益于 AI 自动完成功能，但会受到监督，以防止无意中共享 IP。到2024年，摩根大通报告称，通过该助手的代码泄露事件为零，并且他们开源了部分解决方案，作为金融行业其他公司的最佳实践。有效的措施包括：主动 监控捕捉类似的输出 、定制解决方案以剥离敏感数据，以及明确的政策（禁止使用未经批准的工具，并结合安全的替代方案）。

案例研究 2：微软的 Bing Chat——强大的提示隔离。当微软推出 Bing Chat（由 GPT-4 提供支持）时，用户很快就找到了提示注入的方法，并揭示系统角色“Sydney”以及开发者指令。这些早期的越狱（2023 年 2 月）得到了广泛宣传 [66]。微软的应对措施堪称迭代强化的典范：他们首先限制了会话长度（以减轻对话偏离不必要的领域），然后推出了更复杂的提示隔离。他们开始以模型无法轻易泄露的方式对系统提示进行编码（一些报告表明，他们使用隐藏的标记或词汇表外的嵌入来作为内部指令）。他们还不断扩展停用短语列表，并使用越狱尝试的对抗样本重新训练模型。在几个月内，提示注入的成功率显著下降。尝试相同“忽略先前指令”攻击的用户发现它们无效。微软还增加了一个安全系统，如果用户输入中出现某些模式（例如“忽略所有规则”），AI 就会拒绝或给出平淡的回答。结果：到 2023 年中期，Bing Chat 的越狱难度明显增加，恢复了部分公众信心。微软公开赞扬了他们的 AI 安全研究人员“红队”以及他们从真实世界尝试中不断学习的结果。有效的方法：真实世界攻击数据和模型更新之间的快速反馈循环；分层方法（通过更短的聊天限制暴露并改进及时处理）；以及对用户透明地说明限制（“对不起，我无法继续该请求”成为一种常见的安全完成方式）。

案例研究 3：医疗 AI (Syntegra) — 训练数据的差异化隐私。医疗 AI 初创公司 Syntegra 构建了生成模型来创建合成的患者数据。其核心风险在于，该模型可能会记忆并重复真实的患者记录 (PHI)，从而违反《健康保险流通与责任法案》(HIPAA)。他们在模型训练过程中实施了差异化隐私——注入噪声，使模型无法回忆起超过概率阈值的细节。他们还制定了一项策略：任何试图获取完整患者记录或身份信息的提示都会触发自动拒绝。在一项测试中，一位内部团队成员试图让模型输出特定的罕见诊断记录（他们知道该记录包含在训练集中）。该模型生成了逼真的记录，但关键之处在于修改了某些标识符和细节，这表明差异化隐私正在发挥作用（它生成的是复合回忆，而非逐字回忆）。这让他们有信心在研究环境中部署数据增强功能。他们发表了一篇论文，表明他们的模型在5元语法（五词序列）之外与训练数据的精确匹配为零，而且隐私风险低于监管阈值。有效的方法是：将隐私纳入模型设计之中，而不是事后才考虑；此外，对个人数据的输出进行明确的检查（例如，对社保号或患者姓名进行正则表达式检查——他们使用已知的患者姓名列表来扫描输出，除了误报外，没有发现其他异常）。该案例表明，技术控制（差异隐私）与领域特定过滤器（医疗PHI检测）相结合，即使在处理敏感数据时也能确保GenAI的安全使用。

案例研究 4：谷歌 Vertex AI 在 Waymo 的应用——保障机器学习供应链安全。Waymo（Alphabet 旗下自动驾驶部门）使用生成模型来模拟场景描述。他们依赖谷歌的 Vertex AI 平台来部署这些模型。一个显著的挑战是模型来源：确保他们使用的任何开源模型（例如用于场景创建的文本生成模型）都经过审查且没有后门。Waymo/谷歌通过使用“模型注册表”解决了这个问题，每个模型（即使是第三方预训练的模型）都会被扫描——他们会对任何新模型运行一系列测试，包括检查隐藏的触发器。例如，他们发现一个开放模型在输入一个看似无关的触发词（很可能是研究水印）时会输出一个特定的短语（“XYZZY”）。他们选择放弃该模型，转而采用另一个模型。谷歌随后在 Vertex AI 中构建了一些功能，允许企业客户查看模型沿袭（哪个数据集、哪个来源），并将自定义安全内核应用于模型执行（例如谷歌的 gVisor 沙盒）。实际上，Waymo 可以安全地将 GenAI 模型集成到他们的流程中，并高度保证它不会危及更大系统（在他们的案例中，可能是实际的驾驶逻辑）的安全。他们在一次人工智能会议上报告称，在 18 个月的运行中，他们所有投入生产的生成模型均未引发任何安全问题，这部分归功于严格的供应链控制。有效的方法是：像对待代码一样对待模型——验证签名/哈希值，测试异常行为，并使用支持隔离执行（模型与其他组件之间零信任）的基础设施。

这些案例研究突出了几个主题：持续测试和迭代（微软）、内置的预防性隐私/安全技术（Syntegra 的差异隐私）、引导用户行为的政策和控制（摩根大通的禁令和内部工具）以及供应链警戒（Waymo/谷歌）。遵循这些“有效”实践的组织通常能够避免重大事故，甚至将安全转化为竞争优势（能够宣称“我们拥有高度安全的 AI”成为一个卖点）。相反，那些没有这样做的组织（也有一些臭名昭著的案例，例如一个 AI 写作助手通过共享内存泄露了其他公司的数据——未能隔离租户）则值得警示。

五 30–60–90 天行动计划

第 0-30 天（立即）：巩固基础

开展 GenAI 威胁建模研讨会（负责人：安全架构师，参与人员：AI 开发主管、运维人员、法务人员）：在前两周，召集利益相关者，使用 STRIDE 或类似工具绘制潜在威胁图。识别资产（敏感数据、模型访问）、入口点（API、用户输入）和威胁行为者。输出威胁模型文档草稿。成果：GenAI 威胁模型图以及用例的十大风险列表。

实施速效防护措施（责任人：工程经理）：在第 2-3 周，启用基本的输入/输出过滤功能（例如，使用云内容审核 API 或简单的正则表达式规则）。将提示和响应的最大令牌限制设置为保守的默认值。如果使用外部 API，请确保“不使用数据进行训练”设置为开启状态（例如，OpenAI API 就有此功能）。工件：在 API 设置中配置更改，并设置好过滤代码。

访问控制审计（所有者：CISO 或其代表）：审核哪些人/哪些内容可以访问 GenAI 系统。30 天内，如果尚未集成单点登录 (SSO)，请将 GenAI 应用与单点登录 (SSO) 集成，并锁定 API 密钥。在提示中禁用所有硬编码凭证。强制执行最小权限：例如，如果只有一个服务帐户可以调用模型 API，请确保其他帐户无法调用该网络或令牌。工件：访问策略文档已更新，IAM 角色已调整。

制定 AI 安全 RACI 和事件响应计划（负责人：CISO 团队，参与人员：AI 产品经理、通讯员）：确定谁是“批准新模型”或“响应 AI 安全事件”等决策的负责人、问责人员、咨询人员和知情人员。到第 30 天，还要制定一份一页纸的 GenAI 事件响应计划——例如，如果检测到快速注入或发生泄漏，应采取的步骤（例如，“禁用 AI 服务，通知信息安全主管，保存日志，并在 24 小时内与受影响的利益相关者沟通”）。工件：用于 GenAI 风险决策的 RACI 矩阵；事件行动手册。

第 31-60 天（期中）：强化和测试

红队模拟（负责人：安全测试团队）：在 45 天内进行一次正式的红队演习。使用内部安全人员或聘请外部专家模拟针对 GenAI 系统的攻击。他们应该尝试快速注入、数据泄露、插件滥用等攻击方式。记录有效的方法和发现的漏洞。成果：红队报告，其中包含发现结果和补救措施。

实施高级控制（所有者：工程部门）：基于早期经验，部署更强大的解决方案。如果提示注入存在风险，请考虑使用开源库（例如微软的 PromptGuard）或用于清理提示的商业工具。如果使用工具/代理，请在第 60 天之前实施工具代理模式：禁止模型到互联网的直接调用。建议部署一个“影子模型”来评估输出（一种技术：将输出通过第二个模型运行，检查其是否符合策略，以此作为安全网）。成果：更新的架构图，显示新的控制组件（例如，API 前端的 WAF、用于任何代码执行的安全沙盒）。

演练和培训（负责人：SecOps 负责人）：在第 50 天左右，针对 GenAI 漏洞场景进行一次事件响应演练。例如：“如果模型开始从训练中返回敏感数据怎么办？立即行动！” 演练通知法务部门、提取日志等步骤。找出漏洞（例如日志不易搜索，然后改进）。同时，对开发和运维人员进行安全实践培训：为 大语言模型(LLM) 提供 OWASP Top 10 指南。此外，还要确保业务连续性：如果 AI 服务因安全原因关闭， 我们是否有后备方案（例如恢复到非 AI 流程）？做好规划。成果：演练后行动报告；更新后的 SOP；团队培训出席名单。

模型和数据治理检查点（所有者：数据治理负责人）：到第 60 天，审查输入模型的数据（在提示或微调中），并确保合规。如果未完成，则对数据进行分类，并确定哪些数据不能在 GenAI 中使用。此外，创建一个流程：任何新模型或重大提示变更上线前，都需要安全审查签字确认。在开发工作流程中将其正式化（可以是部署流水线中的检查清单）。工件：GenAI 数据使用策略（例如，“提示中不包含 PHI”；“仅使用来自已批准注册表的模型”）；以及发布流程中的门控检查清单（可以集成到 CI/CD 流水线中）。

第 61-90 天（长期强化和治理）：

外部审计/审查（所有者：CISO）：在此阶段，如果资源允许，可以聘请外部公司根据框架对 GenAI 系统进行审计（例如云提供商的安全审查或专业的 AI 安全公司）。他们可能会评估配置、查找未知漏洞，并确保您的控制措施符合标准（例如 NIST AI RMF 等）。工件：外部审计报告以及针对任何发现的缓解计划。

优化指标和监控（负责人：具备 SecOps 技能的 AI 产品经理）：到第 90 天，对指标进行微调。您可能发现初始阈值过于敏感或不够敏感。调整警报阈值（例如，可以将违规率稳定在 0.5% 左右，如果违规率超过 1%，则设置警报）。实施一个仪表板，由安全和产品团队每周共同审查。还可以考虑针对某些警报实施自动响应：例如，如果某个 IP 触发 5 次快速注入失败，则通过 WAF 自动阻止该 IP 24 小时。工件：GenAI 的实时安全仪表板；自动响应与手动响应的运行手册。

持续改进与治理委员会（负责人：首席风险官/AI治理委员会）：大约在第90天，与AI治理小组（如果存在，或者创建一个由IT、风险、法务和业务负责人组成的小组）召开一次审查会议。汇报GenAI的安全现状：已完成的工作、剩余的风险以及任何事故。以此为基础更新政策和投资需求（或许您可以决定资助内部“安全LM”的开发，或购买更好的监控工具）。确保GenAI安全成为企业风险登记册的一部分，并每季度更新。成果：治理会议纪要，其中包含诸如“所有GenAI用例必须接受安全评估——在第四季度前实现100%合规”或“为季度红队演练和员工培训分配预算”等决策。

关键决策的 RACI：例如，“批准使用新的 GenAI 工具（例如，新的插件）”

——负责人：AI 产品经理，问责人：CISO（或代表），咨询人：法务、隐私官，知情人：开发团队。另一个：“紧急关闭 GenAI 服务”——负责人：SecOps 主管，问责人：CIO，咨询人：AI 开发主管及法务（负责客户影响），知情人：支持团队、通讯。提前拥有此 RACI 可确保在危机时刻，每个人都知道谁在发号施令。

通过遵循这个“30-60-90”计划，组织应该能看到切实的改进：到90天，GenAI应用程序将不再是一个“黑匣子”，而是一个受监控、可控制且责任明确的系统。组织将从临时的安全措施转变为可重复的流程——随着GenAI应用的扩展，这一点至关重要。