Tracked AI

What “tracked” means in AI inventory management

Tracked AI sits between discovery and enforcement. The organisation knows the system exists, can list it in an inventory, and has acknowledged it as part of the estate, but the control plane has not yet been made authoritative at the point where the AI actually acts.

Why tracked AI is not yet controlled AI

The distinction matters because inventory is only a visibility layer. A tracked system can be named, classified, and assigned an owner, yet still operate with rules that are advisory, manually checked, or applied outside production workflows. That gap is common when governance is documented faster than controls are embedded.

Tracked AI therefore signals partial maturity rather than full operational control. It shows that the organisation has moved past shadow use, but has not completed the work needed to make policy enforceable in runtime behaviour, approval paths, or access decisions.

Where tracked AI typically appears

This state often shows up in AI programmes that are building their first inventory, in pilot deployments that have not been integrated into security controls, or in business teams that use approved tools before central governance catches up. The result is an AI system that is visible to planners but still behaves as if governance is optional.

• It may be listed in an asset register, CMDB, or model inventory without being bound to guardrails.
• It may have a named owner, but no enforced operational policy for use, review, or change.
• It may be known to security and compliance teams, yet still rely on manual review for sensitive actions.

What tracked AI tells you about control maturity

Tracked AI is a useful indicator because it distinguishes awareness from enforcement. That distinction helps security, governance, and platform teams see where the organisation has evidence of existence but not yet evidence of control. The practical question is whether the system’s behaviour is still shaped by policy documents or whether policy is already embedded into the runtime path.

For a broader control lens, inventory alone is not enough to establish assurance. NIST CSF 2.0 treats governance, identification, protection, and monitoring as separate functions, which is why a tracked system should be treated as a control gap until its actions are actually constrained. NIST Cybersecurity Framework 2.0 is a useful reference point for that progression.

Risk and Threat Considerations

Tracked AI creates a visibility-to-control gap: the organisation knows the system exists, but its use can still drift beyond policy, especially when deployment teams, business users, and platform owners each assume someone else is enforcing the rules. That makes tracked AI a common precursor to overreach, uncontrolled access, and inconsistent governance.

Failure mechanism: The inventory is treated as evidence of control, so enforcement never reaches the runtime path where prompts, tools, data access, or actions are actually executed.

Impact: The organisation may retain systems that look governed on paper while still allowing unreviewed behaviour, policy bypass, or unmanaged expansion of AI usage.

Practitioner Guidance

Why practitioners should care: Tracked AI is the point where many programmes stall, because visibility can be mistaken for control. The next governance decision is not whether the system is known, but whether its behaviour is bound to an enforceable owner, policy, and operational check.

Practitioner takeaway: Treat tracked AI as an intermediate state, not a steady state, and require a clear path from inventory entry to enforceable control before calling the system governed.

Related resources from NHI Mgmt Group

• What breaks when AI agent ownership is not tracked?
• What breaks when AI agent provenance is not tracked?
• What breaks when AI model sprawl is tracked without identity context?
• What breaks when delegation chains are not tracked for AI agents?