Almost every large organisation now uses AI somewhere. Far fewer run it as a production system with an owner, a budget line and an operating model. In McKinsey's 2025 survey, 88 percent of respondents report regular AI use in at least one business function, yet only about a third say their companies have begun scaling AI programmes. On agents the gap is wider: 23 percent report scaling an agentic system somewhere in the enterprise, and in any single function no more than 10 percent do.
This article sets out a strategy for closing that gap in 2026. It covers what to standardise, what to keep flexible, and a question most pilot programmes defer until it becomes urgent: where the inference capacity for production will come from.
Why pilots stall
Pilots are designed to answer "can this work?" Production has to answer different questions: what does it cost per unit of business output, who is accountable when it fails, which jurisdictions does the data pass through, and what happens when the model vendor changes its terms.
Gartner predicted in June 2025 that more than 40 percent of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. Each of those three is an operating-model problem rather than a model-quality problem.
The takeaway: a production strategy is mostly about unit economics, accountability and supply, not about picking the best model.
The economics moved under your feet
The cost of a given level of capability has fallen fast. The 2025 AI Index reports that the inference cost for a system performing at GPT-3.5 level fell more than 280-fold between November 2022 and October 2024, that hardware costs have declined about 30 percent a year while energy efficiency improved about 40 percent a year, and that open-weight models narrowed their benchmark gap with closed models to 1.7 percent.
Two consequences follow for strategy:
- Lock-in costs more than it used to. When the price of a capability halves repeatedly, a multi-year commitment to one supplier at one price is a bet against the market.
- Smaller and open models are now real options. Many production tasks (classification, extraction, routing, embedding, transcription) are well served by small models that run on modest hardware, with a large model kept for the hard cases.
The takeaway: design for substitution. The model you start with is unlikely to be the one you run in two years.
A five-part production framework
1. Portfolio, not projects. Inventory use cases by business value and by workload shape: interactive (latency-bound), batch (throughput-bound), agentic (multi-step, tool-calling, spends money), and physical (devices and sensors). Each shape has a different cost curve and different hardware needs.
2. A model ladder per workload. For each use case, define the cheapest step that can handle the easy majority of requests and the escalation path for the rest. Measure the escalation rate; it is the single biggest driver of cost.
3. One interface, many suppliers. Put an OpenAI-compatible or similarly standard interface between applications and models, so that switching a model or a supplier is a configuration change. Keep evaluation sets per use case so a switch is tested, not assumed.
4. Accountability in the record. Every production call should leave a record of who or what called it, under whose authority, which model and version served it, where it ran and what it cost. Without that record, audit, chargeback and incident response are reconstruction exercises.
5. Capacity as a sourced input. Treat inference capacity the way procurement treats energy or logistics: several sources, a policy for which work goes where, and the ability to shift load.
Where inference capacity comes from
Enterprises in 2026 have four broad sources. Most will use more than one.
| Source | Strengths | Watch for |
|---|---|---|
| Closed-model APIs | Frontier capability, no operations | Per-token pricing you do not control, data-processing terms, regional availability |
| Hyperscale cloud (managed or self-run) | Elastic, mature tooling | Committed-spend lock-in, GPU availability by region, egress fees |
| Own hardware (on-premises or colocation) | Control, data stays in place, predictable cost at high utilisation | Capital outlay, utilisation risk, staffing |
| Open networks of independent providers | Many suppliers behind one interface, price competition, regional choice | Verifying who served the request, quality and availability guarantees |
The right mix depends on the workload portfolio. Steady, high-volume, latency-tolerant work favours owned or rented capacity at high utilisation. Spiky and experimental work favours pay-per-use. Regulated work favours whatever source can prove where it ran and on what.
Regional differences that change the plan
- EU. The AI Act's obligations phase in over 2025 to 2027, and GDPR governs personal data in prompts and outputs. Placement and logging decisions should be made with both in view.
- UK. A principles-based, regulator-led approach means sector regulators (financial services, health) set much of the practical bar.
- US. Federal guidance and state laws vary; sector regulators and procurement rules drive most requirements.
- APAC. Singapore, Japan, Korea and Australia publish governance frameworks and guidance; data-localisation rules differ widely across the region.
- MENA. Gulf states are building national AI capacity and data-residency expectations alongside it.
The common thread: being able to choose, and prove, where work ran is becoming a requirement rather than a preference.
What this means for CTOs and decision makers
- Move the conversation from "which model" to "which unit cost, which accountability record, which supply mix".
- Fund the shared layer (interface, evaluation, logging, routing) once, so every new use case reuses it.
- Write capacity policy now: which workloads may leave the building, which must stay in a jurisdiction, and which need hardware-attested execution.
- Set an exit plan for every supplier before you sign.
Where Tenzro fits
Tenzro is an open network for the machine economy: machines of every size, from edge devices to data-centre GPUs, sell AI work to agents, apps and people under one identity model and one payment rail. For an enterprise strategy it is one of the capacity sources in the table above, reached like any other model API.
Built today:
- An OpenAI-compatible chat endpoint (
/v1/chat/completions, plus the Responses shape), so applications can add the network as a supplier without rewriting. - Provider discovery that reports each provider's coarse region and declared jurisdiction, and per-request price quotes across every provider serving a model.
- Routing by price, latency, standing or a weighted score, with tail-latency hedging and failover.
- Signed receipts on locally served answers that name the model hash, the serving machine's hardware identity and the billed units.
- Owned, funded agent wallets that can never spend more than their owner put in, and can be paused or reclaimed.
Planned: a harness host role so edge devices can run the cheap rungs of a model ladder and call GPU providers for the rest.
The network is live in preview. The steps to testnet and mainnet are decided by on-chain governance on measured evidence, not on a fixed date. Read more at tenzro.com.
