Most conversations about shadow AI focus on the deliberate adoption scenario: an employee discovers a useful AI tool, signs up independently, starts using it for work, and the business ends up with an ungoverned AI relationship it didn’t know about. This version of shadow AI is real, consequential, and worth addressing — and a significant amount of small business AI governance work has been built around detecting and managing it.
But there is a second, less recognized version of shadow AI that doesn’t involve any employee making a deliberate adoption decision at all. It is the AI that arrives embedded in software the business already pays for — the AI features that ship in Microsoft 365 updates, the AI capabilities that get enabled by default in Google Workspace, the AI assistance built into Salesforce and HubSpot and the industry-specific platforms businesses have been using for years, the AI transcription and summarization that now comes standard in Zoom and Microsoft Teams and Slack. Employees use these features because they are convenient and present, not because anyone evaluated them as AI tools. The business pays for them as part of existing subscriptions. And in most small businesses, no one has evaluated these embedded AI features against the same governance questions that would apply to a new standalone AI tool adoption.
This is embedded shadow AI — and it represents one of the most significant gaps in current small business AI governance programs, precisely because it operates in the blind spot between “software we’ve governed” and “AI tools we need to govern.” Understanding how embedded AI creates shadow AI risk for small business — and what it takes to address it — is an increasingly urgent capability requirement for any business that is serious about its AI data security posture.
How Embedded AI Creates Shadow Risk Without Anyone Making a Choice
The mechanism through which embedded AI creates shadow risk is different from the mechanism that drives deliberate shadow AI adoption, and understanding the difference is what makes it possible to design governance that addresses both. In deliberate shadow AI, an employee makes a choice — to use a specific tool, to submit specific data — and the governance failure is the absence of oversight and control around that choice. In embedded shadow AI, the data flow happens as a byproduct of using software for its primary intended purpose, without any discrete employee decision that governance could target.
When a Microsoft 365 user composes an email and accepts a Copilot suggestion, data has been processed through Microsoft’s AI infrastructure. When a Salesforce user receives an Einstein-generated lead score or activity summary, customer data has been processed through Salesforce’s AI infrastructure. When a Zoom user’s meeting is automatically transcribed and summarized, everything said in that meeting has been processed through Zoom’s AI infrastructure. In none of these scenarios did the employee choose to “use an AI tool” in the way that opening ChatGPT and pasting in a document represents a choice. The AI is simply part of how the software functions, and using the software means using the AI whether or not the user is aware of it.
The governance implication is that the AI tool inventory approach that works for deliberate shadow AI — surveying employees about what AI tools they use — substantially underestimates the AI processing footprint created by embedded features. An employee who answers “I use Microsoft Copilot, Google’s AI suggestions, the Einstein features in Salesforce, and automatic meeting transcription in Zoom” is, in many businesses, accurately describing embedded AI use. An employee who answers “just the AI tools IT gave us access to” may be describing the same situation — using all of those embedded features — without recognizing them as the AI tools the survey question was asking about.
Productivity Suite AI — Microsoft Copilot, Google Gemini, and the Features That Arrive in Updates
Microsoft 365 and Google Workspace are the productivity infrastructure of the overwhelming majority of small businesses in the United States, and both platforms have made comprehensive AI integration a central product direction. Microsoft Copilot capabilities — drafting assistance, meeting summarization, email response suggestions, document analysis, Teams conversation summaries — are being progressively rolled out across Microsoft 365 subscriptions, with different features enabled at different subscription tiers and at different points in time. Google’s AI features in Workspace follow a parallel trajectory, with Gemini capabilities embedded in Gmail, Docs, Sheets, Meet, and the full suite of Google productivity applications.
The data handling implications of these embedded AI features are governed by the data processing terms of the business’s existing Microsoft or Google agreement — but those terms may not have been reviewed since the AI features were added, and they may not address AI-specific data handling in the detail that a governance program requires. More fundamentally, most small businesses haven’t conducted the use-case-specific evaluation that embedded productivity suite AI requires: which AI features are enabled for their tenant, which employees have access to which features, what data flows through which features as part of ordinary work, and whether the data handling terms that govern those flows are adequate for the data sensitivity involved.
The particular risk with productivity suite AI is that it operates across the entire surface area of the business’s work — email, documents, meetings, calendars, spreadsheets — which means it potentially processes every category of data the business handles: client communications, financial records, personnel information, strategic plans, and everything else that flows through the productivity platform. A governance program that evaluates a standalone AI tool adoption but not the AI capabilities embedded in the productivity platform the entire organization uses has evaluated a small fraction of the actual AI data processing footprint.
CRM and Business Platform AI — Salesforce, HubSpot, and Industry Software
Customer relationship management platforms and industry-specific business software represent a second major category of embedded AI risk, because these platforms hold some of the most sensitive data small businesses manage — customer contact information, interaction histories, deal details, financial data, health information in healthcare-adjacent software — and AI features are being added to these platforms at a rapid pace as vendors compete to embed AI value into their core products.
Salesforce Einstein, HubSpot’s AI features, and their counterparts in industry-specific CRM and practice management platforms are generating lead scores, summarizing customer interaction histories, drafting follow-up communications, identifying at-risk accounts, and performing a range of AI-assisted tasks that involve the customer data in the underlying system. From the employee’s perspective, these are simply features of the CRM — tools for working more effectively with customer relationships. From a data governance perspective, they are AI processing relationships involving customer data that may be subject to HIPAA Business Associate Agreement requirements, FTC Safeguards Rule service provider oversight obligations, or Texas TDPSA data processing agreement requirements, depending on the data involved and the business’s regulatory context.
The specific risk with CRM and business platform embedded AI is that the AI vendor is typically the same as the platform vendor — Salesforce is both the CRM and the AI provider — which can create a false sense that the AI relationship is covered by the existing platform agreement. In some cases it is; in others, the AI features operate under separate terms, separate data retention policies, or separate model training provisions that differ materially from the base platform terms. The governance requirement is to evaluate the AI-specific terms, not to assume that the existing platform relationship covers the AI features added to the platform.
Communication and Collaboration Tool AI — Slack, Zoom, Teams, and Email Platforms
Communication and collaboration platforms have embedded AI into their core functionality at a pace that has outstripped most governance programs’ ability to keep up. Zoom’s automatic meeting transcription and AI-generated summaries. Microsoft Teams’ Copilot features for meeting recaps, conversation summaries, and action item extraction. Slack’s AI-powered search, channel summaries, and recap features. Email platforms’ AI-suggested replies, priority inbox features, and compose assistance.
The data sensitivity of communication and collaboration tools makes embedded AI in these platforms particularly consequential from a governance perspective. Business communications contain information from virtually every category that governance programs are designed to protect: client confidential communications, attorney-client privileged discussions, healthcare communications involving patient information, financial advisory communications, personnel discussions, and the full range of business conversations that carry confidentiality expectations or regulatory protections. When communication platform AI features process these conversations — summarizing meetings, extracting action items, generating recaps — they are processing exactly the data categories that are most sensitive and most consequential if mishandled.
The specific governance challenge with communication platform AI is that opting out of these features is often not straightforward. Some features are enabled by default and require administrator action to disable. Others are enabled at the user level and vary across the organization based on individual user settings. And some are so deeply integrated into the platform’s core user experience that disabling them would significantly impair the platform’s usability — making “turn it off” a difficult governance response even when the governance concern is legitimate. The more sustainable approach is ensuring that the platform’s AI data handling terms are adequate for the communications data the AI is processing, and that employees understand which platform communications are being processed by AI features.
Why Embedded AI Is Harder to Govern Than Tool-Based Shadow AI
Embedded shadow AI presents governance challenges that differ in kind from the challenges of governing deliberate shadow AI tool adoption, and understanding these differences is what makes it possible to design governance approaches that actually address embedded AI rather than simply extending tool-based governance approaches that weren’t designed for it.
The inventory challenge is more complex. Cataloguing the standalone AI tools employees use requires asking employees what they’ve adopted — a survey and interview process that, while imperfect, produces an identifiable list. Cataloguing the embedded AI features in existing software requires a different approach: an audit of the platforms the business subscribes to, an assessment of what AI features each platform includes at the business’s subscription tier, an evaluation of which of those features are enabled versus disabled in the business’s configuration, and a determination of which features employees are actually using as part of their daily workflows. This requires platform administration access, vendor documentation review, and technical investigation that a survey-based inventory process doesn’t capture.
The governance remediation is also different. For a standalone shadow AI tool, governance remediation typically means evaluating whether the tool should be authorized (and if so, what agreements and controls are needed) or prohibited (and if so, how the prohibition is enforced and what authorized alternative is provided). For an embedded AI feature, the remediation options are different: disable the feature if it creates governance risk and adequate alternatives exist, accept the feature under the existing platform data handling terms if those terms are adequate for the data involved, negotiate updated terms with the platform vendor if the existing terms are inadequate, or implement compensating controls that limit the data the embedded AI processes. None of these options is as simple as “authorize or prohibit,” and they require platform administration capability and vendor relationship management that not all small businesses have readily available.
According to the Cybersecurity and Infrastructure Security Agency, understanding the data flows created by all software in use — including features added to existing platforms — is a foundational element of organizational data security. The embedded AI features that have been added to productivity suites, CRM platforms, and communication tools in the past two years represent exactly this category: new data flows created by new software capabilities, requiring the same security evaluation that would be applied to any new software adoption, even though the platform itself is not new.
Building an Embedded AI Inventory as Part of Shadow AI Governance
Addressing embedded shadow AI begins with extending the AI tool inventory process to capture embedded features alongside standalone tools. This extended inventory requires a platform-by-platform assessment of every software subscription the business maintains, evaluating each against a consistent set of questions: Does this platform include AI features? Which features are enabled at the business’s subscription tier? Which features are active in the business’s tenant configuration? What data does each enabled feature process? Under what terms does the platform’s AI handle that data?
The assessment produces a materially more complete picture of the business’s AI data processing footprint than a standalone tool inventory alone, because it captures the embedded AI that operates across the full surface area of the business’s software environment rather than only the AI that someone consciously chose to use. For most small businesses conducting this assessment for the first time, the embedded AI footprint is substantially larger than expected — a finding that typically motivates the governance work required to bring embedded AI under the same oversight framework applied to standalone tools.
The NIST AI Risk Management Framework identifies the importance of organizational awareness of all AI systems in operation — not just the AI systems that were formally adopted through intentional decisions, but the full operational AI landscape including embedded capabilities. Building an embedded AI inventory is the operational implementation of that awareness requirement, and maintaining it as platforms continue to add AI capabilities is the ongoing governance work that keeps the inventory current. For small businesses managing this alongside their other operational priorities, ensuring that embedded AI governance is part of the AI program management cadence — reviewed when platform subscriptions are renewed, when platform updates are applied, and when new software is adopted — is what prevents the embedded AI footprint from silently expanding beyond what the governance program covers.
