The embedded AI activating inside your existing SaaS tools is the shadow AI most governance programmes are not built to catch. Shadow AI has a new face, and it is not the one most IT leaders are watching for. The familiar narrative is about employees signing up for ChatGPT or a rogue meeting-transcription tool. That risk is real, and you have probably already started building policy around it. But there is a second, less visible category growing faster and carrying equal compliance weight: AI features silently activating inside software your organization already approved, and it is the category that standard SaaS management processes were never designed to catch.
Microsoft Copilot, Salesforce Einstein, Notion AI, Slack AI - these are not new entrants bypassing procurement. They are AI capabilities being pushed into existing subscriptions by vendors who already have your data and your trust. Your IT team approved the base product. Nobody reviewed the AI overlay. Under EU law, that distinction does not exist. Deployer obligations attach the moment an AI system is in use - regardless of who switched it on.
The Auto-Enabled AI Problem
Embedded AI is not shadow AI in the traditional sense. No employee went around procurement. No personal credit card was involved. The vendor simply updated its product, and AI came with it.
Nearly three-quarters of senior leaders funded AI and generative AI technology capabilities as their top investment priority in 2025 (Deloitte Tech Value Survey, 2025). Simultaneously, 92% of SaaS vendors have either already launched AI features or have them on their near-term roadmap (High Alpha SaaS Benchmarks Report, 2025). The vendor roadmap and the IT governance process are moving in opposite directions.
EMBEDDED AI: THE SCALE OF THE PROBLEM
92% of SaaS vendors have either launched AI features or have them on their near-term roadmap | 80% of enterprises will have deployed GenAI apps by 2026 | 70% of European organisations lack a well-defined AI governance model |
The mechanism is familiar to anyone who has lived through a SaaS platform update. A productivity suite you have run for three years ships a new release. Buried in the changelog is a note that AI-assisted features are now enabled by default for all enterprise tiers. There is no new contract, no new DPA, no new procurement ticket. The admin panel has a toggle to disable it, but only if someone knows to look.
The scale of unsanctioned AI use is already significant. According to Microsoft and LinkedIn’s 2024 Work Trend Index (31,000 people across 31 countries), 78% of AI users are bringing their own tools to work without company provision - and 71% of workers have used unapproved AI tools at their organisations (Microsoft Work Trend Index 2024; IT Pro, Oct 2025). Add vendor-initiated AI activation to that figure, and the true scope of ungoverned AI in your environment becomes difficult to estimate - let alone document.
⚠ The Governance Gap IT teams approved the base product. They did not approve the AI overlay. When a vendor activates AI features by default across existing subscriptions, the organization becomes a deployer under EU law - even if nobody in IT was aware the change happened. |
Concrete examples of this pattern are now mainstream. Salesforce has pushed 30+ new AI capabilities into Slack as of early 2026, transforming it from a messaging tool into an AI-powered workspace that surfaces CRM data, drafts responses, and automates task creation (Salesforce official product announcements, 2026). Notion AI is bundled into Notion accounts on paid plans. Zoom auto-enables AI meeting summaries. Grammarly's AI writing layer activates across platforms wherever the extension is installed. The question is not whether your stack contains AI. It is whether your SaaS inventory reflects which AI, what data it touches, and what legal obligations that triggers.
Which EU Obligations This Triggers
The critical legal point is this: EU obligations do not care whether you deliberately deployed an AI system. They attach to use. The moment an AI system is operational inside your organization, deployer obligations are live.
EU REGULATORY EXPOSURE FROM EMBEDDED AI ACTIVATION
Framework | Obligation Triggered | Max Penalty |
EU AI Act | Article 26 deployer obligations: document the system, implement human oversight, monitor use, inform affected individuals. Applies from first use. | Up to €15M or 3% of global turnover |
GDPR | Article 35 DPIA required when AI begins processing personal data in a materially new way. Article 30 RoPA must reflect all processing operations, including vendor-added AI. | Up to €20M or 4% of global turnover |
NIS2 | AI-powered SaaS tools that process operational data are ICT services under NIS2. Risk management and incident reporting obligations apply. | Up to €10M or 2% of global turnover |
DORA (Financial) | Every AI tool is an ICT third-party service under DORA Articles 28 & 30. Requires documented register entry, risk assessment, and contractual terms. | Proportionate / supervisory action |
Sources: EU AI Act (Regulation 2024/1689); GDPR (Regulation 2016/679); NIS2 Directive 2022/2555; DORA Regulation 2022/2554
The EU AI Act, now in staged enforcement through 2026, is explicit on this point. A deployer is any organization that uses an AI system in a professional context - it does not matter whether you built the model, chose to deploy it, or simply inherited it via a vendor update. If the system is in use, you are a deployer.
Full EU AI Act deployer obligations for high-risk systems take effect on 2 August 2026. GDPR AI literacy obligations and prohibited practices provisions have already been enforceable since February 2025 (EU AI Act, digital-strategy.ec.europa.eu). Most enterprises are tracking August 2026 and assuming they have a runway. They do not - particularly for embedded AI already in production.
GDPR DPIA Trigger: New Processing Mode A DPIA (Data Protection Impact Assessment) is required under GDPR Article 35 wherever processing is likely to result in a high risk to individuals. When a vendor enables AI that begins processing employee or customer personal data in a materially different way - summarising emails, analysing behaviour, generating outputs based on HR or CRM data - this constitutes new processing. The DPIA obligation is triggered regardless of whether your organization chose to activate the feature. |
The GDPR and EU AI Act do not duplicate each other - they stack. A single embedded AI feature in an HR platform can simultaneously trigger a DPIA under GDPR Article 35, a Fundamental Rights Impact Assessment under EU AI Act Article 27, and documenting the system in your Record of Processing Activities. GDPR fines cap at €20M or 4% of global annual turnover; EU AI Act penalties add up to €15M or 3% on top. These are additive risks.
Microsoft Copilot - The Biggest Embedded Risk
No embedded AI scenario demands more governance attention than Microsoft 365 Copilot. Not because of security failures - Microsoft's enterprise data protections are extensive - but because of the unprecedented scope of data access it enables from within an already-trusted product boundary.
Microsoft 365 Copilot operates across the entire M365 surface: emails in Exchange, documents in SharePoint and OneDrive, meetings in Teams, calendar entries, chat history. According to Microsoft's own documentation, Copilot accesses this data through Microsoft Graph, inheriting the user's existing permissions. This means Copilot can read everything the licensed user can read - which, in poorly governed tenants, is often far more than intended.
WHAT COPILOT CAN ACCESS IN YOUR M365 ENVIRONMENT
M365 Data Source | Compliance Consideration |
Exchange / Outlook emails | Personal data, client comms, privileged content - requires DPIA review if Copilot summarises or analyses these |
SharePoint / OneDrive files | Over-permissioned file stores are the #1 Copilot risk. Copilot surfaces files the user has access to, including overshared content |
Microsoft Teams chats & meetings | Meeting summaries and transcripts may contain special-category data. EU AI Act transparency obligations apply if individuals are not aware AI is processing this |
Copilot Studio agents | Custom agents can have elevated permissions and take autonomous actions. Each agent requires its own compliance assessment |
Source: Microsoft Learn, Data Privacy and Security for Microsoft 365 Copilot, updated March 2026
The governance problem is not that Copilot is insecure. It is that it changes the GDPR data processing landscape the moment it is enabled. Microsoft updated its Product Terms in September 2025 to include Copilot Chat under Core Online Services under the EU Data Act. In January 2026, Anthropic became a formal subprocessor for Microsoft 365 Copilot - a material change to sub-processing chains that affects every organisation's DPA review (Microsoft Learn, 2026).
⚠ Deployer Obligations Under the EU AI Act Apply to Copilot Using Microsoft 365 Copilot in your organisation makes you a deployer under the EU AI Act. Deployer obligations include: documenting the AI system in your inventory, assessing risk classification, implementing human oversight measures, and informing individuals who interact with or are affected by the system. Microsoft's GDPR compliance does not satisfy your EU AI Act deployer obligations, these are additive. |
Germany's Federal and State Data Protection Conference (DSK) and ENISA have raised specific concerns that Microsoft's standard Data Protection Addendum may not fully meet European data protection requirements. Regulated organisations are advised to negotiate supplementary agreements explicitly governing Microsoft's role, data processing instructions, and compliance obligations. This supplementary DPA review must be refreshed whenever Copilot's processing scope changes - including when new AI features are activated.
What Montro Sees in Copilot Deployments |
Most organisations that deployed Microsoft 365 Copilot before January 2026 have a DPA that is no longer accurate, not because it was poorly drafted. It is because Anthropic became a formal sub-processor for Copilot in January 2026, which was after most DPA reviews were completed. The document the organisation had was correct for the product that existed when it was signed. But the product has changed and the document has not. This kind of sub-processor change does not trigger automatic notifications in most enterprise contracts. The organisation is not told the chain has changed; it has to check. Montro's discovery work identifies this gap as a documentary issue rather than a technical one: the tool is visible, the DPA exists, but the sub-processor annex is out of date. That is a different problem from shadow AI, and it requires a different solution, not discovery. It requires a targeted DPA review against the current Microsoft sub-processor list. |
How to Audit for Embedded AI in Your Current Stack
Most organisations have no structured process for detecting when vendors add AI to existing subscriptions. The audit approach for embedded AI is therefore distinct from standard shadow IT discovery - you are not looking for new tools, you are looking for what changed inside tools you already trust.
EMBEDDED AI AUDIT: 4 CONCRETE STEPS
STEP 1 | Review vendor release notes and changelogs from the past 12 months Every SaaS vendor in your stack publishes changelogs. Systematically review these for all tier-1 and tier-2 applications, looking specifically for any reference to AI, machine learning, Copilot, Einstein, or intelligent features. Flag any feature marked as 'enabled by default' or 'available to all plans'. |
STEP 2 | Check admin panels for AI feature flags Log into the admin console of each major SaaS application and locate AI or intelligence settings. Microsoft 365: check the Microsoft 365 Admin Center under Copilot settings. Salesforce: check Einstein and Agentforce admin settings. Slack: check Slack AI admin controls under workspace settings. Look for toggles set to 'on' that your governance team never reviewed. |
STEP 3 | Pull and review updated DPAs from AI-embedding vendors When a vendor adds AI features, it typically updates its Data Processing Agreement, often in fine print. Download the current DPA for every vendor in your tier-1 stack and compare it against the version you last reviewed. Look for changes in sub-processors, data retention periods, and processing purposes. Any material change to DPA scope should trigger a DPIA review. |
STEP 4 | Map AI data flows against your RoPA and existing DPIAs Cross-reference newly discovered AI processing against your GDPR Record of Processing Activities. For every embedded AI feature that processes personal data in a new or materially different way, the processing activity must be added to your RoPA and assessed for DPIA necessity under Article 35. If a DPIA was conducted for the base product before AI was added, it must be reviewed and updated, and the SaaS inventory entry for that tool must reflect the new processing scope, not the one that existed at original procurement. |
Audit Frequency Matters A one-time embedded AI audit is not sufficient. SaaS vendors ship AI features on rolling release cycles - sometimes monthly. An embedded AI review must be built into your SaaS renewal process and triggered by any vendor changelog notification flagging AI changes. |
Building an Embedded AI Review Process
The SaaS governance gap embedded AI creates is not primarily a technology problem. It is a process problem. The SaaS renewal process, as it exists in most organisations, was designed to review pricing and contract terms - not AI feature activation. Closing the gap requires embedding AI review into every stage of the SaaS lifecycle.
EMBEDDED AI GOVERNANCE: SAAS LIFECYCLE REVIEW MODEL
SaaS Lifecycle Stage | Embedded AI Governance Action Required |
Annual Renewal Review | Ask vendors three questions: (1) Has this product added AI features in the past 12 months? (2) What data does each AI feature access? (3) Has the DPA been updated to reflect AI processing? Require written answers as part of vendor due diligence. |
Vendor Release Notification | Establish a process to receive and review vendor release notes. Any update referencing AI, ML, Copilot, Einstein, or similar must trigger an internal assessment before the feature goes live in your environment. |
New SaaS Onboarding | Add explicit AI inventory questions to your standard vendor onboarding questionnaire. If a tool has embedded AI, classify it under the EU AI Act before contracting. Request the AI system card or technical documentation if the vendor has published one. |
DPA Change Detection | Monitor DPA versions for all tier-1 vendors. When a DPA changes, assess whether the change reflects new AI processing, new sub-processors (as Anthropic became for Microsoft in January 2026), or expanded data retention. Trigger a DPIA review where personal data processing has materially changed. |
Continuous AI Inventory | Maintain a live SaaS inventory that is updated whenever a vendor activates AI in existing tooling, the software inventory management discipline that makes every other governance action in this table possible. Each entry should record: the vendor, AI capability name, data accessed, risk classification under EU AI Act, DPIA status, and human oversight mechanism in place. |
✓ Embedded AI Governance Checklist - Quick Reference |
✓ Vendor changelog monitoring process in place for all tier-1 SaaS |
✓ AI feature flags reviewed in admin consoles of all major platforms |
✓ Updated DPAs received and compared against prior versions for all AI-embedding vendors |
✓ Embedded AI features mapped against existing RoPA entries |
✓ DPIA review triggered for any AI feature processing personal data in a new way |
✓ EU AI Act deployer obligation assessed for each identified AI system |
✓ AI inventory maintained and updated on each SaaS renewal cycle |
✓ Microsoft 365 Copilot deployment reviewed against GDPR DPIA and EU AI Act requirements |
✓ Human oversight mechanisms documented for all AI systems in use |
Frequently Asked Questions
Does enabling Microsoft Copilot require a new Data Processing Agreement with Microsoft?
Not a new DPA, but a review of the existing one. Microsoft's Data Protection Addendum covers Copilot under its Core Online Services framework, but the scope of what Copilot processes is materially different from what the base M365 subscription was originally assessed against. The January 2026 addition of Anthropic as a formal sub-processor for Microsoft 365 Copilot is a specific change that requires review of the sub-processor chain in your existing DPA. Organisations that have not updated their DPA assessment since Copilot was enabled, or since January 2026, are operating against a DPA that no longer accurately reflects the processing taking place.
If a vendor enables AI by default in a product update, is the organisation immediately in breach of the EU AI Act?
Not automatically, but the deployer obligations attach immediately. The EU AI Act does not require deliberate deployment to trigger deployer status. The moment an AI system is in active use in a professional context, the organisation is a deployer. Whether a breach exists depends on whether the system is high-risk under Annex III and whether the required deployer obligations; human oversight, logging, instructions for use, are in place. For most embedded productivity AI, the risk tier is limited rather than high. For embedded AI in HR, recruitment, or credit-related workflows, the Annex III threshold is far more likely to be crossed and the obligations are substantive.
How should embedded AI features be treated in a GDPR Record of Processing Activities?
Each embedded AI feature that processes personal data should ordinarily be treated as a distinct processing activity; it cannot be rolled into the parent SaaS tool's existing entry. The purposes change when AI is introduced, the data categories may change, and the recipients almost certainly change because the AI model provider becomes a new sub-processor. The existing RoPA entry for Slack, for example, does not cover Slack AI's processing of message content by an AI model. A separate entry should be considered, with the AI vendor identified as processor, the processing purpose documented, and the lawful basis assessed.
What is the governance risk if an organisation disables embedded AI features rather than governing them?
Disabling is a legitimate short-term response for tools that cannot yet be brought into governance, but it is not a permanent solution and it carries its own risks. First, disabling requires knowing the feature exists, which requires the same discovery process as governing it. Second, in most platforms the disable toggle is at tenant or admin level, employee-level workarounds and personal-account usage paths often remain available, reintroducing the same shadow AI exposure through a different route. Third, as vendor roadmaps continue to embed AI deeper into core workflows, the cost of disabling increases over time. The governance path; DPA review, RoPA entry, risk classification, usage policy, is the only position that holds up under supervisory scrutiny.
