As AI regulations multiply across jurisdictions, you're managing models against fundamentally different rule sets. The EU AI Act classifies by use case and systemic risk. NIST AI RMF 1.0 asks for risk tiering and context mapping. SR 11-7 still demands quantitative validation evidence. You need a framework that works across all three.
This guide provides a reference structure to map your validation and governance processes against diverging regulatory requirements without rebuilding your entire model risk management program.
Scope - What This Guide Covers
This guide addresses the challenge of maintaining model validation, documentation, and monitoring practices when your models operate under multiple regulatory regimes simultaneously. It applies to:
- Financial services institutions subject to SR 11-7 deploying AI systems that fall under the EU AI Act
- Organizations implementing ISO/IEC 42001 while preparing for jurisdiction-specific AI regulations
- Model risk teams managing vendor models where provider compliance doesn't match your deployment jurisdiction
- Teams validating General-Purpose AI Models where systemic risk obligations differ by region
This guide does not provide legal interpretations of specific regulations. It maps technical and operational requirements you'll encounter across frameworks.
Key Concepts and Definitions
Regulatory Divergence: When similar AI systems face different validation, documentation, transparency, or monitoring requirements based on jurisdiction or regulatory scope.
Validation Evidence: Documentation proving model performance, limitations, and risk controls meet regulatory expectations. SR 11-7 expects quantitative performance metrics and sensitivity analysis. The EU AI Act's Technical Documentation (Annex IV) requires risk management system descriptions and human oversight measures. ISO/IEC 42001 requires evidence that controls from Annex A operate effectively.
Risk Tiering vs. Risk Classification: NIST AI RMF uses risk tiering to categorize AI systems by potential impact, informing the rigor of your Measure and Manage activities. The EU AI Act uses risk classification (prohibited, high-risk, limited risk, minimal risk) to trigger legal obligations. Your model may be "high-risk" under one framework and "tier 2" under another, requiring different validation depths.
Cross-Border Model Deployment: Operating the same model in multiple jurisdictions where each location imposes distinct requirements on validation frequency, documentation format, or Post-Market Monitoring scope.
Requirements Breakdown
Documentation Requirements
EU AI Act (High-Risk Systems)
- Technical Documentation (Annex IV): System description, training data characteristics, Model Limitations and Use Restrictions, human oversight capabilities
- Instructions for Use delivered to deployers
- Post-Market Monitoring plan and incident reporting procedures
- Conformity assessment evidence
SR 11-7
- Model development documentation: theoretical basis, data sources, assumptions
- Validation Evidence: benchmarking, outcomes analysis, sensitivity testing
- Ongoing monitoring reports with performance metrics
- Model approval and exception documentation
ISO/IEC 42001
- AI policy and objectives (Clause 5.2)
- Risk assessment outputs per ISO/IEC 23894
- Evidence that Annex A Controls operate (e.g., A.6.1.2 Inventory, A.7.2 Data quality)
- Internal audit records demonstrating Plan-Do-Check-Act (PDCA)
Validation Depth
The EU AI Act doesn't prescribe validation methodologies but requires demonstrating accuracy, robustness, and cybersecurity "appropriate to the intended purpose." SR 11-7 demands quantitative validation by qualified independent parties. ISO/IEC 42001 requires validation processes exist and produce evidence, but doesn't mandate specific statistical thresholds.
Practical implication: Your validation report needs modular sections. Keep quantitative performance analysis (for SR 11-7) separate from use restriction documentation (for EU AI Act Instructions for Use) separate from control effectiveness evidence (for ISO/IEC 42001 audit).
Monitoring Obligations
EU AI Act: Post-Market Monitoring for high-risk systems, including systematic collection of deployment data and serious incident reporting within 15 days.
SR 11-7: Ongoing monitoring with performance metrics compared to validation benchmarks, triggering revalidation when material changes occur.
ISO/IEC 42001: Continuous improvement via PDCA, with monitoring tied to objectives and Annex A control effectiveness.
These aren't the same activity. Post-Market Monitoring focuses on real-world safety and performance. SR 11-7 monitoring detects model degradation against approval baselines. ISO/IEC 42001 monitoring feeds management review and corrective action.
Implementation Guidance
Build a Jurisdiction-Aware Model Inventory
Extend your existing inventory (required by ISO/IEC 42001 A.6.1.2 and implied by SR 11-7) with regulatory scope fields:
- Deployment jurisdictions (EU member states, US states, other)
- EU AI Act risk classification (prohibited, high-risk, limited, minimal)
- NIST AI RMF risk tier (if applicable)
- SR 11-7 materiality determination
- Applicable standards (ISO/IEC 42001, sector-specific)
This single inventory becomes your compliance planning tool. When the EU AI Act triggers Technical Documentation requirements for a high-risk system, you know which models need Annex IV packages. When SR 11-7 applies, you know which models need quantitative validation.
Create Modular Validation Templates
Don't write separate validation reports for each framework. Structure validation evidence in modules:
- Model description and intended use (maps to all frameworks)
- Quantitative performance analysis (SR 11-7, feeds into EU AI Act accuracy claims)
- Limitation and use restriction analysis (EU AI Act Instructions for Use, ISO/IEC 42001 A.7.1)
- Data quality and representativeness (SR 11-7, EU AI Act Annex IV, ISO/IEC 42001 A.7.2)
- Robustness and Adversarial Simulation (EU AI Act, NIST AI RMF Measure function)
- Human oversight evaluation (EU AI Act high-risk requirement, ISO/IEC 42001 A.6.2.6)
Each module addresses specific regulatory requirements. You assemble the modules your jurisdiction demands without rewriting core analysis.
Map Monitoring Activities to Multiple Obligations
Consider a production model subject to both SR 11-7 and the EU AI Act. Your monitoring process should:
- Track performance metrics against validation benchmarks (SR 11-7)
- Collect deployment context data and user feedback (EU AI Act Post-Market Monitoring)
- Log serious incidents and near-misses (EU AI Act 15-day reporting, SR 11-7 escalation)
- Feed control effectiveness reviews (ISO/IEC 42001 Clause 9.1)
Use a single monitoring dashboard with views filtered by regulatory purpose. The same drift detection alert triggers SR 11-7 revalidation assessment and EU AI Act Post-Market Monitoring documentation.
Prepare for Vendor Model Gaps
When you deploy Outsourced Models, the Foundation Model Provider's compliance doesn't automatically satisfy your obligations. The provider may comply with the General-Purpose AI Code of Practice (if they're EU-based) but you still need SR 11-7 validation evidence for your use case.
Establish vendor due diligence requirements that map to your jurisdiction mix:
- Request Model Cards or System Cards (transparency baseline)
- Require access to validation evidence or accept third-party validation reports
- Clarify Post-Market Monitoring responsibilities (who detects issues, who reports)
- Define Model Recalibration triggers and responsibilities
Common Pitfalls
Assuming ISO/IEC 42001 certification satisfies EU AI Act conformity: ISO/IEC 42001 is a management system standard. The EU AI Act is product regulation. Certification proves you have governance processes; conformity proves a specific AI system meets safety and transparency requirements. You need both.
Treating all models identically: Regulatory divergence means identical models face different requirements based on deployment location and use case. Your credit scoring model is high-risk under the EU AI Act (Annex III use case) but may not trigger the same validation depth as a similarly performing fraud detection model under SR 11-7 materiality thresholds.
Ignoring transitional timelines: The EU AI Act's high-risk provisions take effect 24 months after entry into force, but General-Purpose AI Model obligations start at 12 months. Your roadmap needs staggered compliance dates.
Over-relying on vendor assurances: A Foundation Model Provider's claim of "EU AI Act compliance" may mean they've met General-Purpose AI transparency obligations. It doesn't mean your fine-tuned deployment automatically satisfies high-risk system requirements.
Skipping root cause analysis across frameworks: When a model fails, different frameworks ask different questions. SR 11-7 wants to know if validation missed the failure mode. The EU AI Act wants to know if Instructions for Use were inadequate. ISO/IEC 42001 wants to know if controls failed. Conduct Root Cause Analysis that answers all three.
Quick Reference Table
| Requirement Area | SR 11-7 | EU AI Act (High-Risk) | ISO/IEC 42001 |
|---|---|---|---|
| Validation depth | Quantitative, independent, benchmarked | Appropriate to intended purpose; accuracy, robustness, cybersecurity demonstrated | Process exists; produces evidence |
| Documentation format | Development + validation + monitoring reports | Technical Documentation (Annex IV) + Instructions for Use | Policy, procedures, records per Annex A |
| Monitoring frequency | Ongoing; metrics vs. benchmarks | Post-Market Monitoring; systematic data collection | Per Plan-Do-Check-Act (PDCA) and management review |
| Incident reporting | Internal escalation per policy | Serious incidents to authorities within 15 days | Nonconformity and corrective action (Clause 10.1) |
| Vendor model obligations | Validation responsibility remains with user | Deployer obligations distinct from provider obligations | Vendor Due Diligence (A.5.1) |
| Revalidation triggers | Material change, performance degradation | Substantial modification | Control changes, objective changes |
| Human oversight | Implied in approval process | Explicit requirement for high-risk systems | Control A.6.2.6 (Human Oversight) |
Bookmark this table. When you're scoping a new model's validation plan, check each column to identify which requirements apply to your deployment context. Regulatory divergence isn't going away, but you can manage it systematically.
