What breaks when teams discover AI after deployment instead of before?

Why This Matters for Security Teams

Late discovery of AI changes the security problem from governance to cleanup. When an AI capability appears in production before it is inventoried, teams cannot reliably apply approval gates, data handling rules, logging, or access restrictions. That weakens control over model risk, prompt handling, and third-party dependencies, and it also creates uncertainty over who owns the system when something fails. The issue is not only technical; it is an operating model gap.

For security and risk teams, the immediate concern is that unseen AI can introduce new data flows, new privilege paths, and new decision influence without ever passing through standard review. A system may look like a normal application on paper while actually sending prompts to external services, exposing sensitive context to a model, or triggering actions through connectors. Guidance from the NIST Cybersecurity Framework 2.0 reinforces that governance, inventory, and continuous risk management are foundational rather than optional. In practice, many security teams encounter the AI component only after a data incident, a customer complaint, or an unexpected automation outcome has already occurred, rather than through intentional approval and inventory.

How It Works in Practice

Discovery before deployment usually means AI systems are identified during procurement, architecture review, SDLC, or change management, so controls can be attached before the first production interaction. That includes knowing whether the system is a model, an agent, a retrieval layer, or a thin wrapper around a third-party API. Each of those patterns carries different exposure. A prompt interface may need content filtering and output validation, while an agent with tool access may need strict action boundaries, approval steps, and logs that show what it attempted, not just what it returned.

When discovery happens late, teams often lack the basic artefacts needed to secure the system:

• an inventory entry with an owner, purpose, and business justification;
• data lineage showing what training, retrieval, or context sources are used;
• connector and API maps showing where the system can read or write;
• logging that captures prompts, tool calls, and decision outputs for investigation;
• testing results for prompt injection, data leakage, and unsafe automation paths.

This is why AI governance should be tied to the same control plane as other critical assets, rather than managed as an isolated innovation track. NIST AI risk guidance and operational control practices both point toward documenting intended use, limiting exposure, and validating outputs before reliance. MITRE ATLAS is useful for thinking about adversarial patterns such as model manipulation and prompt-based abuse, while OWASP guidance for agentic systems helps teams think through execution authority and tool misuse. Best practice is evolving, but the direction is clear: if the system can influence data, decisions, or actions, it needs a defined risk owner and a control boundary before deployment. These controls tend to break down when AI is embedded inside SaaS workflows with shadow IT ownership because the security team never sees the connector configuration or the prompt pathway.

Common Variations and Edge Cases

Tighter AI discovery controls often increase procurement friction and review overhead, requiring organisations to balance speed of experimentation against the cost of uncontrolled exposure. That tradeoff is real, especially where teams are using external models, open-source components, or rapid internal prototypes.

There is no universal standard for exactly how much AI detail must be captured at intake, but current guidance suggests the minimum should include business purpose, model provider or source, data classes touched, and whether the system can act autonomously. A simple chatbot and an agent that can open tickets, send emails, or modify records are not equivalent risks. In hybrid environments, the harder edge case is that AI capability may be delivered through a feature flag, a browser extension, or a low-code platform, which means the “application owner” may not realise an AI service exists at all.

Teams also need to distinguish model discovery from identity discovery. If an AI system uses service accounts, API keys, or delegated tokens, then missed discovery becomes an identity problem as well as a model problem. That is where NHI governance becomes relevant: unmanaged AI often creates unmanaged machine identities. For AI that touches regulated data or critical processes, organisations should align discovery with NIST Cybersecurity Framework 2.0 categories for governance, protect, detect, and respond, then add AI-specific review for model provenance and output validation. The hardest failures appear in fast-moving teams that treat AI as a feature rather than a system with its own trust boundary.

Related resources from NHI Mgmt Group

• How should security teams discover AI usage in source code before deployment?
• Should organisations enforce least privilege for AI agents before or after deployment?
• How should security teams test AI guardrails before deployment?
• How do teams govern AI systems that keep learning after deployment?