How does the framework apply to embedded AI inside enterprise SaaS tools?

The embedded AI surface is the hardest part of the framework to operate. The vendor's product runs the AI on the vendor's infrastructure, with prompts sourced from the deployer's data and responses returned to the deployer's users. The deployer cannot route the embedded surface through its own enforcement proxy unless the vendor supports proxy routing or the deployer's identity provider can mediate the SaaS access. The practical pattern is to extract the vendor's commitments at procurement, configure the embedded AI features for the deployer's data classification, and require the vendor to produce per-decision records the deployer can ingest.

Does the framework need a separate AI risk register or can it ride on the enterprise risk register?

Either approach is acceptable as long as the AI-specific risks are surfaced and the AI-specific evidence layer is connected to the register. Most mature programs treat AI as a category inside the enterprise risk register, with AI-specific risk owners, control statements, and evidence references. The reporting layer of the shadow AI framework is the natural feed for the register, with the audit layer's records supporting the evidence references.

What is the right cadence for refreshing the discovery layer's inventory?

The inventory has to be refreshed often enough to catch new AI adoption before the adoption becomes a compliance gap. In practice, a monthly automated discovery refresh combined with a quarterly manual review of internal applications and agent workflows captures most of the new surface area. The cadence has to be faster than the typical incident detection window: the IBM 247-day detection time for shadow AI breaches is a signal of how stale most discovery layers actually are.

Who owns the shadow AI governance framework inside the enterprise?

The ownership pattern varies. The CISO usually owns the security view, the Chief Compliance Officer owns the regulatory view, and the Chief Data Officer or Chief AI Officer owns the AI program view. The framework has to be operated jointly, with a single risk owner identified for each AI surface in the inventory. The operational layer (the control and audit infrastructure) typically sits with the security or platform engineering team, with policy authority shared with compliance.

How does the framework handle external AI usage by contractors or vendor staff?

The framework covers AI usage that touches the deployer's data, regardless of whether the user is an employee, contractor, or vendor staff member. The control layer applies the same policy to all users in the deployer's identity context. The audit layer produces the same per-decision record. The procurement and access management process has to ensure contractor and vendor identities are in the deployer's identity provider so the control layer can attach the verified identity

Shadow AI Governance Framework: From Discovery to Enforcement

A shadow AI governance framework defines how an enterprise discovers, classifies, controls, audits, and reports on AI usage that runs outside the IT-sanctioned stack. The five layers map onto the deployer obligations the EU AI Act Article 26 imposes, onto the Govern function in the NIST AI Risk Management Framework, and onto the management system ISO 42001 describes. IBM's Cost of Data Breach Report found 247-day detection times for shadow AI breaches, six days longer than standard breaches. The detection gap reflects the governance gap.

Most organizations have policy and discovery covered. The control and audit layers are where the framework usually stops short of operational coverage.

I want to walk through what each of the five layers has to produce, where the practical implementation usually breaks down, and how the layers map to the regulatory frameworks taking effect in 2026.

Layer 1: discovery

Discovery establishes which AI surfaces the workforce is actually using. The output is an inventory: ChatGPT, Claude, Copilot, Gemini, the long tail of vertical AI SaaS, internal applications calling LLM provider APIs, agent workflows touching downstream services. The inventory includes the user population, the access pattern, and the data categories the surface touches.

The discovery layer is the entry point for the framework, and most enterprises have invested here. The investment usually combines CASB visibility for SaaS-app adoption, endpoint or browser telemetry for the user-surface coverage, network telemetry for traffic destinations, and a manual inventory for internal applications and agents that the automated surfaces miss.

The gap that shows up at the discovery layer is coverage. The inventory rarely captures every embedded AI feature inside enterprise SaaS, every agent workflow that calls an LLM provider, and every script a team runs against an OpenAI API key. The framework has to specify how often the inventory is refreshed, what counts as a credible source for the inventory, and what the escalation path is when a new AI surface appears.

Layer 2: classification

Classification assigns each AI surface to a risk tier based on the data the surface touches, the decision the surface informs, and the regulatory scope that applies. The output is a tiered map: green-light surfaces that the deployer permits with default policy, yellow-light surfaces that require additional controls or human oversight, red-light surfaces that the deployer blocks or restricts.

The classification depends on the data context. A ChatGPT surface used for general productivity sits at one tier when the user pastes a meeting agenda and at a different tier when the user pastes a customer record. The classification has to apply at the moment of use, not just at the surface level.

The framework has to specify how data sensitivity classifications map to AI surface usage. The classification layer is where the EU AI Act Annex III risk classifications enter the framework: an AI surface used in a high-risk Annex III category inherits the full deployer obligation chain regardless of the surface's nominal sanctioning.

Most organizations have a corporate data classification policy. The gap is the translation from data classification to AI surface policy at the moment of the prompt.

Layer 3: control

Control is where the framework operates the policy. The output is a decision per AI request: permit, redact, modify, block, route to human review. The control layer requires an enforcement architecture in the AI traffic path and a policy expressed in terms the architecture can evaluate.

The architectural primitive for the control layer is per-decision evaluation at the AI request boundary. The decision depends on the user identity, the data classification of the prompt, the policy in effect, and the AI surface. The decision is made before the prompt reaches the model. The decision is enforced inline.

This is the layer where most current shadow AI programs stop. The discovery and classification layers produce the visibility and the policy on paper. The control layer requires the enforcement architecture in production, with the operational responsibility for routing AI traffic through the policy point.

The Netwrix finding that 97% of organizations suffering AI breaches lacked proper access controls is the symptom of the missing control layer. The discovery layer told the security team shadow AI was happening. The control layer was not yet operating.

Layer 4: audit

Audit produces the evidence layer the framework depends on. The output is a per-decision record for every AI request, with the verified user identity, the data classification, the policy version, the decision outcome, the timestamp, and a cryptographic integrity signature. The record is retained for the period the applicable framework requires.

The audit layer supports three operational functions. The first is the compliance demonstration: showing the regulator or the internal auditor that the policy operated as documented. The second is the post-market monitoring loop: surfacing emerging patterns that the risk management system has to address. The third is the incident response: reconstructing what the AI system did during the window of a serious incident.

The Article 12 logging obligation and the Article 19 six-month retention floor are the EU AI Act expressions of this layer. NIST AI RMF Measure function aligns with the same record. ISO 42001 management system audit samples against the records the layer produces.

The gap at the audit layer is the records' independence from the system that produced the decision. An application-controlled log that the application can modify is not the evidence layer the framework expects. The record has to be produced by the control layer, independent of the application, before the model response returns to the application.

Layer 5: reporting

Reporting consolidates the records and the operational metrics into the views the framework consumers need. The outputs are the board-level dashboard of AI usage and risk posture, the compliance team's regulatory readiness view, the security operations view of policy violations and incidents, and the line-of-business view of AI usage by team and function.

The reporting layer is the framework's interface with the rest of the enterprise governance stack. The board's enterprise risk management view inherits from the reporting layer. The CISO's risk register inherits from the same. The compliance team's regulatory readiness assessments map back to the records the audit layer produces.

The reporting layer is the most common one to staff well and to underdeliver on at the same time. Without the records the audit layer produces, the reports are aspirational. With the records, the reports become the operational language the rest of the enterprise consumes.

How the framework maps to the regulatory chain

For the EU AI Act, the framework operates the Article 26 deployer obligations. The risk management system under Article 9 is fed by the records the audit layer produces. The record-keeping under Article 12 is satisfied by the audit layer's output. The human oversight under Article 14 is operated by the control layer's routing to human review. The post-market monitoring under Article 72 and the serious-incident reporting under Article 73 both depend on the records.

For NIST AI RMF, the framework operates the Govern, Map, Measure, and Manage functions. Govern sits at the policy and classification layers. Map runs the discovery layer. Measure depends on the audit layer's records. Manage operates the control and reporting layers.

For ISO 42001, the framework is the AI management system the standard describes. The certification audit samples against the evidence the audit layer produces and the policy the control layer operates.

For Fannie Mae LL-2026-04 in mortgage lending and DORA in financial services, the same architecture satisfies the per-decision evidence and the disclosure obligations the rules impose.

DeepInspect

This is the architecture the control and audit layers depend on. DeepInspect sits at the AI request boundary as a stateless proxy that operates the control layer and produces the audit layer's records. The policy expressed at the proxy captures the deployer's classification decisions. The per-decision record produced for every AI request captures the evidence the audit layer needs.

For the shadow AI framework's coverage, the proxy operates against the browser surface for ChatGPT and Claude, the API surface for internal applications and agents, and the server-to-server surface for SaaS embeddings the deployer can route through the proxy. The discovery and classification layers feed the policy. The reporting layer consumes the records.

The Cloud Radix finding that 90% of CISOs identify shadow AI as the top security concern for the year and the IBM finding that one in five breached organizations experienced shadow-AI-linked incidents are the operational pressure on the framework. The August 2, 2026 deadline for the EU AI Act high-risk obligations is the regulatory pressure. The framework that produces the records survives both.

If your shadow AI program has covered discovery and policy and you are facing the question of control and audit, the architectural decision is which layer carries the per-decision evidence. Book your free AI readiness check.