Embedded AI is becoming harder for IT teams to govern because it does not always arrive as a new application.
AI features are increasingly being added to software that organizations already use and trust. That creates a visibility gap: IT may know the application is in use, but not which AI capabilities have been enabled, what data they can access, or whether those capabilities were ever reviewed.
In this article, we look at where embedded AI risk comes from, why it can be harder to control than Shadow AI, what IT teams need to track, and how to manage it in practice.
1. Your Approved Software May No Longer Be the Software You Approved
Your organization may already have a strong process for reviewing new software. But what happens when a tool that was approved months ago adds an AI assistant, meeting summarization, or AI capability?
No new application was installed. No employee bypassed procurement. Yet the way company data is processed may have changed.
This is embedded AI risk: AI capabilities appearing inside software your organization already trusts, without triggering a new security, privacy, or governance review.
2. Embedded AI Can Be Harder to Control Than Shadow AI
Shadow AI is easier to recognize as an AI governance problem because it involves employees using tools outside approved channels. Embedded AI is less obvious. The software itself may already be sanctioned, while the AI capability inside it has never been reviewed.
That makes the risk easier to overlook and harder to assign.
Sensitive Data Can Reach AI Without Employees Realizing It
With Shadow AI, employees often take clear actions: open an external AI tool, upload, or enter company information into it. Embedded AI removes much of that friction.
If AI is added to a CRM, it may already have access to customer records, insights, and other sensitive data. Employees can use the feature to summarize accounts or draft follow-ups without realizing that an AI model may now process this information.
The risk is not just what users choose to share. It is what the AI can access through the application itself.
Ownership Becomes Unclear
Shadow AI usually has a visible entry point: a user or team brings in a new tool.
Embedded AI often does not. The application may already be owned by the business, managed by IT, reviewed by Security, and contracted through Procurement.
When AI is added later, no team may be clearly responsible for reassessing it. The result is a familiar governance gap: the software has an owner, but the AI capability does not.
Existing Approvals Can Become Outdated
A software approval only reflects what was reviewed at that point in time.
A CRM approved for storing customer data may later add AI features that summarize records, analyze calls, or generate outreach. The vendor is still approved, but the way data is processed has changed.
If IT does not revisit that approval, the inventory can say “approved” while no longer reflecting the product’s current risk.
Read more: IT Security Risk and IT Asset Management: What Every IT Leader Must Know
3. What IT Needs to Know About Every Embedded AI Capability
These risks all point to the same underlying problem: IT may know the application, but still lack enough visibility into the AI capability inside it.
Before IT can make a decision, it needs a clear picture of the AI capability. Only then can IT decide whether the feature is safe to use, should be restricted, or needs further review.
For each embedded AI capability, IT should be able to answer a few practical questions.
What Does the AI Actually Do?
“AI-enabled” can mean very different things. A feature might summarize meeting notes, generate customer emails, search internal documents, recommend decisions, or act on a user’s behalf.
Understanding the capability matters because not all AI features carry the same risk. A writing assistant may only generate text. An AI agent may access company systems, use sensitive data, and take actions automatically.
What Data Can It Access?
An embedded AI feature may already have access to data stored in the application. That could include customer records, documents, messages, source code, or employee information.
The key question is not only “What data are users giving the AI?” but also “What data can the AI reach on its own?”
Where Does the Data Go?
The application vendor may not operate the AI model itself. Data could be processed by external model providers that were not part of the original software review.
IT should know where the data is processed and whether it stays within the vendor’s environment. The team should also check how long the data is retained and whether it may be used to improve or train AI models.
4. How to Manage Embedded AI Risk
Managing embedded AI does not mean blocking every AI feature. It means knowing where AI exists, who owns it, what risk it introduces, and what action should follow.
Step 1: Add AI Capabilities to Your Asset Inventory
Start with the applications you already know about. For each approved application, you should check whether new AI features have appeared since the last review.
Instead of marking an application as simply “Approved,” add the AI capability to the same record.
For example, if Salesforce adds an AI assistant, record what the feature does. Then document what customer data it can access, who owns it, and whether it has been reviewed. This small change matters. It helps IT see that the application may still be approved while a newer capability inside it is not.
At minimum, record:
- AI capability
- Enabled or Disabled status
- Users or Teams with access
- Business purpose
- Last review date
Rule of thumb: do not wait until someone reports a problem. Make checking for new AI capabilities part of regular software reviews.
Learn more: IT Leaders Prioritize SaaS Management to Tackle Shadow IT
Step 2: Assign an Owner Before You Assess the Risk
Once a new AI capability is identified, decide who is responsible for it. Do not assume the application owner automatically owns the AI risk.
For example, Sales Operations may own the CRM. Security needs to review its AI data access and Legal may need to check how customer information is processed.
For each capability, IT should be able to answer:
- Who owns the business?
- Who reviews the risk?
- Who can approve or disable it?
Without clear ownership, AI features can stay active simply because every team assumes someone else is reviewing them.
Step 3: Assess What the AI Can Actually Reach
Now move from the feature itself to the data and systems behind it. You should not ask whether users can paste sensitive data into a prompt. Instead, check what the AI can already access through the CRM. That may include: contact details, notes, support history and more
Then follow the data one step further. You can check whether:
- Does the data stay inside the application vendor's environment
- Is it sent to another model provider
- Are prompts or outputs retained
- Can the data be used for training
- Can administrators limit what the AI can access
The practical risk often sits in these details, not in the fact that the product simply says "AI-powered."
Step 4: Decide How the Feature Should Be Used
Once you understand the capability, owner, and data exposure, decide what action makes sense. The goal is to match the control to the actual risk, rather than applying the same rule to every AI feature. The answer does not have to be only allow or block.
You might:
- Approve it for general use
- Limit it to certain teams
- Prohibit sensitive data
- Disable specific AI functions
For example, the CRM assistant may be useful for drafting follow-up emails but too risky for analyzing confidential customer attachments. In that case, you can approve the business use while restricting the higher-risk capability.
Step 5: Reassess When the Software Changes
The review should not end once the feature is approved. A vendor may later introduce a new model. The app might connect the assistant to more data, enable agentic AI actions, or change how information is retained.
You should set a trigger for reassessment when:
- A major AI feature is added
- The model provider changes
- The feature gains access to new data
- Permissions expand
- The vendor changes its AI terms
- Usage spreads to more teams
Then you can reupdate the inventory, owner, and approval status.
The important shift is to stop treating software approval as permanent. For embedded AI, the better question is not: "Was this application approved?"
It is: “Does our current approval still match what this application can do today?"
FAQs
1. What are common examples of embedded AI in business software?
Embedded AI can appear in tools your teams already use every day. Common examples include AI assistants in CRM platforms, meeting summaries in collaboration tools, AI search in knowledge bases, code assistants in development platforms, and AI recommendations in HR or analytics software.
The key point is that these features may arrive through a product update rather than a new software purchase.
2. What should IT ask vendors about newly added AI features?
Start with how the feature handles company data.
Ask which AI model powers the feature, whether third-party providers are involved, where data is processed, how long prompts and outputs are retained, and whether customer data is used for model training.
You should also check what admin controls are available. For example, can the AI feature be disabled, limited to certain users, or restricted from accessing sensitive data?
3. How should IT prioritize which embedded AI features to review first?
Not every AI feature needs the same level of attention.
Start with capabilities that can access sensitive data, are available to many employees, rely on external model providers, or can take actions automatically.
For example, an AI writing assistant with no access to internal systems may be lower priority than an AI agent that can read customer records, update data, or trigger workflows.
4. Can existing security tools detect embedded AI?
Sometimes, but not always. Software discovery and SaaS management tools may show that an application is in use. However, they may not show every AI feature enabled inside that application.
That is why IT still needs capability-level visibility. Knowing that a CRM is approved does not automatically tell you whether its AI assistant is enabled, who uses it, or what data it can access.
5. Does disabling an AI feature remove all of the risk?
Not necessarily. If employees have already used the feature, company data may have been processed, retained, or shared with another AI provider before it was disabled.
IT should review previous usage, vendor retention policies, and any data already processed. Disabling the feature stops future use, but it may not resolve what happened before the control was applied.
Final Thoughts
Embedded AI changes the way organizations need to think about software risk. An application can remain approved while new AI capabilities change what data it can access, how that data is processed, and who should be responsible for reviewing it.
AssetLoom is also working on a new AI Scanner to help IT teams discover AI tools and identify AI usage across their environment. Stay tuned for the upcoming release and get a clearer view of where AI is entering your organization.
Top comments (0)