AIBOM management: model registry, versions and approvals

An AIBOM that is generated once and filed away is stale within weeks. Management means tying the AIBOM to the model lifecycle so every version, approval and retirement is recorded.

Why AIBOMs need active management

AI components change more often than most software dependencies. A model may be retrained weekly, a dataset refreshed nightly, and a hosted model version changed by its provider. The EU AI Act requires technical documentation for high-risk AI systems to be kept up to date ^[1] and retained for ten years after the system is placed on the market or put into service ^[2]. RBI's FREE-AI report calls for board-approved AI policies that cover lifecycle management ^[3]. Both assume an inventory that follows the lifecycle.

The registry as the backbone

A model registry already holds much of what AIBOM management needs. MLflow's registry, for instance, versions models automatically, uses aliases to point environments at specific versions, supports tags such as validation_status:approved at version level, and links each version to the run that produced it ^[4]. A workable pattern is:

• each registered model version has exactly one AIBOM;
• the AIBOM references the version by identifier and artefact hash;
• approval status is recorded in both places, with the AIBOM holding the evidence.

Models that bypass the registry, such as hosted APIs or models embedded in vendor products, need their own AIBOM entries with an owner responsible for keeping them current.

Versioning rules

CycloneDX supports versioned BOM documents, and the CycloneDX CLI can diff two BOMs ^[5], which makes these changes reviewable.

Approval workflow

1. Submit. The model owner registers a version and its AIBOM.
2. Validate. Automated checks confirm schema validity and required fields, such as those in CERT-In Table 10 ^[6]. See AIBOM validation.
3. Assess risk. Security reviews framework vulnerabilities, model scanning results and provenance; the business reviews intended use and limitations.
4. Approve. The approver, date and conditions are recorded against the AIBOM version.
5. Promote. Only approved versions can be given production aliases.

Ownership and review

Each AIBOM needs a named owner. Schedule periodic reviews for models whose inputs change outside your control, such as hosted APIs and models that consume live data. ISO/IEC 42001's Annex A objectives on AI system life cycle and third-party relationships give a structure for assigning these responsibilities ^[7].

Common failure modes

• AIBOMs stored as attachments in tickets, with no link to the deployed version.
• Approvals recorded in chat or email instead of against the version.
• Retired models deleted, leaving no record for incident review or audits.
• Hosted model changes that nobody notices because no AIBOM entry exists.

Measures worth tracking

A small set of measures shows whether management is working. Track the share of production models with a current, validated AIBOM; the number of models running without an approval record; the time between a model change and the matching AIBOM update; and the number of hosted AI services with no named owner. Falling numbers on the last three are a better sign of control than the size of the inventory. Report them to the same committee that approves models, so gaps are visible to the people who can close them.

How IntelliXBOM helps

IntelliXBOM keeps every AIBOM version with diffs, validates each against required-field policies, and links models to owners and the business services that depend on them. Correlation with vulnerabilities and licences supports approval decisions, and the result is recorded as timestamped evidence.