算法驱动交易风险：定价漂移、依赖与控制权变更风险敞口

1. 从现金流角度定义算法驱动交易风险

算法驱动交易风险是指：为交付由 AI 支持的客户成果所需的技术、权利、人员或外部服务，可能改变交易中承做的现金流。该风险可能发生在签约前、签约与交割之间，或控制权转移之后。其财务影响可通过客户流失、转化率下降、推理成本上升、服务补偿、整改投资、产品发布延迟、监管限制或更长的整合时间表体现。

因此，尽职调查发现应说明受影响的运营能力、可获得的证据、变化机制、现金流路径、检测时间、整改时间以及能够控制结果的当事方。若缺少这一链条而将模型描述为高风险，并不足以支持定价或合同决策。若未界定受测群体、期间和阈值而将产品描述为准确，同样几乎无法提供保护。

交易团队应建立一份登记册，将技术证据与商业和法律决策联系起来。每个条目均需明确负责人、重要性区间、缓解措施、剩余风险敞口和交割后测试。该登记册应区分影响企业价值、股权价值、交割确定性、整合成本和持续治理的条件。单一问题可能通过不同机制影响其中多个类别。

2. 建立签约时的运营基线

买方需要在计量日获得可复现的产品及经济状况全貌。该基线应明确具体的模型和提示词版本、路由规则、数据快照、评估套件、基础设施、人工审核步骤、上游服务、客户配置和成本分摊。应记录观察绩效、可用性、收入和利润率的期间。这是保证、过渡期契约、交割测试及后续价值计量的参考状态。

管理层演示材料常将不同产品版本或客户群组合并呈现。买方应将主要指标与日志、发票、客户记录和受控评估进行核对。如果历史结果无法复现，买方可将差异视为计量限制，并构建更宽的估值区间。目标是形成可辩护的基线，而非对过去每项决策进行实验室级的完美重建。

应通过哈希化制品、访问受控的导出内容和有记录的测试程序来保存基线。买卖双方应就哪些变更属于日常经营、哪些变更需在交割前通知或取得同意达成一致。看似技术性的版本变更可能改变成本、输出质量、可解释性或合规性。因此，过渡期控制应适用于整个运营系统，而不仅是模型名称。

3. 绘制完整的算法依赖链

AI 产品可能依赖基础模型 API、云区域、向量数据库、标注供应商、安全工具、开源库、专有数据集、支付系统和具名人员。依赖关系图应通过每个重大组成部分追踪客户成果。应识别合同相对方、技术接口、所有权、司法管辖区、集中度、变更权、终止条款、替换方案及受影响的收入。

运行时证据至关重要。架构图可能遗漏影子服务、备用模型和客户特定路由。买方可以比对代码仓库、环境配置、遥测数据、网络调用、发票和事件记录。差异应在对依赖关系评分前解决。如果某个低成本组件位于每个生产请求的路径上且无法快速替换，它仍可能具有高度重要性。

应通过影响和可替代性来衡量依赖关系。影响考虑收入、利润率、客户、义务和安全性。可替代性考虑技术等效性、数据可移植性、合同许可、整合工作量、评估时间和客户批准。两者结合决定该风险应通过价格、交割条件、托管、契约、有资金支持的替换计划还是持续监控来应对。

每项运营依赖关系均与客户成果、受影响的现金流和交易应对措施相关联。

表1. 依赖证据与交易应对措施

重要性结合了现金流影响、替代时间与控制。

4. 将模型漂移与模型故障区分开来

漂移是输入、关系、输出或运营环境的变化，可能使绩效偏离批准范围。数据漂移改变输入的特征。概念漂移改变输入与期望结果之间的关系。性能漂移改变所衡量的质量。运营漂移可能源于路由、提示词、检索内容、基础设施或人工审核。即使底层模型文件保持不变，这些情况也可能存在。

交易应区分正常波动与阈值突破。尽职调查团队应识别指标、细分群体、观察窗口、置信限和业务后果。全局平均值可能掩盖受监管用例、语言、客户群体或高价值工作流程的重大下滑。因此，监控应围绕面临风险的价值和义务，而不是单一模型评分。

故障是无法满足约定要求，例如可用性、准确性、安全性或合同服务。漂移可能在故障发生前形成预警。只有当目标公司具备稳定的衡量、责任归属和响应程序时，买方才能对这种预警进行估值。若监控薄弱，买方可能需要独立的基准、有资金支持的观察期以及更广泛的下行情景。

5. 围绕已观察到的证据构建漂移情景

估值模型应采用有限的一组相互一致的漂移情景。基准情景可反映已观察到的绩效和当前补救支出。中度情景可模拟重大细分群体的恶化、更多人工审核和销售延迟。严重情景可模拟客户限制、上游模型替换、监管补救或数据源丢失。每个情景都应说明触发条件、持续时间、响应和恢复证据。

概率估计不应暗示历史数据无法支持的精确性。买方可以使用区间和决策阈值，然后测试估值对每种状态的概率和持续时间的敏感性。核心问题是，当运营证据超出承销范围时，购买价格和资本计划是否仍可接受。

模型应避免重复计算。收入下降、运营成本上升、整改投入以及估值倍数压缩可能反映同一根本原因。团队应明确哪些现金流影响纳入预测，哪些风险影响折现率或交易条款。有记录可查的衔接分析有助于投资委员会审查以及交割后衡量。

示例情景展示了经营变动如何影响收入、利润率和整改。

表 2. 示例性漂移情景记录

相关数值属于分析假设，需要针对具体交易的证据支持。

6. 检验基准测试的稳定性与决策相关性

当基准测试的数据陈旧、受到污染、范围狭窄或与客户成果关联薄弱时，基准测试可能带来虚假的安心感。买方应使用锁定环境、有记录的提示词、代表性样本、重复运行和清晰评分来复现重大主张。应考察方差和误差分布，而不是仅依赖平均结果。

基准测试的相关性应追溯至收入和义务。编程得分可能无法预测依赖检索、工具、权限和人工审核的客户工作流程中的表现。安全基准测试可能不覆盖产品销售所面向的语言或领域。尽职调查计划应包含围绕客户使用、故障成本和预期集成变更设计的交易特定测试。

NIST 的生成式AI概况强调，系统往往依赖多个第三方组件和数据来源，使归因变得复杂。这对买方很重要，因为复现结果应明确模型、周边系统和证据所有者。无法归因的主张无法通过简单的模型保证得到可靠保护。

7. 识别上游供应商变更权

基础模型和基础设施供应商可以更改版本、弃用端点、调整速率限制、修订安全过滤器、改变数据处理方式并调整使用定价。尽职调查团队应阅读有效协议和服务文档，然后将其与生产配置进行核对。营销描述和非正式保证不应替代合同权利。

分析应识别通知期、单方变更条款、服务水平、责任限额、转让限制、数据使用条款、终止权和可用承诺。应检验目标公司获得的是企业级条款，还是依赖标准在线协议。如果实现可比性能需要昂贵的重新开发或客户重新验证，技术上可移植的应用仍可能在商业上被锁定。

买方应量化替换交付周期和过渡期现金敞口。这包括工程、评估、客户批准、安全审查、数据迁移、并行运行以及可能的收入损失。可信的备用方案是经过测试的运营能力，而不是幻灯片上的替代供应商名称。

8. 为API定价并计算集中度

AI毛利率可能在令牌价格、上下文长度、路由、缓存、利用率或人工审核发生变化时迅速变化。买方应使用发票和遥测数据重建每个成功客户成果的成本。单位成本应区分输入、输出、嵌入、检索、工具、存储、网络、预留容量、失败调用和审核人工。

集中度分析应显示对每个供应商、模型系列、云区域和容量承诺的支出与收入敞口。团队可以建模价格上涨、折扣到期、用量增长、低效提示词和备用方案使用等情形。基于收入的定价可能在使用量上升或客户行为变化之前掩盖成本敏感性。

交易保护可以将购买价格情景与运营控制结合起来。这些措施可能包括限制重大供应商变更的过渡期契约、针对持续访问的交割测试、已拨备的迁移储备金，或基于贡献利润率而非仅收入的盈利支付指标。合同专家应起草并解释所有条款。

9. 构建权利与许可瀑布

被收购产品可能包括代码、权重、提示词、数据、内容、标签、文档、商标、专利、开源组件和客户定制开发成果。每项资产可能有不同的所有者、许可和转让规则。权利瀑布应从客户功能开始，并沿贡献者和供应商链条追溯每一项所需权利。

分析应区分所有权与许可权限。目标公司可能拥有源代码，但在控制权变更后缺乏使用客户数据训练的权利。宽松的软件许可可能规定通知要求。数据集可能可公开获取，但其收集、个人数据或数据库权利仍受到限制。需要就相关司法管辖区和事实获取专业意见。

交易团队应将缺口与补救措施对应起来。缺失的同意可能构成交割条件。不明确的训练权可能需要特定保证、赔偿、补救契约或产品限制。可替换组件可能为计提量化准备金提供依据。应对方案应体现可执行性、重要性以及买方核实合规情况的能力。

只有当链条中每项重大权利均有证据证明且可转让时，客户功能才获得支持。

表 3. 许可瀑布尽职调查记录

应由合格专家对实际生效的权利和限制进行解释。

10. 审查训练数据与输出风险敞口

训练和微调数据应按来源、用途、司法辖区、许可和保留期限进行追溯。买方应识别目标公司是创建了模型、修改了第三方模型，还是作为下游提供商运营。欧盟现行通用目的 AI 框架对相关提供商规定了文档、版权政策和训练内容摘要义务，并对具有系统性风险的模型规定了额外义务。适用性需要结合具体事实进行法律分析。

输出风险敞口包括保密、个人数据、知识产权、有害内容、歧视和信赖。目标公司的合同可能在不同客户之间以不同方式分配这些风险。过滤、检索权限、审查和日志记录等产品控制措施应依据实际承诺进行测试。没有技术落实的政策文件在交易中的价值有限。

买方应区分可补救的文档缺口与依赖被禁止或未获许可用途的运营模式。前者可能需要成本和时间的投入。后者可能影响产品的合法运营边界和终值。交易条款应反映这一差异。

11. 分配提供商与部署者责任

AI 监管日益区分开发模型或系统、或将其投放市场的实体与部署该模型或系统的实体。收购可能改变品牌、整合、用途、分销和控制权。这些变化可能改变各方的责任。尽职调查团队应在分配通用合规标签之前，梳理每个产品和司法辖区。

该映射表应识别相关系统、预期用途、用户、受影响人员、风险分类、文档、人工监督、监测、事件报告和下游信息。还应识别哪个实体能够提供证据。合同分配并不能免除法定义务，尽管它可能支持各方之间的合作与追索。

买方可以将能力缺口与交割和整合决策联系起来。如果目标公司无法提供下游客户所需的信息，收入留存可能面临风险。如果买方计划的整合产生新的提供商角色，整合预算应包含由此产生的评估、文档和控制措施。

12. 审查 UAE 金融服务 AI 义务

UAE 中央银行于 2026 年 2 月发布了面向持牌金融机构的负责任 AI 指引。该指引重点关注消费者保护、透明度、偏见、问责、可解释性、数据隐私和负责任使用。涉及受监管金融机构或其重要技术提供商的交易，应审查这些原则如何适用于具体产品和合同链。

买方应测试治理、客户披露、模型审批、数据保护、结果监测、投诉、人工审查和第三方监督。应识别哪些记录支持管理层的陈述，以及控制措施是否覆盖外包模型。该分析可能影响客户同意、产品变更、整合顺序和持续鉴证成本。

监管解释应由合资格法律顾问及相关专家负责。尽管如此，交易模型仍可纳入可观察的整改工作、受影响收入、决策日期和资本要求。这样可在不将法律结论视为技术评分的情况下，在合规证据与估值之间建立衔接。

13. 逐份合同分析控制权变更触发条件

控制权变更风险敞口可能出现在客户、供应商、数据、云服务、雇佣、融资、保险、赠款和合作协议中。相关条款可能要求同意、通知、还款、重新谈判或终止。尽职调查团队应检索全套合同，并通过法律审查和业务负责人访谈确认结果。

重要性不应仅以合同价值衡量。一份金额较小的数据协议可能支撑一项重要产品。一家支出较低的模型供应商可能支撑大部分收入。拥有终止权的客户可能影响其他客户或监管审批。因此，登记表应将每项条款与技术依赖关系和现金流联系起来。

同意策略需要明确负责人、沟通信息、顺序、备选方案和截止日期。过早提出请求可能泄露交易或削弱谈判筹码。过晚提出请求可能危及交割。各方应使该方案与法律意见、交易条件和运营连续性保持一致。过渡期契约应防止产生可避免的新风险敞口。

14. 检验客户转移与信任

AI 客户可能已批准指定模型、托管区域、安全架构、数据使用、分包商或人工审核流程。即使法定供应商保持不变，收购也可能改变其中一项或多项要素。买方应将合同承诺、鉴证报告、问卷和补充函与拟议整合计划进行对应。

客户尽职调查应按收入对模型、数据、所有权和服务变更的敏感度进行细分。访谈或获准的确认程序可以检验购买原因、转换成本、信任和续约标准。在权限和可行性确立之前，买方应避免承诺未来的产品变更。

留存情景应反映客户证据和合同权利。交易保护机制可将部分对价与留存的经常性毛利润、客户同意或续约挂钩，但须审慎界定并考虑卖方控制因素。运营计划应提供沟通顺序、指定客户负责人和升级路径。

15. 衡量关键人员依赖度

AI 产品往往将知识集中于一小群人，他们了解数据血缘、评估设计、部署、事件响应或客户配置。职位名称并不能揭示这种依赖。买方应将决策、系统、凭证、关系和隐性知识对应到具名角色，然后检验备份覆盖情况和文档记录。

当人员流失可能导致服务中断、阻碍发布、削弱主张、延迟整合或削弱客户信心时，集中度便成为交易风险。分析应考虑通知期、留任、激励、移民、地点、限制性契约、继任、工作负荷和文化契合度。雇佣法和当地可执行性需要专业意见。

仅靠留任付款并不能转移知识。过渡计划应明确交付物、影子跟岗、双重审批、权限转移、客户交接和验收测试。在适当且法律上有依据的情况下，买方可将完成情况与托管释放、盈利支付机制或整合节点挂钩。

集中风险将运营影响与建立可信保障所需时间结合起来。

表4. 关键人员证据与保护计划

留任应与受控的知识转移和运营验收相结合。

16. 核对访问权限、凭据和运营授权

买方应了解谁可以变更生产环境、访问敏感数据、批准发布、更改计费、与客户沟通以及宣布事件。由个人或供应商持有的凭据会带来连续性和安全风险。尽职调查团队应通过经批准的观察和证据来测试访问权限，同时不得干扰生产环境。

访问映射应核对身份系统、云控制台、代码仓库、模型注册表、数据存储、监控、支持系统和第三方门户。它应识别共享账户、不活跃管理员、缺失日志和紧急访问程序。为避免干扰目标公司，整改可能需要等到交割后进行，因此首日计划应优先明确顺序和回滚安排。

交易文件可以支持提供访问证据并开展合作，而整合计划则确立新的授权。买方应保留取证记录，并遵守适用的隐私和劳动用工义务。账户移交绝不应依赖非正式的密码共享。

17. 审查事件历史，将其作为估值证据

事件揭示了产品在压力下的表现以及组织的应对方式。买方应审查安全、隐私、可用性、有害输出、数据质量、客户和监管事件。应核对工单、状态页面、日志、保险通知、客户补偿和董事会报告，以识别被遗漏或分类不同的事件。

该分析应衡量检测时间、遏制、恢复、复发情况、根本原因分析质量以及纠正措施的完成情况。反复发生的低严重性事件可能暴露控制设计的薄弱。若原因已消除且修复已独立测试，单次严重事件的预测性可能较低。交易团队应保留背景信息，而不是仅对事件数量评分。

未解决的事项可成为交割条件、托管事项、专项赔偿或有资金支持的整改计划。历史事件还可能影响陈述与保证、披露、保险和客户留存。合格顾问应确定适当的法律和会计处理。

18. 评估监控与可观测性

一款 AI 产品需要在输入质量、模型与提示词版本、检索、工具调用、输出质量、延迟、成本、安全、人工审核和客户结果等方面具备可见性。买方应测试监控是否覆盖重要细分场景，以及告警是否会促成可问责的行动。只有当定义、数据血缘和响应责任归属可靠时，仪表盘才有用。

监控应区分领先指标和滞后指标。输入变化、供应商通知、延迟和审核升级可能在客户流失或收入损失之前发出预警。客户投诉和续约失败则反映已实现的影响。交易模型可将这两类指标与阈值和响应成本关联起来。

依赖技术指标的交割后契约或或有对价需要稳定的定义和防操纵控制。若指标可能受到路由、样本选择或阈值调整的影响，各方需要商定计量程序并能够获取证据。当技术计量手段尚不成熟时，更简单的商业指标可能更具可执行性。

19. 验证 AI 供应链各环节的安全性

AI 供应链风险包括模型工件、训练流水线、代码、数据、API、插件、云基础设施和第三方工具。买方应审查访问控制、密钥、来源追溯、漏洞管理、日志记录、环境隔离、事件响应和供应商保证。还应测试产品特有的风险，包括提示词注入、数据泄露、不安全工具使用和模型提取。

英国国家网络安全中心的 secure-AI 指南将安全性贯穿于设计、开发、部署和运营。这种生命周期视角在交易中很有用，因为买方既收购当前系统，也收购用于变更该系统的流程。安全快照无法弥补不受控的发布流水线。

安全发现应转化为可利用性、受影响资产、可能的业务影响、整改措施和剩余风险敞口。交易应对措施可包括交割前补救、价格调整、托管、保险审查、专项契约或整合门槛。安全专家应验证严重发现和整改情况。

20. 测试韧性与故障回退运行

备用方案的主张应得到验证。买方应观察或复现供应商故障切换、模型替换、降级模式、队列管理、回滚、备份恢复和事件沟通。测试应反映真实的客户量和数据约束。若备用方案维持了正常运行时间，却显著降低质量或违反合同，则该方案并不完整。

韧性分析应识别恢复时间、恢复点、容量、区域依赖、人工投入和客户影响。分析还应涵盖第三方事件和内部部署错误。当承保服务水平要求维持并行能力时，该能力的成本应纳入估值模型。

交割测试可确认能否获得关键供应商和恢复程序。交割后门槛可将平台整合推迟到韧性得到证明之后。买方应避免仅为尽早实现协同效应而移除冗余，因为该冗余可能保护着重要收入。

21. 量化整改投资

整改应作为一项计划来估算成本，而不是作为一组发现事项的清单。估算应包括人员、专业顾问、许可证、基础设施、并行运行、客户工作、验证、文档、应急储备和管理层投入。应识别哪些工作是运营、合规、整合或实现收购逻辑所必需的。

时点很重要。在收入增长前发生的成本与由后续现金流提供资金承担的成本，其价值影响不同。延迟还可能推迟协同效应或产品发布。因此，估值模型应将成本和收益分配到各期间，并说明依赖关系。

买方应区分卖方补救、购买价格调整、类债务项目、由托管资金支付的工作以及买方投资。会计处理取决于事实和适用准则。商业模型可以展示现金影响，而由合资格顾问确定分类。

22. 将风险转化为估值情景

估值应从观察到的经营基准和明确假设出发。算法化风险登记册随后改变收入、毛利率、运营成本、投资、营运资金或时点。团队可以计算一致情景下的企业价值敏感性，并识别哪些假设驱动该区间。

倍数压缩应谨慎使用。如果较低增长、利润率和持续性已反映在现金流中，额外任意下调可能导致风险重复计算。当依赖性或权利不确定性影响预测期之后的长期可防御性时，较低的终值倍数可能合理。应记录理由。

投资委员会应同时看到预期价值和下行情景下的流动性。一项交易可能保留预期价值，同时需要更多现金用于整改或抵御中断。贷款人和发起人需要在相同情景下评估契约余量、偿债和资金可用性。

23. 在价格与或有对价之间作出选择

固定价格调整可以应对一种风险敞口：其预期现金影响可计量，且在交割后很大程度上不受卖方控制。或有对价可以应对随时间解决的不确定性，例如客户留存、同意、业绩或利润率。指标、期间、控制权和争议程序决定该机制是反映经济实质还是制造冲突。

技术指标在代码中可能精确，但在商业上可能含糊。模型性能可能随样本、路由、阈值和客户组合而变化。经常性毛利等商业指标可能更直接地反映价值，但可能受整合决策影响。各方需要能使控制与计量相一致的定义。

买方应对行为激励进行建模。与收入挂钩的盈利支付可能鼓励高成本的使用或宽松的客户选择。利润率指标可能抑制必要投资。平衡计分卡可能变得过于复杂而难以管理。交易专家应选择能反映未解决风险的最小可计量指标集。

24. 围绕可验证的释放事件设计托管和保留款

托管可支持就违反保证进行追偿，或保障特定义务的履行，但须遵守适用法律和经协商的条款。释放事件应客观、有时间限制，并有双方均可获取的证据支持。示例可能包括收到重大同意、完成权利补救、移交关键访问权限或经独立验证的整改。

托管金额应与合理可能的敞口和执行情况相关，而不是采用通用百分比。团队可以建模重置成本、受影响毛利、客户责任、整改和延迟。上限、赔偿篮子、除外责任和保险会与实际追偿相互作用。

技术验收测试应尽可能在签署前定义。如果测试取决于买方控制的未来环境，协议应处理合作与变更。合资格律师应起草所有托管、保留款和索赔条款。

25. 围绕证据而非形容词起草陈述与保证

就模型准确、稳健或合规作出的陈述可能难以解释。更有用的条款可涉及已披露的系统、所有权和权利、重大合同、事件、索赔、文档、测试、变更历史，以及按照指定政策或义务运营。适当的措辞取决于交易和司法管辖区。

披露应将例外情况与受影响的资产、客户和现金流联系起来。如果买方无法确定哪份文件管辖某项生产依赖，庞大的数据室并不会带来清晰度。附表应与算法风险登记册和重要性分析相核对。

陈述与保证不能替代尽职调查或运营控制。其价值取决于知悉限定、存续期、责任上限、除外情形、保险和可回收性。律师应就起草和可执行性提供意见。交易团队应保存支持商业理由的证据。

26. 利用过渡期契约维护作为承销基础的系统

签署至交割期间对 AI 业务可能具有重大影响。模型、提示词、数据集、供应商、定价、人员和客户承诺可能因日常运营而发生变化。过渡期契约应维护业务中已约定的要素，同时允许必要的开发和合规。

双方可针对重大模型替换、新数据用途、供应商终止、定价变更、关键人员离职、安全事件、监管沟通和客户承诺约定通知或同意机制。门槛应聚焦经济和运营层面的重要性。过度僵化的契约可能妨碍负责任的修复或产品交付。

买方应在交割前通过约定的治理机制运作，并遵守适用的竞争规则。可能需要清洁团队安排和信息控制。法律顾问应确定允许的流程和起草方式。

27. 为关乎存续的依赖事项设定交割条件

如果缺少同意、权利、访问权限或批准导致买方无法运营业务的重要部分，则设定交割条件可能是适当的。该条件应具体且能够客观确定。双方应了解谁控制条件的满足以及延迟的后果。

条件还可涉及交付物、关键协议或监管批准的交付。条件不应成为完成常规尽职调查的替代。买方应评估终止权、最终截止日期、融资和客户影响。

如果完整条件不成比例，替代方案包括附价格保护的豁免、托管、过渡服务、许可、剥离或有资金支持的替代方案。决定取决于重要性、控制权、时间和可执行性。专业顾问意见至关重要。

28. 制定交易保护条款清单

保护条款清单应列出每项重大风险敞口、证据、现金流路径、控制责任人、交割前行动、合同应对措施、交割后测试和剩余风险。这会在商务、技术、法律、财务、税务、监管、安全和整合团队之间形成共享工作文件。

条款清单应保留拟议商业应对方案与已批准法律起草文本之间的区别。它可以在双方确定措辞之前识别选项、估值区间和依赖事项。应记录决策和被否决的替代方案，以支持治理。

最终方案应保持内部一致。购买价格下调的前提是买方接受该风险并为其提供资金。托管假定可以界定可追偿事件。契约假定义务方能够履行。赔偿假定损失与索赔流程可操作。每种机制都需要一份执行计划。

保护措施根据时点、控制力、可衡量性和严重程度进行选择。

表 5. 示例性算法化交易保护条款清单

条款需要针对具体交易进行谈判并取得合格法律意见。

29. 使交割后的保护措施与控制权保持一致

交易条款应反映谁控制结果。在买方改变模型、人员、定价或客户之后，卖方交付交割后产品指标的能力可能有限。买方在交割前取得供应商同意的能力也可能有限。控制权错配会引发争议并削弱激励机制设计。

保护条款应界定允许和要求的行动、证据获取、合作、变更程序以及争议解决。如果买方需要整合自由，固定价格或托管可能比长期技术性盈利支付更清晰。如果卖方继续经营业务，精心界定的业绩衡量指标可能仍然有用。

治理应包括指定决策者和升级机制。技术分歧可能需要独立专家，并使其能够访问相关材料并采用约定方法。法律顾问应确定专家裁定如何与合同索赔相互作用。

30. 整合而不破坏证据

交割后整合可能会覆盖用于验证保证或盈利支付的日志、代码库、账户、模型版本和客户配置。买方应在更改系统之前保留相关证据。保留必须遵守隐私、安全、法律保留和合同要求。

整合计划应安排访问权限移交、密钥轮换、监控、事件响应、权利补救、人员过渡和平台变更的顺序。高风险迁移应使用验收关卡和回滚。产品改进可以尽早开始，而影响计量或索赔的变更需要受控基线。

交易风险登记册会成为整合控制台账。每项保护措施都应映射到负责人、截止日期、证据和放行决策。财务应将支出和结果与估值论证相连接。这使董事会能够看到风险是被消除、转移、接受还是已实现。

31. 收购后对模型和供应商变更进行治理

买方应建立变更流程，涵盖模型版本、提示词、检索、工具、数据集、阈值、供应商和基础设施。变更应说明目的、受影响用户、评估证据、安全评估、成本、监管影响、审批、监控和回滚。控制水平应随重要性调整。

供应商通知应纳入同一流程。采购、工程、产品、风险、法律和财务部门需要就可能影响客户结果和经济性的变更建立共同记录。组织应针对失败超出风险偏好的依赖项维护经过测试的备用方案。

治理应通过明确的阈值和可复用证据来支持速度。一个审查每次提示词变更的缓慢委员会可能会催生影子做法。明确的授权、标准测试和例外路径可以在允许负责任开发的同时保持问责。

32. 将运营指标与投资论证相连接

交割后看板应贯通技术、客户和财务指标，可包括按重大客群划分的绩效、可用性、复核率、事件严重程度、供应商集中度、单位成本、客户留存、毛利润、整改支出和里程碑完成情况。每项指标都需要明确负责人、定义、数据来源和决策阈值。

领先指标应与董事会行动相衔接。回退使用增加可能先于成本压力出现。检索质量下降可能先于支持工单增加出现。供应商通知可能触发评估和客户沟通。看板应记录决策与结果，而不是展示缺乏治理的数据。

财务应将已实现的现金影响与收购模型进行核对。收益和损失应审慎归因，因为整合、市场和算法因素会相互作用。目标是形成有纪律的学习和资本配置，而不是追求人为的精确。

33. 落实会计与减值规范

收购的技术、客户关系、商誉及其他资产需按适用框架进行会计处理。IFRS 3 规范企业合并中的确认与计量，IAS 36 则涉及相关资产的减值。算法依赖、权利限制、客户流失或预测走弱可在会计判断前提下，为现金流假设和减值迹象提供参考。

尽职调查模型应保留预测和估值所用证据。交割后监控可识别绩效、成本、使用寿命或经济利益的变化。管理层和审计师需要透明的假设和核对结果。

本文不确定会计分类、公允价值或减值。合格会计师和估值专家应结合交易事实适用相关准则。该运营框架有助于他们定位证据和现金流路径。

34. 向贷款人提供算法下行情景

贷款人需要清晰了解经常性收入质量、毛利率、集中度、资本需求和下行流动性。一家 AI 企业可能增长强劲，却依赖可能改变价格或条款的供应商。因此，融资模型应纳入供应商、模型漂移、客户和整改情景。

契约余量应在计入现实现金成本和延迟后进行测试。EBITDA 对整改或一次性整合的调整需要审慎审查，因为部分技术与保证支出可能反复发生。贷款人可能根据风险与结构寻求报告、同意、流动性或保险方面的保护。

借款人应避免技术细节掩盖重大经济实质。简明的依赖关系与缓释安排表可支持信用分析。敏感信息应通过适当控制措施并在法律建议下共享。

35. 使用一个交易演算示例

设想某假设买方正在评估一家 AI 工作流公司，其年度经常性收入为 USD 30 million，声称贡献毛利率为 58%。该产品 72% 的生产请求依赖一个外部模型系列，一项从三个来源获得许可的专有数据集，以及六名掌握发布或客户特定知识的资深员工。上述数字为示例性假设。

复现结果显示，一个高价值客户客群的表现低于总体声称水平。供应商提价情景使贡献毛利率下降四个百分点。一项数据许可在转让时需取得同意，两项发布能力缺乏有效的替补人员。买方估计需实施为期十二个月的整改计划，并对收入、利润率、投资和延迟进行建模，且不将任何假设概率视为已观察事实。

买方的初步应对方案包括：反映中度模型漂移情景的估值区间、以重大数据同意为交割条件、针对供应商和模型变更的过渡期契约、为权利补救设置的适度托管，以及留任和知识转移里程碑。律师、会计师、安全专家和相关监管机构需就实际交易提供建议。

36. 运行投资委员会决策关口

投资委员会应收到签约状态基线、依赖关系图、漂移情景、权利瀑布、关键人员评估、保护条款清单和有资金保障的整合计划。文件应区分观察到的证据、分析假设、专家意见和未决问题。文件应识别哪些风险敞口被接受、降低、转移或可能导致交易终止。

决策标准可包括估值区间、下行流动性、交割确定性、法律运营边界、客户连续性、整合能力和战略契合度。委员会应了解哪些假设需要在签署前、交割前和控制权转移后验证。

审批应记录条件、责任人和证据。被隐性接受的风险往往会以整合意外的形式重现。有记录的接受有助于问责和后续审查。

委员会还应收到经依赖关系调整的价值桥。该价值桥从独立估值开始，展示客户集中度、供应商敞口、权利补救、关键人员覆盖、韧性投资和延迟协同效应的影响。每项调整都应指向相关尽职调查证据，并说明其是否改变预期现金流、时间安排、流动性或终值持久性。该价值桥有助于审查人员质疑重叠之处，并识别合同保护在何处支持估值结论。

反向压力测试可以识别导致流动性耗尽或突破融资阈值的漂移、客户流失、成本上升和补救延迟组合。该演练是分析性情景而非预测。它显示哪些早期指标最重要，以及哪些缓释措施必须在交割时落实资金。如下行情形取决于若干相关事件，委员会应审查其共同原因，包括单一供应商、数据集、人员或监管分类。

37. 实施首个100天

第一天应确保权限、访问、连续性和事件响应。前三十天应保存证据、核对资产与权利、测试监控、确认客户承诺并开始知识转移。第三十一天至第六十天应完成优先补救、复现重大评估并测试后备方案。第六十一天至第一百天应仅扩展已通过客户、技术、安全和经济门槛的变更。

时间表应适应交易风险。受监管产品、重大数据迁移或供应商替换可能需要更长时间。日历速度绝不应替代验收证据。例外情况应列明临时控制、责任人、截止期限以及由问责高管接受的剩余敞口。

交易保护登记册应与整合里程碑一并审查。托管释放、盈利支付计算、契约和保证可能取决于运营证据。法律和财务团队应与技术工作保持衔接。

38. 为被收购系统维护证据室

买方应维护一个受控证据室，包含架构、模型和数据清单、评估、许可证、合同、同意书、批准、事件、监控、变更记录和客户承诺。访问、留存和法律特权需要精心设计。该证据室应支持运营和保证，而不会成为敏感数据的失控副本。

证据应进行版本管理并与决策关联。尽职调查后编制的模型卡不应覆盖签约状态记录。同意书应链接到其授权的数据集和技术控制。补救测试应明确环境和验收权限。

自动化有助于核对记录并发现缺失链接。人工专家仍负责解释和批准。证据室支持整合、审计、客户尽职调查、融资和未来退出准备。

39. 以有纪律的不确定性分配作结

AI 交易存在经营不确定性，这些不确定性并非总能在签署前消除。严谨的流程会让不确定性显性化，将其与现金流挂钩，明确控制归属，并选择可衡量的应对措施。买方因此获得更经得起检验的估值和整合计划；卖方则获得更清晰的要求以及展示价值的路径。

核心顺序始终一致：复现基线、梳理依赖关系、测试漂移、以证据核实权利、评估人员与义务、建模现金流影响、选择交易保护措施，并保留交割后测试。每一步都应与重要性相称，并由合格专家提供支持。

当运营证据不完整时，董事会应拒绝关于模型具有专有性、准确性或可移植性的简单保证。他们还应拒绝缺乏现金流路径的技术发现。当控制权变更后，法律权利、运营控制、客户结果和有资金支持的经济性仍保持一致时，交易才算成功。

框架应保持适度。小型生产力工具与受监管的决策系统不需要相同的尽职调查。重要性可通过受影响收入、客户损害、监管敞口、替换所需前置时间、现金需求和战略重要性来设定。当多项指标趋同时，团队可加深测试，并记录低风险领域为何只开展有限工作。这种基于风险的方法既能保护决策质量，又能控制尽职调查成本和管理负担。

随着监管、客户采购和技术保障趋于成熟，未来买方应预期证据标准会提高。如果目标公司能够维持可复现的评估、可追溯的权利、受控发布、经测试的回退方案和可转移的知识，就可以减少交易摩擦。这些能力也会改善日常运营。因此，交易准备度在出售流程之前就已开始，依靠治理使系统可理解、可变更并可问责。

参考文献

1. 美国国家标准与技术研究院，人工智能风险管理框架（AI RMF 1.0），2023 年。 https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
2. 美国国家标准与技术研究院，《人工智能风险管理框架：生成式人工智能概况》，2024年。 https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
3. 美国国家标准与技术研究院，AI RMF 操作手册。 https://airc.nist.gov/airmf-resources/playbook/
4. 欧盟委员会，《通用AI提供商义务指南》，2025年。 https://digital-strategy.ec.europa.eu/en/faqs/guidelines-obligations-general-purpose-ai-providers
5. 欧盟委员会，《关于通用AI模型提供者义务范围的指南》，2025年。 https://digital-strategy.ec.europa.eu/en/library/guidelines-scope-obligations-providers-general-purpose-ai-models-under-ai-act
6. 欧盟委员会，《AI法案中的通用AI模型：问答》。 https://digital-strategy.ec.europa.eu/en/faqs/general-purpose-ai-models-ai-act-questions-answers
7. 欧盟委员会，AI法案监管框架。 https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
8. 欧盟委员会，《通用AI行为准则》。 https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai
9. UAE 中央银行，消费者保护与负责任采用和使用人工智能及机器学习的指引说明，2026 年。 https://rulebook.centralbank.ae/en/rulebook/guidance-note-consumer-protection-and-responsible-adoption-and-use-artificial-intelligence
10. 英国国家网络安全中心，《安全AI系统开发指南》，2023年。 https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development
11. 英国竞争与市场管理局，《AI基础模型：更新文件》，2024年。 https://www.gov.uk/government/publications/ai-foundation-models-update-paper
12. 英国竞争与市场管理局，《合并评估指南》，2021年。 https://www.gov.uk/government/publications/merger-assessment-guidelines
13. 美国司法部与联邦贸易委员会，《合并指南》，2023年。 https://www.justice.gov/atr/2023-merger-guidelines
14. 英国信息专员办公室，《AI与数据保护指南》。 https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/
15. 经济合作与发展组织，《经合组织AI原则》。 https://oecd.ai/en/ai-principles
16. 国际标准化组织，《ISO/IEC 42001 人工智能管理体系》。 https://www.iso.org/standard/81230.html
17. 国际标准化组织，ISO/IEC 23894《人工智能风险管理》。 https://www.iso.org/standard/77304.html
18. 国际财务报告准则基金会，《国际财务报告准则第3号——企业合并》。 https://www.ifrs.org/issued-standards/list-of-standards/ifrs-3-business-combinations/
19. 国际财务报告准则基金会，《国际会计准则第36号——资产减值》。 https://www.ifrs.org/issued-standards/list-of-standards/ias-36-impairment-of-assets/
20. 英国收购委员会，《收购守则》。 https://www.thetakeoverpanel.org.uk/the-code/download-code
21. 欧盟网络安全局，面向 AI 的良好网络安全实践多层框架，2023 年。 https://www.enisa.europa.eu/publications/multilayer-framework-for-good-cybersecurity-practices-for-ai
22. 美国网络安全和基础设施安全局，《人工智能路线图》，2023年。 https://www.cisa.gov/resources-tools/resources/roadmap-artificial-intelligence
23. 美国证券交易委员会，《网络安全风险管理、战略、治理与事件披露》，2023年。 https://www.sec.gov/files/rules/final/2023/33-11216.pdf
24. 金融稳定理事会，《人工智能对金融稳定的影响》，2024年。 https://www.fsb.org/2024/11/the-financial-stability-implications-of-artificial-intelligence/
25. 国际清算银行，金融稳定研究所，《金融行业中的AI监管：最新进展与主要挑战》，2024年。 https://www.bis.org/fsi/fsipapers24.htm