3 AI Vendor Risks Your SOC 2 Report Will Never Catch

Your AI vendors passed their SOC 2 audit. Their security posture looks clean. Access controls, encryption, incident response: all checked.

But none of that tells you whether their AI is safe to deploy in a regulated environment. As Schellman noted in their analysis of SOC 2 and AI, SOC 2 "is not intended to be a comprehensive AI risk management framework." The trust services criteria were designed for data security — not model governance, bias testing, or training data provenance.

Here are three risks sitting inside your vendor stack right now that no security attestation will surface. Regulators will absolutely ask about after August 2026.

1. Your vendor retrained their model. Nobody told you.

AI models aren't static. Your credit underwriting vendor, your fraud detection engine, your KYC provider retrain thei models regularly. New training data goes in, new decision logic comes out.

When that happens, the bias profile of the model can shift. The accuracy can degrade. The explainability documentation you reviewed six months ago is now outdated.

Under the EU AI Act, deployers of high-risk AI systems are responsible for monitoring ongoing performance and ensuring conformity. If your vendor ships a retrained model and you don't know about it, you've lost control of a system that's making decisions about your customers. Credit decisioning systems fall squarely under Annex III high-risk classification.

SOC 2 doesn't require vendors to notify you when models change. Most don't.

2. Your vendor's training data includes PII you haven't accounted for.

Your fraud detection vendor analyzes transaction patterns. Your underwriting engine processes income, employment, and credit data. Your onboarding tool verifies identity documents.

All of that involves personal data. But have you asked: what data did they use to train the model? Was it customer data from other clients? Was it synthetic? Was it scraped? Does it include protected characteristics?

Under the EU AI Act, high-risk AI systems require documented data governance — including training, validation, and testing datasets. If your vendor trained a model on data you can't account for, and that model is making creditworthiness assessments about EU consumers, you have a compliance gap you can't close with a security questionnaire.

A SOC 2 report confirms data is encrypted in transit. It says nothing about what data was used to build the model in the first place.

3. Your vendor quietly shipped an AI feature you never approved.

This is the one that catches teams off guard. You onboarded a CRM vendor for contact management. Six months later, they release AI-powered lead scoring. Your support tool adds auto-generated responses. Your document management platform starts extracting data with machine learning.

None of these features went through your AI governance process because you didn't know they existed. No risk classification. No DPIA. No regulatory mapping. But they're running in your environment, processing your customer data, and potentially making or influencing decisions.

The EU AI Act doesn't care whether you intended to deploy AI. Under Article 3, if it's running in your environment and affecting EU consumers, you're the deployer. You're accountable.

SOC 2 audits the security of the platform as a whole. They don't inventory individual AI features or assess whether each one meets your regulatory obligations.

The gap is governance, not security

These three risks have something in common: they're invisible to security-focused tools and processes. SOC 2, ISO 27001, penetration testing. None of it was designed to evaluate AI-specific risks like model governance, training data provenance, bias testing, or feature-level change management.

Regulated fintechs need a different lens for AI vendors. One that asks the questions auditors haven't started asking yet but will, starting August 2026.

SOC 2 vs. AI Vendor Governance

A vendor can pass SOC 2 cleanly and still ship an AI feature into your environment that nobody on your team reviewed.

AI Vendor Risk Assessment Checklist

Use this as a companion to your existing SOC 2 and security review process, since it covers ground SOC 2 wasn't built to cover.

Before onboarding:

• Does the vendor use AI or ML anywhere in the product, including features not part of the original sales conversation?

• What data trained the model, and can the vendor document its provenance?

• Does the contract include a right to be notified of model changes or new AI feature releases?

• Does the vendor provide bias testing or explainability documentation for AI-driven decisions?

During the relationship:

• Has the vendor retrained or materially updated the model since onboarding?

• Has the vendor shipped a new AI feature since the last review, enabled by default or otherwise?

• Is there a defined cadence for re-reviewing vendor AI, or does the original onboarding review stand indefinitely?

• Who internally owns tracking vendor AI changes, and how would they find out about one?

Questions to send vendors directly:

• What AI or ML capabilities does your product currently include?

• What data was used to train any models involved in decisions about our customers?

• How will we be notified if you retrain a model or add a new AI-powered feature?

• Can you provide documentation supporting bias testing for any AI-driven decisioning?

For a deeper look at what the EU AI Act requires from financial institutions and what you should be doing now, read our full guide: EU AI Act Compliance: What Financial Institutions Need to Know Before August 2026.

LucidTrust is the AI governance platform built for regulated financial institutions. We help compliance teams manage AI vendor risk, classify high-risk systems, and stay audit-ready across every jurisdiction. Request a demo →