Fragmented AI adoption creates hidden data risk across enterprises

At a glance

What this is: This is a Cyberhaven analysis of how uneven AI adoption creates concentrated data exposure through the many paths created by GenAI use.

Why it matters: It matters because IAM, data security, and governance teams must control how sensitive information moves through AI systems, not just which tools are approved.

By the numbers:

• The 99th percentile of AI adoption leader organizations are using more than 300 GenAI tools.
• 95th percentile AI leaders average over 200.
• Frontier organizations, or the 95th percentile, see a 71.4% employee adoption rate.
• 50%.

👉 Read Cyberhaven's analysis of fragmented AI adoption and data risk

Context

Enterprise AI adoption is no longer a uniform rollout. The primary governance problem is fragmented use, where some teams embed GenAI into daily work much faster than security, legal, and data controls can respond. That creates uneven exposure across the business, which is especially relevant for AI security, data security, and identity governance.

The primary risk is not simply having too many tools. It is the movement of sensitive data into and out of AI systems through prompts, outputs, assistants, and downstream workflows. Where AI becomes part of engineering, customer operations, or regulated business functions, security teams need controls that follow the data path rather than the app catalog.

Key questions

Q: How should security teams govern AI use cases across multiple business units?

A: Security teams should require a single inventory of AI use cases, models, and agents with consistent ownership, lifecycle stage, and risk metadata. That lets governance teams compare activity across business units, prioritize exceptions, and avoid the blind spots created by separate reporting paths. Without a shared record, oversight becomes fragmented and reactive.

Q: Why does fragmented AI infrastructure create security risk?

A: Fragmented AI infrastructure creates risk because each provider handoff can split responsibility for credentials, permissions, and logging. When teams stitch together GPU services, model hosting, and cloud platforms, the result is often inconsistent governance and hidden access paths. That makes it harder to prove who can reach what and under which conditions.

Q: What do organisations get wrong about approval for AI actions?

A: They often assume a single approval step is enough for a whole conversation. In practice, broad approval can give an AI carte blanche to reuse context and act beyond the original intent. Approval has to match the specific action, the specific tool, and the specific data being sent, or it becomes a weak control.

Q: How can teams reduce AI leakage risk without slowing adoption?

A: By designing for containment and recovery instead of relying on perfect prevention. That means isolating sensitive data sources, tightening access to retrieval layers, and preparing purge or restore workflows for accidental disclosure. This approach keeps AI usable while reducing the blast radius when content escapes its intended context.

Technical breakdown

Why fragmented AI adoption creates data sprawl

When AI adoption is uneven, each team tends to choose tools that fit its own workflow, data sensitivity, and tolerance for friction. That produces many separate data paths, each with its own retention, logging, sharing, and access characteristics. The result is not just more software. It is more places where regulated, confidential, or operationally sensitive information can be exposed, copied, or retained outside central control. For security teams, this turns AI usage into a governance and data-flow problem rather than a simple software approval problem.

Practical implication: inventory AI usage by workflow and data class, not just by approved application.

Why prompts and outputs act like data in motion

Enterprise AI exposure often happens in ordinary user behaviour. Employees paste information into prompts, models generate outputs, and those outputs get copied into documents, tickets, code repositories, or customer-facing material. That makes AI a high-volume data-in-motion channel even when no traditional file transfer is occurring. From a security perspective, this creates visibility gaps because the information is being transformed, not merely moved. If you cannot inspect content at the point of entry and exit, you cannot reliably govern what the system has seen or produced.

Practical implication: apply content inspection, DLP, and logging at the prompt and output layers.

Why developer adoption increases AI supply chain risk

Developer use of coding assistants turns AI from a productivity layer into part of the software delivery chain. Source code, infrastructure details, and internal logic can enter tools that then influence commits, pipelines, and production changes. That creates a coupling between AI security and SDLC integrity. Once AI-generated output is merged into repositories or services, the risk is no longer limited to disclosure. It can also affect code quality, dependency choices, and downstream trust in the software supply chain.

Practical implication: govern coding assistants as part of SDLC and source-control controls, not as standalone productivity tools.

Threat narrative

Attacker objective: The effective objective is to capture or exploit sensitive enterprise data as it moves through unmanaged AI interactions and downstream workflows.

1. Entry occurs when users paste sensitive business, source code, or regulated data into GenAI tools across scattered business workflows.
2. Escalation follows when outputs are reused, copied, or embedded into repositories, tickets, documents, and production-related processes outside central review.
3. Impact is the loss of data governance consistency, with sensitive information flowing into systems and records that security teams cannot fully see or control.

NHI Mgmt Group analysis

Fragmented AI adoption is a data governance problem before it is an AI tooling problem. The article shows that risk concentrates where adoption is fastest, not where policy is most complete. That means security teams need to treat GenAI usage as a distributed data plane with inconsistent controls. For programmes that already struggle with shadow IT, the lesson is familiar: visibility and control must follow actual use, not approved intent.

Data flow, not app inventory, is the central control boundary for AI security. The article is right to shift attention away from counting tools and toward prompt and output behaviour. That is where sensitive information enters and leaves AI systems, often outside normal review. In identity and access terms, this creates a new governance surface for who can move data through AI services and under what conditions.

Engineering teams create the sharpest AI governance debt. When AI is embedded into coding workflows, the impact extends into repositories, pipelines, and production services. That makes AI behaviour part of software supply chain risk, not just productivity enablement. AI governance debt: the growing gap between how AI is actually used and how quickly governance can define acceptable data handling, access, and logging. Practitioners should treat that gap as an operational risk indicator.

Identity and access controls still matter, but they are not sufficient on their own. AI systems can be approved, yet the sensitive data they touch may still be uncontrolled in practice. This is where IAM, DLP, DSPM, and AI governance need to converge. In programmes with human and machine access paths, the control objective is to constrain data movement across AI interactions, not merely authenticate the user.

The market signal is toward continuous AI governance rather than one-time approval workflows. Static allowlists cannot keep pace with tool proliferation, employee adoption shifts, or the embedding of AI into core work. Security leaders should expect demand for controls that observe usage, classify content, and apply policy dynamically. Practitioners should plan for AI governance to become a standing operating discipline, not an exception process.

What this signals

Fragmented AI adoption will push many organisations into a two-speed governance model. High-adoption teams will outpace policy, while low-adoption teams may be over-governed by rules that do not match their actual exposure. The right response is continuous monitoring of data movement through AI systems, supported by controls that operate at prompt, output, and downstream storage points.

AI governance debt: the longer an organisation waits to align policy with real AI usage, the larger the gap between approved tools and unmanaged data flow becomes. That debt is visible in engineering first, then in business operations, and finally in audit findings. Security leaders should expect AI governance to become a recurring operational discipline, not a one-off enablement exercise.

For practitioners

• Measure real AI usage by team and workflow Map which GenAI tools are actually in use, which teams use them most, and which business processes move sensitive data through them. Approved lists alone will miss shadow usage and fragmented adoption patterns.
• Apply data controls at prompt and output points Use DLP, content classification, and logging where data enters and exits AI systems. Focus on prompts, generated outputs, and any downstream storage or sharing paths that can persist sensitive information.
• Govern developer assistants as SDLC controls Treat coding assistants as part of source control, pipeline, and repository governance. Review how source code, secrets, and internal design details can flow into AI-assisted development and then into production artefacts.
• Prioritise high-risk workflows first Start with engineering, regulated data environments, and any workflow where AI outputs are copied into records of truth. These are the places where fragmented adoption creates the highest exposure and the least tolerance for leakage.

Key takeaways

• Fragmented AI adoption turns ordinary user workflows into a distributed data security problem.
• The real control gap is not tool approval, but the inability to govern prompt and output data flow consistently.
• Security teams should prioritise workflow-level controls in engineering and regulated environments before adoption outpaces oversight.

Key terms

• Fragmented AI Adoption: A state where different teams, departments, or business units adopt AI at very different speeds and with different tools. This creates uneven exposure because governance, logging, and data controls cannot be applied consistently across the enterprise.
• Data-in-Motion: Data-in-motion is sensitive information while it is being transferred between systems, identities, or applications. For SaaS and AI programmes, the main concern is not only where data is stored, but which identities can move it, transform it, or expose it during transit.
• AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.

What's in the full article

Cyberhaven's full article covers the operational detail this post intentionally leaves for the source:

• The reported adoption splits by percentile and department, useful if you need the original data for internal benchmarking.
• The article's breakdown of where AI usage is most concentrated across engineering and regulated business functions.
• The framing of how prompts and outputs behave as a data-in-motion channel in day-to-day work.
• The source article's guidance on using DSPM and related controls to reduce exposure without blocking adoption.

👉 Cyberhaven's full post covers the adoption data, risk concentration, and control recommendations in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives practitioners a structured way to connect identity control with broader security programmes.