AI Risk Assessment

Build your answer around

Define the intended use, system boundaries, users, affected people, data, decision authority and operating context. Identify potential benefits and harms, applicable obligations and credible failure modes. Assess likelihood, severity and uncertainty, evaluate existing controls, determine residual risk, document ownership and approval, and establish monitoring and reassessment triggers.

Show judgment:

Explain that the depth of assessment should be proportionate to potential impact and that affected-stakeholder input may be necessary for higher-risk uses.

Build your answer around

AI can be probabilistic, difficult to explain, sensitive to changing data and context, and capable of influencing decisions at scale. Performance may differ across groups or degrade after deployment. AI also creates familiar risks in new combinations. A strong process integrates established privacy, security, legal, model risk and operational controls while addressing AI-specific uncertainty and oversight.

Build your answer around

Inherent risk is the exposure associated with the use case before considering controls. Residual risk is what remains after the design, procedural and monitoring controls are applied and evaluated. State assumptions clearly because weak or untested controls should not be credited as though they are operating effectively.

Build your answer around

Risk appetite expresses the amount and type of AI risk the organization is prepared to pursue or retain in support of its objectives. Tolerance translates that direction into measurable boundaries and escalation triggers. Use categories and examples tied to business context, legal duties, affected people and the organization's ability to detect and respond to harm.

Build your answer around

Include the business and system owner, technical team and specialists relevant to the use, such as legal, privacy, security, data governance, compliance, procurement, accessibility, human resources or model risk. Higher-impact uses may require independent challenge and input from affected users or communities. Participation should reflect the decision, not a fixed invitation list.

Build your answer around

Identify who is directly and indirectly affected, including people who may be underrepresented in available data. Examine the decision's stakes, frequency, scale, reversibility, available recourse and distribution of errors or benefits. Use disaggregated evidence where appropriate, acknowledge limitations and involve people with relevant lived or operational knowledge.

Build your answer around

Start with the intended use and risk tier, then request evidence on system purpose, limitations, data practices, security, testing, performance, human oversight, subcontractors, intellectual property, incident handling and material updates. Contract for notice, audit or evidence rights, support, data terms and exit options. If the vendor cannot provide evidence proportionate to the risk, recommend restrictions, compensating controls, a different use or rejection.

See related roles and tools in the GRC and AI Governance Career Resource Center.

Build your answer around

Make uncertainty visible. Use conservative assumptions for potentially severe or irreversible harm, distinguish missing evidence from low risk, identify what information would change the decision and set time-bound conditions. A limited pilot, additional testing, enhanced monitoring or delayed deployment may be appropriate depending on stakes.

Build your answer around

Triggers include changes to model, vendor, data, purpose, users, scale, autonomy or operating environment; drift or performance deterioration; complaints or incidents; new threat information; control failure; and changes in law or organizational risk appetite. Define triggers and owners at approval rather than improvising after a problem appears.

Build your answer around

Record the decision, rationale, evidence, assumptions, controls, residual risk, accountable approver, affected obligations, conditions, expiration date and monitoring requirements. Exceptions should be time-bound and visible. The person accepting risk must have appropriate authority, and legal or ethical duties cannot be waived by an internal approval.