Governing Shadow AI Without Blocking Adoption

A practical framework for turning unmanaged AI experimentation into governed organizational capability

Executive Summary

AI adoption inside organizations is increasingly happening from the bottom up.

Employees are experimenting with new models, creating reusable prompts, building skills and agents, connecting AI to enterprise data, and adopting specialized AI applications—often faster than centralized IT, security, and governance teams can formally evaluate them.

This activity is commonly described as Shadow AI.

The instinctive response is to restrict it.

But organizations face a difficult tradeoff: controls that are too weak create real security, privacy, compliance, and operational risks. Controls that are too restrictive can push useful experimentation further outside approved systems, slow adoption, and prevent organizations from learning what their employees are already discovering.

The objective should not be to eliminate experimentation.

It should be to bring experimentation into a system where it can become visible, trusted, reusable, and appropriately governed.

That requires a change in how organizations think about AI governance.

Governance can no longer focus only on which models or applications employees are permitted to access. Increasingly, the important organizational assets are the capabilities built on top of those systems: instructions, skills, workflows, agents, tools, integrations, and other reusable components that encode how work gets done.

The challenge is therefore not simply:

Which AI tools should we allow?

It is increasingly:

What AI capabilities exist inside our organization, what can they access, who owns them, whether they are trusted, and where should they be allowed to operate?

A successful Shadow AI strategy creates a path from experimentation to organizational trust.

That path should be easier than working around governance.

1. Shadow AI Is an Adoption Problem—and an Adoption Signal

Shadow AI broadly describes the use or creation of AI systems outside an organization’s normal technology, security, procurement, or governance processes.

Early examples were straightforward:

An employee opened a personal ChatGPT account and pasted work into it.

The problem is now considerably broader.

Shadow AI can include:

• personal accounts for public AI applications
• AI functionality embedded inside otherwise approved SaaS products
• cloud AI platforms provisioned directly by technical teams
• locally hosted models
• developer frameworks connected to enterprise systems
• custom AI applications
• autonomous or semi-autonomous agents
• reusable prompts, skills, workflows, and instructions shared informally among employees

Netskope's 2025 research found that unmanaged personal AI use remained widespread even as organizations consolidated around enterprise AI platforms. Its research also identified emerging Shadow AI in cloud AI development platforms, local AI infrastructure, and custom agents—not simply public chat applications.

The pattern is familiar.

Technology becomes useful faster than an organization develops the systems required to manage it.

That does not make the associated risk unimportant. It does mean that Shadow AI should be treated as more than policy noncompliance.

It is also a demand signal.

Employees adopting an AI tool without being told to do so are identifying something they believe helps them work.

Employees building prompts, skills, workflows, and agents are going further: they are beginning to encode organizational work into reusable AI capabilities.

Those capabilities may contain important organizational knowledge.

Ignoring them does not make them disappear.

Blocking them does not necessarily stop them from being created.

The more useful response is to make them visible.

2. Employees Are Moving Faster Than Their Organizations

Organizations are already seeing a gap between individual AI capability and institutional readiness.

Microsoft and LinkedIn reported in 2024 that 78% of surveyed AI users were bringing their own AI tools to work.

By 2026, the question had progressed beyond whether employees would use AI at all.

Microsoft's 2026 Work Trend Index found that only 19% of surveyed AI users occupied what it describes as the "Frontier" position, where strong individual AI capability and strong organizational readiness reinforce one another.

Another portion of employees had developed meaningful AI capability while lacking the organizational systems needed to apply it effectively—a state Microsoft describes as blocked agency.

This distinction matters.

An organization can purchase enterprise AI licenses and still have an AI governance problem.

It can publish an acceptable-use policy and still have an AI governance problem.

It can block dozens of public AI applications and still have an AI governance problem.

The underlying issue is whether the organization has built an operating model capable of absorbing what employees are learning and creating.

Shadow AI thrives in the gap between:

what employees can do

and

what the organization knows how to support.

Closing that gap requires more than access control.

3. Why Blanket Blocking Is Not a Governance Strategy

There are situations where an AI system should absolutely be blocked.

A service may have unacceptable data-handling practices.

A model may not be appropriate for regulated data.

An agent may request excessive privileges.

A capability may contain unsafe code or expose credentials.

A particular use case may simply exceed the organization's risk tolerance.

The problem is not blocking itself.

The problem is treating blocking as the entire governance model.

Blocking is too coarse

Not every interaction with an AI system carries the same risk.

Asking an approved model to summarize a public document is materially different from giving an autonomous agent write access to financial systems.

A binary allow-or-deny policy treats both as technology-access decisions instead of risk decisions.

Blocking does not govern what employees build

A company may approve three enterprise AI platforms but still have hundreds of prompts, custom GPTs, skills, agents, workflows, and integrations circulating within them.

The provider may be approved.

The capability may not be.

Blocking can reduce visibility

When legitimate experimentation is difficult to conduct through sanctioned systems, employees have greater incentive to work elsewhere.

Governance then loses exactly what it needs most:

visibility.

Blocking cannot capture successful experimentation

Suppose an operations employee develops a workflow that saves their team several hours each week.

If the organization has no way to register, evaluate, version, approve, and distribute that workflow, the capability remains local knowledge.

Other employees rebuild it.

Versions diverge.

Ownership becomes unclear.

The organization receives some productivity benefit but captures little organizational leverage from the innovation.

The better goal is not:

Stop employees from experimenting.

It is:

Give successful experimentation somewhere to go.

4. The Governance Unit Is Shifting From Models to Capabilities

Enterprise AI governance began naturally at the model and application layer.

Organizations asked:

• Can employees use ChatGPT?
• Can we enable Claude?
• Can engineering use OpenAI APIs?
• Can customer data be processed by this provider?
• Which models meet our security requirements?

Those questions remain important.

But they are no longer sufficient.

As AI use matures, organizations are building reusable layers above the model:

• system instructions
• prompts
• skills
• tools
• connectors
• knowledge packages
• agents
• workflows
• evaluation criteria
• automation
• provider-specific configurations

These components increasingly encode organizational processes.

Consider a contract-review capability.

The model might be replaceable.

The underlying capability may include:

• the organization's preferred review methodology
• specific clauses to identify
• escalation criteria
• formatting requirements
• tool permissions
• reference material
• output validation
• human approval steps

That capability is far more organizationally specific than the underlying model.

The model may change.

The capability should endure.

This changes the governance question from:

Is this model approved?

to:

Is this capability appropriate for this use, with this data, these permissions, this version, and this audience?

That is a more durable foundation for AI governance.

5. The Risks Hidden Inside Shadow AI

A capability-centric approach also reveals risks that application-level governance can miss.

Data exposure

Employees may submit intellectual property, regulated information, source code, credentials, or customer data to systems that have not been approved for those data classes.

Unreviewed instructions

A reusable capability may encode incorrect assumptions, unsafe behavior, outdated policy, or instructions that conflict with organizational standards.

Excessive access

Agents and tools can move beyond generating text.

They may read databases, access cloud environments, create tickets, send communications, update records, execute code, or initiate other actions.

Governance must consider what the capability can do, not simply which model it uses.

Unknown provenance

Organizations may not know:

• who created a capability
• where it originated
• what source material it contains
• whether portions came from outside the organization
• whether dependencies have changed

Version drift

A reviewed capability can become an unreviewed capability after modification.

Without immutable versions and clear trust states, "approved" can quickly become ambiguous.

Capability sprawl

Different employees may independently create versions of the same capability.

Useful knowledge becomes fragmented across personal accounts, repositories, AI applications, and teams.

Invisible organizational dependency

A workflow created informally can become business-critical without anyone intentionally making that decision.

Governance arrives only after the capability fails, its creator leaves, or access changes.

These are not reasons to prevent AI use.

They are reasons to create infrastructure around it.

6. Governance Without Gridlock

A workable AI governance model should follow a simple principle:

The safest path should also be the easiest path.

If adding a capability to the organization's governance system immediately removes the employee's ability to use it, employees receive a clear incentive not to register what they create.

If review requires multiple tickets and weeks of waiting, employees will avoid review whenever possible.

If every experiment receives production-level scrutiny, governance teams will become overwhelmed.

Instead, organizations should separate visibility from approval.

Something can be known without being approved for every purpose.

Something can be safe for individual experimentation without being approved for organization-wide distribution.

Something can be approved for one team without being approved for production.

Governance becomes substantially easier when trust is treated as a state rather than a binary property.

For example:

The exact terminology will vary.

The important property is that trust is visible.

A user should be able to understand not only whether a capability can be used, but why.

7. A Risk-Tiered Model for AI Adoption

Organizations do not need the same governance process for every AI activity.

A practical model can assign controls according to potential impact.

Tier 0 — Exploration

Examples:

• brainstorming with public information
• experimenting in an approved sandbox
• learning how a model behaves

Typical controls:

• approved environment
• no restricted data
• no external actions
• basic usage policy

Formal review should generally not be necessary.

Tier 1 — Individual Productivity

Examples:

• drafting internal material
• summarization
• analysis using approved information
• personal workflow assistance

Typical controls:

• enterprise-managed account
• defined data policy
• visibility where appropriate
• no high-impact autonomous actions

Tier 2 — Shared Capability

Examples:

• reusable team prompts
• Claude Skills
• custom GPT-style capabilities
• shared analysis workflows

Typical controls:

• registration
• named ownership
• versioning
• automated security and policy checks
• defined audience
• provenance

This is an important transition point.

Once a capability becomes reusable by other people, it begins to behave like an organizational asset.

Tier 3 — Integrated Business Workflow

Examples:

• agents connected to enterprise systems
• workflows processing sensitive information
• capabilities that create or modify business records
• automated decisions with material consequences

Typical controls:

• human review
• explicit permissions
• testing and evaluation
• logging
• change control
• rollback
• periodic reassessment

Tier 4 — Critical or Regulated Use

Examples:

• highly regulated decisions
• financial authorization
• externally consequential autonomous actions
• safety-critical workflows
• capabilities operating on highly sensitive data

Typical controls may include:

• security review
• compliance review
• formal evaluation requirements
• separation of duties
• strict approval gates
• continuous monitoring
• detailed audit trails

The purpose of risk tiers is not to weaken governance.

It is to concentrate governance where it matters most.

8. The Shadow AI Governance Lifecycle

NIST's AI Risk Management Framework organizes AI risk management around four functions: Govern, Map, Measure, and Manage, with governance operating across the lifecycle. NIST also emphasizes that AI risk management should be continuous as systems, contexts, risks, and impacts evolve.

Organizations can operationalize those principles for Shadow AI through a capability lifecycle.

1. Discover

First determine what exists.

Discovery may include:

• sanctioned AI applications
• personal or unmanaged applications
• enterprise AI platforms
• AI-enabled SaaS products
• local model infrastructure
• repositories containing AI applications
• agents
• skills
• reusable prompts and workflows

The initial objective is visibility, not punishment.

Organizations cannot govern what they cannot see.

2. Register

Reusable capabilities should have an authoritative record.

At minimum:

• name
• description
• owner
• source
• version
• provider or supported providers
• intended use
• trust status
• permitted audience

Higher-risk capabilities may also record:

• data classifications
• connected tools
• required permissions
• dependencies
• evaluation results
• review history

3. Assess

Assessment should be automated wherever reasonable.

Potential checks include:

• secret detection
• malicious or unsafe code patterns
• dependency analysis
• policy violations
• required metadata
• excessive tool permissions
• prohibited data sources
• provider compatibility
• changes from previously reviewed versions

Automation allows low-risk capabilities to move quickly while directing human attention toward meaningful exceptions.

4. Apply Trust

Trust should attach to a specific version and context.

For example:

Contract Review v2.3 is approved for the Legal team using the organization's managed Claude environment.

That is much more precise than:

Contract Review is approved.

If the capability changes, the trust decision may need to change with it.

5. Distribute

Approved capabilities should become easy to find and use.

Employees should not need to copy instructions from Slack messages or rebuild existing capabilities because they cannot discover them.

Governance creates more value when it helps employees answer:

Has somebody already solved this?

6. Observe

Usage completes the governance loop.

Organizations should understand:

• whether approved capabilities are actually being adopted
• whether unapproved alternatives remain popular
• which teams rely on which capabilities
• where duplication exists
• which capabilities are dormant
• whether use has expanded beyond the reviewed context

A registry without usage information eventually becomes an archive.

7. Reassess

AI systems change continuously.

A new capability version, provider, integration, audience, data source, or permission may alter its risk.

Governance therefore cannot be a one-time certification.

Trust must evolve with the capability.

9. What Organizations Should Measure

A Shadow AI program should not measure success primarily by the number of applications blocked.

Better metrics measure the transition from unmanaged use to trusted adoption.

Examples include:

• percentage of AI usage occurring through managed accounts
• percentage of reusable capabilities registered
• percentage of shared capabilities with identified owners
• time from capability creation to trusted team use
• percentage of high-risk capabilities reviewed
• percentage of deployed capabilities with known version lineage
• adoption of approved capabilities relative to unmanaged alternatives
• number of duplicate capabilities consolidated
• percentage of capabilities with observable usage
• security or policy exceptions by risk category

One metric deserves particular attention:

Time to trusted use

If governance reduces risk but takes so long that employees route around it, the system is not functioning.

The objective is not the shortest approval time possible.

It is the shortest approval time appropriate to the risk.

10. A Different Way to Think About Shadow AI

Traditional Shadow IT programs often begin from an understandable assumption:

Unapproved technology is a problem to eliminate.

AI makes that assumption less useful.

An employee experimenting with a new AI workflow may simultaneously be:

• creating security risk
• discovering a valuable use case
• encoding institutional knowledge
• exposing an unmet technology need
• developing a reusable organizational asset

Those realities can coexist.

The job of governance is to separate them.

That means identifying what is useful, controlling what is risky, and creating a path for useful experimentation to become trusted infrastructure.

In that sense, Shadow AI can become an innovation discovery mechanism.

An organization that can observe grassroots capability creation gains information about:

• which tasks employees want to improve
• which AI platforms they prefer
• where existing enterprise tools are insufficient
• what capabilities deserve wider investment
• where reusable organizational knowledge is emerging

The goal is therefore not simply to bring Shadow AI under control.

It is to bring valuable AI capabilities into the organization.

11. The Need for an AI Capability Control Plane

Most organizations already have systems for managing pieces of this problem.

Identity systems determine who employees are.

Endpoint and network tools observe applications.

Data security tools help protect information.

Source control manages software.

AI providers manage capabilities inside their individual platforms.

Those systems remain important.

But none necessarily provides an organization with one authoritative view of the reusable AI capabilities operating across providers and teams.

That creates the need for a new management layer.

An AI capability control plane should make it possible to answer:

• What capabilities exist?
• Who created them?
• Who owns them now?
• What version is active?
• What changed?
• Where did the capability come from?
• Has it been reviewed?
• Why is it trusted?
• Who can use it?
• What systems can it access?
• Which AI platforms can run it?
• Where is it deployed?
• Is anyone actually using it?

This control plane should sit above individual model providers.

Claude may represent one execution environment.

ChatGPT may represent another.

Internal AI systems may represent others.

The organization's capability should not have to disappear when the underlying provider changes.

12. From Shadow AI to a Common Set

This is the idea behind Commonset.

Commonset is designed around a simple premise:

AI capabilities are becoming organizational assets.

They need infrastructure appropriate to that role.

Instead of leaving skills, prompts, tools, workflows, and agents scattered across individual accounts and provider platforms, organizations should be able to build a trusted set of capabilities that can be governed and made available wherever they belong.

That means creating one place to understand:

• what exists
• what it does
• who owns it
• what changed
• whether it is trusted
• who can use it
• where it is available
• whether anyone actually uses it

This is governance without gridlock.

Employees can continue discovering useful ways to work with AI.

Security and governance teams gain visibility and control.

Platform teams gain a reusable capability layer across providers.

And successful employee experimentation has a path to become durable organizational knowledge.

The outcome is not less AI adoption.

It is more intentional AI adoption.

Conclusion

Shadow AI is unlikely to disappear.

The number of AI applications, models, agents, development platforms, and embedded AI features is increasing too quickly for organizations to manage adoption through static application lists alone.

Nor should organizations want to suppress the underlying behavior entirely.

Employees experimenting with AI are learning where the technology creates value.

The challenge is converting that experimentation into something the organization can trust.

The organizations that do this well will not choose between innovation and governance.

They will build systems in which governance enables innovation to scale.

That requires visibility before control.

Risk-based governance instead of universal gates.

Clear ownership.

Versioned trust.

Continuous monitoring.

And a governed path through which individual AI experimentation can become reusable organizational capability.

The future of enterprise AI will not be defined only by which models companies buy.

It will increasingly be defined by the capabilities they build on top of them.

Those capabilities should not have to remain in the shadows.

---

About Commonset

Commonset is the control plane for reusable AI capabilities.

It gives organizations one place to create, review, govern, distribute, and understand the AI skills and capabilities used across teams and AI platforms.

AI capabilities. Governed.

References

• National Institute of Standards and Technology — Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• National Institute of Standards and Technology — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
• Microsoft and LinkedIn — 2024 Work Trend Index: AI at Work Is Here. Now Comes the Hard Part
• Microsoft — 2026 Work Trend Index: Agents, Human Agency, and the Opportunity for Every Organization
• Netskope Threat Labs — Cloud and Threat Report: Shadow AI and Agentic AI 2025