NIST AI RMF 落地指南：小团队前 30 天如何管好 AI 风险

客户问“你们是否遵循 NIST AI RMF”时，回答要落到具体 AI 系统的证据上：谁对风险负责、做过哪些测试、允许系统执行哪些操作，以及出问题后如何处置。这套框架包含 4 项职能，供组织自愿采用。前 30 天的目标，是让风险管理流程真正运转起来，并如实说明尚存的缺口。NIST 框架提供了组织这些工作的基本结构。

美国国家标准与技术研究院（NIST）的 AI Risk Management Framework（AI RMF，AI 风险管理框架），用于帮助组织在设计、开发、部署或使用 AI 时，管理可能对个人、组织和社会造成的风险。它关注的不只是模型，还包括系统周围的人员、数据、权限和使用环境。AI RMF 1.0阐述了这一更完整的范围。

对于一家有 20 至 200 名员工、正将大语言模型（LLM）投入生产的公司，最实用的起点是先划定实施范围。选一个影响较大的功能，把它的风险与决策、记录串起来，再逐步扩大范围。从其他公司采购模型，并不能向客户说明你如何管控基于该模型构建的功能。

资料核查日期：2026 年 10 月 26 日。 本文已依据 NIST 的在线页面和出版物核查框架、Playbook 和 Generative AI Profile。NIST 的框架页面称 AI RMF 1.0 正在修订，并仍链接至该版本。这条说明不代表新版已经发布，也没有给出新版发布日期。

NIST AI RMF 如何把风险管理落到实处？

这套框架要求在系统的整个生命周期中，把责任、使用情境、证据和行动连起来。可以把它理解为建筑物的消防方案：知道出口在哪还不够，还要有人负责确保通道畅通，有办法检查，也有出事后的应对措施。

NIST AI 100-1：核心文件讲了什么？

NIST AI 100-1 是 AI RMF 1.0 的出版物编号，该版本发布于 2023 年 1 月 26 日。第一部分解释风险与可信赖性，第二部分介绍核心内容（Core）和应用概况（Profiles）。Core 将风险管理分为 Govern、Map、Measure 和 Manage，每项职能下设类别和子类别。这些内容描述的是要实现的结果和要采取的行动，并非一份通用于所有组织、只需判断通过与否的审计清单。NIST 框架及发布信息；AI RMF 1.0，第 1、2 部分。

可信赖性涵盖多个方面：系统是否有效、可靠；是否安全；是否具备信息安全保障与韧性；是否可问责、透明；是否可解释、可理解；是否加强隐私保护；以及是否公平，并对有害偏差加以管理。回答流畅，并不能证明其中任何一项。NIST 在 AI RMF 1.0 第 3 节讨论了这些特征及其间的权衡。

例如，一个客服助手可能准确回答了产品问题，却泄露了另一位客户的记录。有效的评估必须同时检查回答内容和访问权限边界。如果只衡量回答质量，就可能漏掉后果更严重的失效情形。

NIST AI RMF Playbook：按实际风险选择行动

NIST AI RMF Playbook 提供了建议行动、参考资料和指导，帮助组织实现 Core 描述的结果。NIST 明确允许组织按自身需要选用建议，并不要求每家组织全部落实。Playbook 也不是一份必须按顺序执行的清单。NIST Playbook；NIST Playbook 常见问题。

当某项风险需要具体应对措施时，再用它查找适合的行动。如果客服助手可能泄露私人记录，就重点查看数据、访问权限、风险度量和事件处置相关建议。记录选了什么、为什么适合，以及如何确认措施确实在运行。把所有建议抄进表格，只会增加工作量，并不能替你决定这个功能是否该上线。

四项职能，小团队各需要留下什么记录？

四项职能要相互衔接。Govern 贯穿 Map、Measure 和 Manage，整个 AI 生命周期中的工作也需要不断迭代。测试发现新风险后，可能要重新梳理使用情境；发生事件后，可能要调整政策。NIST 并未规定只能单向推进的顺序。NIST AI RMF Core。

下表是我们为小团队建议的落地方式。NIST 定义的是结果；这里的记录形式和负责人安排，是为这些结果提供证据的具体做法。一份记录也可以同时支持多项职能。

上表中的编号和结果描述来自 NIST Core 各职能表。这里选取了部分对应条目，并不表示已经覆盖所有子类别。

Govern：让负责人真正有权叫停

Govern 建立风险管理所需的政策、问责机制和组织文化。NIST 在这项职能中纳入了成文的职责、高管责任、员工培训和人工监督。NIST Core：Govern。

假设有一家 40 人的软件公司，创始人可以负责风险政策，客服主管负责助手，工程师负责访问控制。写下姓名还不够，这些人也需要相应权限。要明确谁能暂停功能，以及采取防护措施后，谁有权接受仍然存在的风险，也就是剩余风险。

一条可执行的人工监督规则可以这样写：“助手只能使用经批准的客服资料起草回复。发送前，客服人员必须核对来源和收件人。助手无权退款或修改账户访问权限。客服主管可以停用助手；恢复运行须经工程负责人和客服主管同意。”

这条规则只是设计示例。不同工作流可能需要不同权限。关键在于，实际部署的权限与审核行为必须和规则一致。

Map：说明整个功能，而不只是模型

Map 梳理理解风险与影响所需的情境，包括系统组件和第三方。它也帮助组织判断：这个问题是否适合用 AI 解决。NIST Core：Map。

为客服助手单独建立一条系统清单记录，写明用途、负责人、服务对象、数据类别、检索来源、连接的系统、模型或服务标识、允许执行的操作和审批状态。还要列出可能因其错误受到影响的人，包括从未直接使用过助手的客户。

再按“原因—事件—后果”描述风险：“错误的账户筛选条件检索到另一位客户的工单；助手将其写入草稿；审核人员把机密信息发给了错误的客户。”只写“隐私风险”，工程师并不知道该修哪里。

把拟采取的防护措施放在对应场景旁，注明负责人、状态和证据链接。即使底层模型没有变化，只要用途改变或新增权限，也值得重新评估。

Measure：测试已经识别的具体风险

Measure 通过定量、定性或混合方法评估风险与可信赖性。NIST 纳入的内容包括：在接近部署的条件下测试，记录局限，以及评估信息安全、隐私和有害偏差等方面。NIST Core：Measure。

针对客服助手，应保留这些测试用例：普通问题、来源资料缺失、政策冲突、涉及其他客户的记录，以及检索文本中夹带恶意指令。**提示词注入（Prompt injection）**是指攻击者提供指令，试图让系统偏离原定行为；NIST 的 Generative AI Profile 第 2.9 节讨论了直接攻击，以及通过系统检索资料发起的攻击。

每份评估记录都应注明测试配置、用例输入、预期行为、实际输出或操作、评审人和结果。将未通过的用例关联到它暴露的风险。敏感证据应保存在有适当访问控制的位置，不要把客户数据复制到通用报告里。

在查看结果之前，先写好验收标准。在这个例子中，只要出现跨客户数据泄露，就不能发布，即使其他回答都表现良好。这是我们建议的发布规则，并非 NIST 规定的阈值。少量测试可以发现问题，但通过测试并不代表以后绝不会出问题。

Manage：把发现转化为决策

Manage 为风险排定优先级，并分配资源进行处置。NIST 纳入的内容包括：决定是否继续开发或部署，选择缓解或接受风险等方式，建立停用机制，以及持续监测和事件响应。NIST Core：Manage。

如果账户隔离测试失败，应先停用受影响的检索路径，修复授权控制，并在重新测试后恢复访问。如果问题后果较轻，可以考虑在监测下限范围发布，但要记录为什么可以接受，以及由谁作出决定。只标注“已接受”，却没有理由或承担责任的审批人，证据是不充分的。

维护一份事件日志，记录发现时间、受影响的系统及配置、已知影响、遏制措施、证据位置、沟通情况、纠正行动和恢复运行审批。险些造成损害的情况也要记录。如果从未发生事件，日志为空是如实呈现；可以附上一份明确标注为演练的记录，证明有人能够执行响应流程。

NIST AI 600-1：生成式 AI 专项指南补充了什么？

NIST AI 600-1，即 Generative Artificial Intelligence Profile（生成式 AI 专项指南），将框架应用于生成式 AI 独有或被其放大的风险。该文件发布于 2024 年 7 月 26 日，是 AI RMF 1.0 的配套文件，并非替代框架，也不是另一项认证。NIST 出版物页面。

这份 Profile 列出 12 个风险领域，并提供与框架对应的建议行动。制定过程中，重点关注了治理、内容溯源、部署前测试和事件披露。内容溯源关注内容来自哪里、经历过什么。这些考虑有助于将生成内容与可问责的运营实践连接起来。NIST AI 600-1：引言、第 2 节及附录 A。

针对客服助手，可以先把相关风险转化为具体的失效用例：

• 虚构内容（Confabulation）： 回答语气笃定却内容不实，凭空声称客户享有退款权利。保留符合政策的预期答案，并核查系统引用的资料是否支持其说法。
• 数据隐私与信息安全： 客户数据泄露，或检索到的恶意内容让助手偏离原定行为。既要测试数据访问边界，也要测试系统面对恶意输入时的表现。
• 人机协作配置： 审核人员过度信任一份措辞流畅的草稿。要让其拿到原始资料，了解拒绝标准，并有权叫停操作。
• 有害偏差或同质化： 不同相关用户群体或语言获得的服务质量存在差异。检查实际服务的场景，并记录证据的局限。
• 价值链与组件集成： 模型、数据来源或集成发生变化，而团队并不了解影响。保留依赖关系和变更记录，再重新评估受影响的风险。

这些是基于 Profile 风险描述提出的实施示例，并非精简版官方清单。其余列出的领域包括：CBRN 信息或能力（化学、生物、放射性或核）；危险、暴力或仇恨内容；环境影响；信息完整性；知识产权；以及淫秽、贬损和／或辱虐内容。应判断它们是否与自己的系统相关，并记录判断理由。完整定义见 NIST AI 600-1 第 2 节。

使用 Profile 时，一个实用做法是逐项记录适用风险、所选行动、负责人和证据，并解释重要的排除项。对于能通过所连接软件执行操作的智能体，评估不能只看生成文本，还要检查操作链路。草稿准确，并不能证明账户变更得到了授权。

前 30 天怎么做：一份启动计划

目标是在明确范围内，建立一套能拿出证据的流程。以下时间安排是我们的建议，并非 NIST 规定的期限、成熟度等级，也不保证到期即可完成。 治理工作应贯穿全程；这份日程用于安排第一个月的工作，并非框架规定的执行顺序。

1. 1

   第 1-5 天：确定范围与责任人

   明确一位承担责任的高管和一位系统负责人。盘点当前使用 AI 的情况，包括已采购软件内置的 AI 功能。选择一个在客户、数据或操作方面有实质风险的生产功能，作为首次详细评估的对象。

   写明用途和边界，识别受影响人群，收集现有的发布、访问权限及事件处置流程。盘点中发现的缺口要如实记录，不能在缺少证据时就宣称清单已经完整。

   留存记录： 初步系统清单、明确到人的职责，以及经过实际功能权限核对的人工监督规则。

2. 2

   第 6-10 天：梳理失效场景，选择应对措施

   与功能开发者和工作流操作人员一起走查选定功能，并请能够质疑客户影响假设的人参与。逐步追踪输入、检索资料、输出和相连的操作。

   将损害场景写入风险登记表，再用 Generative AI Profile 检查是否存在遗漏。根据潜在影响和发生可能性排序，同时考虑不确定性，并为处置工作指定负责人。明确哪些失效会阻止发布，哪些需要收窄运行范围。

   留存记录： 系统说明、风险登记表、所选行动、证据缺口和拟定的验收标准。

3. 3

   第 11-20 天：评估准备部署的方案

   针对计划使用的配置，运行代表性用例、失效用例和对抗用例。在信息可获取的范围内，记录模型或服务标识、提示词、检索设置和工具权限。如果提供商未披露某项相关细节，就在评估中保留这一局限。

   也要测试人工接手环节：审核人员能否识别错误回答、找到来源并拒绝输出？修复问题后，记录复测结果。条件允许时，请开发者之外的人参与评审；规模很小的公司可以请具备相应专业能力的外部评审人员参与重大决策。

   留存记录： 带版本信息的评估记录、尚未解决的问题，以及对应风险的链接。不要把未经测试的假设记成已通过的结果。

4. 4

   第 21-30 天：作出决定、开展演练、汇报进展

   依据证据决定批准、收窄范围或暂停功能。明确由谁接受剩余风险，并为数据、模型、用途或权限的变化设定复审触发条件。

   演练一个事件：客户报告回答中出现了其他账户的信息。确认谁能关闭访问、保存证据、评估影响、协调沟通并批准恢复运行。清楚标注这是演练。

   留存记录： 成文的发布决策、监测职责、事件日志，以及面向客户或董事会的简短说明，区分已经运行的控制措施和尚未完成的工作。

NIST AI RMF 培训：围绕真实决策开展演练

培训要对应每个人负责的决策。GOVERN 2.2 涉及员工和合作伙伴的风险管理培训，目标是让他们能够履行各自职责。NIST Core：Govern。

对客服主管来说，这意味着能识别不安全的信息披露、暂停助手，并上报升级处理。对工程师来说，则意味着知道哪些权限变更需要重新评估。保留演练场景、参加人员、决策和后续行动记录。只有课程结业证明，不能说明生产环境中的响应流程有效。

NIST 还描述了 **Current Profiles（当前概况）**与 Target Profiles（目标概况），分别记录现有和期望达到的风险管理结果。对照两者，就能看出还有哪些工作未完成。小公司可以在证据索引中采用这种区分：已实施、部分实施、计划实施，或不适用并附理由。这些状态标签是我们的建议。AI RMF 1.0 第 6 节。

如何向客户、审计人员或董事会说明进展？

在声称“与框架一致”之前，先说明工作的范围和成熟程度。客户评估一个客服助手时，需要知道证据是否覆盖该功能、当前配置及其获准执行的操作。

如果还在实施，就如实说明。 例如：

我们正在为客服助手落实 NIST AI RMF 实践。责任归属、系统清单和风险评估已到位，评估测试与事件响应演练尚未完成。在相关决定作出前，该功能继续保持现有的受限运行范围。

如果实践已在运行，且记录足以支持，可以作更完整的说明：

我们以 NIST AI RMF 1.0 组织客服助手的风险管理，并采用 Generative AI Profile 中的相关行动。我们持续维护责任与监督规则、系统和风险记录、评估证据及事件处置流程。范围说明列明了已评估的配置、已知局限、待办行动和下一次复审安排。这是对自身实施情况的描述，并非 NIST 认证。

这些话术仅供参考，应按实际证据调整。如果支撑这些表述的控制措施还停留在计划阶段，就不能照搬更强的说法。

提供一份简短的证据索引，包含文件负责人、日期和受访问控制保护的链接。每项声明都要区分政策规定和实际执行记录。监督规则说明应该怎么做，经过审核的发布或审批记录则证明实际做过。若底层证据包含客户数据或敏感安全细节，应分享脱敏后的评估报告。

向董事会汇报时，应突出影响重大的未解决风险、需要作出的决策和责任人。表格完成百分比，可能掩盖那个足以阻止部署的关键未决问题。

开发者、运营人员和采购方，各自该调整什么？

开发者： 把新增权限视为设计变更。给起草回复的助手增加退款权限，即使模型和提示词都没变，风险也已经变化。启用前，应更新系统说明、权限测试和审批决定。

运营人员： 让反馈与风险登记表持续关联。如果客户反复投诉助手编造政策，就应调查这一反复出现的失效模式，将其转化为评估用例，并决定是否继续使用。要指定专人跟进到处理完成。

采购方和创始人： 索取已评估的范围、近期评估证据和剩余局限。供应商关于遵循框架的声明，应说明哪些部分由其控制，哪些需要你自行配置或监测。

当功能接触敏感信息、影响重大决策、向客户发送内容，或能修改外部记录时，应立即行动。对于使用公开或合成信息、范围有限且不执行外部操作的实验，可以采用较轻的流程。如果无法证明权限边界、审核路径或停止机制有效，就应暂缓扩大自主操作范围。这些是我们建议的优先级判断规则，并非 NIST 的风险分类。

框架修订不会让已知风险暴露自动消失。继续管理这些风险，并在文档中明确所采用的框架版本。

ISO/IEC 42001 和欧盟 AI Act 分别管什么？

应按各份文件的用途来使用它们。ISO/IEC 42001:2023 规定了组织 AI 管理体系的要求。组织可以为该管理体系寻求独立认证；ISO 自身不颁发证书。ISO 标准概览；ISO 对认证的说明。

**欧盟 AI Act（《AI 法案》）**根据相关角色、系统和用途规定法律义务。AI RMF 记录可以为相关工作提供支持，但遵循框架并不等于符合法案要求。适用规则和时间表请查看欧盟委员会的 AI Act 指引，本站的相关解读见 EU AI Act 专题页。

我们的 AI 治理框架提供公司层面的责任安排，AI 可接受使用政策提供面向员工的使用规则。应将这些政策与系统证据衔接起来，避免为不同框架各自维护互不关联的政策。

哪些说法被夸大了：证书、完成分数与“安全模型”

最常见的夸大，是把采用框架等同于证明系统安全。NIST 的指导用于组织风险管理；真正有用的证据，仍然必须对应具体系统、使用情境和决策。Core 明确强调灵活性与迭代。NIST AI RMF Core。

所谓 NIST AI RMF 认证，并不是 NIST 颁发的资质

NIST 不会依据 AI RMF 为组织颁发认证。应描述实施情况、范围和证据，不要声称“获得 NIST 认证”。独立评估可能有价值，但报告应说明由谁、对什么对象、依据哪些标准进行了评估。它不会因此成为 NIST 颁发的证书。官方起点是 NIST 的自愿性 AI RMF 框架。

填完清单，不等于作出了风险决策。 NIST 没有规定适用于所有组织的风险容忍度，Playbook 也不要求执行每一项建议行动。验收标准应与潜在损害相匹配，并说明理由。AI RMF 1.0 第 1.2.2 节；Playbook 指导。

供应商的证据不能覆盖整个应用。 你的检索数据、访问控制、集成和用户都会带来额外的情境因素。NIST 明确涵盖第三方组件及其持续管理；应保留供应商证据，同时测试自己的实际运行方案。NIST Core：Map 与 Manage。

人工审核并非万能防护。 审核人员需要来源资料、时间、相关知识，以及介入的权限。如果工作流让审批在实践中变成自动放行，就应先调整流程，再谈是否实现了有效监督。

常见问题

为什么需要 AI 风险管理框架？

AI 风险来自技术、人员和部署环境之间的相互作用。框架帮助组织在整个生命周期中管理这些相互作用，也关注对直接用户之外人群的影响。它是供自愿采用的资源，并非法律强制要求采用的框架。NIST AI RMF 1.0。

AI 有哪 5 类风险？

对生成式 AI 功能而言，可以先看五个典型例子：自信却错误的输出、隐私泄露、有害偏差、人的过度依赖，以及使系统偏离原定行为的攻击。这些例子对应 Generative AI Profile 讨论的风险领域，并不是其完整风险清单。NIST AI 600-1 第 2 节。

NIST 风险管理框架（RMF）的主要目的是什么？

就本文讨论的 AI RMF 而言，目的是帮助组织管理 AI 风险，并将可信赖性纳入开发和使用过程。回复客户时，应明确写出“AI RMF”，避免对所指框架产生歧义。NIST 框架概览。

NIST AI RMF 必须采用吗？

框架本身是自愿性的。应另行核对适用于企业的合同、采购或法律承诺；采用自愿框架，并不能自动解决这些义务。NIST 框架概览。

什么会取代 RMF？

对于 AI RMF，2026 年 10 月 26 日核查的 NIST 页面称 1.0 版本正在修订，并继续链接至该版本。不能据此推断替代版本已发布。NIST AI 600-1 是配套的 Generative AI Profile。NIST 框架页面。

金融风险管理（FRM）会被 AI 取代吗？

无法根据 AI RMF 判断金融风险管理工作是否会被取代。这套框架关注组织如何管理 AI 风险，包括人的责任与监督，并不预测某个职业是否会被替代。NIST Core：Govern。

排名前 3 的网络安全框架有哪些？

不存在适用于所有组织的通用前三名。选择网络安全指导时，应考虑自身系统、义务和保障需求。就这里的决策而言，应将 AI RMF 与现有安全计划配合，用于应对 AI 特有的风险；框架中有关信息安全与韧性的结果，并不能覆盖全部网络安全工作。NIST AI RMF 1.0。

网络安全行业正在衰落吗？

引入 AI 不会消除对安全工作的需求。AI RMF 包括评估信息安全与韧性、管理第三方风险和响应事件。对生产系统的运营方来说，这些仍是需要明确分工、并拿出证据的责任。这是运营层面的结论，并非劳动力市场预测。NIST Core。

当前排名第 1 的网络安全威胁是什么？

没有一种威胁能在所有公司都排第一。应优先考虑会在自身部署环境中造成损害的问题。以客服助手为例，未经授权的数据访问和提示词注入都值得专门测试；优先级取决于涉及的数据与权限。NIST Generative AI Profile 第 2.9 节。

下周一，就从这件事开始

和影响最大的 AI 功能负责人一起打开系统清单。选一个可能发生的失效场景，确定谁会受到伤害，再追踪它是否对应测试、发布决策和停止流程。只要其中一环断开，就把这个缺口列为下一项行动，并明确负责人。

这样，下次回答客户时就有了具体依据：范围内是哪套系统、现有哪些证据、还有哪些工作需要完成。

想了解将 AI 投入生产的实操经验，欢迎订阅邮件通讯。