Feed an AI copilot a service map with a duplicate configuration item in it, and it won't ask for clarification. It picks one record, ignores the other, and recommends a decommission with complete confidence, because nothing in the data told it there was a choice to make.
That's the real constraint in most AI readiness conversations. They focus on the AI, when the actual limit is the configuration management database (CMDB) feeding it. AI is only as reliable as the operational data underneath it, and for most estates, that data has never been checked against this bar before.
An AI tool can't distinguish production from development if duplicate records make both look equally current. It can't trace an incident to the right cause if two configuration items claim to be the same server. Every one of these failures traces back to the same root: identification rules that aren't catching duplicates before they're created, not a limitation of the AI model itself.
This is why a CMDB AI readiness assessment starts with structure, not tooling. Consistent CI classes, Common Service Data Model (CSDM) alignment, standardised naming, and clear ownership all determine whether an AI system is working from one trustworthy record per asset or three conflicting ones.
Cloud resources change by the minute. On-premise infrastructure changes daily. If the CMDB behind an AI tool is only reconciled quarterly, the AI is making recommendations against a version of the estate that stopped being true weeks ago.
A server marked active in the CMDB but decommissioned last month will still show up in an AI-generated capacity report. A newly provisioned database that hasn't been discovered yet is invisible to any AI-assisted impact analysis run against it. Neither failure is a flaw in the AI. Both are a reconciliation gap that existed long before anyone connected an AI tool to the data.
AI delivers the most value when it understands how systems connect, not just that they exist. Without accurate service mapping, an AI tool asked "what breaks if this server goes down" has no dependency chain to walk. It either returns nothing, or it guesses from naming conventions, which is worse than returning nothing, because a wrong answer delivered confidently gets trusted.
We've written before about using AI agents to triage CMDB de-duplication tasks safely, with evidence, human approval and an audit trail at each step. That pattern only works because the underlying relationship data was solid enough to trust the agent's evidence against. Readiness has to come before the agent, not alongside it.
The assessment looks at four areas, in this order, because each one depends on the last:
Structure and integrity. Consistent CI structures, CSDM compliance, standardised classifications and clear ownership. This is where duplicate CIs, stale records and orphaned assets get identified and counted, not just noticed anecdotally.
Relationship visibility. Service mapping quality, dependency accuracy and CSDM alignment across the estate, so impact analysis has something real to walk.
Data freshness. The gap between the live environment and what the CMDB record says, measured directly rather than assumed from the last reconciliation date on a dashboard.
Governance. Whether reconciliation, change control and ownership accountability are set up to keep the first three areas true as the estate keeps changing, not just true on assessment day.
Improving AI readiness isn't a one-off clean-up before a project kicks off. A clean CMDB on the day of the assessment degrades within weeks if the reconciliation rules and ownership model that produced it aren't still running afterwards.
The estates that stay AI-ready treat reconciliation as a standing process: automated discovery feeding identification rules that catch duplicates on the way in, ownership reviewed as people change roles, and CSDM alignment checked whenever a new class or integration is added, not only during the next scheduled audit.
Four areas, in order: structure and integrity, relationship visibility, data freshness and governance. Each depends on the one before, so duplicate CIs, stale records and unowned items are counted first, and the governance that keeps them fixed is checked last.
An AI tool has no way of knowing a second record exists for the same item, so it picks one and acts on it with full confidence. The cause is almost always identification rules that don't catch duplicates before they're created.
Current enough to match the live estate, which the assessment measures directly rather than assuming from the last reconciliation date. Cloud resources change by the minute and on-premise infrastructure daily, so a quarterly reconciliation leaves AI working from an out-of-date picture.
Impact analysis needs a dependency chain to walk. Without accurate service mapping, an AI tool asked what breaks if a server goes down either returns nothing or guesses, and a confident wrong answer tends to be trusted.
No. A clean CMDB degrades within weeks if the reconciliation rules and ownership model behind it stop running. Estates that stay ready treat reconciliation as a standing process, with ownership reviewed as people change roles and CSDM alignment checked whenever a class or integration is added.
We run a data quality assessment scored against weighted critical success factors, key performance indicators and metrics, so you can see exactly where de-duplication, normalisation and reconciliation are failing, and why, before you point an AI tool at the result.
Written by Iain Moone, Apex Configuration Group.
Image Source: Envato