Before you can calculate AI savings, you need a reliable pre-AI cost baseline that accurately reflects what the same work cost before the technology was introduced. Without it, any savings figure you report is an estimate built on assumption rather than fact. The sections below walk through the most important questions organizations face when establishing and using an AI savings baseline.
Why does choosing the wrong baseline distort AI savings calculations?
Choosing the wrong baseline distorts AI savings calculations because it changes the reference point against which all improvements are measured. If your baseline is too high, you overstate savings. If it is too low, or based on an unrepresentative period, you understate them. Either outcome weakens your AI business case and erodes trust with finance and leadership.
This matters especially when AI investments are large and the pressure to justify them is real. A baseline drawn from an unusually expensive quarter, a period of peak staffing, or a process that has already been partially optimized will produce numbers that do not hold up under scrutiny. When the CFO or board asks how savings were calculated, a flawed baseline becomes a credibility problem, not just a measurement problem.
The distortion also compounds over time. If ongoing savings tracking continues to reference a bad baseline, every subsequent report carries the same error forward. This is why getting the baseline right at the start is not a technical detail but a governance decision that shapes how AI value is communicated across the organization.
What are the main types of baselines used in AI cost measurement?
The main types of baselines used in AI cost measurement are the historical cost baseline, the activity-based baseline, the run-rate baseline, and the counterfactual baseline. Each captures a different dimension of pre-AI cost and is suited to different measurement contexts.
- Historical cost baseline: Uses actual costs from a defined period before AI deployment, typically 6 to 12 months. This is the most straightforward approach and works well when the pre-AI process was stable and well-documented.
- Activity-based baseline: Calculates cost per unit of work performed, such as cost per invoice processed or cost per support ticket resolved. This allows savings to be measured even when volumes change significantly after AI is introduced.
- Run-rate baseline: Projects forward what costs would have been without AI, based on historical trends and expected volume growth. Useful when business activity is growing and a simple historical snapshot would understate what costs would have become.
- Counterfactual baseline: Models what the organization would have spent if it had taken an alternative path, such as hiring additional staff or upgrading legacy systems. This is the most complex type but is useful when AI replaces a planned investment rather than an existing one.
Most organizations benefit from combining at least two of these approaches, particularly the historical cost baseline with an activity-based adjustment, to account for volume changes without inflating the savings figure.
How do you establish a reliable pre-AI cost baseline?
You establish a reliable pre-AI cost baseline by identifying the specific process or function AI will affect, gathering actual cost data for that scope over a representative period, and validating that data with both IT and finance stakeholders before AI deployment begins.
The steps involved are straightforward, but each requires discipline to execute correctly:
- Define the scope precisely. Identify which processes, teams, systems, or outputs the AI will directly affect. Avoid broad scope definitions that pull in costs AI will never touch.
- Select a representative measurement period. Use at least 6 months of data, and ideally 12, to smooth out seasonal variation. Avoid periods that include one-time events, major incidents, or organizational restructuring.
- Capture all relevant cost categories. Include labor (fully loaded, not just salary), software licenses, infrastructure, support, and any manual workarounds the current process depends on.
- Document assumptions and exclusions. Record what is included and why, so the baseline can be defended later and compared consistently with post-AI actuals.
- Validate with finance. A baseline that IT builds alone is vulnerable to challenge. Finance sign-off at the start protects the integrity of savings claims later.
This process connects directly to FinOps practices for cloud cost visibility, where establishing trusted cost data before optimization begins is a foundational discipline.
What costs should be included and excluded from the baseline?
The baseline should include all costs that AI directly replaces or reduces, and exclude costs that are unrelated to the process being automated or that will remain constant regardless of the AI investment. Getting this boundary right is one of the most important decisions in AI cost savings measurement.
Costs to include
- Fully loaded labor costs for staff performing the task AI will take over, including benefits, overhead, and management time
- Software licenses for tools the AI replaces or consolidates
- Infrastructure costs directly attributable to the process, such as compute or storage for existing systems
- Third-party service costs, such as outsourced processing or manual data entry services
- Error correction and rework costs that result from manual processing
Costs to exclude
- Overhead costs that will not change regardless of the AI deployment, such as facility costs or shared IT infrastructure that serves other functions
- One-time or non-recurring costs from the baseline period that are not representative of normal operations
- Costs of adjacent processes that AI does not directly affect
- Opportunity costs or theoretical savings that cannot be measured against actual expenditure
A common mistake is including costs that sound related but are not causally connected to the AI’s scope. This inflates the baseline and makes savings look larger than they are, which creates problems when results are audited.
Should you use a static or rolling baseline for ongoing AI savings tracking?
For ongoing AI savings tracking, you should use a rolling baseline rather than a static one in most cases. A static baseline freezes a single pre-AI snapshot and compares all future periods against it, which becomes less meaningful as time passes and business conditions change. A rolling baseline adjusts periodically to reflect volume changes, inflation, and process evolution.
The right choice depends on your measurement goals:
- Use a static baseline when you need to report the total cumulative savings since AI was deployed, or when the business case was built against a fixed cost target. This is useful for executive reporting and for validating the original investment decision.
- Use a rolling baseline when you are tracking ongoing performance and need to account for the fact that volumes, team sizes, or market rates have changed since deployment. A rolling baseline keeps the comparison relevant and prevents savings from being overstated simply because the business grew.
Many organizations run both in parallel: a static baseline for the original business case and a rolling baseline for operational performance management. This approach gives leadership a clear view of total return while giving IT and finance teams a meaningful signal for continuous optimization. This is consistent with how mature cloud financial management programs track cost efficiency over time, separating one-time savings from structural cost reduction.
What are the most common baseline mistakes that undermine AI business cases?
The most common baseline mistakes that undermine AI business cases are using an unrepresentative measurement period, failing to include fully loaded costs, mixing up cost reduction with cost avoidance, and not getting finance alignment before deployment. Each of these errors produces savings figures that do not survive scrutiny.
- Unrepresentative period: Measuring baseline costs during an unusually expensive or unusually quiet period creates a skewed reference point. Always validate that the period reflects normal operations.
- Incomplete cost capture: Including only direct labor while ignoring overhead, tooling, and rework costs understates the true pre-AI cost and compresses the savings figure.
- Conflating cost reduction with cost avoidance: If AI prevents costs that would have grown, that is cost avoidance, not cost reduction. Both are valid, but they need to be reported separately. Mixing them creates confusion when actuals are compared to the baseline.
- No finance alignment: A baseline built solely by IT is easy to challenge. Finance involvement at the outset creates shared ownership of the methodology and makes savings claims far more defensible.
- Ignoring volume changes: If the business grew by 20% after AI was deployed, some of the apparent savings may simply reflect that more work is being done at the same cost, not that cost per unit has fallen. Adjusting for volume is necessary for an honest measurement.
- No documentation of assumptions: Without a clear record of what was included, excluded, and why, the baseline cannot be consistently applied or defended over time.
How we help you build a solid AI savings baseline
Measuring AI savings accurately requires the same financial discipline that underpins any serious IT investment decision. At It’s Value, we help organizations establish the cost transparency and governance frameworks that make AI business cases credible and defensible. Specifically, we support you with:
- Defining the right scope and cost categories for your pre-AI baseline, aligned with both IT and finance stakeholders
- Implementing IT Financial Management (ITFM) and Technology Business Management (TBM) frameworks that give you the structured cost data needed to measure savings reliably over time
- Integrating FinOps practices for cloud-based AI workloads, so that compute and platform costs are allocated accurately and included in your baseline from the start
- Building reporting cadences that track AI savings against both static and rolling baselines, giving leadership the visibility they need to validate the investment
If you are preparing an AI business case or want to validate the savings methodology you already have in place, get in touch with us to discuss how we can help you build a baseline that holds up.