Most AI planning starts in the wrong place: a use case, a demo, a vendor pitch. On ServiceNow, the better starting point is your CMDB, because every AI capability you build depends on it for context, and AI Control Tower now gives you a structured way to plan, assess, and govern use cases before a single agent gets built.
Why does most AI investment fail to pay off?
RAND Corporation's analysis of more than 2,400 enterprise AI initiatives found over 80% fail to deliver the business value they promised, roughly twice the failure rate of a typical IT project. The pattern behind that number matters more than the number itself: research across multiple independent studies keeps landing on the same root cause, and it isn't the model. It's governance. No agreed definition of success before the project started. No risk read before anyone built anything. No named owner once the initial sponsor moved on.
That's the gap AI Control Tower is built to close, and closing it is worth something on its own, before a single agent gets built. A structured intake and risk assessment that kills or reshapes a bad use case in week one is cheaper than discovering the same problem after six months of build.
Why does AI planning keep stalling before it starts?
Most organisations we assess have the same problem: ideas for AI live in Slack threads, slide decks, and someone's notebook. There's no single place to see what's been proposed, what's approved, what it's expected to deliver, or what it depends on. Without that, "AI strategy" is really a collection of disconnected pilots competing for budget and attention.
ServiceNow's answer to this is AI Control Tower: a structured intake, assessment, and governance layer purpose-built to link AI initiatives back to actual business goals rather than tracking them as isolated projects.
What does Control Tower's out-of-the-box process actually look like?
A business user submits an AI use case through the Employee Center, describing the business goal and linking the systems and Datasets it depends on. Those Datasets should already carry sensitivity metadata, PII, PHI, ownership, before the use case ever gets submitted. From there, an AI Steward runs the AI Impact Assessment, and the platform classifies the use case as minimal, limited, or high risk. High-risk or non-compliant use cases get flagged for Steward review before anything gets built.
That classification depends on data that's already been classified. If your Datasets don't carry sensitivity metadata yet, the assessment is guessing.
For an Australian organisation, that assessment can link back to the Privacy Act, the Australian Privacy Principles, or sector rules like APRA CPS 230. The templates ship with global frameworks like the EU AI Act and NIST AI RMF pre-loaded too, useful if you operate across borders, but the local frameworks are the ones that actually apply to most of our clients. The point is that risk and privacy get assessed early in the lifecycle, before development starts, not retrofitted after something's already live.
Why does the CMDB matter more than the AI model?
Every AI capability acts on information objects (data sets, the structured data your business applications hold and exchange) and CIs that live somewhere. It needs to know what a service is, who owns it, what depends on it, and what it's allowed to touch. That's exactly what the CMDB already holds, assuming it's accurate.
ServiceNow's own field guidance on this is blunt: successful teams don't chase the most advanced AI capability first. They identify three to five priority use cases, then clean and validate the CMDB data those use cases actually depend on, before building anything. Get that sequence backwards and you get an agent making confident decisions on top of stale ownership data and orphaned CIs. That's not a model problem. It's a foundation problem wearing an AI costume, the one we cover in detail in Why Your ServiceNow CMDB Is Lying to You.
CSDM 5.0 also now has two dedicated CI classes for this: AI Function, for AI hosted externally, and AI & Model Application, for AI built and hosted in-house. Every AI asset should be traceable through your CMDB the same way a server or an application is, with lineage, ownership, and a lifecycle state, not sitting off to the side in a spreadsheet someone updates occasionally.
What does an information object need before AI can touch it?
Knowing an information object exists isn't the same as knowing what's safe to do with it: what's sensitive inside it, who's allowed to touch it, and which rules govern it.
A few organisations have already solved that classification problem properly. NC State University added data classification tables directly into their CMDB, tagging systems and data by sensitivity tier, specifically to meet a state government data-security standard. That's the pattern worth copying: your CMDB shouldn't just record what a system is. It should record how sensitive the data behind it is, which security standard governs it, and which other applications touch it. When an AI use case comes through Control Tower's intake process, that classification is exactly what should be feeding the risk assessment, not a separate exercise someone does by memory.
Where do you actually start?
Cleaning up your CMDB and classifying your information objects shouldn't happen off to the side, separate from the rest of your roadmap. AI is going to shape how your ServiceNow platform evolves over the next several years, not just the next project, so it belongs inside your existing roadmap, not next to it as a separate stream of work. Treated as its own thing, it's easy to lose sight of automation that doesn't need AI at all: every AI call carries a token cost, and a good share of what looks like an AI opportunity is really a flow with the right spokes wired up, something that costs nothing extra to run once it's built. That trade-off, cost, effort, and whether a model is actually required, deserves the same evaluation rigour as anything else on the roadmap, and it's worth its own article.
For the AI side specifically, three things, in order:
- Get your CMDB Health score. It's in CMDB Workspace → Management → CMDB Health. If completeness and correctness sit below eighty percent on your business-critical classes, fix that before any AI use case goes near those services. That's the starting point of a CMDB Excellence engagement, if you'd rather have someone else run the assessment.
- Pick three to five use cases, not thirty. Bring them through a structured intake, even a simple one, that captures the business goal, the data it touches, and a basic risk read, before anyone starts building.
- Classify sensitivity at the information object level. If you don't know which of your data is sensitive, or which standard governs it, that has to happen before AI touches it, not after.
Last updated: 22 July 2026. This article covers ServiceNow's AI Control Tower and CMDB capabilities as they currently stand and will be revisited as the platform evolves.
If you want a clear read on where you stand, we run a roadmap that covers three things together: AI use case identification with real ROI calculations, a CMDB health assessment specific to what those use cases would depend on, and a broader automation review, so the highest-value work that doesn't need AI at all doesn't get missed. Book a platform assessment.
- CMDB
- AI
- Governance
- ServiceNow
