By NHI Mgmt Group Editorial TeamPublished 2026-03-31Domain: Best PracticesSource: Collibra

TL;DR: More than 70% of organisations now use AI in at least one business function, according to McKinsey, and code-first AI registration lets developers register models, versions, and use cases directly from development workflows, reducing manual documentation gaps and improving traceability, per Collibra research. Governance that starts after deployment is too late for fast-moving AI estates.


At a glance

What this is: This is a product update about automatically registering AI models from development workflows, with the key finding that governance moves earlier in the AI lifecycle.

Why it matters: It matters because IAM, governance, and risk teams need traceability and ownership before AI systems reach production, not after documentation has already drifted behind deployment.

By the numbers:

👉 Read Collibra's post on automatically registering AI models from code workflows


Context

AI governance breaks down when model inventory is captured after deployment rather than during development. The result is incomplete metadata, weak traceability, and AI systems that enter production without a clear governance record.

Code-first registration addresses that gap by moving model onboarding into the engineering workflow, where the model, version, and use case are first created or changed. For AI governance teams, the practical question is no longer whether to document models, but how early that documentation becomes authoritative.


Key questions

Q: How should teams prevent AI models from bypassing governance during development?

A: Teams should make registration part of the normal development workflow, not a manual post-deployment task. The strongest control is a release gate that requires model metadata, version information, and use case linkage before a model can progress into production. That turns governance into a prerequisite for delivery rather than a cleanup step after assets are already live.

Q: When does AI model governance usually fail in practice?

A: It usually fails when documentation begins after deployment. At that point, model inventories are already stale, relationships to use cases are missing, and engineering teams have moved on to newer versions. Governance is weakest when it depends on manual follow-up instead of capturing model details at the moment the asset is created.

Q: How can organisations know whether AI model registration is actually working?

A: Look for complete traceability from development repository to governance record. If model name, framework version, source code location, and use case are consistently present, the process is working. If teams still find unregistered models in notebooks or pipelines, the workflow is not embedded deeply enough to be reliable.

Q: What should governance teams do with AI assets that exist outside the register?

A: Treat them as shadow AI until they are identified, documented, and assigned an owner. The immediate goal is to reconcile engineering inventories with governance records so that unregistered models do not continue to move through the lifecycle without accountability.


Technical breakdown

Code-first AI registration in development workflows

Code-first registration embeds AI asset onboarding into the same environment where models are built. A CLI workflow scans a local project or repository, detects models, and prompts the developer to select the relevant use case and version. The key mechanism is not discovery alone, but the immediate capture of governance metadata at the point of development, before deployment or handoff. That reduces reliance on manual inventory processes that tend to lag behind engineering reality.

Practical implication: governance teams should treat development-time registration as the control point, not a post-deployment cleanup task.

Model metadata, version control, and use case linkage

The governance value comes from the metadata captured during registration: model name, framework version, source code location, and relationships between models and AI use cases. Those fields create a baseline for traceability, letting teams answer what model exists, where it came from, and which business use case it serves. Without that linkage, lifecycle decisions such as review, retirement, or exception handling become harder because the model exists in engineering systems but not in governance records.

Practical implication: require version and use case linkage as minimum registration data before an AI asset can progress.

AI governance onboarding before production release

This approach shifts governance onboarding left. Instead of discovering AI assets after they are already live, the registration step creates an early governance record that can be connected to broader oversight processes. That matters in environments where models are iterated frequently and deployment velocity exceeds manual review capacity. The operational issue is not just visibility, but whether governance can keep pace with engineering change without creating a backlog of unregistered assets.

Practical implication: align release gates so that unregistered AI assets cannot move from development into production unchecked.


NHI Mgmt Group analysis

Code-first registration closes the AI inventory gap, but only if governance authority starts in development. Manual documentation after deployment is too slow for modern AI delivery pipelines. When developers can register models where they build them, governance stops being an after-the-fact recordkeeping exercise and becomes part of the asset lifecycle. The implication is that AI governance programmes need a development-time control point, not just a production review process.

Model traceability is now a lifecycle control, not a documentation feature. Capturing model name, framework version, source code location, and use case association creates the minimum evidence needed for later review, exception handling, and retirement decisions. Without those relationships, teams cannot reliably distinguish active AI assets from stale or shadow models. Practitioners should treat traceability as a governance requirement tied to release readiness.

Early onboarding reduces shadow AI risk by making the registration path easier than the exception path. When governance depends on manual follow-up, untracked models accumulate quietly in notebooks, repositories, and pipelines. A code-first workflow narrows that gap by aligning governance with engineering behaviour instead of asking teams to leave their normal tools. The practical conclusion is that AI governance succeeds when it fits the workflow developers already use.

The control problem is timing, not intent. The article reflects a common failure mode across AI programmes: governance starts after the asset is already in motion. That is a programme design issue, not a user discipline issue. For practitioners, the lesson is to move ownership, registration, and oversight to the point where the model is first created.

From our research:

  • 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025.
  • 15% of commit authors have leaked at least one secret in their contribution history, which shows how quickly development workflows can become identity and secrets exposure points.
  • For the governance angle that sits closest to this topic, see Ultimate Guide to NHIs - Lifecycle Processes for Managing NHIs for how registration, rotation, and offboarding should be tied together.

What this signals

Code-first registration will only matter if it becomes part of the same control plane that already governs software change. AI programmes rarely fail because teams lack intent. They fail because the inventory, ownership, and approval steps sit outside the delivery path, so the governance record is always one release behind.

The practical next step is to align AI registration with broader identity lifecycle discipline, especially where models have owners, dependencies, and business use cases that change over time. That is where the NIST Cybersecurity Framework 2.0 and identity governance thinking converge: asset visibility only matters if it can drive action.


For practitioners

  • Make registration a development-time gate Require AI models to be registered before merge or release, not after deployment. Tie the registration step to the same workflow that records source code location, framework version, and the use case the model serves.
  • Standardise the minimum model metadata set Define the fields that every AI asset must capture: model name, version, source location, owner, and business use case. Use that same schema across notebooks, repositories, and CI/CD-driven model delivery paths.
  • Block promotion of unregistered AI assets Add a control that prevents models from moving into production environments until governance registration is complete. This should be enforced consistently so that exceptions remain visible and time-bound.
  • Reconcile development inventories with governance records Run periodic checks between engineering repositories and the governance platform to identify models that were created but never formally onboarded. Use the gap to surface shadow AI and stale versions that no longer match current use cases.

Key takeaways

  • Code-first AI registration moves governance into the development workflow, which is where AI inventory problems begin.
  • Traceability depends on capturing model name, version, source location, and use case before production, not after deployment.
  • Teams should make registration a release prerequisite so shadow AI does not accumulate outside the governance record.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-4Access and governance controls matter when AI assets are onboarded from development workflows.
NIST AI RMFAI RMF GOVERN fits the need for ownership and traceability across the AI lifecycle.
OWASP Agentic AI Top 10Agentic and AI system governance benefits from early asset registration and lifecycle visibility.

Treat model registration as part of AI system governance and require a traceable inventory before release.


Key terms

  • Code-first AI registration: A workflow that registers AI models directly from the development environment instead of waiting for manual documentation later. It improves traceability by capturing model details, version information, and use case context while the asset is still being built and changed.
  • Shadow AI: AI systems or models operating outside formal governance, inventory, or approval processes. In practice, these are assets that engineering teams can create or run without the security, risk, or ownership records needed for reliable oversight.
  • Model traceability: The ability to follow an AI model from source code and development environment through to governance records and business use case. It is essential for ownership, review, and retirement decisions because it shows what the model is, where it came from, and why it exists.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Collibra: Automatically register AI models from code workflows. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-03-31.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org