Every enterprise security team has a shadow IT playbook. Unsanctioned SaaS, personal devices on the network, cloud storage that procurement didn’t approve. The playbook is well-understood: discover, classify, remediate or approve. Governance frameworks handle this competently. The risk is legible, the remediation paths are established, and the tooling has matured considerably over the past decade. Most mid-sized enterprises can run a discovery pass and produce a reasonably credible inventory of what their employees are using without authorization.
Shadow AI is different from shadow SaaS in a way that the security framing doesn’t capture — and the difference is consequential. When an employee signs up for an unauthorized project management tool, the exposure is data leakage. That is a security problem, and it’s the right frame for it. When an employee uses an AI agent to draft client communications, approve expense reports, or screen resumes, the exposure isn’t just data leakage. It’s liability generation. The AI is making or influencing decisions that produce legal and financial consequences. An unauthorized tool that affects decisions is not merely a data governance problem. It’s an insurance problem.
We keep encountering this gap in client conversations. The security team has done good work — they’ve mapped the data flows, locked down the endpoints, implemented data loss prevention policies. The CISO can show a dashboard. But nobody has asked the question that carriers are now beginning to ask when reviewing AI endorsement applications: what decisions is this AI making, and is anyone insuring the outcomes? These are different questions, and right now, almost no organization is positioned to answer both of them in the same breath.
The Security Lens vs. The Insurance Lens
Security frameworks ask a coherent set of questions about shadow AI. What data can this tool access? Where does that data flow once it leaves the organization’s perimeter? Is the access authorized under the acceptable use policy? Can we detect exfiltration if something goes wrong? These are good questions. They are the right questions for a security team to be asking, and the tooling to answer them has improved substantially. Behavioral analytics, CASB platforms, endpoint telemetry — a well-resourced security organization can build a credible picture of AI tool usage from a data exposure standpoint.
Insurance frameworks ask entirely different questions. What decisions does this tool influence? Who is affected by those decisions, and what’s the downstream consequence if the output is wrong? What’s the financial exposure if the AI makes a mistake that causes loss to a third party — a client, a job applicant, a customer? And critically: is any of that exposure actually covered by an existing policy, or did an exclusion quietly carve it out when the policy renewed?
Both sets of questions are valid. The problem is they don’t overlap. A tool that passes every security check — properly authorized, data encrypted, access logged, vendor SOC 2 certified — can still create massive uninsured liability if it’s influencing consequential decisions without governance documentation that carriers can evaluate. SOC 2 compliance speaks to control environments and data handling. It says nothing about whether an AI chatbot’s output is covered under a commercial general liability policy. Penetration testing assesses attack surface. It does not assess whether an AI system is generating commitments that bind the company legally. The security audit and the coverage audit are not the same document, and treating one as a proxy for the other leaves a gap that accumulates silently.
A shadow AI tool that passes every security check can still create massive uninsured liability. SOC 2 doesn’t measure whether an AI’s outputs are covered by your policy.
Estimates of unsanctioned AI application usage inside enterprises have been consistently high — numbers in the range of several hundred to over a thousand distinct AI tools per large organization are not unusual in recent surveys. Security teams have started working through this inventory. But discovery through a security lens produces a prioritized list of data exposure risks. Discovery through an insurance lens asks a different question of the same inventory: which of these tools are generating liability that existing policies don’t cover? Same database. Completely different query. And currently, almost no organization is running both.
Where the Real Exposure Lives
The divergence between these two lenses becomes concrete when you look at specific shadow AI scenarios — the kind that are actually occurring inside organizations today, not hypothetical edge cases.
Consider the marketing team’s content AI. The security assessment might conclude: acceptable risk. No PII exposure, data contained within the vendor’s environment, terms of service reviewed, no red flags on the data flow diagram. But the insurance questions look different. Who owns the IP in the outputs? If the model was trained on data it wasn’t licensed to use, and a client later sues over AI-generated deliverables, does that fall under errors and omissions coverage — or does an intellectual property exclusion apply? Does the organization even know whether its E&O policy has been updated to address AI-generated professional work product? The security team cleared the tool. The insurance exposure was never evaluated.
Consider the HR team’s resume screening tool. Security assessment: vendor SOC 2 Type II certified, data encrypted in transit and at rest, access controls properly configured. Insurance assessment: is this tool making or substantially influencing employment decisions for positions in Illinois or Colorado? Does the organization’s employment practices liability policy have an AI decision-making exclusion, which carriers have been increasingly adding since 2024? Is the organization disclosing AI use to candidates as state laws in several jurisdictions now require? The security baseline is met. The EPL exposure is unexamined. We’ve written previously about how AI classification intersects with industry-specific liability frameworks, and employment decisions represent one of the sharpest edges of that problem.
Consider the finance team’s forecasting model — internal only, no external data, no third-party exposure that a security assessment would flag. But the insurance question is whether material business decisions are being made on the basis of AI outputs, and whether those decisions are documented in a way that would survive a D&O claim if they cause significant losses. The model is secure. Whether the governance around it is adequate for a director’s fiduciary defense is a separate question that the CISO’s team isn’t positioned to answer.
Consider the customer support chatbot that’s been deployed with good intentions and reasonable technical controls — sandboxed, can’t access production systems, responses logged. The Air Canada case established that chatbot commitments can create binding obligations even when the company disputes that the bot was authorized to make them. If that chatbot makes a promise about pricing, delivery, or service terms, and a customer relies on it to their detriment, the question of whether the organization’s commercial general liability policy responds to that claim is not a technical question. It’s a coverage question, and the answer depends entirely on how the policy is written and what the carrier knew about AI use when it priced the risk.
The pattern is consistent across all of these scenarios. Security frameworks look at the input side of AI tools: data, access, authorization, exfiltration risk. Insurance frameworks look at the output side: decisions, commitments, affected third parties, financial consequences. Shadow AI that is secure — in the full technical meaning of that word — can still be entirely uninsured. The two assessments are not redundant. They are examining different things.
Why the Framing Matters
This is not an academic distinction. The framing determines who owns the problem, what they do about it, and what gets left undone.
If shadow AI is a security problem, it gets handled by the CISO’s team using security tools. The workflow is discovery, risk scoring based on data exposure criteria, access control remediation, and ongoing monitoring. The output is a dashboard showing which unsanctioned AI tools are in use, what data they touch, and whether access has been revoked or approved. This is legitimate and valuable work. It solves the problem it’s designed to solve.
If shadow AI is also an insurance problem — which it is, and which carriers are increasingly confirming through their underwriting questions and exclusion language — then it requires a parallel exercise that most organizations aren’t running. An AI inventory with decision-level classification, not just data-level classification. A policy audit that maps current AI usage patterns against exclusion language in CGL, E&O, EPL, D&O, and cyber policies. A governance framework that produces documentation carriers can evaluate when an AI endorsement application comes in. The output of this exercise isn’t a risk dashboard. It’s a carrier-ready risk posture that demonstrates that someone inside the organization has mapped AI usage to coverage.
Most companies are doing the first exercise and not the second. The gap between these two is exactly where uninsured AI liability accumulates — not because anyone is being negligent, but because the organizational structures that handle each exercise don’t talk to each other about shadow AI. The CISO is solving the security problem. The risk manager is renewing policies. Neither is conducting the joint exercise that would reveal which approved and unapproved AI tools are creating exposure that isn’t covered.
The organizations we work with that navigate this most successfully are the ones where the security team and the risk management team are actively collaborating on shadow AI — not working in parallel silos toward different deliverables. The security team’s discovery capabilities are excellent; the problem is that what they discover is being evaluated only through a security lens. That same inventory, run through an insurance lens, produces a completely different risk picture. Both are necessary. Right now, most organizations are only doing one.
The shadow AI problem is going to get worse before it gets better. Every software vendor is embedding AI features into products that organizations already use and have already approved. Every employee is experimenting. The discovery challenge is real, ongoing, and not going away — the inventory that a security team builds today will be partially obsolete in six months as capabilities proliferate.
But the deeper problem isn’t that shadow AI exists. It’s that the people discovering it and the people insuring it are using different maps. The security team’s map shows data flows and access patterns. The carrier’s map shows decisions, outputs, and liability. These maps cover the same territory from different vantage points, and until organizations start overlaying them — until the AI inventory that security runs and the coverage assessment that risk management needs become the same exercise, or at least synchronized exercises — the gap will keep producing exposure that nobody owns and no policy covers.
That’s not a technology problem. It’s an organizational one, which means it’s solvable without waiting for new tools or new regulations. It requires the CISO and the risk manager to sit down together with the shadow AI inventory and ask two sets of questions instead of one. The technology is already doing more than the governance has accounted for. The coverage gap that creates is real, and it’s already being written into policy exclusions by carriers who understand it better than most of their insureds do.