Your CMDB is lying, and AI will believe it
Walk into almost any managed services or IT consulting firm and pull a sample of 50 configuration items. You'll find assets assigned to employees who left in 2023, three duplicate records for the same firewall, a client mapped to the wrong tenant, and a dozen items with no owner at all. The technicians already know this — which is why they ignore the CMDB and ask in Slack instead. Now imagine pointing an AI ticket-router at that same table. It won't ask in Slack. It will confidently assign a P1 to a contact who no longer works there.
That's the trap with AI on service data: it doesn't degrade gracefully. A human reading a stale asset record hesitates. An automated workflow reading the same record acts. The U.S. Census AI business adoption analysis and the OECD SME AI adoption report both show services firms feeling real pressure to put AI into operational workflows — but adoption pressure and clean data are not the same thing, and the gap between them is exactly where SLA breaches get manufactured. So pick one domain and only one: ticket categorization, asset/CMDB accuracy, or client-contact mapping. Clean that single lane before any assistant uses it to route, escalate, or report.
Count the breaches AI would have caused, not the drafts it produced
Say you pick the CMDB as your one domain. Before you let any AI touch it, get the embarrassing baseline on paper: how many duplicate configuration items exist, how many assets have no current owner, how many are tied to a decommissioned client, and how many hours a week a service-desk lead burns reconciling the PSA against the actual environment. Most firms have never measured this honestly, and the first number usually stings.
Then run the cleanup pilot and watch the metrics that map to money and SLAs — not the vanity ones. The wrong metric is "AI flagged 4,000 records for review." The right metrics are: did first-assignment accuracy on tickets go up, did the rate of tickets bounced for missing asset context go down, and did SLA reporting stop disagreeing with what the techs actually did? Every change the AI proposes should land in a change log a human can read in plain language: which field, old value, new value, who approved it. If a cleaned record later causes a misroute, you want to trace it back in under a minute. Run the AI Opportunity Score or the AI ROI Calculator once — but only after these operating numbers have a named owner who has to defend them next quarter.
Govern it like a client environment, because it is one
Here's what makes IT services data different from a generic spreadsheet: those records often describe your clients' infrastructure. Asset tables, contact lists, tenant mappings — that's regulated, contractual, sometimes contains credentials-adjacent metadata. So treat the cleanup project with the same rigor you'd demand of a client's environment. The NIST AI Risk Management Framework gives you the structure to write down the intended use, the failure modes, and who's accountable when an automated change goes wrong. The CISA AI data-security best practices tell you how to scope field-level access, handle client records, and keep change-control evidence that would survive a client audit.
Concretely, on Monday: assign each data domain a single source-system owner (the CMDB owner is not "everyone"), require human QA sampling before any AI change is promoted to live, and write a rollback rule for any record that touches client-facing routing or SLA reporting. Only after a cleaned domain has improved real ticket routing and reporting for a full cycle — with no spike in reversals or breaches — do you let automation act on it unattended. One clean domain that earns trust beats five half-cleaned tables that nobody believes.
