AI 组合爆炸：250 个用例，25 个上线

ModelOp 于 2026 年 3 月 11 日发布《2026 年 AI 治理基准报告：AI 组合爆炸——当活跃造成价值的错觉》，基于对 100 位高级 AI、数据与技术负责人的全球调查（ModelOp，2026 年 3 月 11 日）。报告的核心发现可以用两个数字概括：67% 的企业目前报告有 101 至 250 个待建 AI 用例，而 94% 的企业上线运行的不足 25 个。ModelOp 把这种状态命名为「AI 价值错觉」——活动被误当成影响力。对工程组织而言，这份报告真正有价值的地方在于：它把治理从合规议题变成了交付效率议题。

几百个想法的清单，不是几百个已交付的系统

一、组合规模与交付产出之间的裂缝

报告的另一组数据同样值得放在一起看：三分之二的企业仍缺少自动化的 ROI 度量手段，依赖人工统计或预测性指标；多数企业把 AI 系统接入近 20 个外部工具与服务（ModelOp，2026 年 3 月 11 日）。这三件事在因果上是连着的：用例数量快速增长、交付节奏被压缩到以月计，而度量方式仍然停留在表格与预测阶段，于是「上线了多少」取代了「产生了什么」。ModelOp 首席执行官 Dave Trier 的说法很直接：业务部门可能打出了一垒安打，而领导层期待的是全垒打。把交付周期压缩到「月」确实是一种进步，但瓶颈也随之向下游转移：当用例能在一个季度内上线，真正限制价值的就变成了有多少系统能被持续运营、留下证据、并在合适的时候退役——这是与「再多跑一个试点」完全不同性质的工作。

-- portfolio_reality.sql - proposed vs in production, by business unit
SELECT business_unit,
       COUNT(*) FILTER (WHERE stage = 'proposed')                AS proposed,
       COUNT(*) FILTER (WHERE stage = 'in_production')           AS in_production,
       COUNT(*) FILTER (WHERE stage = 'retired')                 AS retired,
       ROUND(100.0 * COUNT(*) FILTER (WHERE stage = 'in_production')
             / NULLIF(COUNT(*) FILTER (WHERE stage = 'proposed'), 0), 1)
                                                                 AS conversion_pct
FROM ai_use_cases
GROUP BY 1
ORDER BY proposed DESC;

-- ModelOp's 2026 benchmark: 67% of enterprises report 101-250 proposed use
-- cases, while 94% have fewer than 25 in production. Report the conversion
-- rate, not the pipeline size.

手工统计的 ROI 是预测值，不是观测值

二、为什么「用人工统计 ROI」等于没有 ROI

预测性指标与观测性指标的区别，是这份报告里最实用的一条工程含义。预测型 ROI 通常在立项时写下一个假设的节省金额，然后在季度汇报时重复引用；观测型 ROI 则要求系统在运行中真的发出事件——自动审批了多少张发票、有多少工单在无人介入下关闭、多少条合同条款被标出——并把事件与系统 ID 绑定。前者的成本几乎为零，因此会一直存在；后者需要一次性的埋点投入，但它能在系统上线后持续回答「值不值」。工程团队应该主动承担后者，因为这既是最可靠的产出证明，也是撤下线时的唯一依据。顺带还有一层好处：一旦开始发出事件，用来证明价值的那路信号同时就是价值中断时的回滚触发器。

# outcomes.py - instrument the outcome, never the projection
OUTCOME_EVENTS = {
    "invoice_auto_approved":   {"unit": "usd", "annual_baseline": 4_200_000},
    "ticket_resolved_no_touch": {"unit": "count", "annual_baseline": 61_000},
    "contract_clause_flagged": {"unit": "count", "annual_baseline": 9_400},
}

def emit_outcome(system_id, event, value, measured_at, evidence_ref):
    assert event in OUTCOME_EVENTS, "declare the outcome before you launch"
    return {
        "system_id": system_id,
        "event": event,
        "value": value,
        "measured_at": measured_at,
        "evidence_ref": evidence_ref,      # link to the system that produced it
    }

# Two-thirds of leaders in the benchmark still measure AI ROI manually or
# with projected figures. An emitted event is observed value; a forecast is
# not. Declare the event before launch or you will project forever.

每个 AI 系统接 20 个外部服务，就是 20 个新的故障域

三、近 20 个外部依赖意味着什么

当每个 AI 系统平均接入近 20 个外部服务时，治理问题会从模型层转移到供应链层：每一个外部服务都是一条数据流出路径、一个可用性依赖、以及一份可能不属于 IT 部门管理的续约合同。报告明确指出，Agentic AI 正在扩大这种第三方暴露面。可操作的起点是把依赖清单自动化：按类别（模型 API、向量库、数仓、SaaS 连接器、身份提供方）归类，标出未分类项与缺乏数据处理协议的项（代码示例 3）。这份清单的第一版通常会让所有人吃惊，而它只需要解析现有的配置文件。一个有用的纪律是：在引入每个依赖时就为它指定负责人与已知失效模式，因为在事故中事后补齐这些信息，正是治理成本最高的时候。

# dependency_inventory.py - count the external surface per AI system
CLASSES = ("model_api", "vector_store", "data_warehouse", "saas_connector", "idp")

def surface(system):
    deps = system["external_services"]
    unclassified = [d for d in deps if d.get("class") not in CLASSES]
    return {
        "count": len(deps),
        "classes": sorted({d["class"] for d in deps if d.get("class")}),
        "unclassified": unclassified,
        "no_dpa": [d["name"] for d in deps if not d.get("agreement_on_file")],
    }

# The benchmark found most enterprises connecting AI systems to nearly 20
# external tools and services. Each one is a data-flow disclosure, an
# availability dependency, and a line in a renewal you may not own.

四、从分散试验到工业化交付

报告的结论部分给出了方向：企业 AI 已进入新阶段，快速试验不再是竞争优势，成功的组织正在从分散试验转向工业化交付——把治理嵌入工作流，把 AI 当作受管理的组合来运营。这个区别在运营上是可量化的：工业化交付看的是有多少个准入最终变成在运营的系统，而不是漏斗里进过多少个想法。工程上这意味着两件具体的事。第一，每个上线系统必须有负责人与复核日期，否则它就不算被管理（代码示例 4）。第二，治理不应以 PDF 形式存在，而应以流水线形式存在：准入、设计、预生产、运营四个阶段的检查项都应当是代码里的门禁，任何一项缺失就暂停流转（代码示例 5）。这套东西的价值恰恰在于它无聊——无聊的制度才会在下一个季度仍然被执行。

# lifecycle.py - every live AI system needs an owner and a review date
from datetime import date

MAX_DAYS = 365

def audit(systems):
    flags = []
    for s in systems:
        if s["stage"] != "in_production":
            continue
        if not s.get("owner"):
            flags.append({"id": s["id"], "issue": "no owner"})
        if not s.get("next_review"):
            flags.append({"id": s["id"], "issue": "no review date"})
        elif (s["next_review"] - date.today()).days > MAX_DAYS:
            flags.append({"id": s["id"], "issue": "review too far out"})
    return flags

# Portfolios fail quietly. A system with no owner and no review date is not
# managed, no matter which dashboard it appears on.

五、把组合数字变成可交付的转化率

报告里真正可被行动的度量是转化率，而不是管道规模。建议工程团队每月只报四个数字：各业务单元的「待建 → 上线」转化率（代码示例 1）、每个上线系统的观测型产出事件（代码示例 2）、每个系统的外部依赖数量与未分类项（代码示例 3）、以及缺少负责人或复核日期的系统数量（代码示例 4）。这四个数字合起来，就是「工业化交付」在数据上的定义。它们都不需要新采购，只需要把已经存在的信息结构化。复盘节奏建议按月而不是按年——报告的证据本身就说明，组合的变化速度超过了年度周期能观察到的粒度。而一旦这四个数字开始变化，组合爆炸就会从恐惧变成可管理的路线问题。

# gates.py - governance as a pipeline, not a PDF
GATES = (
    ("intake",     lambda c: c["business_outcome"] and c["outcome_event"]),
    ("design",     lambda c: c["data_classification"] and c["dependency_inventory"]),
    ("pre_prod",   lambda c: c["eval_set"] and c["human_oversight"] and c["rollback"]),
    ("operate",    lambda c: c["owner"] and c["next_review"] and c["evidence_uri"]),
)

def advance(use_case):
    blocked = [name for name, check in GATES if not check(use_case)]
    return {"stage": "advance" if not blocked else "hold", "blocked_by": blocked}

# ModelOp's conclusion is that the next phase is industrialized delivery:
# governance embedded in the workflow and AI run as a managed portfolio.
# Gates in code are the only version of that which stays true next quarter.