Committed Resource Unit pools ran 2 to 3 times measured consumption in the first year, and 30 to 50 percent of the pool went unused, because capacity was bought against a plan rather than against a measurement
A prepurchased pool looks like a discount and behaves like a forecast. The estates that took a measured floor with a fair true up paid less for the same year.
Prepared by Redress Compliance · August 18, 2026 · IBM advisory. 30 to 45 IBM engagements reviewed, 2024 to 2025.
Executive summary
Committed Resource Unit pools ran 2 to 3 times measured consumption in year one. The pool was sized to an adoption plan, and the adoption plan was written before anybody had a measurement to write it from.
Between 30 and 50 percent of the committed pool went unused, and it rarely carried forward cleanly, so the unused balance was mostly a transfer to the vendor.
A measured floor plus a fair true up cut first year cost by 20 to 35 percent. The structure changed, not the rate, which is the finding worth carrying into any AI capacity conversation.
One metric spans three platforms. watsonx.ai, watsonx.data and watsonx.governance all draw on the same Resource Unit pool, which is what makes a single oversized commitment possible in the first place.
What is actually being licensed here?
Three platforms on one consumption metric. watsonx ships as watsonx.ai, watsonx.data and watsonx.governance, and all three convert compute, storage and inference into Resource Units drawn from a shared pool.
That shared metric is the commercial mechanism. It lets a buyer commit once across an entire AI portfolio, which is convenient, and it lets a single forecast error size the whole commitment wrongly.
| Platform | What it covers | What drives Resource Unit draw |
|---|---|---|
| watsonx.ai | Model selection, prompt engineering, tuning, inference serving | Inference volume and tuning runs |
| watsonx.data | The data layer beneath the models | Storage and query compute |
| watsonx.governance | Model risk, monitoring and documentation | Models under management, including non IBM models |
| The shared pool | One Resource Unit balance across all three | Everything above, which is why one forecast sizes it all |
Governance covers models IBM did not sell you
watsonx.governance handles OpenAI, Google, AWS and open source models. That is genuine value in a mixed estate, and it is also a reason the pool draw grows faster than an IBM only forecast predicts.
Why is the pool almost always too big?
Because it is sized before the workload exists. AI capacity is committed at the point of maximum optimism, against an adoption curve nobody can yet measure, and the discount for committing more makes the larger number feel prudent.
Across the engagements reviewed the result was consistent: pools ran 2 to 3 times measured first year consumption, with 30 to 50 percent left unused and rarely carried forward cleanly.
An unused Resource Unit is not a saving deferred, it is a payment made. The discount that justified the larger pool is returned in full by the balance that expires inside it, which is the arithmetic nobody runs before signing.
The IBM renewal strategy brief
Sizing the commitment against measurement, the true up structure that beats prepay, and the clause set that protects an AI capacity commit.
Get the brief →What 30 to 45 IBM engagements showed
Across roughly 30 to 45 IBM engagements reviewed between 2024 and 2025, committed watsonx capacity was bought ahead of measured demand more often than not.
Pool overbuy led. Committed Resource Unit pools ran 2 to 3 times measured consumption in the first year, which is a different scale of error from the usual commitment overshoot.
The unused balance followed from it. Between 30 and 50 percent of the pool went unused, and it rarely carried forward cleanly, so most of that balance was simply spent.
The correction was structural rather than commercial. A measured floor plus a fair true up cut first year cost by 20 to 35 percent, without any change to the Resource Unit rate itself.
That is the whole argument. Prepay buys a discount on a quantity you cannot yet estimate. A floor with a true up buys the same rate on the quantity you actually consume, and the second structure wins in a first year nobody can forecast.
- Every risky clause flagged with the verbatim quote and the page anchor
- Committed capacity modeled against trailing consumption, with the unused balance priced
- Paste ready replacement language for the carry forward and true up terms
Does the deployment path change the economics?
Yes, and it is decided separately from the commitment. watsonx runs on IBM Cloud, on AWS or Azure as a managed service, or on Cloud Pak for Data on OpenShift for on premises estates.
- Match the deployment to the cloud strategy already in place, rather than to whichever path the first proposal assumed.
- Check how the entitlement travels under Passport Advantage, because the paper follows a different logic from the platform.
- Price the Cloud Pak path separately where on premises is a requirement rather than a preference.
The on premises path runs through Cloud Pak for Data, worked in our Cloud Pak licensing guide, and the vehicle itself is usually an IBM ELA.
The audit surface travels with the entitlement
An AI platform bought under an existing IBM agreement inherits that agreement's measurement obligations. Our briefs on IBM and Red Hat audit defense and IBM software audit defense cover what that means when a reconciliation arrives.
What structure should replace the prepaid pool?
A measured floor with a fair true up. Commit to the consumption you can evidence, agree the rate for everything above it, and let the estate grow into the number rather than paying for the growth in advance.
That structure cut first year cost by 20 to 35 percent across the engagements reviewed. It is worth more than a rate concession because it removes the breakage rather than discounting it.
Carry forward is the clause to read
Unused balance rarely carried forward cleanly in the agreements reviewed. If the pool structure stays, the carry forward terms are what decide whether an overshoot is recoverable or simply gone.
What the engagements measured, 2024 to 2025
Two cuts of the engagement file frame the sizing error.
Committed Resource Units in the first year, against what the estate actually drew, across the engagements reviewed.
By replacing a prepaid pool with a measured floor and a fair true up, at the same Resource Unit rate.
The second number is the one to carry into any AI capacity conversation, because it comes from the shape of the deal rather than from the discount inside it.
Watch the briefing · 5:19Negotiating IBM: Five ThingsHow IBM structures a commitment, and which parts of it are decided before the rate is discussed.
Your first five moves
- Measure Resource Unit draw per platform before committing anything, because pools ran 2 to 3 times measured consumption where nobody did.
- Propose a measured floor with a true up instead of a prepaid pool, which cut first year cost 20 to 35 percent at the same rate.
- Read the carry forward terms if the pool structure stays, since unused balance rarely carried forward cleanly.
- Decide the deployment path on the cloud strategy you already have, not on the path the first proposal assumed.
- Account for governance covering non IBM models, which grows the draw faster than an IBM only forecast. The IBM practice sizes the commit from measurement before the proposal lands.
Frequently asked questions
How oversized is a typical watsonx commitment?
Committed Resource Unit pools ran 2 to 3 times measured first year consumption across the engagements reviewed, with 30 to 50 percent of the pool going unused.
Does the unused balance carry forward?
Rarely, and rarely cleanly. That is what turns an oversized pool from a timing problem into a payment, because the balance is mostly just spent.
What structure works better than a prepaid pool?
A measured floor with a fair true up. It cut first year cost by 20 to 35 percent at the same Resource Unit rate, because it removes the breakage rather than discounting it.
What is a Resource Unit?
The shared consumption metric across watsonx.ai, watsonx.data and watsonx.governance. Compute, storage and inference all convert into it and draw from one pool.
Why does one metric matter commercially?
Because it allows a single commitment across the whole portfolio, which is convenient and which lets one forecast error size everything at once.
Does watsonx.governance only cover IBM models?
No. It handles OpenAI, Google, AWS and open source models, which is real value in a mixed estate and also a reason pool draw grows faster than an IBM only forecast.
Which deployment paths exist?
IBM Cloud, AWS or Azure as a managed service, and Cloud Pak for Data on OpenShift for on premises. The path should follow the cloud strategy already in place.
Does buying watsonx change our audit exposure?
It can. An AI platform bought under an existing IBM agreement inherits that agreement's measurement obligations, so the audit surface travels with the entitlement.
When should the commitment be sized?
After measurement, not before. AI capacity committed at the point of maximum optimism is how a pool ends up at two to three times what the estate draws.
Is the discount for committing more ever worth it?
Only against a quantity you can evidence. The discount that justifies a larger pool is returned in full by the balance that expires inside it.
