ServiceNow just published a white paper on AI Control Tower that most people will skim past.
The governance features get most of the attention. Approvals, risk tiers, steward sign-off, that’s where readers tend to stop. Those things matter, but they’re not actually the interesting part of this white paper.
The interesting part is that ServiceNow is thinking about AI from the data layer up.
Every AI system becomes a normal CSDM entity
Every AI agent, model, prompt, and MCP server an organization runs gets modeled as a normal entity inside the Common Service Data Model (CSDM). From there, it moves through the same lifecycle as everything else you run, under three specific entity types.
In the design stage, a planned agent, digital worker, or generative AI service is an AI Product Model. That same entity’s underlying prompts, datasets, and skills get modeled too, as an AI Content Product Model. Once it moves into build, it becomes an AI Digital Asset, a traceable artifact with a named owner that carries through deployment and eventual retirement. One asset can deploy through many packages to many operational instances, and the ownership travels with it the whole way. Once it’s live, it becomes an AI Function, the operational configuration item for that deployed AI service, mapped into the same service dependency and impact map as any other CI in your CMDB.
That structure is what lets governance actually function as governance instead of a spreadsheet exercise. AI asset lifecycle management (intake, assess, build and test, deploy, retire) runs alongside risk and compliance reviews mapped to frameworks like GDPR, HIPAA, and the EU AI Act, and continuous monitoring feeds drift, performance, and ROI signals back into that same lifecycle before they become incidents. Three workflows, one shared record.
AI is not a bolt-on with its own inventory somewhere off to the side. It lives in the same data model as your servers, apps, and services.
That single design choice is why this white paper deserves more attention than a typical governance release.
Here is why that matters
Picture a health system running an AI agent that drafts patient portal replies on a third party LLM. Eighteen months in, two things land in the same quarter. The vendor deprecates the model, and an audit asks where AI touches PHI.
In most organizations, both of those questions kick off a scramble. Someone has to track down which teams are using that model, whether any of them touch PHI, and what actually breaks if the model goes away. That kind of work tends to rely on institutional memory more than documentation, which is a fragile way to answer a compliance question.
If AI is in the CMDB, every one of those hard questions becomes a query instead of a scramble.
- Ask what’s exposed by the deprecation, and one asset record maps to every deployment. You instantly see the claims workflow nobody remembered was on the same model.
- Ask what breaks if you shut it off tonight, and the dependency map shows that patient messaging degrades but stays up.
- Ask to see the controls for an auditor, and the trail already exists, because it was captured as the entity moved through its lifecycle rather than pieced together after the fact.
It doesn’t stop at IT
The same structure extends outward in a way that’s easy to miss on a first read. AI Control Tower sits on top of the CMDB and CSDM, and it pushes policy and lifecycle control out to the modules that already touch AI: IT asset management, third party risk, enterprise architecture, integrated risk management, ITSM, security operations, and more, while those modules feed events and usage signals back in.
It also reaches outside ServiceNow entirely. The white paper points to more than 40 integrations across hyperscalers and data platforms, foundation model providers, developer tooling, and security partners, all discovered into the CMDB as AI assets through the same connector framework used for everything else. A model running on a hyperscaler’s infrastructure and a homegrown agent built in-house end up governed the same way, because they’re modeled the same way.
The part worth sitting with
It would be easy to read AI Control Tower as another governance product, one more layer of approvals and dashboards for an already crowded AI tooling stack. That reading misses what makes it worth paying attention to.
The reason organizations struggle to answer basic questions about their AI footprint is rarely a lack of concern. It’s a lack of a shared record. AI has largely existed outside the systems that already track ownership, dependency, and change, so every governance question has to be answered from scratch, by whoever happens to remember where things live.
Folding AI into the same data model used for infrastructure and applications doesn’t solve governance on its own. Risk classification still requires judgment. Approval workflows still require people who understand the business context. But it removes the part of the problem that has nothing to do with judgment, the part where nobody can say with confidence what AI is running, who owns it, or what it touches.
The AI governance conversation and the CMDB conversation are the same conversation.
Organizations that have already done the work to keep their CMDB clean are going to find AI governance considerably less painful than the ones treating it as a problem to solve from scratch.
Curious what AI Control Tower and CSDM alignment would take for your environment? Get in touch with KeenStack to talk through where your CMDB stands today.
