1. 明确交割时的运营决策
收购委员会应批准合并后的企业打算使用的 AI 系统的书面运营基础。该决定应确定允许的目的、责任实体、重要限制以及有权暂停每项服务的人员。对于收入关键的应用程序，委员会还需要有关模型被撤销后可用服务的证据。本文提出了一个交割后框架，用于汇集这些信息并决定可以进行哪些集成。
一项交易可以通过不同的合约、数据源和客户接口将使用相同底层模型的应用程序聚集在一起。共享的供应商名称提供了初始比较点。集成团队仍然需要检查部署的配置及其在每个公司的实际使用情况。这包括传统的预测模型、商业软件中的第三方 AI 功能以及检索信息或执行操作的生成式系统。拟议的范围遵循运营风险和决策权限。
“一个控制系统”一词描述了共享的治理记录和负责任的决策。它允许单独的生产环境，其中合同条件、技术依赖性或评估结果支持该安排。统一登记册可以将这些环境链接到相同的审批策略和事件程序。技术整合成为一项单独批准的变更，具有自己的测试证据、预算和恢复安排。持续运营取决于适用于个别服务的条件。
NIST 的 AI 风险管理框架为组织治理、背景映射、衡量和风险处理提供了自愿的跨部门参考。其清单、监控和问责结果与提议的集成设计相关。该框架并未确定收购是否合规或继承的系统是否安全。本文利用其已发表的结果来制定尽职调查问题和运营记录。投资委员会仍然负责获取其实际决策所需的专业建议和证据。 [1]
2. 在更改访问权限前明确范围
从交易中包含的法人实体、业务流程和环境开始。记录交割时转移的内容以及仍依赖于卖方或第三方的内容。确定每项服务的预期运营商、接收其输出的客户以及可以更改其配置的员工。交割之前，任何信息共享或整合准备工作均应遵循交易批准的保密和竞争法安排。本文不假定在法律交割前已获得合并系统的授权。
范围应扩展到购买软件中嵌入的 AI 功能。要求每个流程负责人确定建议或自动化操作在哪些方面影响定价、客户沟通、生产计划、招聘或服务获取。将这些说明与授权的技术和采购记录进行核对。保持发现方法相称并得到批准。目标是建立可追踪的相关用途清单；员工的个人账户和不相关的机密材料仍不在授权审查范围内，除非有合法的、特定的流程将其纳入其中。
对于每个部署，定义要计数的操作单位。有用的建议单元是指定环境中的版本化应用程序，由已识别的实体用于批准的目的。使用相同模型系列的两个应用程序可以保留两个部署，因为它们的数据、权限和结果不同。如果多个注册表项是重复的管理记录，则可能描述一项部署。保留支持每个核对决定的证据，以便可以重现以后的计数。
包括位于收购范围之外的依赖项。要调查的示例包括卖方管理的身份服务、共享评估数据集以及通过卖方合同提供的供应商支持。记录依赖项的负责人、访问安排、计划持续时间和更换验收条件。应审查过渡协议以了解实际需要的援助。然后，集成计划可以将依赖性到期与必须测试和批准替代方案的日期联系起来。
区分对清单发现结果的确信程度与运营批准状态。负责人确认的清单条目可能仍然缺乏经过验证的监控阈值或可用的恢复过程。相反，初始交易登记册中可能不存在受良好控制的服务。明确跟踪这两个条件。这使委员会能够了解已发现的内容，并对支持其继续使用的证据有单独的看法。
3. 核对模型清单并保留全部相关部署
保留两家公司的原始标识符并添加与其链接的集团标识符。记录应包含模型或服务版本、应用目的、运营主体、生产地点和承担责任的业务负责人。通过受控参考链接支持文档。保留历史版本，以便以后的事件可以连接到当时运行的配置。清单变更应标明编辑者、原因和生效日期。
以下核对示例完全是假设的。 A 公司提供 100 条记录，B 公司提供 80 条记录。审查发现 15 条重复的管理记录，描述已计数的部署。随后的证据证实，剩余部署中的 25 个已退役。经批准的发现活动发现初始登记册中缺少 12 个额外的在用部署。由此得出的在用部署总数为 180 减去 15、减去 25、加上 12，或 152。每个数字都是说明性假设。
作者提供的示例性清单核对计算。共享模型系列不会仅仅因为它们具有相同的供应商而被删除。
停用需要明确的证据标准。拟议的记录应表明生产路线已被禁用，相关凭证已得到解决，并且任何持续保留义务都有负责人。在开发工具中标记为已关闭的项目可能仍会留下活动的计划流程。清单负责人应将管理状态与授权的操作证据进行核对。需要保留的历史资产可以保留在与在用部署分开的存档类别中。
核对后，按运营证据对 152 个说明性部署进行分类。假设 82 个拥有其当前批准用途的完整证据，50 个有时间限制的有条件批准，20项仍等待运营决策。前两类共计132项，占清单中的部署总数的86.8%。该百分比描述了假设标准下记录的批准状态。它本身没有说明剩余风险的严重性或所使用标准的充分性。
4. 将每个部署连接到允许的用途
用操作语言写出预期目的。为经过培训的员工起草回复的服务与有权直接向客户发布回复的服务具有不同的工作流程。记录输出、接收者、允许的操作和所需的审查。描述禁止的扩展以及请求更改的路径。批准的使用声明应该足够具体，以便流程负责人能够识别实际实践何时偏离了它。
在该用途说明中附上数据访问关系图。识别源系统、数据类别、检索权限以及日志或输出的目的地。关系图应显示每个连接的相关法律实体和环境。律师和隐私专家应评估适用的权利和限制。技术人员应证明批准的访问可以实施。集团层面的所有权变更并不能证明每个数据集都可供每个应用程序使用。
检查能够执行操作的系统的权限。可以搜索文档存储、更新客户记录以及启动与支付相关的工作流程的应用程序需要对每个功能进行单独的描述。询问批准的目的需要哪些权限以及谁可以授予额外的访问权限。测试被拒绝的操作和升级路径以及成功的请求。拟议的验收记录应确定哪些操作仍需人工批准。
对于生成式系统，记录检索源、提示或配置说明、连接的工具和相关模型版本以及应用程序代码。 NIST 的生成式 AI 专题指南讨论了第三方依赖关系，并建议盘点有权访问组织内容的实体。它对价值链和组件集成的讨论支持超越模型供应商的依赖性审查。拟议的交易清单使用该指南来请求有关访问和服务依赖性的特定于版本的证据。 [2]
在集成过程中使访问权限更改可单独审核。建议的共享身份组应列出获得访问权限的人员和应用程序、业务目的以及临时权限的预期到期时间。保留用于验证这些边界的测试。如果访问仍未解决，请记录当前允许的服务配置以及实现更广泛的操作安排所需的工作。
5. 在合并后的业务中分配决策权
董事会或授权的高管应确定风险偏好并任命一名负责任的整合发起人。发起人需要权威来解决资源、期限和业务优先级方面的冲突。指定的业务负责人应对每项服务的批准使用和后果负责。工程部门应保存实施和技术证据。独立质询审查应分配给有适当能力的人员，并与交付决策充分分开。
下列责任矩阵提出一种分工方式，使用时应根据实际组织调整。R 表示负责执行工作，A 表示对所列决策承担最终责任，C 表示应征询意见，I 表示应获知信息。每行仅设一个 A 角色。专业审查职责仍受组织适用的法律和监管要求约束。该矩阵不转移原责任人或实体依法承担的责任。
| 决策或工作项目 | 整合项目发起负责人 | 业务负责人 | 技术负责人 | 独立评审员 |
|---|---|---|---|---|
| 清单及用途记录 | I | A | R | C |
| 评估证据及独立质询 | I | C | R | A |
| 批准范围内的常规上线 | I | A | R | C |
| 重大整合事项的例外安排 | A | R | C | C |
| 紧急技术遏制 | I | A | R | C |
| 重大事件后恢复 | A | R | R | C |
示例性分工。使用前，应明确列出整合项目发起负责人、业务负责人、技术负责人及独立审查人员的姓名。整个过程中均应就适用要求征询法律和合规专家的意见。
该矩阵应附有明确的授权和响应安排。指定缺勤的替补人员，并明确紧急事项如何送达这些替代决策者。每月召开的治理委员会会议不能作为需要立即遏制的服务的唯一机制。在规定的条件下预先授权具体的紧急行动，保留审计跟踪并要求后续审查。承担问责责任的负责人应该知道每项授权行动的操作后果。
独立审查应形成决策者可以使用的结论。它应该说明测试的内容、重要的限制以及需要再次审查的更改。未解决的分歧应连同决定和理由保留在批准记录中。评估系统的工作人员需要获取相关证据，并在证据缺失时提供升级渠道。 NIST 在其治理成果中确定了明确的角色和执行责任。 [1]
避免仅仅为了填完登记册而让一个人成为每个部署的永久负责人。将责任分配给能够理解服务并对其后果采取行动的职能部门。集团治理可以定义共同要求并挑战例外情况，同时运营责任仍然可识别。当组织重组改变汇报关系或撤销岗位时，请检查分配。
6. 通过证据统一批准门槛
使用其系统所经历的实际变化来比较两家公司现有的审批规则。相关示例包括引入新的数据源、更改模型版本、扩展到新的客户群或授予应用程序新的操作功能。记录每家公司当前所需的证据以及签署决定的机构。这种比较应识别差距，并找出整合后仍需保留的有效控制措施。
创建一个通用的变革分类法，其阈值与后果和不确定性相关。当日常维护保持在评估的操作范围内时，可能符合既定的技术发布程序的要求。目的、受影响人群、自主行动能力或法律角色的变化应促使进行额外审查。定义确定变更属于现有批准范围所需的证据。开发人员对较小变更的描述应得到记录的评估的支持。
批准记录应规定在适当测量的情况下可测量的验收条件。包括相关的绩效指标、测试人群、观察期和解释限制。单独记录定性要求，例如经过验证的合同许可或经过培训的人工审核员。综合分数可以掩盖缺失的强制性条件。拟议的流程在做出发布决定之前记录每个必需的条件以及支持其结论的证据。
如果授权决策者认为该安排是允许的，则对规定的运营安排使用有时间限制的例外情况。说明未解决的问题、临时控制、责任人以及到期条件。识别提前终止例外安排的事件，例如供应商版本更改或监控违规。到期后继续运营需要根据现有证据做出新的决定。该文件没有给出使用例外来推翻适用的禁令或强制性义务的依据。
保留过渡期间的变更历史记录。当两个发布日历重叠时，记录评估了哪个版本以及部署了哪个版本。建立一个必须重新评估批准的商定点，因为期间发生的变更已经影响了其证据。共享工单标识符可以连接工程记录、业务审批和独立审查。验收测试应确认这些参考文献指向实际的文档和部署的配置。
7. 评估综合运营环境中的绩效
评估计划应反映交割后提议的用途。确定范围内的用户、语言、数据源、交易量和决策结果。如果收购方引入不同的客户群或操作，则对卖方原始工作流程执行的测试可能需要扩展。保留原始结果并记录仍然适用的内容。审查者应说明在批准更改用途之前需要哪些额外的观察结果。
使用其来源和允许使用已经过审查的评估数据集。将开发材料与用于独立质询审查的证据分开，其中评估设计需要这种区别。记录抽样方法、相关分组和已知限制。定量结果应包括分母和测试条件。没有评估案例描述的百分比无法支持两家公司评估记录之间的可靠比较。
测试整个应用程序路径。正确的模型响应可能会被下游工作流程错误地转换、交付给未经授权的接收者或在未经预期审查的情况下被接受。包括测试设计中的输入处理、检索、用户界面、批准和最终操作。对于使用工具的系统，评估应用程序在不利输入下是否尊重权限边界。允许的测试级别应得到授权，并在必要时与生产活动隔离。
记录对业务决策重要的失败案例。客户支持应用程序可能需要对缺乏依据的承诺、受限信息的披露和投诉的不正确路由进行单独评估。生产计划应用程序可能需要评估不可行的计划以及人工干预过迟的后果。这些是用例设计的建议示例。实际的测试套件应遵循服务的目的、合同义务和相关的专业要求。
NIST 的测量功能包括部署前和操作期间的测试，并关注不确定性和方法的适当性。整合委员会应该收到评估结果及评估者说明的限制。测试成功仅能支持该项测试证据所能证明的具体结论。更广泛的运营批准需要评估计划中确定的其余证据。审核频率应反映应用程序以及可能影响其性能的更改。 [1]
8. 建立支持决策的监控机制
每项监测措施都应有明确的响应。记录数据来源、计算、报告频率和调查违规行为的人员。确定如何检测缺失的观测值以及当监控本身不可用时会发生什么情况。业务负责人应该了解衡量标准是否描述了服务可用性、输出质量、访问行为或影响客户的结果。即使这些维度出现在一个仪表板上，也需要单独解释。
保留公司特定的措施，直到团队证明有效的通用定义。两个应用程序可以使用不同的样本、标签或审查方法来报告准确性。将这些百分比结合起来可能会产生无法解释的结果。协调记录应解释旧定义、拟议定义以及任何平行测量时期。保留在报告指标发生变化后解释历史结果所需的信息。
根据批准的目的、评估证据和适用的义务来选择阈值。该论文没有提出通用的准确度阈值或可接受的错误率。即使总体性能保持在数值限制内，某些条件也需要立即限制。评估的示例包括未经授权的访问、重大改变的目的以及所需人工审核步骤的丢失。将这些情况与统计警报一起记录下来，以便事件团队可以针对任一类型采取行动。
将人类监督作为一项运营活动来衡量。确定由谁审查产出、分配给他们的工作量以及他们干预时保留的证据。测试审阅者是否收到足够的上下文来识别有问题的结果。检查他们是否可以暂停工作流程并获得帮助。审查要求应附有人员配置和服务能力假设，可以根据实际运营计划进行检查。
审查事件、投诉和未遂事件以及数值表现。客户报告可以识别当前测试集之外的问题。将报告链接到相关部署和版本，对其进行调查并记录评估计划的任何更改。维护对投诉详细信息和事件证据的访问控制。监测应支持关于继续运营、额外控制、重新评估或暂停的书面决定。
9. 将供应商和合同纳入治理
供应商登记册应确定哪些实体为每项服务签订了合同，以及哪些实体在交割后使用该服务。与适当的顾问一起检查合同转让、控制权变更、授权用户和处理规定。记录支持继续访问的证据，包括任何所需的同意或修订的订单。供应商提供访问的技术能力应与使用该访问的合同许可分开考虑。
记录供应商在没有客户控制发布的情况下可以做出的更改。这些可能涉及模型、托管安排、保留设置或应用程序功能，具体取决于实际服务。获取适用的通知和版本管理条款。技术负责人应解释如何检测供应商所作的变更以及如何评估其对批准用途的影响。对于相关配置无法保持不变的依赖项，保留备用操作计划。
就事件信息如何到达供应商和合并后的企业达成一致。确定支持渠道、授权联系人以及各方可以共享的信息。审查可用于调查、遏制和恢复的援助。 NIST 的事件响应指南将第三方视为责任共担模型的参与者，并将其纳入计划和演习中。拟议的整合过程使用联合演习来测试实际合同中描述的安排。 [3]
根据依赖关系及其后果评估集中风险。多个业务应用程序可能依赖于一个服务端点或身份提供者，即使它们使用不同的模型名称。依赖关系图应显示哪些客户流程将受到该服务故障或撤回的影响。根据相关数据权限、容量和质量要求测试替代方案。未经测试的第二供应商仍然是候选应急方案，其验收工作尚未完成。
根据验证的范围和退出成本来保持采购节省。合并合同可以改变最低承诺、使用权和支持安排。要求财务部门将拟议的节省与迁移成本、剩余义务和额外评估相协调。治理记录应确定哪些供应商决策已获得批准以及在确认其对集成预算的影响之前所需的证据。
10. 按验收条件安排控制措施的统一顺序
拟议的整合顺序从交割时的稳定运营记录开始。建立承担问责责任的负责人，保留现有批准的配置并确定紧急决策。在进行广泛的技术迁移之前，引入共享事件联系人和受控变更日志。任何需要立即采取行动的已知问题都应进入适当的响应流程。该序列提供了一个组织框架；交易特定的义务和事件条件可能需要早期干预。
下一阶段将核对清单并比较控制证据。确认重要部署的目的和依赖性，审查差距并分配有时限的补救措施。引入统一的记录定义和审批途径。这项工作可以在单独的生产环境按照其批准的安排继续进行的同时进行。当所需的证据和决策存在时，阶段就完成了，无论整合计划中最初打印的日期如何。
具有基于证据的接受条件的说明性序列。没有假设固定的完成时间。
迁移应遵循经过测试的设计以及明确的恢复决策。在批准的测试条件下，比较建议环境中的输出和工作流程行为。确定哪些差异是预期的，哪些差异需要调查。同意可以停止迁移的人员、可以回滚的最新时间点以及恢复所需的证据。技术回滚应解决尝试切换期间写入的数据或采取的操作。
仅在其工作人员接受文件、访问和支持责任后，才将责任移交给长期负责运营的组织。记录未解决的例外情况、剩余的供应商依赖性和审核日期。通过授权流程注销临时账户和过渡安排。根据适用的保留要求保留证据。整合发起人应收到一份收尾声明，明确哪些内容已被接受，哪些内容仍属于运营义务。
11. 绘制事件从检测到授权恢复的过程
使用可以接受来自两家企业各方、客户和相关供应商的报告的共享事件处理路径。初始记录应确定受影响的服务、观察到的行为、报告的时间和来源。通过授权程序保存证据。响应者应评估潜在影响并决定是否需要立即遏制。随着信息的改进，应重新审视分类；过早的描述可能会忽略重要的后果。
指定一名事件负责人，可以接触业务负责人、技术团队和相关法律专家。领导协调响应并记录决策。拟议的地图将技术遏制与有关外部通知和恢复的决策分开。适用法律、合同和专业义务决定通知要求。该论文没有设定通用的报告截止日期，也不假定可以向所有参与者披露个人或机密信息。
通知要求和恢复权限必须根据实际服务和管辖范围确定。箭头表示协调，并在需要时进行并行专家审查。
考虑一个说明性事件，其中新连接的检索源将信息暴露给其批准的访问范围之外的应用程序。建议立即采取的应对措施是使用授权控制措施限制受影响的连接，保留相关证据并确定暴露范围。调查应检查权限、配置更改和下游收件人。业务负责人应确定哪些服务可以在经过验证的限制范围内继续进行，同时评估更广泛的问题。
恢复需要证据证明批准的服务可以在修改后的条件下运行。测试补救措施和相关故障路径，确认监控并记录残留问题。在恢复受影响的功能之前获得所需的授权。技术可用性的回归为这一决定提供了一个观察结果。事件审查还应解决客户后果、证据保留和集成过程所需的更改。 NIST 的应对指南包括恢复和反馈到风险管理的经验教训。 [3]
12. 将司法管辖区和行业要求应用于特定用途
为每个重要部署创建法律适用性记录。确定供应链中的运营实体、受影响人群、服务市场、目的和角色。请合格的顾问确定相关义务和适用日期。将该记录与批准的配置保持链接。当地区、用途或品牌变化可能影响法律分析时，应触发复审。然后，集团政策可以合并由此产生的要求，而不会模糊本地责任。
2026 年 7 月 27 日的欧盟 AI 法案综合文本提供了一个具体示例。第 25 条涉及运营商成为高风险系统提供商的情况，包括涉及品牌、实质性修改或预期目的的某些变化。第 26 条规定了部署者的义务，包括由具备相应能力的人员实施的人工监督和监控。这些规定要求在将其视为特定系统的现行职责之前对范围、例外情况和适用的过渡规则进行评估。 [4]
欧盟委员会当前的实施页面描述了该法案不同部分的不同适用日期，并反映了 2026 年的修正案。整合团队应维护一份注明日期的义务登记册，并根据综合立法和相关建议进行检查。本文并未断言每个高风险要求都适用于交割时的每项部署。交易计划应当记录具体要求、适用日期、责任主体以及合规所需的证据。 [5]
SDAIA 的 AI 道德原则讨论了整个系统生命周期的问责制、可追溯性、监控和第三方尽职调查。 阿联酋2024年7月的宪章包括人工监督、治理、问责和遵守适用法律。这些第一手机构出版物为拟议的治理设计提供了相关的区域参考点。它们的地位和对特定实体的应用需要单独评估。它们没有对跨境数据传输、受监管的金融活动或特定行业的部署提供普遍批准。 [6],[7]
对于为国际客户提供服务的 GCC 运营，请在法律登记册旁边保留合同义务。客户合同中的安全附件或采购要求可能会施加与持续交付相关的证据条件。核实已签署的合同条款以及有权接受变更的一方。保留法定要求、合同承诺和内部选择的控制措施之间的区别。投资委员会需要清楚记录每个条件的依据以及不满足该条件的后果。
13. 取证及并行运作预算
实施预算应将共同计划成本与特定部署工作和临时运营成本分开。使用有据可查的清单作为数量基础。获取实际评估、修复和迁移任务的估计及其背后的假设。记录可以更改审核数量或并行运行持续时间的依赖关系。财务部门应根据批准的工作包调整预算，并确定每个重要估算的负责人。
以下预算完全是假设，金额均以美元计。假设共同项目启动工作需要 USD 180,000，包括登记册、政策核对及初始运营程序。将152项示例部署分为三类工作量：32项需要深入评估，每项 USD 4,000；60项需要中等程度评估，每项 USD 2,000；另60项需要有限审查，每项 USD 500。这些只是工作量假设类别，不代表法律上的风险分类。
| 工作包 | 计算 | 假设支出 |
|---|---|---|
| 共同项目启动工作 | 固定假设金额 | 180,000 |
| 深入评估 | 32项部署，每项4,000 | 128,000 |
| 中等程度评估 | 60项部署，每项2,000 | 120,000 |
| 有限审查 | 60项部署，每项500 | 30,000 |
| 临时并行运行 | 6个月，每月35,000 | 210,000 |
| 基础实施总支出 | 五个工作包的总和 | 668,000 |
作者假设，金额以 USD 计。未采用已观察到的供应商价格、人员费用标准、咨询报价或市场基准。此计算中的评估类别互不重叠。
计算假设评估费用涵盖指定的审核工作，并且临时运营成本是这些费用的额外费用。它不包括普通企业运营成本、税收、融资成本、收入影响和超出规定工作包的补救措施。在实际预算中，需要范围定义和时间记录，以避免重复计算相同的员工成本。说明性总额是选定假设下的支出，不附带任何概率。
假设按每月 USD 35,000 的相同并行运行成本延长三个月，将增加 USD 105,000。另假设发生重大配置变更后，八次深入评估需要重做，每次 USD 4,000。重复评估增加 USD 32,000，因此新增支出为 USD 137,000，延期后总支出为 USD 805,000。重复评估是针对现有部署的额外工作，不增加清单中的部署数量。
委员会应审查延期的原因。供应商延迟同意、缺乏证据以及失败的迁移测试需要不同的应对措施。预算储备金应有书面目的和批准规则。该模型没有量化可避免的损失，也没有表明这种支出会创造特定的投资回报。任何节省或收入假设都应有单独的证据支持，并与集成期间维护服务的成本相协调。
14. 在采用整合方案前测试服务连续性
对于每项重要服务，确定在 AI 组件受限或不可用时企业可以提供的服务。描述替代工作流程、人员配置要求和客户后果。验证相关合同和专业要求是否允许该替代方案。应使用代表性工作和授权数据来测试手动流程。记录它可以处理的数量、所需的审查以及在所选测试条件下累积的积压工作。
将技术正常运行时间与已完成的客户服务分开。当产生需要大量修正或无法在批准的流程中使用的输出时，应用程序可能是可访问的。定义与实际客户义务相关的服务措施。拟议的连续性测试应遵循从输入到审核和交付的事务。包括解决异常情况所需的时间以及下游团队吸收额外工作的能力。
确定后备措施变得不足的点。负责人应该知道哪些服务获得优先级以及哪些承诺需要升级。集成计划应指定谁向客户传达变更以及谁批准临时容量的支出。在相关人员、访问权限和操作程序到位之前，拟议的应急措施仍然是有条件的。保留测试证据并在这些条件发生变化时安排重新验证。
投资案例应显示新旧安排的运作期间。记录哪些成本会持续存在，哪些收益取决于迁移验收。如果底层服务仍在使用以前的环境，那么财务部门应该挑战任何这样的假设：在依法交割时就开始完全节省。拟议的模型使临时并行运作保持可见，以便委员会可以评估支持商定的过渡所需的现金。
在每次重要切换之前审查连续性证据。确认后备仍与当前数据、供应商访问权限和人员配置匹配。重组前制定的恢复计划可能会列出不再拥有必要权力的人的名字。测试记录应识别实际参与者和决策者。委员会的验收声明应具体说明支持下一阶段批准的服务安排的证据。
15. 委托范围明确的整合顾问工作
委托外部支持的买方应定义需要帮助做出的决策以及要提供的证据。拟议的任务可以涵盖部署清单核对、控制比较、整合治理和实施计划的协调。它应该说明哪些专家评估是由具有适当资格的顾问进行的，哪些是由客户团队进行的。该约定应保留管理层对运营批准和风险接受的责任。
将可交付成果与验收标准联系起来。部署清单交付成果应协调原始记录，确定未解决的范围并将重要部署与负责人联系起来。批准框架应针对代表性变更进行测试。供应商专项工作应记录已签署的合同条款和未完成的决策。应与相关参与者共同演练事件处理程序。最终报告应说明证据的局限性以及拟议运营模式仍需要采取的行动。
在共享材料之前就信息访问、保密、保留和冲突管理安排达成一致。顾问应获得适合任务的访问权限和授予的权限。范围应解释如何报告调查结果以及紧急问题如何到达管理层。在发现过程中发现的任何额外工作都应该有一个记录的变更过程。这使得客户可以在开始之前批准进一步调查的成本和目的。
商业条款应将特定工作的聘用费与实施支出、软件费用和专家费用区分开来。本文中的假设预算不是 Matchpoint Partners 费用建议。针对特定客户的提案需要确认范围、管辖范围、部署复杂性和证据的获取。该文件和初步讨论均未承诺监管许可、不间断运营或财务结果。
对于投资委员会来说，有用的收尾是一份决策记录，显示已批准的运营安排、剩余条件和承担问责责任的负责人。该记录可以支持后续的治理审查和未来的收购整合。交易团队解散后，运营组织仍应可以访问它。任务的完成标准应反映商定的交付成果和实际提供的证据。
16. 达成书面运营结论
委员会应该收到一份已核对的部署清单和针对每项重要部署的具体运营决策。它应该看看哪些系统可以在批准的限制内继续运行，哪些需要额外的条件，哪些等待未决的决定。报告应确定这些类别背后的证据、实质性依赖性以及得出每个结论的日期。总完成百分比应附有未完成项目的后果。
使用测试和负责签核支持的验收条件批准集成顺序。当不再满足特定功能的条件时，保留限制该功能的能力。在整个过渡过程中保持客户连续性、法律义务和事件权限可见。当提议的环境具有所需的权限、评估证据和操作支持时，可以进行技术整合。任何继续保持的环境分离都应有书面原因和审查条件。
假设的计算说明了两个不同的管理问题。部署清单核对确定了需要治理的部署总体，而实施预算则确定了选定范围和时间假设下的支出。这两种计算都无法确定实际的部署准备情况或商业价值。收购委员会应在使用该方法批准资源或评估整合案例之前，用交易证据取代这些假设。
拟议的框架以联合治理流程的永久负责人、批准使用的维护记录以及变更和事件决策的工作路线结束。其有效性需要通过操作和审查来证明。因此，下一个投资决策应包括初始集成计划结束后维护系统的成本和责任。
附录 A. 部署决策的最低证据
拟议的部署记录应标识法人实体、业务负责人、批准的目的和生产环境。保留每个公司的原始标识符以及清单核对后使用的集团标识符。链接相关模型或服务版本、应用程序配置和依赖项。记录检查操作事实的日期以及执行该检查的人员。如果发现仍然不完整，请描述缺失的证据及其对决策的影响。
批准部分应确定适用的内部政策以及相关顾问提供的法律或合同条件。附上评估结果以及测试范围、分母和限制。描述监控措施、响应阈值和人工审核安排。记录批准的操作能力和数据访问限制。决定应确定授权人、生效日期、到期或审查条件以及需要重新评估的变更。
连续性部分应描述回退、其测试容量以及授权激活它的人员。将事件处理路径、供应商支持安排和证据保存程序联系起来。恢复决策应指定受影响功能恢复之前所需的测试和批准。保持运营记录与当前的人员配置和合同安排保持一致。移交演练应确认永久负责人可以找到证据并执行所需的操作。
附录 B. 重现假设计算
清单从 A 公司的100条记录和 B 公司的80条记录开始。扣除15条重复管理记录及25项已确认停用的部署，再加上12项新发现的在用部署，得到152项在用部署。三类假设审批状态分别为：82项证据完整，50项获得有条件批准，20项等待决定。前两类共132项；132除以152等于86.8421%，显示为86.8%。
评估工作量类别是对同一组152项部署的另一种分类。将32乘以USD 4,000、60乘以USD 2,000，再将60乘以USD 500，可得假设评估支出USD 278,000。加上USD 180,000的共用设置费用，以及每月USD 35,000、持续六个月的费用，总额为USD 668,000。额外三个月和八次重复深入评估增加USD 137,000。延期后的支出为USD 805,000。计算未包含折现、概率加权、通胀调整或税费。
来源
- 美国国家标准与技术研究院。人工智能风险管理框架，AI RMF 1.0，NIST AI 100-1，2023年1月。自愿采用的框架，涵盖治理、情境映射、衡量及管理成果。 阅读第一手来源
- 美国国家标准与技术研究院。人工智能风险管理框架：生成式人工智能专题指南，NIST AI 600-1，2024年7月。涉及第三方依赖、组织内容访问及价值链整合。 阅读第一手来源
- 美国国家标准与技术研究院。网络安全风险管理中的事件响应建议与注意事项：CSF 2.0 社区专题指南，SP 800-61r3，2025年4月。涉及事件处置权限、第三方协调、恢复和改进。 阅读第一手来源
- 欧洲联盟。 (EU) 2024/1689 法规，2026 年 7 月 27 日合并文本。第 25、26 和 113 条；特定角色的规定和应用规则需要特定交易的评估。 阅读第一手来源
- 欧盟委员会。 AI 法案实施和应用时间表。当前官方概述，访问日期：2026 年 9 月 10 日。 阅读第一手来源
- 沙特数据和人工智能管理局。 AI 道德原则。问责、监控和第三方尽职调查；访问日期：2026 年 9 月 10 日。 阅读第一手来源
- 阿联酋人工智能、数字经济及远程工作应用国务部长办公室。阿联酋人工智能开发与使用宪章，2024年7月。 阅读第一手来源
