Every Technology Business Management (TBM) program is about to face the same question from the CIO's office: "Can we turn on AI against our TBM data?" It’s a fair question, and IT Finance and TBM teams want to say yes. Natural language query (NLQ) promises to put resource tower spend, cost pool allocations, and showback data directly in the hands of business leaders, no analyst required.
But there’s an uncomfortable truth underneath that promise. AI doesn’t fix bad data. It amplifies it. An NLQ tool built on top of unreconciled resource towers and unvalidated cost pools won’t flag its own uncertainty. It will answer with complete confidence, every time, whether the underlying number is right or not. For a TBM program, that’s not a minor inconvenience. It’s a credibility risk that reaches the CIO, the CFO, and every business unit leader who now trusts a dashboard instead of an analyst.
This whitepaper lays out what AI readiness actually means for a TBM program, why resource towers and cost pools are the layer where data problems surface first, and what a practical validation standard looks like before any organization turns on natural language query against its TBM model. It closes with a maturity lens IT and Finance leaders can use to honestly assess where their program stands today, and the concrete steps to close the gap.
The Question Every TBM Leader Is About to Get Asked
Somewhere in the next planning cycle, a CIO, CFO, or business unit leader is going to ask a version of the same question: "Why can't I just ask our system where the money's going?" AI copilots have made that expectation universal. Executives have used natural language tools in other parts of the business and reasonably expect the same experience from their TBM platform.
The instinct across most IT Finance and TBM teams is to say yes: the technology exists, the vendors are ready, and the pressure to modernize reporting is real. What’s missing from that instinct is a hard look at what sits underneath the TBM model. Cost pool allocations, resource tower mappings, and solutions-layer consumption data were built for periodic, analyst-reviewed reporting. That data was never stress-tested against the standard AI actually requires: every field trustworthy enough to be surfaced instantly, without a human in the loop to catch the error first.
That gap between "reportable" and "AI-ready" is where most TBM programs currently sit, whether they've acknowledged it or not.
What AI Readiness Actually Means for a TBM Program
AI readiness gets discussed as if it were a technology question: which model, which interface, which vendor. For a TBM program, it isn’t. It’s a data trust question, and it can be evaluated against the same four criteria that determine whether any TBM data is fit for its purpose:
- Completeness. Are the fields an NLQ tool will be asked about — GL codes, vendor invoices, consumption metrics, asset counts — fully populated across every resource tower? A single gap doesn't just create a blank cell; it creates a wrong answer delivered with total confidence.
- Consistency. Does every system feeding the model use the same taxonomy, the same tower definitions, the same naming conventions? An NLQ tool has no way to know which version is correct — it will simply pick one and answer as though there's no ambiguity at all.
- Timeliness. Is the data current enough to support a query asked in real time? A dashboard refreshed monthly can carry a disclaimer. An AI answer delivered in the moment cannot, since the executive asking the question has no reason to assume the number they’re seeing is 30 days stale.
- Accuracy. Do the TBM model's outputs reconcile against the systems of record they're supposed to represent — the CMDB, the ERP, the actual invoice? This is the criterion that matters most once AI enters the picture, because accuracy failures are exactly the kind of error a natural language interface is least equipped to catch.
Every TBM program has some level of maturity against these four criteria today. Very few have validated that maturity specifically against the demands of an AI interface, which is a materially higher bar than the demands of a quarterly report reviewed by an analyst who already knows where the soft spots are.
Resource Towers and Cost Pools: Where the Cracks Show First
If AI readiness fails somewhere in a TBM model, it fails at the resource tower and cost pool layer first, because that’s the layer NLQ tools query directly, and it’s the layer built from the widest range of source systems.
Resource towers aggregate asset and consumption data across Compute, Storage, Network, Database & Middleware, End User Workplace, and every other domain in the TBM Taxonomy. Each of those towers pulls from a different system of record: a CMDB for infrastructure, an ITSM platform for service data, a cloud billing feed for consumption, an ITAM system for licensing. Those systems were never designed to agree with each other automatically, and in most enterprise environments, they don’t. A server retired six weeks ago in the CMDB may still be generating a monthly charge in the billing feed. A software license renewed under a new SKU may show up as two separate entries in the asset inventory.
None of this is unusual. It’s the normal condition of enterprise IT data, and it’s also exactly the condition an AI interface cannot see or self-correct for.
Cost pools carry a parallel risk on the financial side. Allocations depend on GL mapping, vendor invoice data, and labor and overhead figures pulled from ERP and HR systems. When a cost pool contains unidentified spend, or when an allocation formula was built against a resource tower count that’s since drifted, the resulting unit cost is wrong, but it doesn’t look wrong. It looks like every other number in the model. An analyst reviewing a monthly report might catch the anomaly because they know the business context. An NLQ tool asked “what’s our cost per VM this quarter?” has no such context. It will report the flawed unit cost with the same confidence as a correct one, and the business leader on the other end of that query has no way to tell the difference.
AI Readiness Is a Governance Problem, Not a Technology Problem
It’s tempting to treat AI readiness as something a better NLQ vendor or a more sophisticated model will solve. It won’t. The organizations furthest along in AI readiness aren’t the ones with the most advanced AI tools. They’re the ones with the most disciplined data governance practices already in place around their resource towers and cost pools.
Viewed through a maturity lens, most TBM programs land in one of three stages when it comes to AI readiness:
Ramping
Data governance is informal. Reconciliation between the CMDB, ERP, and TBM model happens manually, periodically, and usually only when a discrepancy is escalated by a business stakeholder. Cost pool allocations are built from spreadsheet exports rather than validated feeds. At this stage, turning on NLQ isn’t a modernization step. It’s a liability, because the model will surface every unresolved discrepancy as a confident answer.
Maturing
Governance roles exist, including data stewards and TBM analysts, and reconciliation happens on a defined cadence. Resource tower definitions are documented and mostly consistent across systems. This is the stage where most enterprise TBM programs actually sit, and it’s a workable starting point for AI readiness, but only after a targeted validation pass on the specific towers and pools an NLQ tool will be asked about most.
Innovating
Data validation is continuous and automated, resource towers reconcile against systems of record in near real time, and cost pool allocations are traceable back to source data on demand. This is the standard AI readiness actually requires, not because it’s aspirational, but because it’s the only condition under which an NLQ answer can be trusted without a human double-checking it first.
The organizations that will succeed with AI-enabled TBM reporting aren’t the ones that move fastest to turn NLQ on. They’re the ones that treat AI readiness as a governance milestone to be validated, the same way they’d validate any other change to a system feeding executive-level reporting.
What Validation Looks Like in Practice
Closing the gap between where most TBM programs sit and where AI readiness requires them to be doesn’t mean starting a multi-year data cleanup initiative. It means validating the specific layer AI will touch first: resource towers and cost pools.
FogLifter® was built to operate at exactly this layer, upstream of the TBM model itself. Its Count, Caliber, and Cost framework directly maps to the validation standard AI readiness demands. Count delivers a deduplicated, cross-system-reconciled view of every asset in a resource tower, so the number an NLQ tool reports back matches what’s actually deployed, not what one system happens to claim. Caliber validates the performance and SLA data tied to those assets, so operational context stays connected to the financial picture instead of drifting apart. Cost reconciles ERP, HR, and asset management data into a true, defensible cost of service, so a cost pool allocation can withstand being surfaced instantly to a business unit leader who has never seen the underlying model.
The Validation View is where this becomes operational rather than theoretical. It gives data owners on both sides of a discrepancy, including IT and Finance, a managed service provider and its client, or a CMDB owner and a billing team, a shared workspace to resolve disagreements before they ever reach the TBM model, let alone an AI interface sitting on top of it. And the CIO Heat Map gives leadership a way to see, at a glance, exactly which towers and pools carry unresolved validation risk, so a decision to turn on NLQ for one part of the business and hold off on another is a deliberate choice, not a blind one.
A Pre-Launch Validation Checklist
Before any TBM program turns on natural language query against Resource Tower or Cost Pool data, the following checkpoints separate a defensible launch from an exposed one:
- Reconcile Resource Tower asset counts against the CMDB, cloud billing feeds, and ITAM records — on a cadence that matches how often the data will be queried.
- Audit Cost Pool allocations for unidentified spend and confirm GL mapping traces cleanly back to source invoices.
- Standardize taxonomy definitions across every system feeding the model, so a tower or pool means the same thing everywhere it appears.
- Identify the towers and pools with the highest expected query volume an NLQ tool will actually face, and prioritize validation there first rather than attempting a full-model cleanup.
- Establish a Validation View or equivalent workflow so discrepancies are resolved by data owners before they reach the reporting layer, not after a business leader flags a wrong answer.
- Set a visible confidence indicator, such as a heat map, a data quality score, or a validation status, so stakeholders know which parts of the model are AI-ready and which still require an analyst.
- Run a controlled pilot with a small group of practitioners before opening NLQ access broadly, and treat every wrong or inconsistent answer as a validation gap to close, not an AI limitation to tolerate.
None of these steps require replacing a TBM platform or delaying a broader AI strategy. They require treating the resource tower and cost pool layer with the same discipline a TBM program already applies to its financial reporting, because that layer is about to be held to a much less forgiving standard.
Turning On AI With Confidence
"AI readiness, in the end, isn't a feature to enable. It's a standard of trust a TBM program has to earn at the data layer, before it can be extended to the interface layer."
— FogLifter® analysis
The organizations that get the most value from AI-enabled TBM reporting won’t be the ones that adopted NLQ first. They’ll be the ones that validated their resource towers and cost pools before a business leader ever typed the first question into the box. AI readiness, in the end, isn’t a feature to enable. It’s a standard of trust a TBM program has to earn at the data layer, before it can be extended to the interface layer. FogLifter® exists to help TBM programs earn that trust faster, by validating the Count, Caliber, and Cost data underneath the model before AI is asked to rely on it.
Ready to see where your program stands?
Get a FogLifter® AI Readiness Assessment for your TBM program at foglifter.ai.
Key takeaways
- AI readiness is a data trust question, evaluated against four criteria: completeness, consistency, timeliness, and accuracy.
- Resource Towers and Cost Pools crack first — they're queried most directly and built from the widest range of source systems.
- It's a governance problem, not a technology problem. Most programs sit at "Maturing" — a workable starting point with targeted validation.
- Validation is targeted, not a multi-year cleanup. Prioritize the towers and pools with the highest expected query volume first.
- A seven-step checklist separates a defensible NLQ launch from an exposed one.
"AI doesn't fail gracefully at the weak layer of a TBM model — it fails with total confidence. Resource Towers and Cost Pools are where that shows up first, which is exactly why we validate them before an NLQ tool is ever allowed to rely on them."