At Knowledge26, AI was everywhere.
You could hear it in almost every conversation: agents, automation, orchestration, governance, productivity, and the new possibilities ServiceNow customers are starting to explore. The direction is clear, and there is a lot to be excited about.
But those conversations kept bringing us back to a more practical question:
What happens when AI acts on the wrong operational data?
Not just when it gives an answer that is slightly off, or when a summary misses an important detail. We mean the more everyday ServiceNow scenario, where a workflow is triggered, a task is routed, a recommendation is made, an incident is escalated, or an approval path is selected based on data that nobody has really validated.
That is where the discussion becomes a more serious one. Once AI starts using ServiceNow data to influence action, data quality is no longer just a reporting issue. It becomes a question of trust, requirements, and accountability.
For ServiceNow teams, this is not only an AI question, either. It is a CMDB, CSDM, and foundation data question. The same shared data that already supports workflows, reporting, impact analysis, service management, and platform decisions is now being asked to support more automation and AI-assisted work.
And that means the data needs to be good enough not only to look at, but to act on.
A familiar problem in a new setting
For many years, ServiceNow teams have grown used to living with imperfect data. There might be a missing owner here, an outdated support group there, a relationship that everyone knows is not quite right, or a business application record that exists but does not really reflect how the application is used. More often than not, there may be a service map that was accurate at one point, but has not kept up with reality for a long time.
People often work around these things. They check with a colleague, look at another system, remember that a certain team changed names six months ago, or know from experience that one field should not be trusted even if the report still uses it.
That kind of human workaround is not ideal, but it is common.
The concern with AI and automation is that these workarounds may quietly disappear from the process. If the data says a CI belongs to a certain service, the process will treat that as true. If the owner field points to a person, the task will go there. If the support group is wrong, the workflow will still follow it. And if an application is classified incorrectly, the impact analysis will inherit the mistake.
The platform will not always know that people inside the organization have quietly stopped trusting a piece of data. And that is exactly the problem.
Visibility is not the same as trust
Most organizations already have some way to measure CMDB quality. They look at health dashboards, completeness, correctness, relationship quality, duplicate records, stale records, or compliance against internal rules.
That visibility is useful, but it is not the same as trust.
A dashboard can tell you whether a field is populated. It may not tell you whether the value is still correct, whether the right person has reviewed it, whether the data consumer can actually use it, or whether there is an accepted exception behind it.
This distinction becomes much more important when data is used by automation or AI-assisted workflows. If bad data leads to a bad report, the impact may be frustrating but somewhat contained. But if bad data drives a workflow, a recommendation, or an operational decision, the effect can move faster and become harder to notice until something has already gone wrong.
The problem is often not lack of visibility. The problem is that the process stops there.
An organization may have dashboards, the dashboards may show the issues, the issues may be discussed, and then the same issues appear again the next month. Everyone agrees data quality is important, but the actual data does not improve at the pace people hoped.
To improve trust, the organization needs a way to turn requirements into checks, checks into tasks, tasks into ownership, and ownership into actual remediation. It also needs a way to see whether the situation is improving, not just whether the same gaps are still visible.
To put it bluntly – your goal should not be a nicer dashboard, but to know which data can be trusted.
AI-readiness means enforced data requirements
AI-readiness is sometimes discussed as if it is a new layer that can be added on top of everything else. First CMDB, then Foundation Data, then governance, and now AI-readiness.
From our point of view, these are not separate problems. They are different expressions of the same underlying issue: can the organization define, maintain, and trust the data it depends on?
AI does not create that need, but rather, it exposes and accelerates it.
A CMDB that is good enough for occasional reporting may not be good enough for automated action. Foundation data that is mostly correct may not be good enough when workflows rely on users, groups, companies, locations, departments, and relationships. And a CSDM model that exists in slides may not help much if the actual records are incomplete, outdated, or not owned by the people closest to the reality.
That is why AI-readiness should be treated less as a new initiative and more as a reality check.
Before a workflow or AI-assisted process relies on ServiceNow data, the organization needs to define what that data must articulate. Which fields must be complete? Which relationships are required? Which ownership data must be confirmed? Which records are allowed to have exceptions? Which ones should not be used until they are fixed?
This is where many teams get stuck. The requirements may exist, but enforcing them continuously is difficult. The CMDB changes, services change, applications change, owners change, and foundation data changes. Without a repeatable way to audit and remediate against the model, the organization ends up relying on assumptions.
And assumptions are a weak foundation for automation.
This is also where broad statements like “we need better CMDB quality” become too vague. Better questions are: what data is required for this use case, what does good look like, who can confirm it, how often should it be reviewed, what happens when it does not meet the requirement, and should automation be allowed to rely on this data yet?
CSDM helps by giving structure and a shared language. But the model itself does not guarantee trust. The data still needs requirements, ownership, review, remediation, and continuous maintenance specific to a use case or a desired outcome.
Accountability cannot sit only with the platform team
One of the things that makes ServiceNow data quality difficult is that the data is shared, but accountability is often fragmented.
The platform team may own the technical setup, the CMDB team may own the process, application owners know the applications, service owners know business impact, infrastructure teams understand technical dependencies, and HR, finance, and other systems may provide foundation data. Different teams also consume the same data for different reasons.
That is normal, and it is also why data quality cannot be solved by one team alone.
When AI or automation acts on poor data, it will not be enough to say that a dashboard showed a red indicator somewhere. Someone will need to understand what the data requirement was, who was responsible for it, whether it had been reviewed, and what process existed to fix it.
Ideally, this should be visible in the platform, not only in a governance slide.
That is the practical side of governance. Not governance as a policy document, but governance as the daily work of making sure the right people are involved in keeping the right data fit for purpose.
Who owns this data, who uses it, who provides it, who confirms it, who fixes it when it is wrong, and who decides whether it is reliable enough for a particular use case?
These are not theoretical questions. They are the questions that decide whether automation can be trusted.
Some data is more important than other data
Not every field carries the same risk.
Some data is useful context, while some data directly affects routing, ownership, compliance, prioritization, automation, impact analysis, or reporting. The more a data element influences action, the more care it needs.
For example, if a workflow depends on application ownership, that ownership needs to be current. If impact analysis depends on CMDB relationships, those relationships need to be maintained. If service information affects prioritization, the service model needs to reflect reality. And if approvals rely on user, group, location, or company data, foundation data quality is no longer just an administrative concern.
This is where teams need to be more specific about the use case. A business application record may need one set of requirements for portfolio reporting, another for service mapping, and another for automation. A relationship may be good enough for a high-level view, but not good enough to drive impact analysis. A support group may look complete, but still be wrong for routing.
That is why ServiceNow data quality needs to be connected to purpose. The question is not only whether the data exists, but whether it is fit for the way the organization intends to use it.
So before choosing where AI or automation should go next, ServiceNow teams should ask:
Can our operational data support the action we want the system to take?
If the answer is unclear, that does not mean the organization should stop exploring AI. It means the data quality conversation needs to become more operational.
Define the data requirements. Audit against them. Involve the right owners and providers. Route issues to the people who can fix them. Certify critical data. Make exceptions visible. And keep doing it, because the data will keep changing.
That work may not sound as exciting as an AI roadmap, but it is what makes the roadmap credible.
From ambition to trust
We are optimistic about what AI can do in ServiceNow. But it does not remove the need for the basics. Rather, it makes the basics more visible.
If ServiceNow data is incomplete, inconsistent, outdated, or not clearly owned, AI will not turn it into a reliable operational foundation. It may simply use that data faster and in more places.
That is why this moment is a good opportunity to look again at the data foundation. Not as a one-time cleanup, not as a dashboard exercise, and not as something that belongs only to the CMDB team, but as a continuous way of defining what good data looks like, checking whether the data meets that standard, engaging the people who own and provide it, and building confidence in what the platform is allowed to do with it.
Because before ServiceNow data can support more intelligent action, it needs to be trusted in ordinary operational work.
And that is where AI-readiness really starts.
If your ServiceNow roadmap includes more automation or AI-assisted workflows, it is worth checking which parts of your CMDB, Foundation Data, or any data in ServiceNow are already fit to support action.
In a DCM demo, we can show how data requirements can be designed, audited, remediated, certified, and continuously enforced inside ServiceNow, without turning the process into another manual reporting exercise.
