RAI — GARP Risk and AI Certificate Scenario Practice Guide

How to approach RAI scenario questions

The GARP Risk and AI Certificate, exam code RAI, tests whether you can apply AI risk concepts in realistic financial-services settings. Scenario questions may describe a model, dataset, business objective, governance process, control gap, validation issue, or incident. Your task is not just to recognize a familiar term. Your task is to decide what the scenario is asking you to do and select the answer that best fits the full fact pattern.

Use this guide to build a repeatable reading process for RAI-style scenarios. The goal is to slow down enough to identify the decision point, separate relevant facts from background detail, and choose the most defensible action based on AI risk management principles.

This is independent exam-preparation guidance and is not affiliated with or endorsed by GARP.

Start with the business and risk context

Before evaluating answer choices, establish the setting. AI risk questions often become easier once you know what the AI system is being used for and what could go wrong.

Ask:

• What is the AI system or model doing?
• Who relies on the output?
• What decision could the output influence?
• Is the use case high impact, customer-facing, regulatory-sensitive, operationally critical, or advisory?
• Is the scenario about development, deployment, monitoring, validation, governance, compliance, or remediation?

For finance scenarios, the same technical issue can have different risk implications depending on the use case. A model used for internal research support may raise different concerns from a model used in credit decisions, fraud alerts, trading surveillance, customer communications, capital planning, or risk reporting.

Identify the AI lifecycle stage

Many scenarios contain clues about where the issue sits in the AI lifecycle. Labeling the stage helps you avoid choosing a response that is premature or too late.

Common stages include:

• Use-case intake and approval: Is the organization deciding whether the AI use case should proceed?
• Data sourcing and preparation: Are the facts about data quality, consent, representativeness, lineage, or provenance?
• Model development: Is the question about feature selection, training, model design, explainability, or performance?
• Independent review or validation: Is the scenario asking whether the model should be challenged before deployment?
• Deployment and change management: Is the concern about production controls, approvals, user training, access, or release governance?
• Ongoing monitoring: Are the clues about drift, performance degradation, unexpected outputs, or changing market conditions?
• Incident response and remediation: Has harm, noncompliance, or a material control failure already occurred?

A strong answer usually matches the lifecycle stage. For example, if the scenario says the model is already in production and performance has degraded, the best answer is unlikely to be limited to initial model documentation. You would look for monitoring, escalation, remediation, and governance actions.

Find the actual decision point

Scenario questions often include several facts, but only one central decision. Train yourself to summarize the question in one sentence before reading the answer choices.

Examples:

• “What should the risk team do before approving this AI use case?”
• “Which control best addresses the identified data-quality weakness?”
• “What is the most appropriate governance response after model drift is detected?”
• “Which evidence would best support explainability and accountability?”
• “What is the best next step before using a third-party AI tool in a regulated process?”

The words best, most appropriate, first, primary, and next matter. They tell you whether the answer should be the strongest overall control, the first action in a sequence, the main risk implication, or the most direct remediation.

Translate the question into an action type

Most RAI scenarios ask for one of these action types:

• Assess: Identify risks, classify the use case, evaluate materiality, or review impact.
• Control: Add safeguards, access limits, human review, testing, documentation, or monitoring.
• Validate: Challenge model assumptions, performance, robustness, explainability, bias, or data integrity.
• Govern: Escalate, obtain approval, assign ownership, apply policy, or document accountability.
• Monitor: Track drift, performance, outcomes, exceptions, and changes in data or environment.
• Remediate: Pause, rollback, correct, notify appropriate stakeholders, or strengthen controls after an issue.
• Document and disclose: Maintain evidence, audit trails, limitations, approvals, and user-facing transparency where applicable.

If the question is asking for governance, a purely technical answer may be incomplete. If it is asking for validation, a broad policy statement may not directly address the decision point.

Identify the role and accountability

AI risk scenarios often include multiple parties: model developers, validators, business owners, compliance, internal audit, legal, operations, vendors, data owners, and senior governance committees. The best answer often depends on who has the responsibility to act.

Ask:

• Who owns the business process?
• Who developed the model or selected the AI tool?
• Who independently reviews or validates it?
• Who approves deployment or material changes?
• Who monitors performance after implementation?
• Who must escalate issues or document exceptions?
• Is a third party involved, and has the firm retained accountability for the risk?

In financial institutions, accountability usually cannot be outsourced simply because a vendor or external AI service is used. A scenario involving a third-party AI model may point to vendor due diligence, contractual controls, explainability limitations, data protection, ongoing monitoring, and internal governance.

Watch for independence clues

If the scenario says a model was built by the same team that approved it, or that validation was skipped because the model is “vendor-provided,” independence may be central. The strongest answer may require independent challenge, not just developer testing.

Look for facts such as:

• “The business unit wants to deploy quickly.”
• “The vendor will not provide details about training data.”
• “The development team performed its own review.”
• “No independent validation has been completed.”
• “The model output will be used in a material decision process.”

These clues generally point toward governance, validation, and approval discipline.

Separate relevant facts from background detail

Scenario questions may include extra information about technology, business goals, market conditions, or model type. Some details are useful; others are context only. Do not treat every technical term as equally important.

Facts that usually matter

Pay close attention to facts about:

• Purpose: What decision or process the AI supports.
• Materiality: Whether errors could affect customers, markets, regulatory reporting, capital, liquidity, credit, fraud, operations, or reputation.
• Data: Source, quality, representativeness, lineage, privacy, missing values, labeling, bias, or drift.
• Model behavior: Accuracy, robustness, stability, explainability, hallucination risk, false positives, false negatives, or performance gaps.
• Controls: Human review, access limits, approval gates, change management, monitoring, logging, and incident response.
• Governance: Ownership, policy alignment, documentation, validation, escalation, and oversight.
• Third-party dependency: Vendor transparency, service limits, contractual protections, concentration risk, and monitoring.
• User impact: Fairness, transparency, adverse outcomes, suitability of use, and ability to challenge or override outputs.

Facts that may be distractors

Some details may be interesting but not decisive:

• The model has a sophisticated architecture, but the question is about data lineage.
• The AI tool improves efficiency, but the scenario asks about approval before deployment.
• A vendor is well known, but the firm still needs due diligence and oversight.
• The model has high average accuracy, but performance is poor for a relevant subgroup or condition.
• A human is “in the loop,” but the human lacks training, authority, or meaningful ability to challenge the output.

The key is not to ignore background facts. It is to decide which facts directly affect the decision being asked.

Use a structured RAI decision sequence

When a scenario feels dense, move through a consistent sequence. This prevents you from jumping to the first familiar answer.

1. Define the use case

State the AI use case in plain language:

• “This model ranks fraud alerts.”
• “This tool summarizes customer communications.”
• “This model predicts credit risk.”
• “This system supports trading surveillance.”
• “This generative AI tool drafts internal risk reports.”

Then ask whether the use case affects customers, regulated activity, financial risk, controls, or management decisions.

2. Identify the primary risk

Classify the main risk theme:

• Model risk
• Data risk
• Operational risk
• Compliance risk
• Conduct or fairness risk
• Cybersecurity or privacy risk
• Third-party risk
• Reputational risk
• Strategic risk
• Governance and accountability risk

Many scenarios contain multiple risks. The best answer usually addresses the risk that is most directly connected to the question stem.

3. Determine whether the issue is preventive, detective, or corrective

This helps you choose between similar answers.

• Preventive: Approval, risk assessment, policies, access controls, data checks, validation before deployment.
• Detective: Monitoring, exception reports, drift detection, performance dashboards, audit logs.
• Corrective: Remediation plans, model recalibration, rollback, escalation, incident response, customer-impact review.

For example, if the scenario asks what should have been done before deployment, a monitoring answer may be useful but not the best preventive answer. If the model is already producing unexpected outputs, a pre-deployment checklist alone is too late.

4. Match the answer to the control objective

AI risk management is not about adding any control. It is about adding the right control for the risk.

Examples:

• Weak data lineage: improve documentation of data sources, ownership, transformations, and quality controls.
• Model drift: establish monitoring thresholds, escalation procedures, review, and recalibration or redevelopment as appropriate.
• Lack of explainability: use interpretable methods, explanation tools, documentation, and user guidance appropriate to the use case.
• Third-party opacity: perform due diligence, assess limitations, require sufficient information, and monitor vendor performance.
• Bias or unequal outcomes: evaluate performance across relevant populations, investigate causes, document findings, and implement mitigation.
• Unapproved production changes: apply change management, approval, testing, version control, and rollback procedures.

5. Choose the defensible action, not the most dramatic action

The strongest answer is usually the one that is proportionate, governed, and tied to the facts. It may not be the answer that sounds the most severe.

Consider whether the answer:

• Directly addresses the stated risk.
• Fits the lifecycle stage.
• Preserves accountability.
• Produces evidence for oversight.
• Is practical and proportionate.
• Avoids relying on unsupported assumptions.
• Does not ignore customer, regulatory, or operational impact.

Read finance and AI scenarios through a risk lens

RAI candidates should expect scenarios that blend AI concepts with financial-risk judgment. When reading, connect the AI issue to the financial context.

Credit, lending, and customer decisioning

If a scenario involves customer eligibility, credit scoring, pricing, collections, or other customer-impacting decisions, look for clues about:

• Data representativeness and bias.
• Explainability and ability to justify outcomes.
• Governance and approval before use.
• Monitoring for performance and outcome disparities.
• Documentation of assumptions, limitations, and decision logic.
• Human review that is meaningful, not symbolic.

The best answer often balances model performance with fairness, transparency, documentation, and oversight.

Markets, trading, and surveillance

For trading, market-risk, or surveillance scenarios, focus on:

• Model stability under changing market conditions.
• Backtesting, stress testing, and scenario analysis where relevant.
• Controls over automated decisions or alerts.
• False positives and false negatives.
• Escalation procedures for unusual behavior.
• Change management for model updates.
• Monitoring for drift and emerging risks.

Do not assume a high-performing model is acceptable if it fails under stress or lacks appropriate oversight.

Risk reporting, capital, and management information

For internal risk reporting or management dashboards, key issues include:

• Data lineage and reconciliation.
• Model assumptions and limitations.
• Explainability for senior decision-makers.
• Audit trails and reproducibility.
• Governance over changes to metrics.
• Monitoring for stale, incomplete, or misleading outputs.

If leaders rely on AI-generated outputs for risk decisions, the organization needs confidence in the source, process, and limitations of those outputs.

Fraud, AML, and operational controls

For fraud detection, AML support, cybersecurity, or operational-risk models, read for:

• Alert quality and operational capacity.
• False positive and false negative tradeoffs.
• Human review procedures.
• Data timeliness and completeness.
• Model monitoring and tuning.
• Governance over thresholds.
• Documentation of investigation outcomes.

A model that produces many alerts may still be ineffective if alerts are not actionable, reviewed, documented, or escalated properly.

Generative AI and large language model use cases

Generative AI scenarios may emphasize a different set of risk clues:

• Hallucination or unsupported output.
• Prompt and output controls.
• Confidential information exposure.
• User overreliance.
• Lack of source traceability.
• Inconsistent responses.
• Inadequate review before external use.
• Third-party platform and data-handling risk.

For generative AI, the best answer often involves defined use cases, user guidance, human review, restrictions on sensitive data, logging, monitoring, and escalation for inappropriate outputs.

Interpret common scenario signals

Use scenario language as evidence. Small phrases often tell you which risk principle is being tested.

“The model has high overall accuracy”

High average performance is not the end of the analysis. Ask:

• Does performance hold across relevant segments?
• Is the model stable over time?
• Are false positives and false negatives acceptable for the use case?
• Was performance measured on appropriate data?
• Does the model remain explainable enough for its intended purpose?

An answer that relies only on overall accuracy may miss the broader risk issue.

“The model is complex and difficult to explain”

Complexity is not automatically unacceptable. The question is whether the complexity is appropriate and controlled.

Look for:

• Use-case materiality.
• Need for explainability by users, customers, validators, or oversight functions.
• Availability of explanation techniques.
• Documentation of limitations.
• Evidence that users understand how to interpret outputs.

The best answer may not be “use only simple models.” It may be to ensure the model’s complexity is justified, explainability is sufficient for the use case, and controls are in place.

“A human reviews the output”

Human review only reduces risk if it is meaningful.

Ask:

• Does the reviewer have training?
• Does the reviewer understand model limitations?
• Can the reviewer override the output?
• Are overrides documented?
• Is reviewer behavior monitored?
• Is the review timely enough to affect the decision?

If the scenario suggests rubber-stamp review, the answer should strengthen governance, training, authority, or monitoring.

“The vendor says the model is proprietary”

Vendor confidentiality does not eliminate the firm’s risk responsibility. A strong answer may involve:

• Vendor due diligence.
• Sufficient transparency for intended use.
• Contractual obligations.
• Service-level expectations.
• Data-handling review.
• Ongoing performance monitoring.
• Contingency planning.
• Internal approval based on documented limitations.

If the firm cannot obtain enough information to assess risk, the best answer may limit, delay, or condition deployment.

“The model was approved last year”

Prior approval does not guarantee current suitability. Ask what has changed:

• Data distribution.
• Market environment.
• Customer behavior.
• Product design.
• Regulation or policy expectations.
• Model inputs or thresholds.
• Vendor service or model version.
• Actual outcomes.

If there has been material change, the scenario may call for revalidation, change review, or enhanced monitoring.

Evaluate answer choices systematically

After reading the scenario, do not immediately select the first plausible answer. Compare choices against the facts.

Use four tests

For each answer choice, ask:

1. Relevance: Does it address the issue in the scenario?
2. Timing: Is it the right action for the current lifecycle stage?
3. Authority: Is the proposed party or process appropriate?
4. Completeness: Does it handle the risk without ignoring governance, documentation, or monitoring?

The best answer usually passes all four tests.

Prefer evidence-based governance over informal comfort

In AI risk scenarios, answers that rely on trust, reputation, or informal judgment are usually weaker than answers that create documented evidence and accountable oversight.

Stronger answer patterns include:

• Documented risk assessment.
• Independent review or validation.
• Defined ownership.
• Approval before deployment.
• Ongoing monitoring with thresholds.
• Clear escalation path.
• Data and model documentation.
• Audit logs and change records.
• Vendor due diligence and monitoring.

Weaker answer patterns often rely on:

• The vendor’s reputation alone.
• The model’s complexity as proof of quality.
• High average accuracy without further analysis.
• A one-time approval despite changing conditions.
• Human review without training or authority.
• Efficiency gains without risk assessment.

Mini-scenarios: applying the process

Example 1: Model drift after deployment

A bank uses an AI model to prioritize fraud alerts. After several months, analysts notice that alert volumes have increased sharply, but confirmed fraud cases have not increased. The model was validated before launch.

A strong reading process:

• Use case: fraud alert prioritization.
• Lifecycle stage: ongoing monitoring after deployment.
• Primary issue: performance drift or threshold degradation.
• Relevant facts: increased alerts, no corresponding confirmed fraud increase, prior validation but current performance change.
• Best action type: monitor, investigate, escalate, and adjust through controlled governance.

The most defensible answer would likely involve investigating performance changes, reviewing data and thresholds, escalating under model governance, and recalibrating or updating through approved change processes if needed. A choice that says “no action is needed because the model was previously validated” would not address the current facts.

Example 2: Vendor AI in customer communications

A firm wants to use a third-party generative AI tool to draft customer-facing explanations of investment product features. The vendor states that its model is proprietary and cannot disclose training details.

A strong reading process:

• Use case: customer-facing communication support.
• Lifecycle stage: use-case approval and third-party review.
• Primary risks: hallucination, misleading output, data exposure, third-party opacity, governance.
• Relevant facts: external customer impact, generative AI, vendor limits on transparency.
• Best action type: due diligence, controls, human review, documentation, and approval conditions.

The strongest answer would not rely solely on vendor claims. It would require a risk assessment, vendor due diligence, controls over inputs and outputs, human review before customer use, documentation of limitations, and ongoing monitoring.

Example 3: High accuracy but uneven outcomes

A credit-risk model shows strong overall predictive performance, but testing shows materially weaker performance for a particular customer segment. The business team wants to proceed because the overall accuracy metric exceeds its target.

A strong reading process:

• Use case: customer-impacting credit decision support.
• Lifecycle stage: validation or pre-deployment review.
• Primary risks: fairness, representativeness, performance segmentation, suitability for use.
• Relevant facts: weaker performance for a segment, customer-impacting context.
• Best action type: investigate, document, mitigate, and obtain appropriate approval before deployment.

The best answer would address subgroup performance and potential unfair or unreliable outcomes. It would not approve deployment based only on the overall metric.

Build a concise annotation habit

During practice, mark the scenario lightly. Your notes should help you think, not slow you down.

Use a short code if helpful:

• U: Use case
• R: Primary risk
• S: Lifecycle stage
• D: Data issue
• G: Governance issue
• V: Validation issue
• M: Monitoring issue
• T: Third-party issue
• A: Best action

For example:

Vendor model used in credit review. No independent validation. Vendor limits transparency. Business wants rapid deployment.

Quick annotation:

• U: credit decision support
• R: model and third-party risk
• S: pre-deployment
• V/T: insufficient independent review and transparency
• A: complete risk assessment, due diligence, validation, approval before deployment

This habit helps you avoid overreacting to one familiar term while missing the controlling fact.

Final review checklist for RAI scenarios

Before selecting an answer, confirm:

• I know the AI use case and its business impact.
• I identified the lifecycle stage.
• I know the main decision point in the question stem.
• I separated the central risk from background facts.
• I considered data, model, governance, monitoring, and third-party clues.
• I checked whether human review is meaningful.
• I checked whether documentation and accountability are addressed.
• I matched the answer to the timing: before deployment, during use, or after an issue.
• I avoided choosing based only on technical sophistication or efficiency.
• I selected the answer that is most defensible from the facts provided.

Practice plan for scenario mastery

For final review, practice in short, deliberate sets rather than rushing through large blocks. After each scenario, write one sentence explaining why the correct answer is best and why the closest alternative is less complete. Over time, your goal is to recognize the decision sequence: use case, risk, lifecycle stage, control objective, and best action.

A practical next step is to complete a focused set of RAI scenario questions by topic, then take a timed mixed mock exam to practice applying the same reading process under exam conditions.