Security teams should start with a comprehensive AI inventory that captures users, workflows, systems, and applications across approved and shadow environments. Without that baseline, discovery, detection, and policy enforcement will miss large parts of actual usage. The goal is not to block AI adoption, but to understand where it exists well enough to govern it consistently and reduce blind spots.
What an AI visibility baseline actually needs to capture
An effective baseline is broader than a list of approved tools. It should show where AI is being used, who is using it, what business workflows it touches, and which systems or applications are part of that path. That includes sanctioned deployments, employee experimentation, and shadow usage, because each creates a different governance and control problem.
The practical test is whether a security team can explain the exposure without guessing. If the inventory does not distinguish users, workflows, systems, and applications, then later control decisions will be built on partial sightlines rather than on the real usage pattern.
That baseline also has to be current enough to reflect change. AI usage tends to appear first in small pockets, then spread through teams, browser workflows, integrations, and SaaS features before it is formally approved, so a one-time discovery exercise quickly becomes stale.
Why discovery comes before enforcement
Controls work only when the team knows what it is trying to govern. If enforcement starts before discovery is complete, policy will be applied unevenly, high-value use cases will be blocked by accident, and unauthorized use will continue in the blind spots the control was meant to close.
A baseline lets teams separate three questions that often get collapsed together: what AI is present, how it is being used, and whether that use is acceptable. Discovery answers the first question. Enforcement should follow only after teams can see enough of the environment to make the policy decision intentionally.
This order also matters for operational credibility. When users experience controls that do not match real work patterns, they route around them. A good baseline reduces that mismatch and gives security teams the evidence needed to enforce consistently rather than selectively.
How to turn visibility into a usable control baseline
Start by normalising AI into a few practical categories: approved enterprise tools, embedded AI features inside existing platforms, custom or internal AI services, and unsanctioned usage. Those categories help security teams compare risk and policy coverage without treating every instance as the same thing.
Then map each discovered use case to the workflow it supports and the systems it can touch. The important question is not just which model or product is involved, but what data it can see, where outputs go, and whether the interaction creates a new trust boundary. That is where visibility becomes actionable for policy, logging, and review.
Use the inventory to identify control gaps such as missing approval paths, unowned integrations, or duplicate tools solving the same business problem in different ways. A baseline should not only describe what exists, it should show where governance will fail if controls are enforced too early or too narrowly.
Risk and Threat Considerations
An incomplete AI baseline creates a detection and governance blind spot. Security teams may believe they are enforcing policy on the full estate when, in practice, the highest-risk usage sits in shadow environments, browser extensions, ad hoc SaaS features, or unsanctioned integrations that were never inventoried.
Failure mechanism: Discovery misses one or more usage paths, so controls are designed around the visible subset and do not cover the actual places where sensitive data, workflows, or decisions are flowing.
Impact: Policy enforcement becomes inconsistent, shadow usage persists, and the organisation can neither measure exposure nor prove that controls are covering the full AI footprint.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-1 — Inventory and Control of Enterprise Assets | AI visibility baselines depend on knowing where AI tools and usage exist. |
| Recommendation — Inventory approved and shadow AI assets before enforcing policy. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems within the organization are inventoried | The question is about building a baseline inventory before control enforcement. |
| Recommendation — Establish and maintain an inventory of AI systems, tools, and usage locations. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | A usable AI baseline requires an inventory of the components and platforms in scope. |
| Recommendation — Maintain an accurate inventory of AI-related components and platforms. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | AI visibility depends on identifying the assets and services that need governance. |
| Recommendation — Document AI-related assets and services before applying governance controls. | ||
| CSA Cloud Controls Matrix | AIP — Application & Interface Protection | AI usage often appears inside applications and interfaces that need discovery and governance. |
| Recommendation — Map AI-enabled applications and interfaces before enforcing controls. | ||
Practitioner Guidance
What to prioritise: Build the baseline around business reality, not around vendor approval lists. If a workflow uses AI to handle sensitive content, influence customer decisions, or automate operational steps, it belongs in the inventory even if it is hidden inside a broader application.
What to verify: Confirm that the inventory captures both sanctioned and unsanctioned usage, and that each entry has an owner, a workflow context, and a system boundary. If any of those three are missing, the baseline is not yet good enough to drive enforcement.
Common mistake: Teams often try to enforce by tool name only. That misses embedded AI features and informal user behaviour, which are usually where the control gap appears first.
Practitioner takeaway: Do not treat visibility as a reporting exercise. Treat it as the prerequisite for defensible control design, because you cannot govern AI consistently until you know where it actually lives and how it is being used.
Related resources from NHI Mgmt Group
- How should security teams build visibility into assets and identities before they try to improve cyber controls?
- How should security teams implement a practical data classification programme before they enforce controls?
- Why do security teams need automated data discovery before they can enforce meaningful data protection controls?
- How should security teams build a DLP programme before they deploy cloud controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
