What Is Shadow AI, and Why It's Now a Regulatory Problem

For years, shadow IT (the use of unsanctioned software by employees without IT approval) kept CISOs up at night. Shadow AI is the same problem, an order of magnitude more consequential.

In 2024, the concern was data leakage: an employee pasting customer data into ChatGPT, a team running an unapproved automation tool, a developer spinning up a GPT-4 integration without security review. Those risks are real. But in 2026, shadow AI has acquired a second, more serious dimension: it is now a regulatory liability.

Under the EU AI Act's Article 26, which comes into force in August 2026, organisations deploying AI systems in high-risk contexts have affirmative obligations to monitor, oversee, and document how those systems operate. "We didn't know this agent was running" is not a defence under Article 26. It is precisely the failure the regulation was designed to prevent.

Article 26 of the EU AI Act places monitoring and human oversight obligations on deployers, not just providers. If an AI agent is operating in your environment, you are responsible for evidencing its oversight, regardless of whether you sanctioned it.

What Shadow AI Actually Is

Shadow AI is any AI agent, model, or automated workflow operating within an organisation's technical environment without formal IT visibility, approval, or governance. The term is broader than most people initially assume.

It is not limited to employees using personal ChatGPT accounts. Shadow AI includes:

• Google Apps Script automations built by individual employees that call the Gemini API, processing internal documents without security review
• Microsoft Power Automate flows connecting to OpenAI or Copilot Studio, triggered by business users with no IT involvement
• Salesforce Agentforce configurations deployed by a sales operations team, accessing customer records at scale
• ChatGPT plugins authorised by individual employees through their own OpenAI accounts, connected to shared Google Drive or email
• AWS Bedrock-invoked agent roles assumed via IAM, set up by a developer during a proof-of-concept that never got switched off
• Third-party SaaS tools with embedded AI features that received OAuth grants to organisational data when a user connected their account

What these have in common is not that they are malicious. Most were created with good intentions by capable people. What they share is that they are invisible to any single administrative surface, and therefore invisible to the governance and compliance functions that need to account for them.

Why the Security Framing Is No Longer Sufficient

Shadow AI has traditionally been framed as a security and data protection problem. That framing is correct but incomplete. The security risks (data exfiltration, model poisoning, uncontrolled data retention by third-party AI providers) are genuine. But framing shadow AI purely as a security issue misses the regulatory shift that has occurred in 2025 and 2026.

Three regulatory developments have changed the stakes:

EU AI Act Article 26: Deployer Monitoring Obligations

Article 26 of the EU AI Act requires deployers of high-risk AI systems to implement appropriate technical and organisational measures to ensure human oversight, monitor AI system operation, and maintain logs sufficient for regulatory examination. The obligation runs to the deployer (the organisation using the AI system) not just the vendor who built it.

An AI agent operating without the deployer's knowledge cannot, by definition, be monitored, overseen, or logged in the way Article 26 requires. Shadow AI is therefore not merely a governance gap. It is a compliance failure under EU law.

FCA SYSC 8: Third-Party AI Arrangements

The FCA's SYSC 8 sourcebook governs outsourcing and material third-party arrangements. As AI agents increasingly access regulated data and perform functions that affect customers or regulated activities, the FCA's expectation is that firms maintain demonstrable oversight of those arrangements. An AI agent accessing customer data under an OAuth grant the firm is unaware of is a SYSC 8 problem as much as a security problem.

ICO AI Governance Framework: 11 Controls

The ICO's AI Governance and Accountability Framework sets out 11 controls that organisations should implement to demonstrate responsible AI use. Control 4 (transparency and accountability for AI systems) requires organisations to maintain awareness of AI systems processing personal data. Shadow AI agents processing personal data without oversight fail this control directly.

The Discovery Gap: Why Your Admin Console Doesn't Show You Everything

The instinctive response to shadow AI risk is to check the admin console. Google Workspace admin. Microsoft Entra ID. Salesforce setup menu. This is the right instinct, but it reveals only a fraction of the problem.

Each platform's administrative surface shows you what is authorised within that platform. It does not show you:

• Cross-platform patterns: an agent that reads data from Google Workspace and sends output via Microsoft Exchange appears in neither platform's admin console as a combined pattern
• Delegated grants made by individual users: in many organisations, users can authorise third-party applications to access their own data without IT involvement
• Service identities operating under application-level OAuth grants rather than user-level delegated grants
• Agents operating via API keys rather than OAuth: these leave no trace in OAuth grant management surfaces
• Historical grants that were never revoked: an OAuth grant made eighteen months ago for a proof-of-concept that was never formally decommissioned

The result is that the true population of AI agents operating in a regulated firm's environment is materially larger than what any single administrative surface reveals. For organisations with obligations under Article 26, SYSC 8, or the ICO framework, this gap is not a technical curiosity. It is a compliance exposure.

What "Fixing" Shadow AI Actually Requires

Shadow AI governance is not solved by policy alone. Issuing an acceptable use policy for AI tools is necessary but not sufficient. The regulatory obligations created by Article 26 and the ICO framework require demonstrable, evidenced oversight, not just a policy document.

A credible shadow AI programme has three components:

1. Discovery

Systematic enumeration of AI agents operating in the environment, across all major platforms, including delegated and application-level OAuth grants. This cannot be done manually at scale. It requires programmatic access to workspace admin APIs across each platform.

2. Classification

Each discovered agent needs to be classified by risk level. The relevant dimensions are: what data the agent accesses, whether it communicates externally, whether there is human-in-the-loop approval for its outputs, and whether it touches regulated activities or personal data. A risk classification that can be re-produced and verified under regulatory examination is significantly more valuable than one that lives in a spreadsheet.

3. Evidence Generation

This is the component most organisations are missing. A supervisor or auditor will not accept a description of your shadow AI governance programme. They will ask for evidence (signed, reproducible, dated) that monitoring occurred, that findings were identified, and that appropriate action was taken. Audit logs are not the same as governance evidence. The distinction matters under regulatory examination.

How AETHER Pulse Approaches Shadow AI Discovery

AETHER Pulse is an AI governance evidence platform built specifically for regulated firms. It connects to workspace admin APIs across Google Workspace, Microsoft 365, OpenAI Assistants, Salesforce Agentforce, Microsoft Copilot Studio, LangSmith, and AWS Bedrock, enumerating every AI agent with an active OAuth grant visible at admin level, including both delegated grants and application-level service identities.

Discovered agents are classified using a five-dimensional framework covering data access scope, external communication capability, human oversight status, regulatory touchpoints, and cross-platform pattern exposure. Eight cross-platform toxic-combination patterns (such as an agent reading personal data on one platform and communicating externally on another with no human oversight) are detected through deterministic logic that produces findings reproducible under regulatory examination.

The output is not an audit trail. It is a cryptographically signed evidence pack (HMAC-SHA256 signed, canonical-JSON serialised, per-tenant signing keys) that can be reproduced and verified 24 months after generation. That is what Article 26 actually requires.

Published methodology: aetherpulse.app/methodology

Frequently Asked Questions

What counts as shadow AI?

Any AI agent, model, or automated workflow operating in your organisation's environment without formal IT visibility or governance. This includes tools authorised by individual employees, legacy integrations never formally decommissioned, and AI features embedded in SaaS tools that received OAuth grants when a user connected their account.

Is ChatGPT shadow AI?

It depends on how it is being used. If employees are using the ChatGPT web interface with their personal accounts, that is shadow AI from a data governance perspective but does not necessarily create an OAuth grant visible in your workspace admin. If employees have connected ChatGPT plugins to shared Google Drive or Microsoft 365 data, those connections will create delegated OAuth grants that are discoverable at admin level, and those are shadow AI in the regulatory sense.

What does Article 26 require regarding shadow AI?

Article 26 does not use the term shadow AI. It requires deployers of high-risk AI systems to implement human oversight measures, monitor AI system operation, and maintain documentation sufficient for regulatory examination. If AI agents are operating without your knowledge, you cannot satisfy these obligations. Shadow AI discovery is therefore a prerequisite for Article 26 compliance, not a separate activity.

Who is a deployer under the EU AI Act?

A deployer is any natural or legal person who uses an AI system under its own authority. If your organisation is using AI systems (even if you did not build them) you are a deployer and Article 26 obligations apply to you.

When does Article 26 come into force?

August 2026 for high-risk AI system obligations. FCA and ICO obligations under SYSC 8 and the ICO AI Governance Framework are already in force.

Book a 15-minute Shadow AI Discovery Review →