AI 供应商替换：重建、重新谈判或退役企业平台

1. 围绕业务服务界定决策

决策应始于平台所支持的业务服务。管理层需要识别用户、客户、决策、工作流、数据、司法管辖区、运营时间以及中断后果。服务基准应记录当前业务量、质量、延迟、可用性、人工审核、单位成本、事件和合同承诺。这为每种备选方案建立了共同的比较基准。

以供应商为中心的问题可能掩盖企业所需的结果。一个平台可能承载多个模型、检索服务、编排工具和工作流组件，而业务仅依赖其中的一部分。反之，一项许可可能看似可替换，但未记录的提示词、数据转换和运营惯例会使所交付的服务难以复现。因此，分析应沿着服务从输入到被接受结果的完整过程展开。

触发因素应被记录在案。相关触发因素包括价格或条款的重大变化、服务恶化、集中度风险、失去战略控制、数据权利不足、监管义务、供应商产品停售、收购、安全事件或更优越的内部能力。触发因素会影响紧迫性和谈判筹码。计划性成本审查允许采取与突然终止不同的行动。

决策标准应在评估备选方案之前获得批准。这些标准可以包括客户连续性、监管合规、安全、绩效、战略控制、时间、现金敞口、运营能力和未来选择权价值。在供应商提案到达后再对这些标准进行加权，可能会偏向某种偏好的叙事。预先商定的基准还能让董事会区分证据与游说。

基准期应反映季节性和增长。工作负载、模型消耗量和支持需求会因报告周期、营销活动或客户群体而异。管理层应保留原始计量数据和调整规则，以免继任方因业务量下降而获得有利评价，或因范围扩大而受到不利评价。当平台支持多项服务时，共享成本和依赖关系应同时按服务以及整个企业层面列示。

决策备忘录还应明确哪些内容仍不在范围内。接管方案可能涉及应用层，而云、数据或身份依赖保持不变。那些保留的风险敞口应保持可见，并明确负责人和未来审查日期。清晰的边界可防止将有限的迁移呈现为完全的战略独立。

2. 明确四种可信的最终状态

当前状态仍是一种备选方案，应如实评估。维持现状可保持连续性、供应商创新、经证实有效的控制措施以及承诺支出的使用。其成本包括预期价格走势、未解决的依赖、集中度以及对战略灵活性的限制。假设合同或技术均无变化的现状情景会低估风险敞口。

重新谈判可改变价格、最低承诺、服务水平、数据权利、审计访问、可移植性支持、模型选择、终止协助和责任分配。当管理层拥有可信的替代方案、完整的依赖记录，并且在续约前有充足时间时，其效果最强。没有结构性变化的折扣可能只是推迟同一决策。

重建可指内部平台、开放架构、新的托管服务或组合。重建这一概念应明确真正重建的内容。替换模型端点但保留原供应商的身份、数据、监控或工作流层，只会形成部分接管。后续方案设计应说明哪些依赖被移除、转移或有意保留。

当所支持的工作流不再创造足够价值、可回归更简单流程或可由另一平台承接时，退役是合适的。退役仍需要记录、数据处置、客户沟通、控制关闭和合同终止。相比为一个薄弱用例资助替代方案，退役可以更有效地释放成本并降低复杂性。

该决策依据服务必要性、表现不佳的证据、可信的替代方案以及过渡可行性。

表1. 四种最终状态的决策关口

每项替代方案均按相同的服务基线和下行情景进行评估。

3. 梳理依赖系统

依赖关系始于技术栈。依赖图应包含模型、嵌入、向量存储、编排、智能体、应用服务、集成中间件、身份、日志、监控、安全工具、云基础设施和开发流水线。每个组件都应列明负责人、版本、接口、位置、吞吐量、服务水平和替换路径。

数据依赖关系需要单独处理。源数据、衍生特征、标签、提示词、检索语料库、评估集、模型输出、日志和反馈可能具有不同的权利和格式。管理层应了解哪些数据可以导出、以何种模式导出、成本多少以及在多长时间内完成。能够下载记录并不能证明接替系统可以解释这些记录。

运营知识往往会造成最被低估的锁定效应。专业人员了解异常模式、未记录的配置、提示词行为、客户特定的变通方法和事件处理惯例。登记表应识别关键人员依赖、供应商管理的流程以及从未转化为企业可控成果物的知识。

商业和法律依赖关系包括承诺支出、抵扣额度、用量层级、捆绑许可、知识产权、保密、数据使用、分包商、终止通知、过渡支持和争议条款。一个平台单独看可能显得昂贵，但在经济上却与更广泛的云或软件承诺相关联。替代方案必须衡量整体捆绑情况。

面向客户的依赖关系应映射到相关陈述和服务承诺。提案、尽职调查答复、合同和运营手册可能提及特定模型、托管地点、认证、数据实践或服务水平。过渡办公室应识别哪些陈述具有约束力、哪些需要通知，以及哪些可以通过常规配置管理进行变更。这项审查可以揭示技术清单中未包含的义务。

依赖关系图应记录证据强度。已确认的合同权利、已完成的可移植性测试和最新运行手册，比员工回忆或供应商演示提供更强的支持。高后果且低置信度的事项应立即成为尽职调查任务。这可以防止视觉上完整的依赖图暗示每条路径都已得到验证。

4. 区分有益的专业化与可避免的锁定效应

专业化可以创造真正的价值。专有模型、托管基础设施、集成控制和供应商专业知识可能提高速度、质量或可靠性。要求每个组件都可移植可能会增加当前成本并减缓创新。相关问题在于专业化的价值是否超过依赖的预期成本和风险。

当切换摩擦并未带来相称的服务价值时，就会产生可避免的锁定效应。示例包括未记录的接口、不必要的专有数据结构、惩罚性数据提取费用、限制性许可、仅由供应商控制的凭据，以及省略过渡支持的合同。竞争主管机构已审查数据出口费、互操作性和许可实践，因为它们可能限制切换和多云使用。

企业应按后果和可逆性衡量依赖关系。即使某个组件有替代方案，如果迁移时间超过组织可承受的范围，它仍可能至关重要。高度专有的组件在非关键且经济上可替代时可能是可接受的。因此，依赖评分应结合关键性、替代所需时间、可移植性证据、技能和合同支持。

架构决策应说明哪些专业化是有意为之。这些选择可以通过模块化边界、自有数据、带版本管理的接口、经测试的导出、在适当情况下的托管以及最新运营文档加以保护。这样既能保留获取供应商创新的渠道，又能保留可信的战略选择。

退出难度由技术、数据、人员、控制措施、合同和客户义务等多方面因素造成。

表 2. 依赖关系登记表

关键性与可逆性分别记录。

5. 在选择前构建证据架构

决策文件应将每项重大主张与来源关联。合同条款应链接至已签署文件。使用情况与性能应与系统记录核对一致。成本应与发票、薪资和分摊规则核对一致。事件、例外情况和客户承诺应链接至经批准的登记册。这为采购、技术、风险和财务建立可复现的基线。

替代方案应使用可比定义进行评估。如果当前平台成本不含内部支持，而重建方案包含完整的运营团队，则该比较存在偏差。如果继任方绩效基于纯净样本衡量，而现有方绩效反映生产复杂性，则结果同样不可靠。证据字典应定义期间、工作负载、质量指标和分摊方法。

未知项应清晰可见。区间值或未解决事项可附带负责人、测试和决策日期录入。将不确定性隐藏在单点估计中，会使提交董事会的论证显得更精确，却降低其实用性。高影响未知项应决定下一项尽职调查活动与资本审批关口。

该证据体系也为谈判提供支持。相比笼统地抱怨成本或锁定问题，供应商更可能解决具体且有证据支撑的问题。完整的基线使企业能够针对可衡量的风险敞口，就价格、权利、服务、可迁移性和过渡支持提出变更要求。

6. 将可迁移性作为一项运营能力进行测试

可迁移性不仅仅需要一项数据导出条款。企业应提取具有代表性的数据集，验证其完整性，将其转换为有文档记录的模式，加载到受控的替代环境中，并复现选定的输出结果。应记录时间安排、人员、缺陷和供应商协助情况。成功的测试可形成关于实际可逆性的证据。

测试样本应包含难以处理的记录。历史格式、多语言内容、客户特定配置、已删除用户相关产物、审计日志、嵌入向量和衍生特征可能暴露出隐藏依赖。组织应界定哪些产物必须为法律、客户、控制和数据分析目的保持可复现。

应用可迁移性应测试接口和工作流行为。等价的 API 语法并不等于等价的服务。模型输出、速率限制、延迟、内容过滤器、上下文管理、可观测性和故障处理都可能改变业务结果。替代方案需要在实际工作流中进行情境化验证。

重大变更后应更新可迁移性证据。新功能、集成、模型版本和数据量可能使先前的测试失效。定期开展此类演练有助于同时提升运营韧性和商业议价能力，因为其使替代方案的成本和时间保持可见。

7. 建立最小可行替代方案

替代方案应保留过渡期间所需的最低限度服务。试图复现现有供应商的每一项功能，可能会在关键路径尚未明确之前扩大范围。管理层应将功能分类为切换上线时必需、上线后不久需要、可选改进以及可考虑淘汰。

最小可行替代方案应包含控制措施。身份、访问、日志记录、数据保护、人工审核、监控、事件响应、记录和客户承诺都是服务的一部分。一个技术上可运行但不具备这些组件的应用只是原型，无法为切换提供可靠依据。

验收测试应在构建或采购之前界定。其应覆盖代表性工作负载、性能、安全性、韧性、数据核对、操作流程、客户义务和成本。阈值可能因用例和风险而异。例外情况应有可问责的验收和有限的整改期。

设计应保留未来选择权。模块化接口、企业控制的数据定义、可迁移的评估集和可观测的成本单元，使模型或提供商能够在不重建完整服务的情况下更换。这种架构有前期成本，应与灵活性预期价值进行比较。

8. 建立过渡关键路径

关键路径始于合同日期。续约窗口、通知期、承诺支出到期、支持义务和终止权决定了可用时间。忽视这些日期的技术计划可能导致资金闲置，或使企业在合同支持结束后仍处于依赖状态。

依赖关系应有序排列。数据提取可能先于转换。身份和安全审批可能先于生产环境访问。验证可能需要稳定的替代方案版本。客户通知可能取决于法律解释和已完成的保证工作。计划应显示每个可能延迟切换的事项的最早和最晚日期。

并行运行既能形成证据，也会产生成本。企业可以比较输出、服务水平、事件和运营投入，同时保留回退能力。并行持续时间应取决于业务关键性、变异性和可逆性。较短的并行期可能遗漏罕见故障模式，而开放式并行期可能保留重复成本和薄弱的问责机制。

切换计划应明确决策权限、指挥结构、回滚、沟通以及切换后监控。仅有一个排定日期并不能形成就绪状态。只有在强制性证据完整或已明确接受剩余风险敞口时，责任高管才应批准切换。

综合排程应纳入资源冲突。同一批工程师、风险专家和业务用户可能同时支持现有运营、继任系统建设、验证和客户工作。若将他们按满负荷分配到每个工作流，就会形成一个数学上完整但无法执行的计划。过渡办公室应模拟可用工时、关键技能、休假、供应商可用性和决策前置时间，然后为现有服务中的事件保留容量。

变更控制应稳定过渡基线。现有供应商新增功能、业务需求和客户配置可能不断改变目标。每项拟议变更都应说明其服务价值、对可移植性的影响、测试以及关键路径日期。强制性的监管或客户变更可以继续推进，而可自由裁量的新增项可在切换后放入继任系统待办事项。

商业、技术和控制工作流在切换前汇合。

表 3. 过渡关键路径控制措施

过渡办公室负责综合计划与源证据。

9. 为全生命周期定价

经济基准应首先包括支付给现有供应商的现金以及运营该服务所需的内部资源。它应包括许可证、使用费、云、支持、实施、集成、保障、事件响应、采购、财务和业务用户时间。共享承诺应透明分摊，并在企业层面列示。

过渡成本包括发现、提取、补救、架构、开发、采购、验证、安全、并行运行、培训、客户保障、终止和切换后稳定化。生产力损失和延迟举措可能具有重大影响，即使未出现在技术预算中。商业论证应说明哪些成本属于现金、已吸收容量还是机会成本。

后继服务的稳态应包括完整的运营模式。内部能力需要产品、工程、数据、安全、风险、支持和供应商管理资源。较低的模型单价可能与更高的集成或保障工作量并存。成本应按工作负载和客户群建模，以便规模效应清晰可见。

无法转移的承诺和残余依赖应保持明确。云积分、最低消费、长期许可证和资本化资产可能在切换后继续存在。后继方也可能通过另一层继续面临同一云、模型或数据提供商的风险敞口。经济比较应基于整个企业的整体状况。

成本区间应反映证据的成熟度。合同费率和当前发票可能支持较窄的区间。数据补救工作量、客户例外和稳定化持续时间在测试完成前可能仍处于较宽区间。模型应展示基准、下行以及严重但可信的情景，并说明驱动每种差异的运营事件。敏感性分析可以识别该决策是否依赖于少数不确定假设。

单位经济性应跟踪公认的业务产出，而不是便利的技术单位。Token、调用或计算成本可以是有用的运营指标，而客户和业务领导者可能看重已完成事项、已批准决策或已解决例外。将两个层面连接起来可以揭示技术效率是否转化为服务价值，以及后继方是否改变人工审核或故障成本。

10. 对现金、会计和融资影响进行建模

董事会应按月或按季度查看现金时点。过渡支出通常先于节省出现，并行运营会造成暂时峰值。合同通知、终止付款、承诺支出和供应商付款条件可能使该峰值移动。正的长期净现值并不能证明组织能够安全地为过渡提供资金。

会计处理需要根据企业政策和适用准则由合格人员进行审查。配置、定制、内部开发、终止、减值和合同修改成本可能具有不同的确认模式。决策模型应将运营经济性与会计结论分开呈现，以免一方掩盖另一方。

融资能力可能受到收益、现金转换、契约和贷款人同意的影响。降低未来运行率成本的过渡仍可能压低近期现金和报告指标。财务部门应将已批准计划与流动性余量和下行触发条件联系起来。

效益应分类。合同节省、避免的价格上涨、释放的容量、降低的风险和战略选择权价值具有不同的证据强度。商业论证应避免将所有效益都呈现为现金。每项效益都需要负责人、基线、衡量方法和实现日期。

假设性指数值显示过渡成本和残余成本如何抵消较低的后继方费用。

11. 通过谈判改变结构

谈判应处理依赖登记册和成本登记册所显示的风险敞口。价格仍然重要，同时还要关注最低承诺、上量曲线、抵扣、续约上限、服务水平、可移植性、支持、审计、数据权利、模型选择、次级处理商、安全、变更控制、终止协助和责任。目标是达成一项经济性和可逆性与该服务相匹配的安排。

议价筹码来自可信的准备。经过测试的数据导出、合格的替代方案、已批准的预算和已知的决策时间表，比无依据的退出威胁更有力。企业应了解其最佳替代方案、转换成本、退出条件以及可用来交换的条件。

让步应按全生命周期进行估值。临时抵扣的价值可能低于更低的经常性承诺或更强的终止权。捆绑折扣可能增加对另一项服务的依赖。每项提案都应录入用于替代方案情形的同一模型。

最终协议应转化为运营控制措施。数据导出权需要有责任人和测试频率。服务水平需要有数据和救济措施。可移植性承诺需要明确格式、时间、成本和协助。只有当企业能够行使相关权利时，谈判价值才得以实现。

基准比较应比较商业实质。公开目录价、经销商报价和同行个案可能未涵盖工作负载形态、支持、数据传输、预留容量、实施和风险分配。采购方应按已批准的需求画像对提案进行归一化，并说明每项调整的置信度。较低的可比价格可以增强谈判地位，而不可靠的基准可能削弱可信度。

治理还应防止碎片化谈判。业务部门可能分别同意单独的试点、抵扣或功能，从而增加总承诺并使退出复杂化。统一的供应商立场应核对每份合同、预测工作负载和战略需求。本地需求可在协调一致的企业委托范围内保持可见。

12. 为可执行的退出设计合同

合同登记册应识别通知日期、终止事件、过渡期时长、协助范围、费率、知识转移、数据返还、删除、格式、次级处理商、知识产权、审计和持续服务。相关权利可能分散在主协议、订单、产品条款和在线政策中。已签署协议的层级关系应清晰明确。

退出支持应明确交付物和时间安排。泛泛的合作表述可能在人员、数据、文档、接口、测试和客户义务方面留下不确定性。企业应界定证明完成所需的证据以及未决事项的处理流程。

变更权在合同期内很重要。模型替换、产品停用、数据使用变更、修订后的限额和新次级处理商，都可能在续约前改变服务。通知、批准、测试和终止条款应与变更的关键程度相匹配。

法律解释取决于事实、司法辖区和合同语言。过渡办公室应在需要时获取专业意见，并将已批准立场转化为日期、行动和依赖关系。商业模型应使用这些已批准的事实，而不是关于可执行性的假设。

13. 保护数据权利和数据血缘

数据清单应区分企业、客户、许可、公开、供应商生成和派生信息。在训练、检索、评估、支持、监控和产品改进方面，权利可能不同。接替计划需要为其预期使用的每一类数据提供合法且合同允许的路径。

数据血缘应连接来源、转换、模型、输出和已接受的业务决策。如果标识符、时间戳、版本或审计日志丢失，迁移可能中断这一链条。对账应测试数量、控制总数、样本和异常总体，并在需要时测试重现重大历史结果的能力。

删除应得到证明。现有供应商可能在生成环境、备份、日志、支持系统和次级处理商中持有数据。企业应识别合同和监管要求，获取适当证据，并保存处置决定的记录。

继任系统的数据设计应减少不必要的依赖。由企业控制的模式、目录、保留规则和评估集可提升可移植性和治理水平。它们还有助于管理层判断，所感知到的模型优势究竟是由专有企业数据或工作流知识创造的。

14. 重新验证模型和业务成果

模型替换会改变交付的系统。准确性、校准、弃答、延迟、安全行为、内容过滤、上下文限制、可解释性和成本都可能不同。验证应使用经批准的使用场景、具有代表性的人群和故障模式，而不是通用基准。

比较对象应包含现有生产服务，并在相关情况下包含当前的人工或基于规则的流程。继任系统即使优于实验室基准，仍可能不如客户实际获得的服务。测试设计应说明阈值、置信度、排除项和运行控制。

业务验收不同于技术性能。用户需要完成工作流、理解例外情况并信任证据。过渡期间，除模型指标外，还应衡量周期时间、审查投入、人工覆盖、缺陷、客户成果和运营事件。

验证证据应进行版本管理。模型、提示词、检索语料库、工具、工作流规则和人工审查政策都可能改变结果。切换审批应明确已测试的配置以及触发重新验证的条件。

15. 保障软件供应链安全

软件采购应审查供应商治理、开发实践、依赖项、漏洞管理、部署假设和事件处理。官方的安全采购指南鼓励客户利用采购问题和合同标准来评估供应商实践。同样的纪律适用于内部构建或由开源组件组装而成的继任系统。

物料清单应包含模型、库、容器、API、数据服务和重要分包商。应记录所有权、版本、来源、许可证、漏洞和更新路径。内部重建可能扩大企业对先前由供应商管理的组件的责任。

威胁建模应覆盖变更后的架构。相关风险包括数据泄露、提示词注入、不安全的工具使用、受感染的依赖项、过度权限、模型操纵、服务拒绝和日志丢失。控制措施应在部署配置中接受测试。

安全验收应设定强制性条件、明确责任签署和切换后监控计划。暂缓问题应可见，并附有风险遏制措施和日期。进度压力不应将未知的关键暴露转化为默示批准。

16. 保持运营韧性

企业仍对依赖第三方的重要服务承担责任。服务映射应将 AI 平台连接到人员、流程、技术、设施、信息和下游提供商。影响容忍度和客户后果应为过渡设计提供依据。

退出计划应切合实际、可行，并与合同时间安排保持一致。金融服务监管指南强调技术计划、替代安排、所需技能、成本、数据传输和测试。这些原则为受监管公司之外的组织提供了有用的管理标准。

业务连续性和长期退出具有不同作用。连续性安排可通过回退、人工操作或容量储备来维持短期中断期间的运营。退出计划则确立可行的持久状态。若不重新评估风险和经济性，临时变通方案无法支撑无限期运营。

演练应测试可能的故障模式，包括现有供应商突然中断、导出数据损坏、继任方不稳定、关键人员缺位和回滚。结果应更新时间估计、资源计划和客户沟通安排。演练证据比未经测试的文档更有说服力。

韧性分析应涵盖合同供应商以下的集中度。若干看似可替代的方案可能依赖同一云区域、模型提供商、身份服务、开源库或专业支持公司。转型可能改变商业关系，却保留共同的故障点。架构和供应商记录应识别这些共享依赖，并定义适当的多元化或应急安排。

人工回退方案值得进行经济和运营测试。有文档记录的流程仍可能在生产规模下失败、需要无法获得的专业能力或造成不可接受的延迟。演练应衡量可持续吞吐量、错误、控制证据和员工福祉。由此得出的能力上限可用于确定影响容忍度和回退方案可支持的最长期间。

17. 管理人员和知识转移

能力计划应确定设计、运营、控制和改进继任方所需的角色。应区分永久运营能力与临时迁移专家。招聘假设需要提前期、成本和可用性证据。

知识转移应围绕交付物和已演示的任务来组织。运行手册、架构决策、数据字典、提示词、测试、事件记录和客户配置应由企业统一管控。没有可用文档和观察到的执行情况的研讨会难以形成有效连续性。

应衡量关键人员风险敞口。计划应说明谁可以执行关键任务、谁可以批准变更以及人员缺位时如何处理。结对、轮岗和演练可以检验知识是否已转移。

激励需要关注。现有供应商员工、内部平台团队和业务用户可能有不同利益。治理应界定决策、证据和冲突升级。沟通应解释服务目标、时间安排和角色期望，但不得对结果作出无依据的声明。

18. 划分客户与义务

客户可能有不同的合同、数据位置、安全条件、验收标准和对变更的容忍度。单一切换可能造成可避免的风险。过渡办公室应对客户进行划分，确定哪些可以一起迁移、哪些需要同意或保证、哪些需要单独计划。

销售期间作出的承诺应与已部署配置核对一致。模型提供商、数据处理、服务水平、认证、审计权利和指定功能可能反映在协议或尽职调查答复中。继任方应履行这些承诺，或遵循经批准的变更路径。

客户沟通应准确，并按合同和运营需要安排时点。沟通可以说明连续性、相关变更、所需行动和支持。技术细节应与客户影响和已商定的披露程度相称。

应保留验收证据。可包括已完成的测试、核对后的数据、客户批准、成功交易或约定观察期届满。未决例外应在客户被视为完成迁移前明确负责人和处理措施。

19. 治理过渡办公室

过渡办公室应整合商业、技术、数据、安全、风险、法律、财务、运营和客户工作流。它负责总体计划、决策日志、依赖登记册、证据索引、预算和问题升级。各工作流报告应使用相同的日期和定义。

决策权应当明确。技术负责人在其权限范围内批准发布。控制负责人评估安全、数据和运营敞口。财务负责经济基线和流动性。商务负责人管理供应商和客户方面的头寸。责任高管批准资本关口和切换。

每周治理应重点关注关键路径进展、新增依赖、未解决的强制性证据、成本和服务指标。已完成任务数量庞大，可能掩盖某一项会阻碍安全过渡的事项。报告应显示每个关口的预测日期范围和证据质量。

独立质疑可以检验假设、架构、合同解释、验证和就绪情况。发现的问题应由适当授权主体解决或接受。鉴证工作应尽早安排，以便能够改变计划。

20. 通过证据关口释放资金

探索阶段资金应确立服务基线、依赖关系图、备选方案、合同地位和初步经济性。在管理层明确是否存在可信过渡之前，应保持资金有界。这可以防止战略偏好演变成无边界的技术项目。

设计阶段资金应产出目标架构、运营模式、验收测试、过渡计划和更新后的成本范围。当关键权利、资源和接口得到充分理解后，再进入建设阶段资金。切换阶段资金则在强制性证据完成且下行方案获批后提供。

每个关口都应说明面临风险的资本、学习目标、交付物、责任人和停止条件。沉没成本不应决定下一项决策。后继方案不经济的证据可支持重新谈判或退出，并且仍能创造价值。

应急资金应与已指明的具体不确定性挂钩。一般性储备可能掩盖规划薄弱。示例包括数据修复、供应商协助、延长并行运行、客户特定工作和额外安全处理。释放资金应要求提供相关不确定性已发生的证据。

21. 衡量风险价值

风险价值应将运营事件与财务和客户后果联系起来。相关情景包括服务中断、数据丢失、性能恶化、控制失效、客户违约、切换延迟、搁浅支出和无法招聘。模型应识别敞口持续时间和缓解措施。

概率估计可能不确定。董事会仍可利用情景严重性、可逆性和证据质量来确定行动优先级。低频但客户后果不可容忍的事件，即使预期价值经济性看似有利，也可能需要强制性控制。

风险降低不应被重复计算。过渡可能降低供应商集中度，同时增加内部执行、安全或关键人员风险。矩阵应在相同类别下比较当前、过渡和后续状态。

风险偏好应转化为具体条件。示例包括可容忍的最长中断时间、数据对账阈值、未解决的严重漏洞、客户例外情况和流动性缓冲。这些条件使切换决策可观察。

矩阵应记录风险速度和检测情况。成本超支可能在数月内逐渐显现，从而允许采取纠正措施。数据或安全事件可能在管理层获得完整信息之前立即造成客户和监管后果。变化更快的风险需要更早的指标、预先授权的遏制措施和更短的升级路径。

风险归属应遵循控制责任，而不是组织便利。技术部门可以运营平台，而业务高管负责服务结果，财务负责流动性，控制职能负责既定审批。综合登记册应显示每项应对措施的单一责任所有人以及执行所需的贡献者。剩余敞口的接受应由有能力承受其后果的授权主体承担。

示例分数显示，风险敞口在各类别之间迁移，而非消失。

表4：风险价值矩阵与控制应对

在概率不确定时，严重性、可逆性和证据质量指导行动。

22. 设定切换和回滚条件

切换条件应涵盖服务、数据、性能、安全、控制措施、人员、客户、合同和流动性。强制性条件仍采用二元判断。其他指标可采用阈值和观察期。较高的平均得分不应抵消未解决的关键漏洞或未核对的客户数据。

回滚应能在规定期限内技术上和商业上可行。计划应明确数据同步方法、权限、触发条件、沟通方式和最长决策时间。无法接收更新记录的现有环境在切换后可能不再是可行的回退方案。

切换指挥结构应提供单一事实来源。问题、决策、系统状态和客户沟通都应记录在案。专业团队需要清晰的升级路径和针对常见场景的预先批准响应。

切换后稳定期应监控服务、缺陷、例外覆盖、成本、支持需求、客户成果和剩余任务。退出稳定期需要证据证明承接方在批准范围内运营。在运营责任归属确立之前关闭项目可能留下隐性风险。

23. 构建董事会记分卡

记分卡应呈现服务成果、依赖关系、经济性、过渡就绪度、风险、客户状态和所需决策。指标需要定义、来源、周期、负责人和阈值。趋势和例外信息比静态红绿灯汇总更有用。

经济视图应核对批准预算、已承诺现金、完工预测、当前运行率、承接方运行率和已实现收益。它应区分现金、会计和产能影响。差异说明应识别范围、数量、费率、缺陷或时间安排是否发生变化。

就绪度应体现证据质量。一项任务可以被标记为完成，而其产出仍未经过测试。记分卡应区分已起草、已审核、已测试和已验收的交付物。强制性证据应链接至源记录。

董事会决策记录应说明选定的最终状态、已考虑的备选方案、假设、剩余风险敞口、授权资本和下一阶段关口。这有助于保护机构记忆，并支持后续审查预期价值是否实现。

领先指标应显示过渡可信度是在上升还是下降。示例包括最近一次成功导出距今时长、已记录的关键接口百分比、验收测试通过率、未解决的强制性控制、数据异常、已培训岗位覆盖率、客户批准、预测现金峰值和回滚持续时间。已实现节省和服务事件等滞后指标在切换后仍然重要。同时使用两类指标可为董事会提供预警，而不会在证据尚不存在时呈现就绪状态。

记分卡应保留失败测试和修订后的假设。删除被取代的结果可能使项目显得更整洁，却会削弱审计轨迹。受控历史记录显示管理层学到了什么、范围或时间安排为何变化，以及先前关切是否已解决。它还支持外部尽职调查，无需审阅者从电子邮件和演示文稿中重建决策。

表5. 董事会决策与就绪度记分卡

强制性条件可防止进度报告掩盖关键缺口。

24. 进行一次带演算过程的假设性比较

设想一家企业使用 AI 平台进行文档分类、检索和初步案件准备。该服务支持多个业务单元，并已与现有云服务、身份服务、数据存储和监控工具相连接。管理层担心即将到来的续约、使用成本上升以及模型选择有限。

假设当前年度成本指数为 100。替换平台看似可节省 32 的费用。前期调研识别出假设性过渡成本：构建与迁移 18、并行运行 12、保障与培训 9，以及首个比较期内无法转移的承诺 7。由此得出的成本指数在未进行任何风险调整前为 114。这些数值是分析性假设，不代表已观察到的企业。

依赖性测试还发现，客户特定的工作流规则和评估集记录不完善。直接替换将带来重大服务风险。管理层资助一个有边界的证据阶段，以重建工作流、测试数据导出并验证两个替代模型。这项工作提升了替代迁移方案与谈判的可信度。

随后现有供应商提供更低的最低承诺、模型可移植性、出资支持的迁移协助以及明确的数据导出服务水平。企业将这种结构性重新谈判与分阶段重建进行比较。它选择一项为期两年的模块化计划，包含立即的合同改进和保留的选择权。该示例表明，决策应依据证据和全生命周期经济性，而不是名义许可价格。

25. 运营决策后的价值管理办公室

选定的最终状态需要运营责任归属。重新谈判的合同要求对服务、支出和可移植性进行控制。重建需要产品管理、架构、安全、支持和供应商治理。退役需要确认成本、数据、访问权限和客户义务均已结清。

价值管理办公室应核对预期结果与实际结果。衡量指标包括已支付现金、单位成本、服务质量、事件、支持投入、释放的时间、客户成果、可移植性测试和选择权使用情况。收益应始终与原始基线挂钩，并针对数量或范围变化进行透明调整。

应监控剩余依赖关系。新供应商、开源组件和内部专家可能形成不同的集中度。在重大架构、合同或运营变化后，应更新登记册。年度可移植性或退出演练可使战略选择保持可信。

经验教训应更新采购标准。反复出现的问题可转化为对数据模式、接口文档、模型替换、审计、终止协助、可观测性和知识转移的要求。随后，组织可降低其整体资产组合中未来平台决策的成本。

26. 将框架转化为交易尽职调查

AI 供应商依赖会影响收购、剥离、拆分、融资和估值。尽职调查应识别收入、运营或知识产权是否依赖于目标公司并不控制的平台。买方需要合同、架构、数据权利、成本、技能、可移植性证据和客户承诺。

在分拆交易中，卖方的企业协议、身份标识、数据服务或人员可能无法转移。过渡服务协议应明确范围、期限、定价、安全、数据和退出里程碑。独立运营模式应包含替换共享能力的完整成本。

盈利质量分析应检验供应商返点、临时折扣、供应商承担的实施投入或资本化成本是否影响报告利润率。续约或使用量上调可能改变未来经济效益。该分析应将平台使用量与客户收入和工作负载联系起来。

交易文件和估值结论需要合格顾问和具体案例事实。该框架为这些决策提供证据结构。它帮助管理层将有价值的专有能力与那种经济性和连续性依赖第三方的企业服务区分开来。

27. 建立企业供应商替换手册

该手册应包含服务基线模板、依赖登记册、可移植性测试、合同检查清单、全生命周期成本模型、过渡计划、验收标准、切换规程和董事会记分卡。每个模板应明确负责人、证据来源、生效日期和审批。

该手册应包含紧急事件的分级处置路径。供应商故障、安全事件、制裁问题或产品立即下架可能剥夺常规尽职调查所需的时间。预定义的遏制、数据保全、法律升级、客户沟通和紧急采购步骤有助于企业在决定长期最终状态期间保护服务。紧急路径仍应保留决策日志和明确的剩余风险接受。

该流程应与关键性相称。低风险生产力工具可能只需简短的数据和访问关闭流程。支持客户决策、受监管活动或关键运营的平台则需要更深入的证据、测试和治理。比例原则改变深度，但保留核心问题。

采购与架构团队可在首次采购前应用该手册。预先设计数据权利、接口、可观测性、模型选择、过渡支持和运营知识，可降低未来供应商替换成本。合同续约成为经常性的战略选项审查，而非行政事务。

最终决策应回答：该服务是否仍有必要；当前安排是否创造可接受的价值；结构性重新谈判能否解决重大风险敞口；接替方能否在获批条件下运营；以及企业能否在下行情景下为过渡提供资金。围绕这些问题的证据支持有纪律的保留、重新谈判、重建或退出决策。

结论

AI 供应商替换是一项企业服务决策。技术、数据、控制、合同、人员、客户和现金必须作为一个集成运营系统整体迁移。当迁移、保障、业务中断、搁浅承诺和剩余依赖仍被排除在比较之外时，较低的平台价格无法确立价值。

该框架从经过衡量的服务基线和完整依赖关系图开始。它测试实际可移植性，定义最小可行接替方，整合商务和技术日期，评估全生命周期价值，并通过证据关口释放过渡资金。切换以已认可的服务、数据、控制、客户和运营证据为依据。

由此形成的纪律也会改善现有供应商关系。可信替代方案和具体风险敞口登记册可支持结构性重新谈判。当用例无法证明其复杂性合理时，仍可选择退出。当战略控制和生命周期价值超过有资金支持的过渡风险时，重建变得合适。董事会为每条路径保留证据、假设和剩余敞口的清晰记录。

参考文献

1. 英国竞争与市场管理局。云服务市场调查。 https://www.gov.uk/cma-cases/cloud-services-market-investigation
2. 英国竞争与市场管理局。CMA宣布针对商业软件和云服务的一揽子行动。 https://www.gov.uk/government/news/cma-announces-package-of-actions-on-business-software-and-cloud-services
3. 欧盟委员会。《数据法案》解读。 https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained
4. 欧盟。法规 (EU) 2023/2854，关于数据公平获取和使用的统一规则。 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32023R2854
5. 欧盟委员会。数据处理服务互操作性研究结果。 https://digital-strategy.ec.europa.eu/en/library/results-study-interoperability-data-processing-services
6. 美国国家标准与技术研究院。人工智能风险管理框架。 https://www.nist.gov/itl/ai-risk-management-framework
7. 美国国家标准与技术研究院。 AI 风险管理框架 1.0。 https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
8. 美国国家标准与技术研究院。生成式人工智能概况。 https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
9. 美国国家标准与技术研究院。网络安全供应链风险管理尽职调查快速启动指南。 https://csrc.nist.gov/pubs/sp/1326/final
10. 美国国家标准与技术研究院。安全、隐私与网络安全供应链风险管理计划。 https://www.nist.gov/news-events/news/2026/06/security-privacy-and-c-scrm-risk-management-plans-nist-releases-sp-800-18r2
11. 美国网络安全和基础设施安全局。面向政府企业用户的软件采购指南。 https://www.cisa.gov/sites/default/files/2024-07/PDM24050%20Software%20Acquisition%20Guide%20for%20Government%20Enterprise%20ConsumersV2_508c.pdf
12. 美国网络安全和基础设施安全局。面向中小企业的供应商供应链风险管理实施模板。 https://www.cisa.gov/resources-tools/resources/operationalizing-vendor-scrm-template-smbs
13. 美国网络安全和基础设施安全局。面向客户的推荐实践指南。 https://www.cisa.gov/news-events/alerts/2022/11/17/cisa-nsa-and-odni-release-guidance-customers-securing-software-supply-chain
14. 英国金融行为监管局。外包与运营韧性。 https://www.fca.org.uk/firms/outsourcing-and-operational-resilience
15. 英国金融行为监管局。面向企业的运营韧性洞察与观察。 https://www.fca.org.uk/firms/operational-resilience/insights-observations
16. 英国金融行为监管局。CTPS 4 运营风险与韧性要求。 https://handbook.fca.org.uk/handbook/ctps4
17. 欧洲中央银行。关于将云服务外包给云服务提供商的指南。 https://www.bankingsupervision.europa.eu/ecb/pub/pdf/ssm.supervisory_guides202507.en.pdf
18. 欧洲银行管理局。外包安排指南。 https://www.eba.europa.eu/publications-and-media/press-releases/eba-publishes-revised-guidelines-outsourcing-arrangements
19. 欧盟。法规 (EU) 2022/2554，关于金融部门的数字运营韧性。 https://eur-lex.europa.eu/eli/reg/2022/2554/oj
20. 英国国家网络安全中心。《安全 AI 系统开发指南》。 https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development
21. 阿联酋中央银行。《关于消费者保护及负责任采用和使用人工智能与机器学习的指导说明》。 https://rulebook.centralbank.ae/en/rulebook/guidance-note-consumer-protection-and-responsible-adoption-and-use-artificial-intelligence
22. 迪拜金融服务管理局。2025 年 AI 调查。 https://www.dfsa.ae/news/new-dfsa-ai-survey-generative-ai-adoption-has-nearly-tripled-within-difc-last-12-months-governance-continues-develop
23. 经济合作与发展组织。经合组织 AI 原则。 https://oecd.ai/en/ai-principles
24. 国际标准化组织。ISO/IEC 42001 人工智能管理体系。 https://www.iso.org/standard/81230.html
25. 英国审慎监管局。监管声明 SS2/21 外包与第三方风险管理。 https://www.bankofengland.co.uk/prudential-regulation/publication/2021/march/outsourcing-and-third-party-risk-management-ss