先比较职责，再比较产品

比较相同结果

原型工具的选择，不必决定生产运行模式。员工可以使用适合工作的工具探索。组织仍需要受支持的方式，保障有用成果的安全、部署、维护和运行。

编程助手、内部平台和软件工厂可以解决问题的不同部分。未定义范围就比较订阅价格，可能导致误导性决策。

从所需结果开始：按照公司的数据、安全和可靠性要求，交付并运行内部服务。再识别整个生命周期所需工作，包括首次成功演示之后的工作。

对于虚构合同服务，组织需要获批要求、员工访问、私密记录、经过验证的发布、事件响应和持续更新。生成端点的工具只解决其中一部分。

描述三种可行运行模式

使用编程助手时，开发者在现有工程系统中使用 AI。组织提供周边流程、集成、平台能力和证据收集。这可能适合共享服务已经成熟的组织。

采用内部组装的交付系统时，组织自行集成智能体、上下文、检查、部署和运行反馈。组织能控制设计，同时也负责集成产品、支持和升级。

采购软件工厂时，供应商提供范围更广、相互连接的工作流。应验证实际范围和受支持集成。组织仍需要作出产品决策，并明确职责划分。

这些是比较模型，不是通用产品类别。具体供应商或内部平台可能以不同方式组合能力。

验证从原型到运行服务的路径

对每个选项使用相同具体场景。对于银行应用原型，从合成交易开始，不授予真实系统权限。扩大访问前，要求团队或供应商展示这些能力：

1. 评估原型，识别需要修改或替换的代码。
2. 部署到所需基础设施，包括策略要求时使用组织自己的云账户。
3. 验证应用权限、秘密信息处理，以及开发和运行时数据流。
4. 根据适用要求提供证据，并记录发布决定。
5. 监控服务、修复漏洞、测试恢复并响应事件。

将代码迁入自己的账户，只是其中一部分。验证谁可以管理环境，以及数据会被哪些外部服务、在哪些位置接收。让控制措施与义务相匹配；单凭部署位置不能证明合规。

如果要查看一家供应商声明的边界，可以将 Taiga 共同责任说明与职责图比较。这是本站发布者拥有的材料。启用 Taiga 前，验证适用协议和配置。

区分执行、检查与决策

为每项活动记录执行方、结果验证方，以及接受后果的一方。同一方可以承担多个角色，但角色无人承担就构成缺口。

云服务也会在提供方与客户之间划分责任，具体取决于服务。因此应要求精确职责图，而不是假设所有托管产品都有相同边界。参见 AWS 共同责任。

查找缺口与重复工作

假设供应商生成了一条流水线，而平台团队已经维护获准的部署路径。决定供应商是否应使用该路径。两条独立维护的流水线，可能带来冲突控制和不必要成本。

反过来，供应商可能假设客户已有事件团队，而客户以为服务包含运维。在用户开始依赖服务前，解决这个缺口。

CNCF 的平台指南允许组织组合内部和托管能力。关键是最终体验能否在责任明确的前提下满足用户需要。参见 CNCF 指南。

将职责图用于商业决策

把职责图附在评估记录中，并在适用协议中明确。为仍由组织承担的工作估算成本，包括维护组件之间连接的成本。

范围更广的供应商，如果能减少集成工作并在生命周期中保留证据，就可能有价值。如果独特要求值得组织持续承担责任，内部方案也可能有价值。根据所需结果和已验证范围作决定。