AI 风险用户指南（第五部分）：信任即产品

让我强调一下本系列这些文章迄今为止所传达的核心信息：用一句话来说，我认为它比我在这些文章中讨论过的每一个框架、每一个数字和每一种运营模式都更重要。信任就是产品。快速构建，同时治理得当——是同时，而非先后。

为什么我抗拒“先构建，后治理”的本能

技术组织中存在一种根深蒂固的本能——包括我曾工作过的许多组织——将治理视为在证明技术可行之后才发生的事情。构建原型，让客户接触，证明价值，然后，一旦商业案例得到验证，再引入治理和合规职能，将已经构建的东西正式化。在我的职业生涯中，我目睹这一顺序在多次技术浪潮中上演，我完全理解为什么它感觉高效——它将成本和摩擦推迟到你确信这项投资值得捍卫之时。

但我认为，这一顺序对AI系统而言尤其危险，原因我在过去几篇文章中一直试图论证：AI系统的风险面不是你在发布时一次性支付的固定成本。它是一种复利负债，在系统于生产环境中无治理运行的每一天都在累积。‘先构建，后治理’的每一天，都是累积风险敞口的一天，无论是声誉、监管还是运营方面的，你是在推迟它，而不是避免它。

同时，而非先后，是一种真正不同的运营模式

我特意选择‘同时，而非先后’，因为我认为这不仅仅是一种思维方式的转变。它是一种实际的运营模式变革。关于这个主题的每一篇博文都在论证：将治理编织进技术构建过程本身，而不是将其视为一个最终会赶上的并行工作流。

这正是我思考自己构建自主DevOps和SRE代理工作的方式。一个采取真实基础设施行动的代理系统，必须在其初始架构中就构建治理工具——日志记录、人工监督检查点、回滚机制——而不是事后改造。试图在代理已经在做生产决策之后再添加治理层，比从第一行代码就构建它要困难得多，也危险得多。

试图在代理已经在做生产决策之后再添加治理层，比从第一行代码就构建它要困难得多，也危险得多。

为什么信任才是真正的产品，而不是产品的一个功能

这是我想留给你的更深层观点。在一个AI赋能的企业中，技术本身——模型、代理、框架——很少能长期成为你竞争差异化的东西。能力扩散得很快；你今天能构建的东西，大多数竞争对手在一个月内就能构建出来，有时甚至几天内。而不那么容易扩散、一旦失去就需要更长时间重建的，是你的客户、监管机构和你自己的员工对你的AI系统受到负责任治理这一事实所抱有的信任。

这种信任正是让你能够以产生真正商业价值的节奏和规模实际部署 AI 的关键。一个被客户和监管机构信任、拥有真正监督机制的组织，可以更快地推进新的 AI 能力，而不是更慢，因为它不会永远处于一次事件就会被迫暂停或招致监管干预的边缘。治理如果做得好，并不是对速度的阻碍。它是可持续速度的前提条件。

治理如果做得好，并不是对速度的阻碍。它是可持续速度的前提条件。

建立信任，正当其时。

在大多数企业中，仍然缺失的并不是知道该做什么。而是真正去做必要的治理实施工作的组织意愿——从现在开始，在下一场事件迫使这个问题浮出水面之前。如果让我请你们从这一系列文章中带走一件事，那就是：不要等到那场让治理变得紧迫的事件发生。说明 AI 风险的数据就在那里：那些事件、幻觉率、罚款、企业已经承受的声誉损害。它已经证明了这一点。剩下的唯一问题是，你是在明年你的组织出现在那个数据集中之前采取行动，还是在那之后。

创始人兼负责人 - Data Capital Labs，前 Dell、Truist、IBM 员工，著有：The DevOps Adoption Playbook 和 DevOps For Dummies（IBM Edition）。AI、云、DevSecOps、颠覆性技术。 查看 Sanjeev Sharma 的所有文章