Should AI inventory management sit with security, IT, legal, or procurement?

Who should own AI inventory management?

AI inventory management is not a single-team control, because the inventory itself supports different decisions for different stakeholders. Security typically needs the strongest operational role because it depends on discovery, control validation, and ongoing monitoring. Legal, procurement, and the business all need defined inputs so the inventory remains complete, current, and usable.

The practical split is usually shared ownership with one accountable operating owner. That avoids the common failure mode where everyone is “consulted” but no one is responsible for completeness, evidence quality, or follow-through when a new AI tool, model, or agent appears.

A useful way to think about ownership is by decision type: security validates exposure and control state, legal records policy and compliance obligations, procurement governs vendor intake and contractual terms, and business owners confirm whether the use case is approved and who is accountable for it.

Why shared ownership works better than a single gatekeeper

AI inventories become unreliable when they are treated as a procurement list, a security register, or a legal tracker on its own. Each of those views misses something material. Procurement may know the vendor, but not the runtime access path. Security may see the connector, but not the contract constraints. Legal may know the retention clause, but not whether the tool is actually deployed in a production workflow.

Shared ownership works because the inventory has to answer multiple questions at once: what it is, who provided it, where it runs, what data it touches, what approvals exist, and which controls are in place. That is especially important for AI systems that are introduced informally through pilots, department-level subscriptions, embedded assistants, or agent-style automation.

For discovery and lifecycle visibility, the inventory should support the same discipline used in other identity and access management processes, including lifecycle management and ownership tracking. NHIMG’s NHI Lifecycle Management Guide is useful here because the operational problem is similar: if ownership, rotation, and offboarding are unclear, the register quickly stops reflecting reality.

What needs to be recorded so the inventory is actionable

An AI inventory is only useful if it captures enough detail to support decisions after the initial approval. At minimum, the record should identify the tool or model, the business purpose, the owner, the vendor or provider, data categories involved, integrations, human approval status, and any material limits on use. Without that context, the inventory becomes a static list that cannot support review or escalation.

Security should be able to use the inventory to answer control questions, such as whether the system has access to sensitive data, whether it uses external APIs or agents, whether secrets or tokens are involved, and whether the environment is isolated from higher-risk use cases. That makes the inventory part of operational control assurance, not just administration.

Legal and procurement should use the same record to trace contractual obligations, data processing terms, retention rules, model/provider restrictions, and third-party risk obligations. Business owners should use it to confirm that the use case is still legitimate, still needed, and still aligned to the original approval. The inventory should also make shadow AI visible, not just sanctioned platforms. NHIMG’s Shadow AI and AI Agent Discovery Guide is relevant because discovery is often the missing step that turns an inventory into a real control.

When ownership problems become a real risk

Risk usually appears when the inventory is incomplete, stale, or siloed. Then teams cannot tell whether a tool is approved, who can disable it, which data it can reach, or whether the vendor terms match actual use. That creates exposure across compliance, access governance, procurement oversight, and incident response.

One common weak point is unmanaged agent or copilot usage. If an AI tool can act across systems, the inventory has to show who approved the tool, what permissions it has, and whether those permissions still match the business need. NHIMG’s Agentic AI Security Policy Template is a strong example of how ownership, registration, human oversight, and retirement need to be defined together rather than left implicit.

Practitioner Guidance

What to prioritise: assign one accountable operating owner, then define contributing owners for security, legal, procurement, and the business. If the register cannot show who approves, who reviews, and who can remove the system, it is not ready for operational use.

What to verify: confirm that each entry includes a business owner, vendor or provider, data scope, integration scope, and an explicit approval or exception path. If any of those fields are missing, treat the inventory as incomplete rather than merely “in progress.”

What good looks like: the inventory is used as a living control record, not a spreadsheet audit artifact. It should tell teams whether the AI system is sanctioned, who is responsible, what it touches, and what must happen when the use case changes or is retired.

Practitioner takeaway: AI inventory management works best when ownership is shared, but accountability is not. Cross-functional input makes the register accurate; a single operational owner keeps it current and enforceable.

Related resources from NHI Mgmt Group

• Why is single-provider AI agent governance not enough for enterprise security?
• How should security teams handle risks from AI browser extensions?
• How should security teams govern API keys used for generative AI access?
• Who should own third party risk management across security, legal, and procurement?