Understanding the Regulatory Landscape
Klaus Löber's recent statement at Esma made it clear: adopting cloud and AI technologies doesn't lessen regulatory expectations for operational resilience. In fact, it raises them. Since that announcement, procurement and third-party risk teams have been grappling with a critical tension. Your organization seeks efficiency from cloud-based AI services, but Esma's supervisory committee chair has signaled increased scrutiny on these third-party relationships.
Teams are caught between the push to move faster and the need to prove control. Here's what they're asking and what you need to know.
Q1: Does Using a Cloud AI Vendor Complicate Compliance?
Yes, but not because the technology itself is flawed. Esma's stance is that outsourcing computational work doesn't outsource accountability. When you use cloud-based AI services, you're adding a critical dependency to your operations. This creates third-party risk, concentration risk, and potential cross-border data governance issues.
You still own the risk. What's changed is the attack surface. Your vendor due diligence must now cover model provenance, training data lineage, API reliability, incident response protocols, and exit rights. If your vendor's model drifts or their rate limiting changes without notice, that's your problem.
Start by mapping which business-critical processes depend on external AI services. If a vendor outage would halt decision-making, pricing, or customer-facing workflows, that's a material dependency requiring formal risk assessment under your operational resilience framework.
Q2: What Does "Heightened Scrutiny of Third-Party Risk" Mean?
Supervisors will expect documented evidence that you've assessed and mitigated vendor-specific risks before and after deployment. This means:
Pre-contract: Conduct vendor due diligence covering security posture, subprocessor arrangements, data residency, model governance practices, and financial stability. For AI vendors, request Model Cards, training data documentation, and evidence of bias testing.
Contract terms: Include the right to audit, SLA definitions with model performance metrics, notification requirements for model updates, and termination rights with data portability guarantees.
Ongoing monitoring: Conduct quarterly vendor risk reviews, incident tracking, performance drift monitoring, and annual reassessment of materiality. If your vendor provides a General-Purpose AI Model, ensure they meet transparency obligations under the EU AI Act.
Esma's approach emphasizes operational resilience testing. If you're in a regulated entity, be prepared to demonstrate that a vendor failure wouldn't lead to a compliance breach or service disruption.
Q3: How Do We Verify a Vendor's Compliance Claims?
Don't take their word for it. "Compliant" is vague. Compliant with what standard, as of when, and validated by whom?
Ask for specifics:
- ISO/IEC 42001 certification (AI Management System)
- SOC 2 Type II reports covering AI-specific controls
- Evidence of Data Protection Impact Assessments if processing personal data under GDPR
- For high-risk AI systems under the EU AI Act: conformity assessment documentation, Technical Documentation (Annex IV), and quality management system evidence
If they claim their model is "unbiased," request validation evidence: what bias metrics did they measure, on what demographic slices, using which datasets? If they can't provide this, it's a red flag.
Also verify subprocessor arrangements. Your vendor might be compliant, but if they're using a third-party embedding model or cloud infrastructure provider, you need to understand that dependency chain. Concentration risk often hides two layers deep.
Q4: How Do We Handle Vendors Updating Models Without Notice?
This is the kind of operational resilience gap Esma's concerned about. Model updates can change output distributions, introduce new failure modes, or alter performance on edge cases. If you're using that model for a regulated decision process, an unannounced update is a control failure.
Your contract should require advance notification of material model changes, including:
- Retraining on new data
- Architecture changes
- Fine-tuning or model recalibration
- Changes to instructions for use or model limitations and use restrictions
Define "material" explicitly. For example, any change that affects output distributions by more than a certain percentage, any change to the model's intended use case, or any change that could impact fairness metrics.
Post-deployment, implement your own monitoring. Log model inputs and outputs, track performance drift, and set alerts for anomalies. If you detect a distribution shift, that's your signal to ask the vendor what changed.
Q5: How Do We Prioritize Vendor Risks with a Small Team?
Use risk tiering. Not every vendor relationship carries the same regulatory or operational weight. Esma's focus is on operational resilience for critical functions, so start there.
Tier 1: Vendors whose failure would halt a business-critical or regulated process within 24 hours. These require full due diligence, continuous monitoring, and documented contingency plans.
Tier 2: Vendors supporting important but non-critical functions, or those with viable substitutes. Standard due diligence, annual reviews.
Tier 3: Low-impact vendors with commodity services. Lightweight assessment, monitor for concentration risk.
For AI vendors, consider:
- Is the model used in a high-risk AI system under the EU AI Act?
- Does the model process personal data?
- Is the output used in automated decision-making?
- Is there a viable alternative if the vendor exits the market?
If the answer to any of these is yes, that's a Tier 1 relationship. Document your tiering rationale; supervisors will want to see that you've applied a risk-based approach, not just vendor self-attestations.
Q6: What's the Priority This Quarter?
Inventory your AI vendor dependencies. You can't manage risks you haven't identified. Create a register that captures:
- Vendor name and service description
- Business process supported
- Data flows (what goes in, what comes out, where it's processed)
- Contract owner and renewal date
- Criticality tier
- Last risk assessment date
Once you have that inventory, identify gaps: which vendors haven't been assessed in the past 12 months? Which contracts lack audit rights or exit provisions? Which vendors can't produce Model Cards or validation evidence?
That gap list becomes your roadmap. Esma's message is clear: regulators won't accept "we didn't know" as an excuse for third-party risk failures. The expectation is that you know your dependencies, you've assessed the risks, and you can prove both.
Further Resources
For vendor due diligence frameworks, start with ISO/IEC 42001 Annex A controls A.7.5 (supplier relationships) and A.7.6 (supplier management). For operational resilience principles, review your jurisdiction's guidance on outsourcing and third-party risk (DORA in the EU, OCC guidance in the US).
If you're assessing AI-specific vendor risks, the NIST AI RMF Playbook includes a vendor risk management profile. For model-specific due diligence, SR 11-7 provides a solid validation framework that translates well to vendor model risk assessment.
The hard truth: Esma's stance isn't an outlier. It's the direction of travel. Third-party AI risk is becoming a board-level issue, and your procurement decisions today will determine your audit findings tomorrow.
