Embedded AI in SaaS Tools (Notion, Canva, HubSpot): Hidden Shadow AI

Your CRM, project management, and design tools now have AI features that may not be in your policy. Here's the classification framework.

How Embedded AI Differs from Standalone AI Tools

Standalone AI tools — ChatGPT, Claude, Midjourney — are easy to see. Employees sign up, companies can block domains, and the risk surface is visible. Embedded AI is different: it lives inside software your company already licensed, often enabled by default, and invisible to anyone who isn't looking at feature changelogs.

When HubSpot adds AI-generated email copy suggestions, when Canva surfaces a "Magic Write" text generator, or when Notion rolls out its AI assistant, those features inherit the session context of whatever the user is already doing. That means the AI has access to whatever data is open in front of the employee — a client record, a contract draft, a personnel note — without the employee making a conscious decision to "share it with an AI."

The practical difference for your policy team: standalone AI adoption requires an employee to take an affirmative action (open a new tab, create an account, paste content). Embedded AI requires only that the employee be logged into a tool they use every day. That's a fundamentally different risk model, and most acceptable use policies written before 2023 don't address it at all. For broader context on how this fits the shadow AI problem, see what shadow AI actually means for your organization.

Where Your Data Goes: Data Flows in SaaS-Embedded AI

When an employee uses an embedded AI feature, the data path typically looks like this: the content they're working on (a deal record, a design brief, a project note) gets sent to the SaaS vendor's AI infrastructure — which may be their own model or a third-party model they've licensed (often OpenAI, Google, or Anthropic under an API agreement). That third-party receives your business data under the vendor's agreement with them, not under your agreement with the vendor.

This matters because your DPA with, say, HubSpot governs how HubSpot handles your data. But if HubSpot is sending prompts to OpenAI to power its AI features, OpenAI's handling of that data is governed by HubSpot's agreement with OpenAI — an agreement you've never seen and had no part in negotiating. The sub-processor question is the central legal risk in embedded AI, and it's almost never addressed in legacy vendor contracts.

The data retention question is equally important. Some embedded AI features log prompts and outputs; others don't. Some use your inputs to improve their models unless you opt out at the enterprise tier; others commit not to train on customer data by default. These policies vary by tool and by pricing tier — and they change. The table below maps the current documented positions for three common tools.

Sources: Notion Privacy Policy, Canva Enterprise Terms of Service, HubSpot AI Product Documentation. Review these directly — terms change, and what's accurate at publication may be updated by the vendor.

Admin Controls: What Actually Exists

The good news is that enterprise and business tiers of most major SaaS platforms now offer admin-level controls over AI features. The bad news is that those controls are rarely surfaced clearly in the UI, most small-to-midsize companies are on mid-tier plans that don't include them, and even when controls exist, they default to "on."

The practical approach is a two-step audit: first, list every SaaS tool in your stack that has released AI features in the last two years; second, log into the admin console of each and find the AI feature settings. What you're looking for:

• Enable/disable toggle for AI features at the organization level
• User-level permissions — can you grant AI access to some roles and not others?
• Data residency settings — does AI processing occur in the same region as your data?
• Audit logs — can you see which users triggered AI features and on what content?
• Opt-out from model training — is this on by default, or do you have to request it?

For tools where you're on a free or starter plan, assume you have no meaningful admin controls. If those tools touch any regulated data — health information, financial records, personal data of EU residents — either upgrade to a tier with controls, prohibit the AI features explicitly in your policy, or stop using those tools for that data category. There's no middle path that satisfies GDPR Article 28 or HIPAA's Business Associate requirements.

Contract Amendments Your Vendor Agreements Need

Your existing vendor contracts need to be reopened whenever a vendor materially expands how they process your data — and enabling AI features is exactly that. The two documents to focus on are the Data Processing Agreement (DPA) and the list of approved sub-processors.

A DPA written before your vendor had AI features is not a DPA that covers AI features. It's that simple. Assume the gap exists until you've confirmed otherwise in writing.

When you go back to your vendor, you need the DPA to address four things specifically for AI functionality:

• Sub-processor disclosure: The vendor must identify the AI infrastructure provider (e.g., "We use OpenAI's API for our content assistant feature") and either require your consent before adding new AI sub-processors or commit to advance notice.
• Purpose limitation: The vendor must contractually commit that your data processed through AI features is used only to provide the service to you — not to train or improve general models.
• Retention limits: Prompts and outputs generated by your employees should not be retained beyond what's needed to return the result, unless you've explicitly agreed to longer retention for specific purposes.
• Deletion rights: Your right to request deletion of AI-processed data should extend to any copies held by sub-processors.

If a vendor won't provide a DPA amendment covering AI features, treat their AI features as unauthorized for your regulated data categories. That's a policy decision you can document and enforce — and it's a cleaner position than operating under an ambiguous contract.

Policy Language That Actually Covers Embedded AI

Most AI acceptable use policies are written around the use of standalone tools: "Employees must not input confidential data into external AI tools." That language doesn't catch an employee clicking "Summarize" on a client proposal in Notion, because Notion isn't "an external AI tool" in the employee's mental model — it's just Notion.

Your policy needs a definition that covers the feature, not the tool category. A practical formulation:

"AI features" means any functionality within an approved or unapproved software application that uses machine learning or generative AI to process, summarize, generate, or classify content — including features embedded in tools the company has licensed for other purposes.

Beyond definition, your policy needs three operative rules specific to embedded AI:

1. Data classification gate: Before using any AI feature — embedded or standalone — employees must confirm the data they're working with is classified at a tier approved for that tool. If the tool isn't on the approved list for that data tier, the AI feature is off-limits regardless of what the tool's general approval status is.
2. Admin-enabled by default: AI features in SaaS tools are disabled for business use until the IT or security team has reviewed the data flow and the admin controls, and the tool has been added to the approved AI features list.
3. Vendor change notification: Employees who notice a SaaS tool has added a new AI feature must report it to [designated team] within [X] business days. This creates a human detection layer for new feature rollouts.

If you're building or updating your policy from scratch, the AI acceptable use policy template guide covers the full structure, including how to handle data classification tiers. You can also generate a tailored policy kit that incorporates embedded AI coverage alongside standalone tool rules.

Building an Ongoing Review Process

Embedded AI is not a one-time audit problem. Vendors ship AI features in quarterly releases, sometimes with minimal announcement. The company that audits its SaaS stack in January and considers the job done will have a different risk profile by April.

Build a lightweight standing process:

• Subscribe to product changelogs for every SaaS tool in your stack. Most vendors publish these publicly. Assign someone to review them — this doesn't have to be a security role; an operations coordinator can flag AI-related updates.
• Annual DPA review: Set a calendar trigger to review the AI-related provisions of your top five vendor DPAs every 12 months, or whenever a vendor announces a major product update involving AI.
• Quarterly approved-tool list update: The list of AI features approved for each data classification tier should be a living document, reviewed at minimum quarterly.
• New tool onboarding checklist: Before approving any new SaaS tool, require a review of its AI features as part of the procurement checklist — not as an afterthought after the contract is signed.

The operational cost of this process is low. The cost of discovering that your HR platform's AI summarization feature has been processing employee performance records through an unreviewed sub-processor for six months is considerably higher.

About Shadow AI Policy: We build AI acceptable use policy tools for HR and operations teams at 50–500 person companies. We publish guides on shadow AI, acceptable use policies, and AI governance, updated as regulations and AI tools change.