AAISM · Topic 8
AI Risk Assessment
Domain: AI Risk Management, about 31% of the exam
The assessment cycle
- Scope the system
- Build scenarios
- Analyze
- Evaluate
- Treat
- Accept residual
- Monitor
- Scope
- model, data, users, decisions affected
- Scenario
- actor, action, asset, consequence
- Analysis
- likelihood and impact, evidence based
- Evaluation
- compare against appetite and criteria
- Treatment
- avoid, mitigate, transfer, accept
- Monitoring
- KRIs, drift, incident feedback
Assess the AI system in its deployed context; the same model carries different risk in a chatbot and in a loan decision
What makes AI risk different
- Behavior is learned, not fully specified
- Performance decays as data shifts
- Failures can be silent and confident
- Training data carries historical bias
- Explanations approximate, they do not prove
- Emergent behavior appears with scale
- Third-party models are opaque dependencies
Traditional IT risk asks whether the system works as specified; AI risk asks whether the specification was ever complete
Building risk scenarios
- Threat actor
- insider, competitor, researcher, opportunist
- Attack surface
- prompt, training data, API, weights
- Failure mode
- wrong output, refusal, leak, drift
- Affected party
- user, subject, business, public
- Consequence
- safety, financial, legal, reputational
- Non-adversarial risk
- harm with no attacker present
Threat modeling for ML
Method
- Diagram the pipeline end to end
- Trust boundaries at every data intake
- STRIDE per component, ML aware
- MITRE ATLAS for adversary tactics
- NIST AI 100-2 taxonomy for attack classes
Asset view
- Training data and labels
- Weights, checkpoints, embeddings
- Prompts, system prompt, guardrails
- Inference endpoint and API keys
- Feedback and telemetry stores
Attack classes
- Evasion at inference time
- Poisoning and backdoors at training
- Privacy: inversion, membership inference
- Extraction of weights or behavior
- Abuse and misuse of intended capability
Likelihood without history
- Few loss events, so no base rate
- Structured expert elicitation, not a guess
- Red team results as empirical evidence
- Attack feasibility: skill, access, cost
- Public incident databases as analogues
- Early telemetry replaces estimates over time
- Record the basis, not only the score
State the evidence behind every likelihood rating so a reviewer can challenge the number rather than the feeling
Impact dimensions
- Safety
- physical or psychological harm
- Rights
- discrimination, privacy, due process
- Financial
- loss, fines, remediation cost
- Operational
- outage, manual fallback, rework
- Legal
- regulatory action, litigation
- Reputational
- trust, coverage, customer loss
- Scale
- how many people, how reversible
Rate harm to people separately from harm to the business, or the individual impact disappears inside the financial score
Inherent, residual, appetite
- Inherent
- before controls are credited
- Residual
- after controls, evidenced not assumed
- Appetite
- target level the board wants
- Tolerance
- variation allowed around appetite
- Capacity
- most the organization could absorb
- Control credit
- only for controls proven effective
A shrinking gap between inherent and residual can mean controls are weakening, not improving
The AI risk register
- One entry per scenario, not per model
- Named risk owner in the business
- Inherent and residual ratings with dates
- Controls linked, with effectiveness evidence
- Treatment plan, owner, due date
- Linked KRIs and their thresholds
- Review trigger and next review date
Key risk indicators
- Drift
- distribution distance beyond threshold
- Accuracy decay
- live performance against baseline
- Guardrail hits
- blocked prompts trending up
- Override rate
- humans reversing model decisions
- Appeal volume
- subjects contesting outcomes
- Group disparity
- outcome gap across cohorts
- Leading versus lagging
- warns early versus counts damage
Third-party and model risk
- Assess the vendor and the model separately
- Ask for evaluations, model cards, red team results
- Pin a version, changes reset your assurance
- Fine-tuning moves risk back to you
- Contract terms on notice and evaluation access
- Exit plan before dependency deepens
- Inherited risk still needs a local owner
Reporting and acceptance
To the board
- Business consequence first, model detail last
- Trend against appetite, not raw counts
- Decisions requested, clearly stated
- Aggregate scenarios that share a cause
Acceptance record
- Approver with authority to accept
- Risk described in business terms
- Rationale and compensating controls
- Conditions and expiry date
- Re-approval when the system changes
Triggers to re-assess
- Model or prompt version change
- New use case or population
- Regulatory change in scope
- Incident or near miss
- Drift or KRI breach
Rapid recall: which instrument
- Personal data processed
- data protection impact assessment
- Rights at stake
- fundamental rights assessment
- Placing on the EU market
- conformity assessment
- Enterprise risk view
- risk register entry
- Design-stage threats
- threat model
- Live exposure
- KRI dashboard
- Supplier assurance
- third-party assessment
Reference strip: frameworks, taxonomy, method, indicators
Frameworks
- NIST AI RMF: govern, map, measure, manage
- ISO/IEC 23894 AI risk guidance
- ISO/IEC 42001 management system
- ISO 31000 for the underlying process
- EU AI Act risk tiers drive obligations
Attack taxonomy
- NIST AI 100-2 adversarial ML
- MITRE ATLAS tactics and techniques
- OWASP Top 10 for LLM applications
- Evasion, poisoning, privacy, abuse
Analysis method
- Qualitative matrix for most scenarios
- Quantitative where loss data exists
- Expert elicitation, documented basis
- Red team findings as evidence
- Scenario aggregation by shared cause
Register fields
- Scenario, owner, inherent, residual
- Controls and effectiveness evidence
- Treatment, due date, status
- KRI, threshold, current value
- Review trigger and date
Words to keep straight
- Appetite, tolerance, capacity
- Inherent versus residual
- Leading versus lagging indicator
- Hazard, threat, vulnerability, harm
Quick exam traps
- Trap: One risk register entry per model is enough
- Trap: Residual risk can be lowered by assuming a control works
- Trap: Accuracy on a held-out test set measures deployment risk
- Trap: A vendor's model card removes the need for local assessment
- Trap: Likelihood cannot be rated without historical loss data
- Trap: The AI team owns and accepts the risk
- Trap: A DPIA satisfies the fundamental rights assessment
- Trap: Assessment is complete once the system goes live
cybercertprep.com · original revision sheet written from the public body of knowledge