Architecting the AI Control Tower: How to Extend Your CMDB for Next-Gen AIOps

Credit : Gemini

In my experience architecting enterprise solutions and diving deep into CMDB suites to ensure flawless project execution, one operational truth remains constant: You can’t manage what you can’t see. For decades, IT Operations teams have perfected the art of tracking infrastructure by mapping servers, applications, and databases in a Configuration Management Database (CMDB). When an outage occurs, AIOps tools parse this structured data to instantly pinpoint the root cause.

But as enterprises rush to deploy Artificial Intelligence, a massive blind spot has emerged. We are plugging unpredictable, probabilistic AI models into critical business services without mapping their underlying dependencies.

To bridge this gap, an enterprise AI inventory must sit squarely within the CMDB. It requires one cohesive data model on a single platform to facilitate cross-functional collaboration — connecting strategic workflows, technology risk, compliance, legal, and security teams.

This is the AI Control Tower. Here is how you build it.

1. Defining the AI Asset Inventory

To govern AI within the CMDB, we must first define the different types of artifacts that make up an AI service. The AI Control Tower categorizes these into explicit new classes:

• AI System: This is the overarching use case, ranging from simple incident classification to highly complex autonomous agents. AI systems utilize machine-based language, operate with various levels of autonomy, and can even nest other subordinate AI systems underneath them to drive an overall outcome.
• AI Model: The core mathematical or computational artifact that powers the AI system. Think of models as specific weights configured to take an input and generate an output. Unlike traditional deterministic software, given the same inputs, models may or may not produce the same outputs every single time.
• Data Sets: The representation of information curated specifically for AI development. These are used to train, evaluate, and benchmark models, and can exist in various formats (files, images, text, CSVs) residing in external sources referenced by the CMDB.
• Prompts: Design-time instructions given to generative AI applications that define what the expected outcome should look like. We track prompt templates because altering them can materially impact the outcome of the AI system.
• Inputs and Outputs: These define what type of input the AI expects and what type of output it produces. Like prompts, these are captured from a design and build point of view; any changes here directly impact the system’s risk profile and the controls you need to apply.

2. The CMDB Class Hierarchy

The AI Control Tower doesn’t build standalone tables from scratch; it utilizes class inheritance to extend foundational product model tables.

• The architecture begins with the base Product Model (cmdb_model).
• Because AI systems are eventually packaged and deployed as applications, the AI System Product Model (cmdb_ai_system_product_model) extends from the existing Software Component Product Model (cmdb_software_component_product_model).
• Conversely, models, data sets, and prompts are bundled within that overall experience, so they extend from the Content Product Model (cmdb_content_product_model).
• Specifically, the Content Product Model leads to the AI Content Product Model (cmdb_ai_content_product_model), which acts as the parent to the AI Model Product Model (cmdb_ai_model_product_model), AI Dataset Product Model (cmdb_ai_dataset_product_model), and AI Prompt Product Model (cmdb_ai_prompt_product_model).

Credit : ServiceNow — AI Asset Inventory: Product Model diagram

3. Mapping the AI Service Lifecycle

Credit : ServiceNow and Gemini

Integrating AI into operations requires mapping it to a modern Common Service Data Model (CSDM) framework. Here is how AI assets mature from ideation to production:

• Design & Planning: During this phase, existing foundational entities like the Product Model split into CMDB SW Component and CMDB Content. These connect directly to the new AI Inventory classes: AI System, AI Content, AI Model, AI Dataset, and AI Prompt.
• Build & Integration: As abstract designs become actual assets, existing entities (Asset -> Information Asset -> Digital Asset) map to the newly created AI digital assets. This tracks the instantiated AI System, AI Model, AI Dataset, and AI Prompt.
• Service Delivery: Once deployed into production, these digital assets are delivered in two primary ways. They are either mapped as an “AI & Model Application” (for local hosted software) or as an “AI Function” (hosted by a cloud provider).
• Consumption: Finally, these delivery methods culminate in a standard Service Instance, allowing the business to consume the AI capabilities seamlessly.

Real-World Example: AI-Based Credit Scoring

To see how this hierarchy transforms Operations, let’s look at a practical scenario: an AI-Based Credit Scoring for Loan Approvals system.

To the business, this is a single application. But mapped within the AI Control Tower, it is a complex dependency tree:

• The Models: This single AI system leverages multiple models concurrently, such as an internal enterprise LLM, a public OpenAI model, and a specialized model hosted on Azure.
• The Data Sets: Operations can see exactly what fuels these models. The system relies on a “Financial Info” data set for income and payment history, “Public Records” for bankruptcy filings, and “Financial Behavior” data capturing spending and saving habits.

Credit : ServiceNow -AI System Dependency Flow diagram

If loan approvals suddenly drop, AIOps tools no longer throw generic alerts. They can immediately trace the anomaly through the CMDB to see if a specific cloud model drifted, or if the public bankruptcy data set was corrupted.

4. Populating the AI Inventory

An inventory is only as good as its data accuracy. Modern AI Control Towers populate the CMDB through a variety of automated and manual methods:

• Hyperscaler Integrations: Point integrations automatically bring in agents, models, and tools from platforms like Azure Foundry, AWS Bedrock, GCP, and Copilot.
• Auto-Discovery: Native capabilities automatically discover AI skills, agents, and data sets already operating within your primary enterprise platform.
• REST APIs: For assets tracked in spreadsheets or common external repositories, robust APIs import both the artifacts and their complex relationships.
• Manual Entry: Users can request or register AI systems manually via enterprise portals or dedicated workspaces using record producers.
• Multi-Instance Management: The architecture can synchronize inventories across instances, allowing development teams to test agents in lower environments and seamlessly track them into production.

Conclusion

The future of AIOps isn’t just about using AI to fix IT problems — it’s about applying IT discipline to AI itself. By formally defining AI Systems, Models, Data Sets, and Prompts within your CMDB, you empower cross-functional teams to manage changes safely, mitigate compliance risks, and scale enterprise AI with total confidence using various solutions from ServiceNow like Now Assist ,Event Management, Health log Analytics and AI-powered ITSM to empower SRE teams to reduce MTTR and key operational metrics .