AI risk is climbing the ranks of operational risks, now sitting at fifth place for 2026. If your team still treats AI as just a subset of IT or model risk, you're missing a key integration point: your existing risk taxonomy. This template offers a structured AI Risk Assessment that fits seamlessly into your operational risk reporting, helping you evaluate AI systems in a way your risk committee already understands.
Purpose of the Template
This AI Risk Assessment Template connects AI-specific risks with your operational risk framework. It translates technical AI concerns into operational risk categories like cyber, third-party, compliance, and operational resilience, while maintaining the detail your model risk and governance teams need.
Use this template to:
- Assess AI systems within your operational risk taxonomy
- Document AI-specific risk factors your current tools might miss
- Create comparable risk scores across AI and non-AI operational risks
- Support risk tiering decisions for AI systems
- Prepare evidence for internal audit and regulatory inquiries
The template applies to both in-house and outsourced models, covering everything from rules-based systems to General-Purpose AI Model integrations.
Prerequisites
Before customizing this template, gather:
System documentation:
- Model Cards or System Cards for the AI system
- Technical Documentation (Annex IV) if subject to the EU AI Act
- Instructions for Use and model limitations
- Data lineage and feature store specifications
Risk baseline:
- Your organization's operational risk taxonomy (aligned to Basel II/III or similar)
- Existing risk appetite statements
- Current risk tiering methodology (e.g., NIST AI RMF Profiles)
Governance artifacts:
- AI Management System policies (ISO/IEC 42001 if implemented)
- Vendor due diligence records for Foundation Model Providers or other third parties
- Any prior AI System Impact Assessments (ISO/IEC 42005)
You don't need all of these to start. If you're assessing a new AI system, the template will highlight what's missing.
The Template
# AI RISK ASSESSMENT
**System Name:** [AI system identifier]
**Assessment Date:** [YYYY-MM-DD]
**Risk Owner:** [Name, title]
**Assessment Prepared By:** [Name, role]
---
## SECTION 1: SYSTEM PROFILE
**System Type:**
☐ Predictive model (supervised learning)
☐ [Generative AI](/glossary/generative-ai) application
☐ General-Purpose AI Model integration
☐ Rules-based AI system
☐ Reinforcement learning system
☐ Other: ___________
**Deployment Status:**
☐ Development
☐ Validation
☐ Production
☐ [Post-Market Monitoring](/glossary/post-market-monitoring)
**[Model Provisioning](/glossary/model-provisioning):**
☐ In-house developed
☐ Outsourced Models (vendor-provided)
☐ Fine-tuned foundation model
☐ API-based service ([Foundation Model Provider](/glossary/foundation-model-provider))
**Data Sensitivity:**
☐ [Personal data](/glossary/personal-data) (GDPR-regulated)
☐ Confidential business data
☐ Public data only
☐ Synthetic data
---
## SECTION 2: OPERATIONAL RISK MAPPING
Map AI-specific risks to your operational risk taxonomy. Rate each dimension: **Low / Medium / High / Critical**
### Cyber Risk Dimension
**[Adversarial Simulation](/glossary/adversarial-simulation) exposure:**
Rating: [ ]
Evidence: [Describe whether the system has been tested against adversarial inputs, prompt injection, model extraction, or data poisoning scenarios]
**[AI Supply Chain Compromise](/glossary/ai-supply-chain-compromise):**
Rating: [ ]
Evidence: [Document third-party model components, training data provenance, dependency vulnerabilities]
**[Rate Limiting](/glossary/rate-limiting) and access controls:**
Rating: [ ]
Evidence: [Describe Rate Limiting, authentication mechanisms, abuse prevention]
### Third-Party/Vendor Risk Dimension
**[Vendor Model Risk](/glossary/vendor-model-risk):**
Rating: [ ]
Evidence: [If using Outsourced Models, document vendor due diligence, SLA terms, model [validation evidence](/glossary/validation-evidence) from provider, exit strategy]
**Foundation Model Provider dependency:**
Rating: [ ]
Evidence: [For GPAI integrations: provider's compliance with [General-Purpose AI Code of Practice](/glossary/general-purpose-ai-code-of-practice), systemic risk disclosures, model version stability]
### Compliance Risk Dimension
**Regulatory classification:**
☐ [Prohibited AI Practices](/glossary/prohibited-ai-practices) exposure
☐ High-risk AI system ([EU AI Act](/glossary/eu-ai-act))
☐ [General-Purpose AI Model with Systemic Risk](/glossary/general-purpose-ai-model-with-systemic-risk)
☐ SR 11-7 in-scope model
☐ Other regulatory trigger: ___________
**[Disclosure of AI Interaction](/glossary/disclosure-of-ai-interaction):**
Rating: [ ]
Evidence: [Document whether users are informed they're interacting with AI, per [transparency](/glossary/transparency) obligations]
**[Human Rights Due Diligence](/glossary/human-rights-due-diligence):**
Rating: [ ]
Evidence: [Assess impact on protected groups, fairness testing, [bias mitigation](/glossary/bias-mitigation) controls]
### Operational Resilience Dimension
**[Automation Bias](/glossary/automation-bias) risk:**
Rating: [ ]
Evidence: [Evaluate human oversight mechanisms, override capabilities, decision review processes]
**[Model Recalibration](/glossary/model-recalibration) frequency:**
Rating: [ ]
Evidence: [Document retraining schedule, performance monitoring, drift detection thresholds]
**[Reproducibility](/glossary/reproducibility):**
Rating: [ ]
Evidence: [Assess whether model outputs can be reproduced given same inputs, version control rigor]
---
## SECTION 3: CONTEXTUAL RISK FACTORS
Beyond taxonomy mapping, document AI-specific Contextual Risk Factors:
**[Materiality](/glossary/materiality):**
[Describe business impact if this system fails, produces biased outputs, or becomes unavailable. Quantify where possible: revenue at risk, customer impact, regulatory exposure]
**[Model Limitations and Use Restrictions](/glossary/model-limitations-and-use-restrictions):**
[List known failure modes, out-of-scope use cases, environmental constraints, data quality dependencies]
**[Aggregation Bias](/glossary/aggregation-bias) potential:**
[Assess whether the system performs differently across demographic groups, geographic regions, or edge cases]
**[Annotation Quality](/glossary/annotation-quality):**
[For supervised learning: document labeling process, inter-rater reliability, label drift monitoring]
---
## SECTION 4: CONTROL ASSESSMENT
Evaluate existing controls against AI-specific risks:
**Validation Evidence:**
☐ Independent validation completed (SR 11-7 compliant if applicable)
☐ [Red Teaming](/glossary/red-teaming) conducted
☐ Bias Mitigation controls tested
☐ Performance benchmarks documented
☐ Not yet validated
**Monitoring Controls:**
☐ Post-Market Monitoring in place
☐ Drift detection automated
☐ [Root Cause Analysis](/glossary/root-cause-analysis) process for incidents
☐ [Stakeholder Engagement](/glossary/stakeholder-engagement) mechanism
☐ Monitoring gaps exist
**Documentation:**
☐ Model Card published
☐ [System Card](/glossary/system-card) available
☐ Technical Documentation (Annex IV) complete
☐ Instructions for Use provided to users
☐ Documentation incomplete
---
## SECTION 5: RISK RATING AND TREATMENT
**Overall AI Risk Rating:** [Low / Medium / High / Critical]
**Justification:**
[Synthesize findings from Sections 2-4. Explain why this rating reflects the system's operational risk profile]
**[Risk Treatment](/glossary/risk-treatment) Plan:**
| Risk | Planned Control | Owner | Target Date |
|------|----------------|-------|-------------|
| [Specific risk from assessment] | [Mitigation action] | [Name] | [Date] |
| | | | |
**Residual Risk:**
[After planned treatments, what risk remains? Is it within risk appetite?]
**Approval:**
Risk Owner: _________________ Date: _______
Risk Committee: _________________ Date: _______
---
## SECTION 6: REASSESSMENT TRIGGER
This assessment expires or requires update when:
☐ Model is retrained or recalibrated
☐ Deployment context changes (new use case, new user population)
☐ Regulatory classification changes
☐ Material incident occurs
☐ Annual review date: [Date]
How to Customize It
Align to your risk taxonomy:
Your operational risk framework likely uses different category names than "Cyber Risk Dimension." Replace Section 2 headings with your organization's risk categories (e.g., "Technology Risk," "Model Risk," "Strategic Risk"). Keep the AI-specific sub-items but nest them under your existing structure.
Adjust rating scales:
If your risk program uses 1-5 numerical scales or Red/Amber/Green ratings instead of Low/Medium/High/Critical, update Section 2 and Section 5 accordingly. Ensure your scale definitions account for AI-specific severity (a "Medium" cyber risk might be "High" if it involves adversarial manipulation of a credit model).
Add regulatory-specific sections:
If you're subject to SR 11-7, add a subsection under Section 4 for "Effective Challenge" and "Ongoing Monitoring" requirements. For EU AI Act high-risk systems, add fields for conformity assessment body details and CE marking status. For systems processing personal data, reference your Data Protection Impact Assessment and link it here.
Tailor Section 3 to system type:
Generative AI systems need deeper coverage of AI-Generated Content Labelling and Responsible Disclosure policies. Predictive models need stronger emphasis on Feature Store integrity and training data representativeness. Adjust the prompts in Section 3 to match your system portfolio.
Integrate with existing tools:
If you use GRC software, map these template fields to your tool's data model. The "Risk Rating and Treatment" section should feed directly into your operational risk register. The "Reassessment Trigger" should create calendar reminders or workflow tasks in your system.
Validation Steps
Before submitting this assessment to your risk committee:
Cross-check with technical teams:
Share Section 1 and Section 3 with the data science or engineering team that built or integrated the AI system. Confirm you've accurately described model type, limitations, and monitoring controls. If they flag inaccuracies, your assessment loses credibility.
Verify regulatory classification:
If you've marked the system as high-risk under the EU AI Act or in-scope for SR 11-7, confirm this determination with legal or compliance. Misclassification creates audit findings.
Test control claims:
If Section 4 says "Red Teaming conducted," ask for the test report. If it says "Drift detection automated," verify the monitoring dashboard exists and produces alerts. Controls marked as complete must have Validation Evidence.
Compare to peer assessments:
Pull up two other AI Risk Assessments your team has completed. Do the risk ratings make sense relative to each other? If this system has higher cyber risk exposure but a lower overall rating than a simpler model, explain why in Section 5's justification.
Run the residual risk question:
After applying the planned treatments in Section 5, would you personally approve deploying this system? If not, your residual risk statement is too optimistic. Revise the risk rating or add more controls.
This template won't eliminate AI operational risk, but it will make that risk visible in the language your risk committee speaks. With AI risk now a top concern, integrating it into existing frameworks will help your organization move faster than those building parallel governance structures.
