What should organisations do first when adopting secure AI guidance from NCSC and CISA?

Why an AI inventory comes before controls

Secure AI guidance from both NCSC and CISA starts with knowing what is actually in use, because control decisions depend on the system, data, and dependency set you are trying to govern. Without an inventory, teams tend to protect the loudest or newest AI use case while missing shadow deployments, third-party services, and embedded AI features inside existing products. A current inventory also makes it easier to decide which systems need deeper review, which can remain under standard security controls, and where ownership is unclear. CISA’s cyber threat advisories are useful here because they show how quickly exposure can shift when tooling, dependencies, or attacker techniques change. In practice, many organisations discover the lack of an AI inventory only after a model, service, or data flow has already been approved through a non-AI process.

What a useful AI inventory actually contains

A practical inventory is more than a list of model names. It should capture the business purpose, owner, deployment location, vendor or internal build status, data inputs, output consumers, and the systems that can change or call the AI component. It should also record whether the AI is embedded in another product, exposed through an API, used by employees directly, or connected to automated workflows. That detail matters because a large language model used for drafting content, a recommendation engine in production, and an AI agent with tool access create very different assurance needs.

The inventory should also show lifecycle state. Teams need to know whether a system is in pilot, production, retired, or paused, because the right controls differ at each stage. If the inventory only captures what exists at a point in time, it will fail as soon as teams spin up a new tenant, replace a vendor, or connect a model to sensitive data. The most useful inventories are tied to change management, procurement, and architecture review so the record stays current rather than becoming a one-off spreadsheet.

• Identify the system owner and the approving business function.
• Record the model or service source, hosting model, and integration points.
• Note the data categories involved, especially sensitive or regulated data.
• Capture whether the system can act autonomously or trigger downstream actions.
• Track lifecycle status so retired or experimental systems are not treated as active.

Where organisations already maintain asset or application registers, the AI inventory should extend those records rather than sit in a separate silo. That creates a cleaner route to risk assessment, logging, testing, and incident response.

Where the first-step rule breaks down

Starting with inventory is the right default, but it does not mean every AI use case deserves the same depth on day one. Tighter inventory requirements often increase operational overhead, so organisations need to balance coverage against the effort of keeping records accurate. For low-risk pilots with no sensitive data and no external exposure, a lightweight register may be enough at first, while customer-facing or high-impact systems need much stronger detail and review.

The main edge case is embedded AI that arrives through a broader platform or SaaS product. These systems are easy to miss because the organisation did not “adopt AI” in the usual sense, yet the AI capability can still affect data handling, output trust, and change control. Another common exception is agent-like automation, where the AI can take actions across tools or services; even when the underlying model is outsourced, the control problem is not just model quality but delegated execution authority. Guidance is still evolving in some areas, so organisations should treat the exact depth of evidence as a governance decision, not a fixed universal standard.

What teams get wrong is assuming that an approved vendor contract or cloud subscription automatically gives them visibility into every AI function in use. That assumption fails when teams can enable new features faster than governance can track them.

Risk and Threat Considerations

The main risk in AI adoption is not just poor model performance, but unmanaged exposure. If an organisation cannot see what AI systems exist, it cannot reliably assess data leakage, unauthorised use of sensitive inputs, unsafe integrations, or over-privileged automation. The problem scales quickly when AI features are embedded in existing platforms, because the security team may inherit new trust boundaries without a corresponding review.

Failure mechanism: Shadow AI, unmanaged third-party services, and stale records break the assumption that security teams know which systems need controls, monitoring, and approval. That gap creates missed data paths, unreviewed prompts or outputs, and blind spots in change management and incident response.

Impact: Sensitive data can be exposed to the wrong service, high-risk systems can bypass review, and incidents become harder to contain because owners, dependencies, and downstream consumers are unclear.

Practitioner Guidance

What to prioritise: Start with business-critical and externally exposed AI first, then move to internal tools and embedded features. If a system can access sensitive data, influence decisions, or trigger actions, it belongs at the front of the queue.

What to verify: Confirm that each inventory entry has a named owner, a current purpose, and an update trigger. The record is only trustworthy if it changes when a team launches, replaces, disables, or repurposes an AI system.

Common mistake: Treating the inventory as a procurement exercise. The useful version is operational, because security and governance decisions depend on what is actually live, not what was once approved.

Practitioner takeaway: The first control is visibility, but the real test is whether the inventory is wired into the processes that change AI systems, otherwise it becomes stale before it can support governance.

Related resources from NHI Mgmt Group

• Should organisations prioritise discovery or access restriction first for shadow AI?
• Should organisations prioritize visibility or least privilege first for AI agents?
• Should organisations prioritise tool scoping or skill governance first for AI agents?
• Should organisations prioritise least privilege or lifecycle governance first for AI agents?