How should security teams discover and govern the AI systems already running inside the business before they try to scale them?

Security teams should start by building visibility into the models, agents, and copilots already in use, then map how they interact with data and users. Scaling fails when AI exists outside registration and governance, because teams cannot assess risk, enforce controls, or prove accountability. Discovery and runtime observation should come before broad rollout, especially for customer-facing or decision-influencing AI.

Why discovery has to come before scale

AI systems that are already embedded in workflows can create the same governance blind spots as unmanaged services, except the blast radius is often larger because outputs may influence customers, operations, or decisions. A team cannot govern what it has not inventoried: model access paths, connected data sources, human approvers, embedded copilots, and autonomous agents all need to be visible before controls can be assigned. That is the practical first step in making AI accountable rather than merely experimental. The control problem is not just policy, it is finding where AI is actually operating.

Discovery also needs runtime observation, because static inventories age quickly. Teams should look for shadow usage in business apps, browser extensions, internal copilots, and workflow automation that can call models or external tools without central approval. The fastest way to lose control is to scale a capability before the business has agreed who owns it, what data it can touch, and how exceptions are tracked. In practice, most governance failures start with systems that were useful enough to spread before anyone treated them as production assets.

How to discover and govern what already exists

Start with a discovery pass across procurement records, SaaS admin consoles, identity logs, API gateways, endpoint telemetry, and cloud usage data. That gives a first map of where AI is consuming data, returning decisions, or taking actions. Then classify each system by business purpose, data sensitivity, user population, and level of autonomy. A customer-facing assistant is not governed the same way as an internal drafting tool, and an AI that recommends actions is not the same as one that can execute them.

Governance works best when it is tied to observable control points rather than a generic policy document. That usually means assigning an owner, defining approved inputs and outputs, recording model and prompt changes, logging tool calls, and deciding where human review is mandatory. For AI that can affect regulated or high-impact decisions, the review threshold should be higher, not lower. NIST AI Risk Management Framework is useful here because it frames governance, mapping, measurement, and management as separate workstreams, which fits the reality that discovery, risk evaluation, and control enforcement happen at different speeds.

Build an inventory that includes models, agents, copilots, plugins, and external model APIs.
Record which business process each system supports, not just which team requested it.
Trace data movement, especially where customer, employee, or confidential content is sent to third parties.
Separate advisory AI from action-taking AI, and require stronger controls for the latter.
Keep an exception register so unmanaged tools do not become permanent by accident.

These controls tend to break down when AI is adopted through departmental purchases or browser-based tools that never pass through central architecture review.

Common variations and edge cases

Tighter AI governance often slows local experimentation, so teams have to balance speed against control. The right answer is not to block all pilots, but to create a lightweight intake path that lets the business register systems early and graduate them into stronger controls as they prove value. A harmless internal drafting assistant can stay low-risk for a while, but the same tool may need a very different posture once it starts handling customer data, policy decisions, or automated workflow actions.

Edge cases usually appear where AI is embedded inside another product, where ownership is split between business and engineering, or where a vendor updates a model without changing the interface. Those cases need special attention because the visible application may look stable while the underlying behavior changes. Another common variation is agentic tooling, where an assistant can call systems, open tickets, or trigger downstream automation. That requires governance of the action path, not just the model response. NIST AI 600-1 Generative AI Profile is especially relevant when prompt handling, content provenance, or pre-deployment testing become part of the operating model.

Teams also need to distinguish between “known but unapproved” and “unknown and unobservable.” Known systems can be brought under control. Unknown systems cannot be risk-rated honestly, which is why discovery is the governance control that unlocks every other one. The hardest cases are usually the most convenient tools, because broad usefulness is what makes them spread before anyone asks who is responsible for them.

Risk and Threat Considerations

The material risk is uncontrolled AI growth, where tools begin handling sensitive data or influencing decisions before security, legal, or risk functions know they exist. That creates exposure across confidentiality, integrity, accountability, and third-party dependency. Once AI is embedded in business workflow, the risk is no longer just model quality, it becomes unauthorized data access, unreviewed outputs, and unclear responsibility when something goes wrong.

Failure mechanism: Shadow AI spreads through SaaS features, plugins, and departmental tools that bypass normal approval paths. If discovery is weak, teams miss where data is being sent, where model responses are being trusted, and where autonomous actions are being taken without logging or review. That leaves a gap attackers, negligent users, or over-permissive integrations can exploit.

Impact: Sensitive information can be exposed outside approved boundaries, decision-making can become untraceable, and incident response becomes slower because no one can reconstruct which system acted, on what data, and under whose authority.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST AI RMF, NIST AI 600-1 and CIS Controls v8 set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST AI RMF	GOVERN — Govern	AI discovery and accountability are core governance concerns for this exact question.
	MAP — Map	Mapping identifies where AI systems operate, who uses them, and what data they affect.
	MEASURE — Measure	Runtime observation and risk measurement are needed to understand live AI behavior.
Recommendation — Establish AI governance ownership, approval, and accountability before scaling. Map existing AI use cases, data flows, and stakeholders before expansion. Measure model behavior, data exposure, and control effectiveness continuously.
NIST AI 600-1	PM — Predeployment Testing and Evaluation	Predeployment testing matters when moving existing AI toward broader rollout.
	GV — Governance	Generative AI governance is needed for systems already embedded in the business.
Recommendation — Test AI systems before scaling them into higher-risk business workflows. Define approval, logging, and change-management requirements for GenAI use.
ISO/IEC 42001:2023	4 — Context of the organization	Discovery needs an organizational view of where AI is used and why.
	6 — Planning	Planning is required to translate discovered AI usage into controlled rollout.
Recommendation — Identify all AI-related business processes and owners before expanding AI use. Plan AI risk treatments and rollout conditions from the discovered inventory.
CIS Controls v8	6 — Access Control Management	Discovery and governance depend on knowing who and what can access AI systems.
	8 — Audit Log Management	Runtime observation and accountability depend on logging model and tool activity.
Recommendation — Review and restrict access to AI tools, connectors, and sensitive data sources. Log AI prompts, outputs, and action requests so activity is auditable.

Practitioner Guidance

What to prioritise: Inventory systems that can read or write business data first, then move to advisory tools that only draft content. If a system can trigger actions, create records, or influence customer decisions, it deserves stronger governance than a passive chatbot.

What to verify: Confirm who owns the system, what data it touches, where logs are retained, and whether prompts, outputs, and tool calls are reviewable after the fact. If those four items are missing, the system is not ready for broad scaling even if users find it useful.

Common mistake: Treating a vendor platform as governed because procurement approved the contract. Contract approval does not equal runtime control, and a model that can change behavior, data flow, or downstream actions still needs operational oversight.

Practitioner takeaway: The right scaling sequence is discover, classify, observe, then govern. Teams that reverse that order usually inherit AI that is already business-critical, which makes later control work slower, more disruptive, and much harder to prove.