The Problem Worth Solving
If your organisation is deploying AI — whether that's a NowAssist skill, a custom agent on AWS Bedrock, or a third-party SaaS tool like Zoom's meeting summarisation — you already have an AI governance problem, even if you haven't named it yet.
Today, most organisations track AI assets as Digital Assets with a one-to-one mapping to Product Models.
That sounds reasonable until you realise what it means in practice: governance is applied to an entire class of AI, not individual deployments.
- You can't independently govern, pause, or retire the version of your Incident Summarization agent running in your EU production environment without affecting every other environment.
- You can't ask "where exactly is this model running?" because the data model doesn't capture that question.
ServiceNow's AI Inventory and Control Tower (AICT) solves this by introducing three distinct layers —
Product Model, Digital Asset, and Configuration Item (CI) — that together give you a precise, governable picture of every AI asset across its full lifecycle.
The Three Layers
The AICT data model is built around three object types that answer three fundamentally different questions:
- AI Product Model answers: "What type of AI is this?"
- AI Digital Asset answers: "Who owns this AI, and what is the risk?"
- AI Configuration Item (CI) answers: "Where exactly is it running right now?"
To make this concrete: one Travel Booking Agent deployed in three regions produces -
- 1 Product Model
- 1 Digital Asset
- 3 CIs — one CI per deployed environment.
Each CI can be independently governed, paused, or retired without touching the others.
This is the core insight the data model is designed to enable.
1. AI Product Model — The Catalog Definition
The Product Model is the catalog entry for a type of AI.
Think of it like an iPhone 16 model entry in a product catalog — it describes the product, not any specific unit sold.
Examples include — "GPT-4o", "Incident Summarization", "Mixtral"
They are shared globally across all deployments and environments.
Two inheritance branches exist in the class hierarchy:
AI System branch — for agents, skills, and AI systems:
cmdb_model → cmdb_sw_component_product_model → cmdb_ai_system_component_product_model
AI Content branch — for models, prompts, datasets, and MCP servers:
cmdb_model → cmdb_content_product_model → cmdb_ai_content_product_model
The AI Content branch has four specialised sub-types worth knowing:
cmdb_ai_model_product_model— classifies AI models used to generate system responses (Now LLM, GPT-3.5 Turbo)cmdb_ai_dataset_product_model— classifies training and evaluation datasets (Wikipedia, Google Open Images)cmdb_ai_prompt_product_model— classifies prompt templates and instruction sets given to modelscmdb_mcp_product_model— classifies Model Context Protocol servers that expose capabilities to AI agents
Critical rule: Product Models are never created standalone.
They are always auto-created alongside the Digital Asset when an intake form is submitted, or synced hourly from native ServiceNow tables via the "Sync Now Assist AI Assets" scheduled job.
2. AI Digital Asset — The LIFECYCLE Record for Governance & Risk classification
The Digital Asset is the ownership and lifecycle management record.
Crucially, it exists from the moment you declare an AI asset, before it is built and before it is deployed.
The governance attributes — steward oversight, risk tier, compliance — live on the related sn_ai_governance_asset_governance_details and GRC records.
The Digital Asset is the anchor record; the governance detail and risk records hang off it.
When it is created: At intake — the Design & Planning phase.
Even for Zoom's Meeting Summary agent built on Claude, you would create a Digital Asset because you want to govern it, not because you can see its internals.
How it is created:
- Manual: Employee Center → Technology Services → AI Assets, or the AICT Workspace, or REST API (
POST /sn_ent/asset/ai_system) - Automatic: Hourly scheduled job "Sync Now Assist AI Assets" for SN-native AI (skills, agents, use cases)
The key asset types and their tables:
| Asset Type | Table |
|---|---|
| AI System (agents, skills) | alm_ai_system_digital_asset |
| AI Model | alm_ai_model_digital_asset |
| AI Prompt | alm_ai_prompt_digital_asset |
| AI Dataset | alm_ai_dataset_digital_asset |
| MCP Server | alm_mcp_digital_asset |
3. AI CI — The Deployment Record
The Configuration Item is where the data model gains its operational power.
A CI represents a specific running deployment of an AI asset.
One CI per deployment/environment.
What it carries: The agent/skill/model capabilities deployed in a specific instance — environment (DEV/TEST/PROD), location, and links to the application service it supports.
When it is created: Only when two conditions are simultaneously true — the AI is deployed, and you have visibility into that deployment.
CIs are created by cloud/hyperscaler discovery integrations (AWS Bedrock, Azure AI Foundry, GCP Vertex) or the NowAssist native sync job.
The four key CI classes:
| Class | Table | Use case |
|---|---|---|
| AI Function | cmdb_ci_function_ai |
SaaS / cloud-hosted AI (AWS Bedrock, Azure AI, SN-hosted) |
| AI & Model Application | cmdb_ci_appl_ai_application |
On-prem / customer-managed infrastructure |
| MCP Function | cmdb_ci_function_mcp |
AI-callable tool endpoints |
| AI Model Deployment | cmdb_ci_ai_model_deployment |
Deployed, running model instance (in development) |
The Asset-CI Linkage
ServiceNow has introducedcmdb_rel_asset_ci table, a many-to-many (M2M) relationship table that formally links an Asset record (e.g. alm_ai_system_digital_asset) to its corresponding CMDB CI record (e.g. cmdb_ci_function_ai or cmdb_ci_ai_model_deployment).
It is the standardized, future-proof way to express the Asset↔CI relationship in AICT — replacing the older approach of storing a direct reference field on the CI table.
Consider this ascmdb_rel_ci but with an Asset to CI linkage with relationship type.
The Full Data Model — Table Reference
For implementers, here is the complete mapping across all AI asset types:
| Asset Type | Product Model Table | Digital Asset Table | CI Table |
|---|---|---|---|
| Models | cmdb_ai_model_product_model |
alm_ai_model_digital_asset |
cmdb_ci_ai_model_deployment |
| Skills | cmdb_ai_system_product_model |
alm_ai_system_digital_asset |
cmdb_ci_function_ai |
| Agents | cmdb_ai_system_product_model |
alm_ai_system_digital_asset |
cmdb_ci_function_ai |
| Prompts | cmdb_ai_prompt_product_model |
alm_ai_prompt_digital_asset |
— |
| Datasets | cmdb_ai_dataset_product_model |
alm_ai_dataset_digital_asset |
— |
| MCP Servers | cmdb_mcp_product_model |
alm_mcp_digital_asset |
cmdb_ci_function_mcp |
Note: Prompts and Datasets have Product Models and Digital Assets but no CIs in the current scope — as of now, they are governed at the asset level only.
Decision Guide: When to Create Each Object
This is the most practical question for anyone governing AI assets in the platform.
The answer depends on three trigger questions:
Create a Product Model when:
"Has this type of AI been catalogued before?"
If no — a new Product Model is needed. But you never create it directly.
Submit an intake form, and it is auto-created alongside the Digital Asset.
- First time your organisation uses GPT-4o? A new Product Model is created.
- New custom ServiceNow agent? New Product Model.
- Same GPT-4o deployed in five new environments? No new Product Model — it already exists.
Create a Digital Asset when:
"Does my organisation use or own this AI?"
If yes — always create a Digital Asset.
This includes SaaS agents where you have no deployment visibility.
The Digital Asset exists to declare governance intent, not to describe deployment.
They are always created. Even if no CI will ever exist.
- Incident Summarization → 1 Digital Asset, N CIs (one per environment/instance)
- Zoom Meeting Summary (SaaS) → 1 Digital Asset, 0 CIs
Create a CI when:
"Is this AI running somewhere I can see?"
If yes and you have discovery visibility — create a CI (1 per deployment).
The same asset in AMS-Prod and EU-Prod is two CIs, linked to the same Digital Asset.
How It Connects to CSDM and Application Services
The CI layer connects upward into CSDM v5.
AI CIs are populated into a Service Instance via Tags, CMDB Groups, or direct membership.
From there, they participate in standard ITSM workflows — change management, incident, and service impact analysis — exactly as traditional infrastructure CIs do.
There is also a direct governance-layer connection for TPM purposes: the AI System Product Model is linked to Business Application via sn_apm_ws_ba_product_model_map, managed through the EA Workspace.
This connection exists independently of CIs and is established at intake time.
Worked Example: Incident Summarization
To bring this together, here is how a single SN-hosted Incident Summarization skill maps across all three layers:
Product Models (2 records — shared globally):
- "Incident Summarization" →
cmdb_ai_system_product_model - "Azure OpenGPT 4o" →
cmdb_ai_model_product_model
Digital Assets (2 records — shared across all environments):
- "Incident Summarization" →
alm_ai_system_digital_asset(owner, risk tier, steward) - "Azure OpenGPT 4o" →
alm_ai_model_digital_asset(governance)
CIs (N records — one per environment/customer instance):
- "Incident Summarization DEV" →
cmdb_ci_function_ai - "Incident Summarization TEST" →
cmdb_ci_function_ai - "Azure OpenGPT 4o (DEV instance)" →
cmdb_ci_ai_model_deployment(Consumed By DEV Function CI) - "Azure OpenGPT 4o (TEST instance)" →
cmdb_ci_ai_model_deployment(Consumed By TEST Function CI)
Application Services:
- Application Service (DEV) →
cmdb_ci_service_auto— populated via Tags OR CMDB Group from DEV CI - Application Service (TEST) →
cmdb_ci_service_auto— populated via Tags OR CMDB Group from TEST CI
DEV and TEST use separate Service Instances because they are separate deployment environments requiring independent change management and incident scope.
What This Means in Practice
The three-layer data model gives organisations something they have never had before: environment-specific AI governance. With CIs in place, you can:
- Pause the EU deployment of an agent without affecting AMS or APAC
- Raise a change request specifically for the TEST environment model deployment
- Know exactly which version of a model is running in production vs. development
- Trace service impact when an AI agent goes down — through the Service Instance to the Business Application
- Govern SaaS AI through Digital Assets even when you can't see the deployment
Getting Started
The AICT data model is live and available. To begin:
- Activate the AICT Core plugin and update the Data Foundations plugin — enables Product Model tables, Digital Asset tables, and the hourly NowAssist sync job
- Submit AI assets via intake — Employee Center → Technology Services → AI Assets.
- Configure cloud discovery connectors — AICT SGC for AWS (Bedrock, SageMaker) and GCP Vertex for automated CI creation
- Tag CIs and configure Service Instance population — bridge from AI governance into ITSM, change management, and service impact workflows