The model service is inexpensive in the prototype. Then three consumers arrive, each needing different evidence rights, response time, review, controls and fallback. The invoice stays modest while the capability obligation becomes substantial.

The first workflow needs identity resolution and a strict latency commitment. The second needs approved evidence assembly with human exception operations. The third needs outcome evaluation and long-lived audit records. A common model endpoint does not make them a common economic unit. Their differences create integration, testing, support, security, control and requalification work.

An AI capability is a socio-technical asset that remains useful, trustworthy, supportable and replaceable across several consuming decisions or workflows. Its cost boundary runs from discovery through data rights, build, integration, evaluation, change, live operation, incident response, vendor or model replacement and decommissioning. Metered inference belongs inside that boundary, but it does not define it.

The economic problem is not to list every cost anyone can imagine. It is to choose a defensible boundary, classify obligations, connect them to causal drivers and show how they move with demand, heterogeneity, risk and time. An unowned shared cost makes reuse look cheaper than it is. An arbitrary corporate allocation makes a useful marginal reuse look more expensive than it is.

The original construct is a capability cost constitution. It names the capability and consumer decision populations; lifecycle stages and exclusions; direct, shared, step-fixed, committed, contingent and exit classes; causal drivers and allocation policy; service, quality, risk and support commitments; change and requalification triggers; dependencies and replacement rights; owners for forecast, allocation, optimisation and retirement; uncertainty and expiry.

01 · Capability boundarySeparate the shared asset from each operating route

A task route prices an attempt, accepted result or verified outcome in one workflow. A capability boundary answers a different question: what reusable asset must the enterprise discover, create, govern, operate, change and eventually replace so several task routes can depend on it?

The constitution begins with a service statement. It names what the capability provides, the decision populations allowed to consume it, the quality and availability commitments, the authority it does not hold and the conditions under which it abstains or falls back. This prevents a technical component from being treated as a universal platform merely because it can answer several requests.

Every consumer declares its service tier, data class, evaluation burden, support window, incident severity, retention, change tolerance and human operating dependency. Consumers that need incompatible latency, evidence, jurisdiction or control may require separate capability instances or even separate architectures. Forced reuse can cost more than duplication when heterogeneity dominates.

The lifecycle boundary also states exclusions. A corporate identity service may be outside the capability total but still appear as a dependency and allocated charge. Product-specific process redesign may sit in the consuming route. Historical discovery investment may be sunk for a forward scale decision. Exclusion does not mean invisibility; it means the economic owner and decision treatment are explicit.

Sculley and colleagues warned that rapid machine-learning gains can incur system-level technical debt through feedback, entanglement and boundary erosion.12 Production testing, monitoring and data management are continuing obligations, not optional finishing work.34

The strong rival: full TCO can become slow theatre

A comprehensive cost model can delay discovery, invite political bargaining and create decimal precision on weak assumptions. This objection is valid. The response is progressive cost resolution, not a universal template that demands the same detail at every stage.

During discovery, expose material classes, dominant unknowns, irreversible commitments and exit blockers. Before build, measure the costs most likely to change architecture or scope. Before live scale, establish causal drivers, service tiers, requalification rules and owner cadence. As commitments harden, attribution fidelity increases. The standard is decision usefulness, not completeness for its own sake.

Complementary investment can precede measurable benefit,5 and organisational transformation influences technology economics.6 Neither observation excuses an unbounded ledger. Each unknown has an owner, decision leverage, evidence plan and expiry.

02 · Causal allocationCharge consumers for the burdens they cause or the commitments they require

Direct cost traces to one consumer: a dedicated connector, jurisdictional assessment, workflow evaluation or support team. Shared cost supports several consumers: common data curation, control testing, observability, platform operations or incident readiness. Step-fixed cost appears when capacity, staffing or assurance crosses a threshold. Committed cost persists for a contract or retained capability even when volume falls.

Contingent cost depends on uncertain events such as severe incidents, regulatory change, model withdrawal or an unexpected requalification. Exit cost covers migration, parallel running, data and record retention, customer remediation, supplier termination and decommissioning. These classes behave differently under scale, reuse and retirement decisions.

Allocation follows observable cost drivers. Request volume may drive some inference and infrastructure expense. Data domains and jurisdictions drive rights and preparation. Service level drives redundancy and on-call cover. Risk tier and consequence drive evaluation, control and incident burden. Consumer-specific change frequency drives requalification. Human exception volume drives operating capacity. No single denominator represents them all.

FinOps guidance treats allocation as an accountability capability with shared-cost strategy and metadata, not merely a billing export.910 The constitution records the selected driver, why it is causal enough for the decision and how frequently actuals are reconciled.

03 · Cost behaviourBraid obligations that respond differently to a decision

The constitution keeps cost classes separate because each answers a different counterfactual. Direct cost asks what one consumer causes. Shared cost asks what joint service exists because several consumers benefit. Committed cost asks what remains after demand or scope falls. Contingent cost asks what exposure exists if a named event occurs. Exit cost asks what must be paid or performed to stop safely.

Accounting allocation distributes enterprise cost for reporting or accountability. Causal marginal cost estimates the additional obligation created by a decision. Forward avoidable cost estimates what a specific scale, pause or exit choice can change from today. All can be legitimate, but none is a substitute for the others.

A new low-risk consumer may add modest forward cost when capacity, controls and data domains already exist. Charging it an equal share of historical discovery and platform investment can reject beneficial reuse. A high-risk consumer may produce little request volume but require new assurance, on-call support, record retention and fallback. Charging only by requests quietly subsidises it.

Sunk cost remains in the enterprise history but does not become an avoidable future cost merely to make past investment look recoverable. A non-cancellable contract is committed for its term even if its usage charge is low. A renewal decision changes that status. The ledger preserves dates and contractual thresholds so finance can see when the decision set changes.

Cheap API illusion

A prototype multiplies requests by a public unit price and reports a low run cost. Yet production requires lawful data preparation, access control, connector maintenance, outcome evaluation, security and privacy review, user support, exception handling, monitoring, incident response and a vendor-change path. The API price is not wrong; the capability boundary is incomplete.

This control prevents Paper 024's inference economics from becoming the whole story. Tokens, caching, model routing and serving architecture matter as a driver. They belong beside the obligations that allow the service to be used safely and repeatedly. Optimising metered spend while human exceptions or requalification dominate is local efficiency, not capability optimisation.

Shared-platform subsidy and over-allocation

A central team may pay for platform engineering, evaluation tooling, governance, on-call cover and incidents while consumers report only their direct usage. The capability appears cheap and adoption appears profitable because cost sits elsewhere. The constitution makes the enterprise total and consumer drivers visible even if finance chooses not to transfer every charge.

The opposite failure assigns every corporate AI programme cost to the first small consumer. Historical research, enterprise training and unused platform options swamp the consumer's forward decision. The control separates sunk and shared obligations from incremental reuse. Allocation is for transparency and accountability; it should not manufacture a marginal cost.

04 · Demand and uncertaintyForecast steps, service burdens and ranges rather than smooth averages

Demand affects cost through more than volume. Peaks can require reserved capacity or fallback. New jurisdictions can trigger legal and data work. A higher consequence tier can require stronger evaluation and human cover. More diverse workflows create connector, support and change burden even when aggregate requests stay flat.

A forecast therefore combines a volume range, variability pattern, consumer mix and service tier. Step costs appear when the capability needs another on-call rotation, dedicated instance, control review, data steward or evaluation cohort. Average unit cost can fall before a step and rise abruptly after it. A smooth straight-line forecast conceals the actual commitment decision.

Uncertainty is not a generic contingency percentage. The register names the uncertain driver, range, evidence source, trigger, owner and decision leverage. Dominant unknowns may include exception rate, data remediation, vendor price or feature change, incident frequency, policy change and requalification effort. Scenario ranges remain separate until evidence justifies a distribution.

OECD work on firm adoption identifies integration, retooling, data, skills, compliance and return uncertainty as practical conditions of adoption.7 Evidence from Italian financial markets highlights deployment, data, integration, vendor, continuity, skills and governance considerations within that surveyed sector.8 These sources support cost-class completeness, not a universal cost percentage.

05 · Worked counter-caseOne governed evidence capability, three bounded workflows

A regulated-finance organisation develops a governed evidence capability. It resolves authorised entities, retrieves approved records with lineage and evaluates evidence completeness. Three workflows consume it: identity verification, investigation case assembly and control-outcome evaluation. The capability has a common data access layer, retrieval controls, evaluation harness, monitoring and incident process.

The consumers do not receive equal service. Identity verification needs a tighter response-time and continuity tier. Case assembly drives more data-domain and human-exception work. Outcome evaluation needs long retention, versioned cohorts and requalification after policy changes. Each declares its decision population, boundaries, support window, consequence tier and fallback.

Direct connectors and workflow evaluations remain with their consumers. Common data curation, platform observability and base control testing are shared. Redundancy and on-call cover allocate by service tier. Requalification allocates by the consumer-specific change that triggers it. Human exception operations allocate by observed case type and review burden, not request count.

The enterprise total shows the full capability obligation. The allocation view shows which consumers cause or benefit from the shared services. The forward scale view asks what changes if the case-assembly population doubles, if a new jurisdiction joins or if identity verification exits. Historical discovery and already committed contracts remain visible without automatically becoming incremental scale cost.

This counter-case supports reuse because the constitution can explain both common and heterogeneous obligations. If a new consumer requires incompatible evidence rights or continuity, the scale decision includes the architecture split. If one consumer exits, the forward avoidable view identifies which cost actually disappears and which common commitment persists.

06 · Dependency and exitReplacement rights are part of today's cost

A capability cannot be called supportable if the organisation cannot change a vendor, model, data source, specialist team or control design without unknown disruption. Exit is not a distant procurement clause. It determines present bargaining power, continuity, change cost and the feasibility of retiring a weak asset.

Map every critical dependency to an owner, substitution path, evidence needed for requalification, data portability, interface boundary, record-retention duty, parallel-run requirement and maximum tolerated interruption. A contractual right without usable artefacts, skills or test coverage is not operational replaceability.

Retained human expertise is a dependency. If automation erodes the ability to review exceptions, operate fallback or validate a replacement, apparent labour efficiency creates an exit liability. The constitution prices exercises, training, documentation and staffing needed to preserve the fallback appropriate to consequence.

NIST's AI RMF Core includes inventory, ownership, monitoring, incident handling, superseding and deactivation across the lifecycle.11 Its broader framework treats risk as contextual and continuing.12 ISO/IEC 42001 similarly frames objectives, resources, monitoring and improvement as management-system responsibilities.13 These sources support ownership and lifecycle discipline; the constitution remains this paper's economic synthesis.

Teece's account of complementary assets helps explain why technical access alone does not determine who captures value or bears cost.14 Data rights, distribution, specialised operations, controls and organisational skills can be essential complements. They also become dependencies that a replacement plan must address.

07 · Decision viewsUse the cost answer that matches the counterfactual

Enterprise total asks what the organisation bears to keep the defined capability available across all consumers over the chosen period. It supports portfolio accountability, sourcing and architecture decisions. It includes shared and contingent obligations even when no transfer charge reaches a product ledger.

Average allocated cost distributes some or all of that total according to the constitution. It supports consumer accountability, showback, chargeback and comparative operating review. It is not automatically the cost caused by the next unit or consumer. A transparent allocation can still be irrelevant to a forward decision.

Forward marginal cost asks what additional obligations a proposed scale or reuse action creates from today. Forward avoidable cost asks what obligations a pause, contraction or exit can remove, and when. The two can differ because step thresholds, retained skills, notice periods and common commitments make cost asymmetric.

A scale proposal should display all three views side by side. The enterprise view prevents hidden subsidies. The allocation view makes shared accountability explicit. The forward view prevents sunk or arbitrary cost from distorting the actual choice. Differences between the views are an explanation, not an error to average away.

Write allocation policy before the bill arrives

The allocation clause states whether a cost follows cause, benefit, capacity reservation or an agreed accountability policy. It also names what remains centrally funded. Cause is appropriate when a consumer produces observable work, such as dedicated data remediation, exception operations or a service-tier step. Benefit can support genuinely common foundations whose use cannot be traced without disproportionate effort. Reserved capacity may suit a consumer that requires continuity even when its realised volume is low.

These policies carry different incentives. Chargeback based only on realised use can encourage consumers to avoid necessary testing or understate reserved service. Equal division can make a small low-risk consumer subsidise a demanding one. Central funding can accelerate initial reuse but conceal whether the capability has durable demand. The constitution records the behavioural purpose as well as the calculation.

Showback can precede chargeback. During early adoption, finance may display driver-based shares without transferring budget, allowing teams to challenge the boundary and improve metadata. Transfer begins only when drivers are stable enough for accountability. Even then, a product ledger should display direct cost, shared allocation and forward decision cost separately so managers do not mistake a transfer price for an avoidable obligation.

Unused capacity needs a policy owner. If the enterprise reserves capability for resilience, expected growth or a strategic option, that choice should not quietly inflate the apparent inefficiency of current consumers. Conversely, labelling all idle capacity strategic can protect an oversized platform indefinitely. State the sponsor, exercise condition, review date and release decision.

Onboarding a consumer changes the constitution. The platform owner checks data domains, rights, tier, consequence, fallback, evaluation and requalification. Finance identifies incremental steps and the allocation driver. The consumer owner accepts the service and support contract. If the consumer cannot fit a tier without weakening an existing commitment, the decision is architecture redesign, not a more creative allocation formula.

At reconciliation, compare forecast and actual cost by driver, not only by account. A model invoice variance may be caused by request mix, while a support variance may reflect exception severity and a requalification variance may reflect policy churn. Each explanation updates the next forecast and can change the allocation rule. Stable rules support trust; rules that ignore persistent causal evidence create political cross-subsidy.

The constitution also specifies disputes and materiality. Not every small shared item warrants a complex causal model. A simple rule can be defensible when the amount is immaterial to the decision and no consumer's behaviour is distorted. Complexity increases where cost, consequence or commitment changes the choice. This is progressive resolution applied to allocation itself.

08 · Decision instrumentCapability TCO Boundary Test

The test examines whether the cost constitution is fit for the current decision. It does not produce a currency total. Complete it with product, platform, finance, risk and operating owners. Use one named capability and list its consumer decision populations. A technical service with no bounded consumers is not yet an allocatable capability.

Boundary incomplete means at least one material lifecycle class or consumer boundary is absent. The next task is boundary repair, not arithmetic. Discovery estimate only accepts coarse ranges while the decision remains reversible, provided dominant unknowns and exit blockers are visible.

Scale decision cost view means the forward marginal and avoidable obligations are adequate for a named scale choice even if enterprise allocation is not mature. Shared capability allocation ready means causal drivers, tiers, actuals and enterprise reconciliation can support multi-consumer accountability. Neither result implies that benefits exceed cost; the instrument tests cost fitness.

Redesign or exit the capability applies where forced reuse combines incompatible commitments, demand can trigger uncontrolled obligations, a critical dependency has no feasible replacement or a live capability has no owner. Additional allocation precision cannot cure a structurally unsafe or uneconomic boundary.

09 · Operating cadenceForecast, reconcile, optimise, requalify and retire

At discovery, approve the capability name, consumers, lifecycle boundary, material classes and uncertainty register. The product owner states the useful service; platform and risk owners state the commitments it creates; finance identifies the decision counterfactual. Avoid allocation debates where a rough range cannot yet change the decision.

Before build commitment, test dominant drivers and exit feasibility. Establish cost tags and operating evidence at the same time as technical interfaces. A future allocation cannot reconstruct missing service tier, data domain, exception, change and incident metadata reliably from an invoice total.

Before scale, forecast demand ranges and step triggers, price consumer tiers, cost requalification and distinguish enterprise, allocated and forward views. Reconcile actuals by driver at a cadence matched to volatility. Review the largest forecast errors and the assumptions most likely to reverse the decision.

Optimisation targets the dominant causal driver while preserving service and control. It may reduce exception burden through workflow redesign, narrow incompatible consumer scope, retire an unused service tier, renegotiate a commitment or invest in replaceability. Unit inference efficiency is one option, not the default objective.

At every material vendor, model, data, policy, population or control change, requalify the affected consumers rather than the abstract capability alone. Allocate the burden according to the trigger. At retirement, fund parallel running, records, remediation, migration and decommissioning before declaring savings. The cost ends when the obligation ends, not when requests stop.

10 · ConclusionTotal cost is a constitution, not a bigger invoice

The total cost of an AI capability is the obligation to keep a shared socio-technical asset useful, trustworthy, supportable and replaceable across its consumers. Model consumption is visible and variable. Data, integration, evaluation, controls, support, human operations, change, incidents, requalification and exit often determine the harder economics.

A capability cost constitution makes those obligations governable. It fixes the boundary, classes, drivers, tiers, triggers, dependencies, owners, uncertainty and expiry. It prevents the cheap API illusion and the central-platform subsidy without forcing a small consumer to repay every historical programme expense.

The disciplined finance view keeps enterprise total, average allocation and forward marginal or avoidable cost separate. That separation allows fairer accountability, better scale choices and credible exit. Cost precision increases when commitment demands it; visible uncertainty remains more honest than an exhaustive ledger built on arbitrary allocation.

Evidence spineReferences

1. Sculley, D. et al. (2014), ‘Machine Learning: The High Interest Credit Card of Technical Debt’, Google Research. Google Research publication.
2. Sculley, D. et al. (2015), ‘Hidden Technical Debt in Machine Learning Systems’, Google Research. Google Research publication.
3. Breck, E. et al. (2017), ‘The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction’, Google Research. Google Research publication.
4. Polyzotis, N. et al. (2018), ‘Data Lifecycle Challenges in Production Machine Learning: A Survey’, ACM SIGMOD Record, 47(2), 17–28. doi:10.1145/3299887.3299891.
5. Brynjolfsson, E., Rock, D. and Syverson, C. (2021), ‘The Productivity J-Curve: How Intangibles Complement General Purpose Technologies’, American Economic Journal: Macroeconomics, 13(1), 333–372. doi:10.1257/mac.20180386.
6. Brynjolfsson, E. and Hitt, L. M. (2000), ‘Beyond Computation: Information Technology, Organizational Transformation and Business Performance’, Journal of Economic Perspectives, 14(4), 23–48. doi:10.1257/jep.14.4.23.
7. OECD (2025), ‘The Adoption of Artificial Intelligence in Firms’, OECD Artificial Intelligence Papers. doi:10.1787/f9ef33c3-en.
8. OECD (2026), ‘Artificial Intelligence in Italian Financial Markets’, OECD Publishing. doi:10.1787/6f42c977-en.
9. FinOps Foundation, ‘FinOps for AI’. FinOps technology category.
10. FinOps Foundation, ‘Allocation Capability’. FinOps Framework allocation capability.
11. National Institute of Standards and Technology (2023), ‘AI Risk Management Framework: Core’. NIST AI RMF Core.
12. Tabassi, E. (2023), Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1. doi:10.6028/NIST.AI.100-1.
13. International Organization for Standardization (2023), ‘ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system’. ISO/IEC 42001 overview.
14. Teece, D. J. (1986), ‘Profiting from Technological Innovation: Implications for Integration, Collaboration, Licensing and Public Policy’, Research Policy, 15(6), 285–305. doi:10.1016/0048-7333(86)90027-2.