Most enterprises do not lose control of AI because they lack a policy.

They lose control because nobody can answer the operational inventory questions fast enough: which AI systems exist, who owns them, which data they can see, which tools they can call, which model routes they use, which eval gate approved them, what changed last week, and how to shut one down without breaking a business process.

An enterprise AI system registry is the inventory that makes those questions answerable. It is not a spreadsheet for annual compliance. It is the control-routing table for production AI.

The practical question for CIOs, CISOs, enterprise architects, and AI platform teams is this:

What must be registered before an AI system is allowed to touch enterprise data, tools, decisions, customers, employees, or operations?

My answer: register the system at the level where governance decisions happen. Not only the model. Not only the application. Not only the vendor. The useful registry record connects purpose, owner, users, data sources, model routes, tools, permissions, eval evidence, audit logs, risk tier, lifecycle state, and retirement plan.

This builds on the control-plane view in AI governance architecture, the accountability model in AI ownership, the data controls in RAG governance, the action boundary in designing a safe tool registry, the evidence model in agent audit logs, and the release discipline in eval gates for enterprise AI workflows.

The Registry Is A Production Control

An AI system registry should answer one operational question:

1

Is this AI system known, owned, bounded, evaluated, observable, and removable?

That question is wider than asset management. A normal software inventory might record application name, owner, environment, repository, runtime, and vendor. An AI registry needs those fields, but it also needs the parts that change AI risk:

• the business purpose the system is allowed to serve,
• the user population and workflow context,
• the data classes and source authorities it can reach,
• the retrieval indexes and memory stores that can enter context,
• the model providers, model versions, routes, and fallback paths,
• the tools it can call and the authority level of those tools,
• the policy bundle and approval workflow that enforce boundaries,
• the eval gate that approved the current version,
• the audit trace location for investigation and replay,
• the lifecycle state and decommissioning path.

The NIST AI RMF Core is unusually direct on this point: organizations need mechanisms to inventory AI systems, resourced according to risk priorities. It also calls out safe decommissioning. The engineering translation is simple. If the enterprise cannot inventory an AI system, it cannot reliably measure, contain, update, approve, or retire it.

The registry is therefore not documentation after the fact. It is a dependency of runtime governance.

Register Systems, Not Just Models

The most common registry mistake is to stop at model inventory.

Model inventory is useful, but it is not sufficient. The same model route can be low risk in one system and high risk in another. A model used to summarize public documentation is not the same system as the same model used by an agent that retrieves confidential contracts and creates purchase orders.

Register the AI system as the unit of governance:

This structure avoids a dangerous ambiguity. When someone asks “is GPT approved?” the answer should be “approved for which system, purpose, data classes, model route, and authority level?”

Approval belongs to a bounded system context, not to a model name in isolation.

The Minimum Registry Record

A useful registry record should fit in a database row plus linked evidence. It should not become a 40-page questionnaire that teams bypass.

Here is a practical minimum:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

{
  "ai_system_id": "vendor_onboarding_assistant",
  "name": "Vendor Onboarding Assistant",
  "lifecycle_state": "limited_production",
  "business_purpose": "prepare vendor onboarding packets and risk-screening drafts",
  "accountable_owner": "procurement_operations",
  "technical_owner": "enterprise_ai_platform",
  "security_owner": "application_security",
  "data_owners": ["vendor_master_data", "procurement_policy"],
  "user_population": "procurement analysts in EU business units",
  "authority_level": "execute_with_approval",
  "data_classes": ["internal", "confidential_vendor_data"],
  "source_authorities": [
    "procurement_policy_index",
    "vendor_master_read_api"
  ],
  "model_routes": [
    {
      "route": "reasoning_primary",
      "provider": "approved_model_gateway",
      "retention_mode": "enterprise_no_training",
      "fallback": "reasoning_secondary"
    }
  ],
  "tools": [
    "vendor_read_v2",
    "vendor_packet_draft_v3",
    "risk_screening_submit_requires_approval_v1"
  ],
  "policy_bundle": "ai_policy_procurement_v14",
  "eval_gate": "eval_2026_09_07_0845",
  "audit_stream": "ai_audit_procurement_vendor_onboarding",
  "incident_playbook": "ai_incident_procurement_agent_v2",
  "last_material_change": "2026-09-03",
  "next_review_due": "2026-12-07",
  "decommission_plan": "disable tool grants, archive traces, revoke index access, export owner report"
}

The fields are intentionally operational. They are designed to drive access checks, deployment gates, review queues, incident response, and retirement work. If a field cannot influence a decision, it probably belongs in secondary documentation.

The NCSC secure AI system development guidance is useful here because it treats AI-related assets broadly: models, data, prompts, software, documentation, logs, assessments, and known failure modes. That is closer to how production AI actually breaks. The prompt bundle, eval suite, retrieval source, and log stream may be as important as the deployed model.

Make Relationships First-Class

The registry should not be a flat list of AI apps. It should expose relationships.

1
2
3
4
5
6
7
8
9
10
11
12
13

AI system
  -> accountable owner
  -> user population
  -> business workflow
  -> data sources and indexes
  -> model routes
  -> tool connectors
  -> permission policy
  -> approval workflow
  -> eval gate
  -> audit stream
  -> incident playbook
  -> decommissioning plan

These relationships are what make the registry useful during real work.

If a data owner revokes a source, the platform should know which AI systems are affected.

If a model route changes, release managers should know which eval gates must rerun.

If a tool connector adds write authority, security should know which approval policies and audit events must change.

If an incident occurs, responders should know where traces live, which owner can approve containment, and which systems share the same vulnerable component.

If a business process is retired, operators should know which AI systems need decommissioning rather than leaving a forgotten assistant with stale access.

A registry that cannot answer dependency questions is only a catalog. A registry that can answer them becomes part of the control plane.

Lifecycle State Should Control Authority

Every registered AI system should have a lifecycle state, and that state should constrain what the system is allowed to do.

This state should not be decorative. The platform should use it.

A sandbox system should not receive production service credentials. A pilot system should not call high-risk write tools for all users. A contained system should have narrower model routes, disabled tools, or stricter approvals. A retired system should lose active data and tool grants.

This is where registry design meets policy-as-code for enterprise AI agents. The policy engine should be able to use registry state as an input. If the registry says the system is in pilot, policy should enforce pilot authority.

Use The Registry To Trigger Gates

The registry is not only where approvals are stored. It should trigger the work that invalidates old approvals.

Use material-change rules:

The registry should make these triggers visible before the change reaches production.

OWASP’s AI Agent Security Cheat Sheet is useful because it ties production agents to structured adversarial testing, release gates, validation evidence, least privilege, approval controls, and monitoring. A registry gives those controls a place to attach. Without a system record, the tests may run once, but nobody can tell which production authority they still justify.

Separate Registry Fields From Evidence

Do not put every control artifact inside the registry. That makes it slow, noisy, and brittle.

The registry should store stable pointers:

This keeps the registry small enough to maintain while still making it the entry point for governance decisions.

The article on AI incident response makes the same point from the responder side: when something goes wrong, the organization needs traceability across prompts, retrieval, policy, tools, approvals, and output. The registry is how responders find the right trace surface without starting from Slack archaeology.

Risk Tier Decides Registry Depth

A registry should not impose the same evidence burden on every system.

Use risk tiers:

This is not a universal compliance taxonomy. It is a practical way to avoid overloading harmless systems while putting serious control depth where consequence is real.

The NIST Generative AI Profile is helpful because it keeps the focus on context of use. For a registry, context of use means the record must capture not only what the AI is, but what it is doing, who it affects, and which controls stand between output and consequence.

Do Not Let The Registry Become Shelfware

AI registries fail when they are maintained only by governance teams. The source of truth has to sit close to delivery and runtime systems.

Good registry signals should come from:

• platform onboarding forms,
• CI/CD deployment metadata,
• model gateway configuration,
• vector-index creation and source-registration workflows,
• tool registry approvals,
• identity provider app registrations,
• policy bundle releases,
• eval gate results,
• audit stream provisioning,
• incident management tickets,
• data owner reviews.

Manual review is still necessary, but manual entry should not be the main operating model. If engineers can deploy a new model route, create a vector index, or grant a tool scope without updating the registry, the registry will drift.

A better pattern is to make registry updates part of the production path:

1
2
3
4
5
6
7
8

register system
  -> assign owners
  -> declare data and authority
  -> attach sources, models, tools, policies
  -> run required gates
  -> approve lifecycle state
  -> provision runtime access
  -> monitor changes

The runtime access step should depend on registry status. That is the difference between an inventory and an enforceable control.

The First Ninety Days

Do not start by building a perfect enterprise metadata platform. Start by making the most dangerous unknowns visible.

Week 1 to 2:

• define the unit of registration: AI system plus workflow context,
• agree on risk tiers and authority levels,
• create the minimum record schema,
• choose the first owners: accountable, technical, security, data.

Week 3 to 6:

• inventory production and pilot systems,
• map model routes, data sources, tool connectors, and audit streams,
• mark unowned systems and unknown data access as remediation items,
• require registry records for new AI platform onboarding.

Week 7 to 10:

• connect registry state to eval gate requirements,
• connect tool access to registered lifecycle state,
• add material-change triggers for model, prompt, data, tool, policy, and user-population changes,
• define containment and retirement states.

Week 11 to 13:

• review the top-risk systems with owners,
• freeze authority expansion for records missing owners, eval evidence, or audit streams,
• turn the registry into a dashboard for AI platform, security, and business process owners,
• make decommissioning a normal workflow, not an exceptional project.

The first milestone is not “all AI is governed.” The first milestone is that no production AI system with meaningful data or action authority is unknown, ownerless, unevaluated, unaudited, or impossible to contain.

A Registry Is Where Governance Becomes Executable

Enterprise AI governance needs policies, standards, architecture, review boards, and training. But those things do not operate the system by themselves.

The system registry is where governance becomes executable:

• owners become routable responsibilities,
• data classifications become access rules,
• model routes become approved runtime choices,
• tool scopes become enforceable authority boundaries,
• eval results become release decisions,
• audit streams become investigation paths,
• incidents become containment triggers,
• lifecycle states become permissions.

This is also why the registry should be treated as infrastructure. If the registry is wrong, stale, or optional, the governance program is guessing.

OWASP AISVS is a useful signal for where the field is going: AI security controls are becoming more testable, lifecycle-aware, and system-specific. A registry does not replace verification. It tells the enterprise which system needs which verification, who owns the result, and whether production authority still matches the evidence.

That is the standard I would use for production AI: no meaningful authority without a current system record.