How do you reconcile your AI system in your CMDB?

If you try to register an AI system running in production within your configuration management database (CMDB) that doesn’t have an extended schema for AI, chances are high that you’ll run into the following conundrum…

Your CMDB has a field for an item’s name and a field for its version. That default level of granularity is insufficient for identifying your AI system, let alone distinguishing it from a growing sea of models within your organisation. Why is this?

Because an AI system has multiple artefacts that must be accounted for to tell it apart from the others. And the number of artefacts you must account for varies based on how it has been deployed.

Today, we explore these artefacts further.

Before going further: the breakdown below is not based on any standard. It is a conceptual model for your consideration. As of now there is no ISO definition of such a component identity, and no CMDB vendor ships a schema for such a formal standard. So please treat what follows as a working strawman.

Firstly, why a hash and not a filename

A sneek peak: the attribute doing the heavy lifting across everything below is your hash. A filename only tells you what something was called. A hash tells you whether it is the same thing you approved.

Where you cannot produce a hash (which is often the case with a vendor API), you need the strongest identifier the provider will give you plus a record of when you last verified it.

Factoring in where you got your AI model from

If you buy a model through an API

You hold no weights at all, the provider does. So your system’s identity is:

1. The model identifier and snapshot
2. The system prompt
3. The inference parameters
4. Any tool or function definitions you’ve exposed
5. The guardrail and filter configuration applied to the deployment
6. A fine-tune job identifier, if you fine-tuned through the vendor’s API

That gives you five attributes to account for, or six if you have fine-tuned. Items two through six sit within your control. The first one does not. Your provider can repoint an alias, deprecate a snapshot, or ship an update and keep the name the same.

A note on managed cloud: on Bedrock and Azure OpenAI, the deployment name is not the model. Two deployments with the same name while pointing at different snapshots is a live failure mode that’s invisible from the application side.

If you self-host

You hold the artefacts. This means:

1. Base model weights
2. The quantisation format they are served in
3. Any adapter or LoRA layered on top
4. The tokenizer and model config
5. The serving stack and its version
6. The guardrail and filter configuration
7. The same system prompt
8. Inference parameters

That gives you eight attributes that are individually mutable, all within your control. Quantisation earns its own line because Q4 and FP16 built from the same source weights behave differently and share a source hash.

And if you do retrieval

Either pattern gains three more attributes:

1. The retrieval index and its version
2. The embedding model that built it
3. The chunking and retrieval configuration that determines what gets pulled in

Two weeks ago I argued that RAG turns the data pipeline into a runtime dependency, and that argument applies here. For most enterprise deployments the retrieval corpus is the single largest determinant of what the system says.

Across the two patterns and the retrieval overlay, that is five attributes at the low end and eleven at the high end.

Where the version number field falls short

Two teams can both report running the same vendor snapshot and produce materially different decisions.

Imagine that one has a system prompt edited last month. One has temperature set higher. One retrieves from an index rebuilt this week, the other from a stale copy. The model identifier is identical for both teams.

The register this calls for is already an obligation. CPS 234 requires classifying information assets by criticality and sensitivity, including those managed by third parties. CPS 230 requires identifying critical operations and the resources they depend on. An AI system carrying a customer-facing decision sits inside both.

APRA’s April 2026 letter to industry then reinforces the point, observing that AI functionality is often embedded within broader software platforms and developer tooling, which reduces transparency over where and how models are trained, updated or constrained.

So when a supervisor asks whether the system in production is the one that was approved, the version string cannot satisfy their query. You need the full component identity for your deployment pattern.

Impact to downstream systems

Other controls read from the asset register, so a shortcoming here propagates to them too:

1. Patching requires knowing which serving stack, which framework version, and which base model you’re running.
2. Recertification works from the register. A component that isn’t listed doesn’t get reviewed.
3. Decommissioning stalls because endpoints stay live and indexes stay queryable long after the project that built them has closed.
4. Incident response cannot answer “what changed” when the answer sits across five to eleven mutable components and only one of them appears in the CMDB.

What an AI system record needs

For each production AI system, you need to record:

1. The full component list for its deployment pattern, each with a hash or a version identifier that changes when the thing changes
2. The dataset version behind any fine-tuning
3. The change record or approval that authorised the current configuration
4. The accountable owner, named as an individual
5. The date and author of the last change to any component

Item three is the one most registers omit but it’s the most important one for this approach. Without it you can’t say whether what is running is what was signed off, even though you produced a hash.

Where do you begin

Pick your highest-criticality AI system. Establish which of the two patterns it follows and whether retrieval is in play. Then ask the team responsible for it to produce the full component list for that pattern, as it stands right now.

If they can, you have a template. If they can’t, you’ve found a control gap on the system with the highest impact, which is a considerably better place to find it than during an incident.

Tomorrow: the three different ways an attacker goes after these artefacts, and why only one of them involves breaking in.