NIST AI 风险管理框架以自愿方式支持组织管理 AI 风险，并覆盖设计、开发、使用和评估。[1] ISO/IEC 42001 的公开介绍关注 AI 管理体系的建立与持续改进。[2] NIST 的生成式 AI 专题文件则提供与生成式应用相关的管理视角。[3] 本文据此讨论组织方法，不将这些资料等同于对具体应用的合规结论或认证证明。

能源企业的治理起点，是知道哪些业务正在使用 AI、它处理什么资料、输出如何影响工作。仅建立模型清单不足以解释风险：同一个模型可以用于公开资料摘要，也可以用于内部设备分析，两者的权限、错误后果和审核要求明显不同。治理对象应落实到具体应用与用途，使责任和控制能够对应真实业务，而不是停留在技术名称。

支策建议将治理目标表述为可观察的行为：未经授权的数据不能进入处理流程，超出适用范围的结果不能直接执行，关键变更经过相应验证，异常能够被发现并处理。目标越具体，越容易判断控制是否有效。相反，“安全、可信、可控”如果缺少对象和证据，就难以转换为岗位动作，也难以在事故或争议发生后说明责任。

治理强度应随后果和权限变化，不能让所有应用承担同样成本。低影响的资料整理可以采用简化登记与抽查，高影响的业务辅助需要更完整验证，涉及实际控制或重要承诺的动作则需要严格授权和专业评估。分级的目的，是把有限注意力放到关键风险上，同时给可控探索留下清楚路径，避免制度过度宽泛或一刀切。

应用登记至少应描述业务用途、服务对象、输入数据、模型或供应商、输出去向、可调用工具以及最终责任人。还要记录使用方式：是个人临时辅助、部门共享工具，还是已经嵌入正式业务流程。登记不是为了收集尽可能多字段，而是让管理人员能够识别数据流向、权限边界和需要进一步审查的事项。

业务负责人对用途、效果和使用边界负责，技术负责人对系统实现与运行状态负责，数据责任人确认数据授权与适用范围，控制岗位检查风险与例外。应用负责人不能把全部责任转交给模型供应商，也不能以“用户应自行判断”为由省略必要控制。角色可以兼任，但关键决策需要明确由谁提出、谁复核、谁批准和谁持续跟踪。

清单应覆盖正式采购之外的使用。员工可能通过通用工具整理材料，合作方可能在交付中使用 AI，既有软件也可能通过升级加入生成式功能。企业需要提供简单、可理解的申报与咨询路径，并明确允许输入哪些资料。发现未经评估的使用时，应先确认实际数据和影响，再采取适当处理，不能只通过禁用名称判断风险是否消失。

登记信息需要随业务改变而更新。新增用户群、扩大数据来源、改变输出用途或者接入执行工具，都可能使原有评估不再充分。建议设置能够被岗位识别的变更触发条件，并由业务负责人确认是否需要重新评估。长期无人维护、使用范围无法解释的应用应暂停扩展；明确停止使用后，还应处理账号、数据、接口和历史记录。

分级应同时考虑错误后果、数据敏感性、输出影响范围和系统自主程度。一个只生成内部草稿的工具，与能够修改业务记录的工具，即使使用同一个模型，也需要不同控制。企业应明确哪些应用允许输出信息，哪些允许形成建议，哪些可以提出待确认动作，哪些功能必须保持在人工或既有控制系统中。技术可实现不等于业务已授权。

建议将不可接受行为设为硬边界，例如未经批准调用生产控制接口，或者向无权用户披露受限信息。硬边界不能通过其他维度的低风险评分抵消。对剩余风险可以采用分级审批与持续监控，但应说明依据、适用期限和责任人。缺少必要证据时，处理方式可以是缩小用途、补充验证或暂缓上线，不必急于给出一个看似完整的等级。

分级结果还应直接决定控制动作。较低影响场景可以侧重使用说明、权限和抽查；中等影响场景增加代表性测试、引用与人工复核；高后果场景需要专业论证、独立检查、强制授权和可验证回退。具体边界应依据企业业务与适用要求确定，不能把通用矩阵直接当作法律分类，也不能用管理分级替代必要的专业安全判断。

AI 应用的行为不仅由模型决定，还受提示模板、知识库、检索设置、工具权限和业务规则影响。只记录模型名称，无法解释两次输出为何不同。建议建立与实际应用相匹配的版本记录，保存关键配置及其变更原因。对于外部服务无法完全掌握的内部变化，应记录可获得的版本信息和服务条件，并通过持续评估识别行为变化。

变更流程应从影响分析开始。修正文档中的明显错误，和扩大数据范围、启用新工具或更换模型，不需要完全相同的审批强度，但都应说明影响了什么。按影响范围选择回归样本，验证权限与业务边界，再决定上线。紧急修复可以采用预先定义的快速流程，但应保留批准和事后复核，避免紧急通道成为日常绕过评估的方式。

上线时明确观察期、负责人和回退条件。回退需要包含模型、知识、配置和业务状态之间的关系，不能只恢复一个软件版本。如果新版本已经产生业务修改，还应判断是否需要纠正相关记录。暂停服务也要考虑业务连续性，提前准备人工路径或替代工具。治理要求的核心，是出现问题后能够控制影响并恢复工作，而不是保证技术永不出错。

评估材料应让没有参与开发的负责人也能理解应用能够做什么、不能做什么，以及为什么接受当前风险。至少应包括用途说明、代表性样本、错误分类、权限测试、人工复核设计和异常处理路径。不能仅提交一个平均准确率；平均值可能掩盖关键限制，也可能因样本分布偏向简单任务而高估能力。评价结果必须与实际使用范围对应。

样本应包含正常任务与边界任务，包括资料缺失、相互冲突、过期内容、不适用设备或场景，以及要求越权访问和执行的输入。对于提示注入等可能改变应用行为的内容，要验证系统是否仍遵守既定权限与业务限制。测试应在适当隔离和授权条件下进行，使用受控样本，避免为了验证风险而把真实敏感资料暴露给未经批准的服务。

人工审核必须有能力条件。复核人员需要了解业务、能够查看依据、有时间检查，并有权拒绝输出或要求重新处理。高工作量、界面暗示和过度流畅的答案都可能让审核退化为机械确认。建议抽查具体审核记录，观察是否检查了关键字段、引用和限制条件，并通过培训与工作量安排修正问题，而不是只增加一个“已阅读”选项。

证据留存也要适度。日志应足以支持追溯，同时控制对敏感输入和个人信息的重复收集。明确记录内容、访问角色、保存期限和删除方式，区分运行监控、业务审计与模型改进用途。不能因为“以后可能有用”就无限保留全部对话；同样，也不能为减少存储而删去解释关键决定所必需的记录。保存方案需要兼顾管理目的与适用要求。

上线后的监测应观察实际风险，而不仅是系统是否在线。持续关注关键错误、越权尝试、知识过期、人工返工、异常调用和用户投诉，并明确什么情况需要升级。统计口径应保留使用范围和任务构成，避免因使用量增加而误判质量下降，也避免因为用户不再反馈问题就认为风险减少。重大异常应能够追溯到具体版本和业务影响。

处置流程可以围绕发现、控制、分析、恢复和复盘展开。先确认受影响应用、用户和数据，再采取暂停功能、收紧权限或切换人工路径等必要措施。原因尚未明确时，不应急于宣布问题已解决；恢复前需要验证控制是否有效，并确认相关业务记录是否需要纠正。对外沟通与必要报告由有职责的人员依适用要求决定，避免未经核实的信息扩散。

复盘应超越单次提示或模型输出。检查是否存在错误知识、权限设计缺口、评估样本不足、人员负担过重或供应商变化未被识别。将结论转化为有责任人和验收条件的任务，并检查其他应用是否具有相同问题。一个事件如果只被记录而没有改变知识、流程或控制，治理体系就没有从真实运行中学习。

事件分级还应考虑影响是否可能向下游传播。一段错误说明如果只停留在个人草稿，与被复制进入多份报告或自动触发后续流程，处置范围不同。发现问题后应追踪实际使用去向，必要时标记相关输出待复核，并确认修正是否到达使用者。控制岗位需要把传播路径纳入演练，而不是只检查原始应用已经恢复；恢复在线与消除业务影响是两个需要分别确认的状态。

采购 AI 服务时，应比较服务实际处理方式，而不是仅比较模型表现。需要确认输入数据会被如何处理和保存、哪些主体能够访问、服务如何更新、异常如何通知，以及停止服务后数据和记录怎样处置。不同部署方式存在不同责任分工，企业应把自己必须承担的控制明确列出，避免把“使用了云服务”或“本地部署”直接等同于已经解决全部风险。

供应商变更与能力限制要进入日常运营。版本调整、接口变化、服务区域变化或功能下线，可能影响既有评估。合同与运行安排应说明信息提供、通知、支持和退出要求，并核验其可执行性。对于供应商无法提供的细节，应明确剩余不确定性，通过缩小用途、独立测试或备用路径降低依赖，而不是在审批材料中默认这些问题不存在。

退出能力需要提前验证。企业应能够导出必要的业务记录、知识资料与配置，确认数据格式和权限，不把所有流程锁定在无法替代的专有操作中。更换供应商时，历史记录仍应支持审计与问题追溯；停用账号、撤销接口和处理缓存也要纳入清单。退出演练可以采用受控样本，不必真实中断服务，但必须证明迁移路径能够工作。

治理建设可先选择不同风险特征的少量应用，完成登记、分级、评估、上线和异常演练的完整闭环。通过这些应用检验表单是否能理解、责任是否存在冲突、审核材料是否足够、处置是否能够执行。制度应在真实工作中修正，而不是先追求覆盖所有可能情况。对于尚未发生的复杂场景，可以保留原则和升级路径，不必提前设计大量无人使用的审批。

管理层看板应聚焦需要决定的事项：哪些高影响应用缺少关键证据，哪些例外即将到期，哪些问题重复出现，哪些应用扩大了权限，以及哪些服务需要退出。应用数量、登记完成率或培训人数可以作为辅助信息，却不能单独证明风险已受控。建议定期抽查完整案例，从输入和授权追到输出、业务使用及后续复核，以检查制度在现场是否有效。

最终应形成清楚的责任承诺：业务负责人能够解释为何使用，技术团队能够说明怎样运行，数据责任人能够说明依据来自哪里，控制岗位能够检查边界，使用者知道何时需要停止并求助。支策建议把这些能力作为治理成熟度的实际证据。AI 治理的价值，是让组织在探索新能力的同时，持续保有判断、纠正和退出的能力。

制度推广时，还应检查员工能否方便地获得合适工具和帮助。如果正式流程过于复杂，而实际工作又需要快速处理资料，人员可能转向难以管理的外部工具。企业应提供清楚的允许用途、便捷的申请方式和可响应的支持，并用真实反馈改进规则。治理有效性既取决于限制是否清晰，也取决于合规路径是否可用，二者应在同一次管理复盘中被检查。