An on-premises AI platform gets funded as a project and lives as a utility. The capital case is made once — GPUs, storage, network, the platform team — and then, somewhere around the third or fourth production workflow, a second business unit starts using it. That is the moment the finance question changes shape. It stops being “what does this cost?” and becomes “whose budget does this come out of?”
Most organisations answer that question late, informally, and badly. The platform stays parked on the IT budget, consumption grows without any signal attached to it, and by the time the next hardware refresh needs approval, nobody can say which parts of the business actually created the demand. The CIO is asking for more capacity on behalf of value that appeared on someone else’s P&L.
Cost allocation is not an accounting formality here. It is the mechanism that keeps a shared platform fundable.
Why the cloud instinct does not transfer
The reflex is to copy public cloud AI billing: meter the tokens, multiply by a rate, send it to the consuming team. It feels rigorous because it is precise.
It is also wrong for owned infrastructure, for a simple reason. On a cloud API there genuinely is a marginal cost per token — you pay it to a vendor. On your own hardware, the marginal cost of one more request on an already-running GPU is close to nothing. What you actually bought is capacity over time: a fixed number of accelerator-hours per month, whether or not anyone uses them.
Allocating a fixed cost with a variable meter creates two predictable distortions. In a quiet month the unit rate has to rise to recover the same fixed cost, so a team that did not change its behaviour receives a larger bill and concludes the platform is unpredictable. And because every request now carries a visible price, teams start rationing the usage that produces the highest returns — the long document analyses, the multi-step agent runs — while cheap low-value chat traffic continues unchecked.
The economics of an on-prem platform are closer to a datacentre than an API. This is the same distinction that separates flat capacity licensing from token-based pricing at the vendor boundary; it applies just as strongly inside the organisation.
Four cost pools, and how each behaves
Before choosing a unit of account, separate the spend into pools that behave differently. Any allocation model that treats these as one number will misprice somebody.
Capacity. Accelerators, host servers, the power and cooling envelope, and the amortisation schedule against them. Fixed, lumpy, purchased ahead of demand. This pool dominates the total cost of an on-premise AI platform and it is the one least suited to consumption-based allocation.
Storage and index footprint. Document corpora, vector indexes, embeddings, logs and audit trails. Semi-fixed, grows monotonically, and — unlike compute — genuinely attributable to a tenant, because a department’s corpus is a department’s corpus. This is the easiest pool to charge accurately.
Platform operations. The team running the thing: model lifecycle, upgrades, evaluation, incident response, access reviews. A true shared service, and the pool most organisations forget to allocate at all — which is why the platform team’s headcount keeps getting questioned.
Integration and onboarding. The one-off cost of connecting a system or validating a use case. Attributable to the requesting unit almost by definition, and best treated as project spend rather than run-rate.
Pools two and four allocate cleanly. Pools one and three are the argument.
Choosing the unit of account
Whatever unit you pick becomes the thing teams optimise. Choose accordingly.
Reserved capacity share — each business unit commits to a slice of the platform (a number of concurrent workflows, a throughput ceiling, a set of accelerators). Predictable for both sides, mirrors how the capacity was actually bought, and gives finance a number it can put in a budget twelve months ahead. Its weakness is that reserved-but-unused capacity is invisible unless you also report utilisation.
Workflow completions — charge per completed business transaction: a claim triaged, an invoice reconciled, a credit file assembled. This is the unit executives understand, because it maps to the process being automated and therefore to the benefit case. It requires the platform to know which workflow a given execution belongs to, which is a design decision, not a reporting one.
Accelerator-hours consumed — the most technically honest measure of who used the scarce resource, and the least legible to a business owner with no idea how many GPU-seconds a contract review consumes.
In practice the workable design is hybrid: capacity reservation as the baseline charge, a burst pool metered in accelerator-hours for teams exceeding their reservation, and direct allocation of storage footprint. Workflow completions then serve as the value denominator in reporting — cost per claim, cost per case — rather than as the billing mechanism. That framing is what makes the ROI conversation about workflow automation tractable, because numerator and denominator finally come from the same system.
Showback first — always
There is a strong temptation to skip to chargeback, because chargeback is the version with teeth. Resist it for one or two quarters.
Showback reports consumption without moving money. Its purpose is not politeness; it is calibration. The first showback report is where you discover that a share of platform usage has no owner attached, that one department’s index is far larger than anyone assumed, and that the workflow everyone described as high-volume runs a handful of times a week. Those discoveries are cheap in a report and expensive on a P&L.
Only move to chargeback when attribution coverage is high enough that finance will defend the numbers. The gating question is not whether the platform can emit usage data — it is whether the consumer’s identity is captured reliably at execution time, from the authenticated session, rather than declared by the workload. A tenant tag a caller can set is a tag that will eventually be set to whatever is cheapest.
This is a practical argument for department-level isolation in the platform design: the tenancy boundary that keeps one business unit’s documents out of another’s retrieval results is what makes their consumption separable. Multi-tenancy and cost allocation are the same architecture viewed from two directions.
The incentives you are actually designing
An internal pricing model is a policy instrument, and it will change behaviour whether or not you intended it to.
If the model charges for experimentation at production rates, experimentation stops — and with it the pipeline of new use cases that justified the platform. Carve out a centrally funded innovation allowance, so a team’s first pilot does not require a budget transfer to begin.
If the model loads the full fixed cost onto two early adopters, it punishes the departments doing the hardest work. Ramp the recovery: hold more of the capacity pool centrally in year one and shift toward consumption-based allocation as the tenant base grows.
If the model cannot show cost per business outcome, it will be read as a tax. The report that keeps a platform funded is not “marketing consumed 312 accelerator-hours”; it is “cost per processed submission fell from X to Y, at Z volume.” That depends on the platform recording, per execution, which workflow ran, who owned it, what it consumed and what it produced — the same execution record that serves audit and observability. Build it once, use it for both.
What to put in place before the next budget cycle
A workable allocation model needs four decisions written down, ideally before the platform has three tenants rather than after:
- The unit of account, and which pools it applies to. Capacity reservation plus metered burst is a reasonable default.
- The treatment of idle capacity — held centrally, spread by reservation, or spread by consumption. Any of the three is defensible; ambiguity is not.
- The attribution mechanism — where the owner identifier comes from, who can set it, and what happens to executions that arrive without one.
- The review cadence — when rates are recalculated, and what triggers a change outside that cycle.
None of this is exotic finance. It is the discipline any shared infrastructure requires, applied to a platform whose cost is more fixed and whose value is more diffuse than most. Getting it in place early is what turns the next capacity request from a negotiation into an arithmetic exercise.
How VDF AI supports cost allocation
VDF AI runs entirely inside the customer’s environment, so the platform’s cost is the customer’s own infrastructure and licence — there is no external meter to reconcile against. Every model call, retrieval and agent execution is recorded with the authenticated identity and workspace it originated from, which gives the platform team a per-department consumption picture without additional instrumentation. Departmental workspaces keep data, models and workflows separated, and the same boundary is what makes usage separable for showback or chargeback. Licensing is capacity-based rather than per-token, so the internal allocation model can mirror the external one instead of translating between two different meters.