Third-Party AI Integrations

A technology distribution company's enterprise software stack had evolved over six years into a standard enterprise configuration: Salesforce CRM with Einstein AI, HubSpot for marketing automation with AI content generation, Workday for HR with AI applicant screening, ServiceNow for IT operations with AIOps, and Microsoft 365 Copilot across productivity tools. None of this was particularly unusual for a company of their size and sophistication. What was unusual was the discovery, during a routine AI inventory exercise triggered by their legal team's EU AI Act readiness work, that the company had never assessed any of these embedded AI capabilities as AI systems. Each platform had been procured through the SaaS procurement process , security review of the platform, DPA executed, SOC 2 reviewed, approval granted. The AI capabilities within each platform had been treated as features of the evaluated SaaS product rather than as AI systems requiring separate assessment. The AI inventory exercise identified eleven distinct AI systems in active production use across the enterprise's SaaS stack , systems that were making or influencing decisions about sales leads, marketing engagement, job applicants, IT incidents, and employee productivity. Several of these systems involved decisions that carried potential EU AI Act high-risk classification implications. None had been assessed for EU AI Act compliance, training data practices, bias or fairness, or the specific AI governance requirements the company had adopted.

What are Third-Party AI Integration Risks, Really?

Third-party AI integration risks are the security, compliance, governance, and operational risks created when enterprise SaaS platforms embed AI capabilities , features powered by machine learning models, large language models, or AI-driven automation , within their products. These embedded AI capabilities may process the enterprise's most sensitive operational data, make or influence consequential decisions about employees, customers, or partners, and carry specific regulatory compliance obligations that differ from the compliance obligations of the SaaS platform itself. The risk is not that the AI features are malicious , they are legitimate product features. The risk is that they are assessed through a SaaS evaluation framework that is not designed to identify AI-specific risks.

The SaaS-to-AI assessment gap is the core problem. Enterprise SaaS procurement processes evaluate security controls, data handling practices, compliance certifications, and contractual protections for data processed by the SaaS platform. These evaluations are appropriate for SaaS platform risk. They do not address the AI-specific dimensions of embedded AI features: training data provenance, model accuracy and fairness, explainability for consequential decisions, EU AI Act high-risk classification, and the specific ways that AI-driven automation changes the risk profile of the data the SaaS platform processes.

The default enablement problem amplifies the governance gap. Many embedded AI features in enterprise SaaS are enabled by default rather than requiring explicit activation , lead scoring in Salesforce, content suggestions in HubSpot, applicant ranking in Workday. The enterprise that procures a SaaS platform and accepts default settings may be deploying AI capabilities that process sensitive data and influence consequential decisions without any specific decision to adopt those AI capabilities. The SaaS procurement approval covers the platform. The AI capabilities within it are inherited by default.

The data exposure expansion problem is the specific security risk. Embedded AI features often require access to data beyond what the base SaaS functionality requires , AI features that are trained on or informed by data from across the enterprise's SaaS estate can expand the data exposure surface of the platform's AI backend. Salesforce Einstein trained on the enterprise's CRM data, HubSpot's AI processing engagement data from the full customer base, and Microsoft Copilot accessing documents across the Microsoft 365 estate each create data exposure to the respective platforms' AI backends that may exceed the data exposure of the base SaaS platform.

Why this matters

Third-party AI integrations matter for TPRM because the most consequential AI in an enterprise's stack is often embedded in standard SaaS platforms rather than deployed as standalone AI products. The AI that influences hiring decisions, scores sales leads, generates customer communications, and manages IT operations is the AI that the SaaS assessment most consistently misses.

Where most teams get this wrong

The most consistent failure is treating embedded AI features as features of an assessed SaaS platform rather than as AI systems requiring separate assessment. The SaaS assessment covers the platform. The embedded AI requires AI-specific governance.

• Embedded AI assessed as SaaS features not as AI systems
• Default AI enablement not reviewed before SaaS procurement
• AI inventory incomplete , embedded AI not included
• EU AI Act high-risk assessment not applied to embedded AI in regulated use cases
• Data exposure expansion from AI features not assessed

What good looks like

Mature third-party AI assessment programmes include an embedded AI discovery step in every SaaS procurement , identifying which AI features are included in the platform and whether any will be enabled by default , and apply AI-specific governance assessment to any AI feature that processes sensitive data or influences consequential decisions.

• Embedded AI discovery in SaaS procurement , what AI features exist and which are default-enabled
• AI-specific assessment for consequential AI features , training data, fairness, explainability, EU AI Act
• AI inventory including embedded AI , not just standalone AI systems
• Default AI feature review before SaaS activation
• Data exposure assessment for AI feature backends

Tooling

Salesforce Einstein AI , AI feature inventory and data access scope documentation

Salesforce provides documentation of Einstein AI's data access, training practices, and AI feature scope. For TPRM practitioners, requesting Einstein AI's model documentation alongside the standard Salesforce security review provides the AI-specific assessment that the SaaS review alone does not.

Microsoft Copilot , Microsoft Purview for data governance across Copilot scope

Microsoft Purview provides data governance controls for the Microsoft 365 data that Copilot accesses. For TPRM practitioners, assessing Copilot's data access scope against the enterprise's data classification policy provides a specific AI data exposure assessment.

Governance challenges

The governance challenge with third-party AI integrations is the sheer volume of embedded AI in the modern enterprise SaaS stack. Applying full AI governance review to every embedded feature in every SaaS platform is impractical. The governance resolution is risk-tiered assessment , full AI governance review for AI features that make or influence consequential decisions about individuals or that process highly sensitive data, abbreviated review for lower-risk features.

• Add embedded AI discovery to SaaS procurement checklist
• Conduct AI inventory including embedded SaaS AI
• Apply risk-tiered AI assessment , full review for consequential decision AI
• Review default AI feature enablement before SaaS activation
• Assess EU AI Act high-risk implications for HR, credit, and other regulated embedded AI

If you are a small team

Conduct a one-day embedded AI inventory across your five highest-risk SaaS platforms. For each platform, answer three questions: what AI features are included in your subscription, which are enabled by default, and which process sensitive data or influence decisions about employees or customers? That inventory will reveal the AI that has been deployed without AI-specific assessment. Prioritise assessment based on the sensitivity of data processed and the consequence of the decisions influenced.

• Inventory embedded AI features across top five SaaS platforms
• Identify which features are default-enabled
• Prioritise assessment by data sensitivity and decision consequence
• Apply AI-specific governance to high-priority embedded AI

What to require

Ask directly:

"Can you provide an inventory of all AI features included in your platform , specifically which are enabled by default, what data each feature accesses, and for any AI feature that influences decisions about individuals, what training data and fairness assessment documentation you can provide?"

Expect as evidence

• AI feature inventory with data access scope
• Default-enabled AI feature disclosure
• Training data documentation for consequential AI features
• Fairness assessment for AI features affecting individuals

A SaaS vendor who confirms security assessment should be asked for the AI feature inventory. The security assessment covers the platform. The AI feature inventory reveals what AI the platform contains and what data it processes.

How to evidence it

• Embedded AI inventory records
• AI-specific assessment for consequential embedded AI
• Default feature review records
• EU AI Act assessment for regulated embedded AI use cases

Key Takeaway

Eleven AI systems. Zero assessed as AI. Salesforce Einstein scoring leads. HubSpot AI generating emails. Workday AI ranking applicants. ServiceNow AIOps making incident prioritisation decisions. Microsoft Copilot across the productivity estate. All SaaS-assessed. None AI-assessed. The SaaS procurement covered the platform. The AI governance gap is the eleven systems within it. Embedded AI discovery is the first step. Risk-tiered AI assessment is the governance framework. The AI that influences the most consequential decisions is often embedded in the most routine SaaS platforms. Find it. Assess it. Govern it.

More on AI governance

• AI API Key Exposure
• AI Adversarial Attacks
• AI Attack Surface Expansion