The AI Portfolio Explosion: 250 Use Cases, 25 in Production

ModelOp published its 2026 AI Governance Benchmark Report, subtitled The AI Portfolio Explosion - When Activity Creates the Illusion of AI Value, on March 11, 2026, based on a global survey of 100 senior AI, data, and technology leaders (ModelOp, March 11, 2026). Two numbers carry the finding. Sixty-seven percent of enterprises now report 101 to 250 proposed AI use cases, while 94 percent report fewer than 25 in production. ModelOp calls the resulting condition the AI value illusion: activity mistaken for impact. For engineering organizations, the report's real contribution is that it moves governance out of the compliance column and into delivery efficiency.

A portfolio of hundreds of ideas is not a portfolio of delivered systems

1. The Gap Between Portfolio Size and Delivered Output

Two more findings belong beside those numbers. Two-thirds of enterprises still lack automated methods to measure AI ROI, relying on manual or projected metrics, and most enterprises are connecting AI systems to nearly 20 external tools and services (ModelOp, March 11, 2026). The three facts are causally linked: use-case counts grow fast, delivery timelines compress to months, and measurement stays in spreadsheets and forecasts, so how much shipped displaces what it produced. Dave Trier, ModelOp's CEO, puts it plainly: business units may hit a few singles when leadership is looking for a home run. Compressing delivery timelines is a real improvement, but it moves the bottleneck downstream. Once a use case can reach production in months, the constraint on value becomes how many can be operated, evidenced, and eventually retired, which is a different kind of work from shipping one more pilot.

-- 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 measured manually is ROI projected, not ROI observed

2. Why Measuring ROI by Hand Means Measuring Nothing

The distinction between projected and observed metrics is the most practical engineering idea in the report. Projected ROI writes a hypothetical saving at intake and repeats it in quarterly reviews. Observed ROI requires the running system to emit real events - invoices auto-approved, tickets closed without human touch, contract clauses flagged - each bound to a system identifier. The first costs nothing and therefore persists indefinitely; the second needs a one-time instrumentation investment and then answers the worth-it question continuously. Engineering teams should volunteer for the second, because it is both the strongest evidence of output and the only defensible basis for switching a system off. There is a second-order benefit too: once events are emitted, the same signal that proves value doubles as a rollback trigger for when the value stops.

# 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.

Twenty external services per AI system is twenty new failure domains

3. What Nearly 20 External Dependencies Actually Mean

When each AI system connects to roughly 20 external services, the governance problem migrates from the model layer to the supply chain. Every external service is a data-flow disclosure, an availability dependency, and potentially a renewal contract that sits outside IT's ownership. The report specifically notes that agentic AI is expanding this third-party exposure. The practical starting point is to automate the inventory: classify dependencies by type - model API, vector store, data warehouse, SaaS connector, identity provider - and surface anything unclassified or lacking a data-processing agreement on file (example 3). The first version of that list usually surprises everyone, and it can be produced by parsing configuration files you already have. A useful discipline is to assign each dependency an owner and a known failure mode at the moment it is added, because retrofitting that information during an incident is when governance gets expensive.

# 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.

4. From Decentralized Experimentation to Industrialized Delivery

The report's conclusion sets a direction: enterprise AI has entered a new phase, rapid experimentation is no longer the competitive advantage, and successful organizations are shifting to industrialized AI delivery - governance embedded directly in workflows, AI operated as a managed portfolio. Two concrete things follow. The distinction is measurable in operations: industrialized delivery is judged by how many intakes become operated systems, not by how many ideas entered the funnel. First, every production system needs an owner and a review date, or it is not managed at all (example 4). Second, governance should not live in a PDF but in a pipeline: intake, design, pre-production, and operate gates expressed as code, where any missing item blocks progress (example 5). The value of that apparatus is precisely that it is boring - boring mechanisms are the ones still being executed next quarter.

# 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.

5. Turn Portfolio Numbers Into a Conversion Rate

The actionable measure in this report is conversion, not pipeline size. Report four numbers monthly: the proposed-to-production conversion rate by business unit (example 1), observed outcome events per live system (example 2), external dependency count and unclassified items per system (example 3), and the count of systems missing an owner or review date (example 4). Together those four numbers are what industrialized delivery looks like in data. None of them requires new procurement; each requires only structuring information you already have. Set the cadence monthly rather than annually - the report's own evidence is that portfolios change faster than an annual cycle can observe. Once those numbers start moving, the portfolio explosion stops being a source of anxiety and becomes a routing problem you can manage.

# 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.