An AI risk assessment is not a generic worksheet asking whether a model is “accurate, fair and secure.” Those words describe categories, not the specific failure that could harm a user. The IAPP AIGP knowledge base expects professionals to understand how organizations identify, evaluate and manage AI risks in context. A useful assessment describes the system, the people affected, the decision or action it influences, the evidence of possible failure, and a control owner. It should be concrete enough that a reviewer can challenge an assumption or order a test. The best assessments begin with how a person or institution can be harmed, not with the vendor’s impressive benchmark score.
Define the actual use and its decision boundary
Imagine a hospital deploying an assistant to summarize clinical notes for staff. That application is different from an algorithm that recommends treatment or directly updates a patient record. The first may primarily create documentation error and privacy risks; the latter could influence patient safety and requires much stronger validation and oversight. Even within the same organization, roles and access levels change the threat model. Define intended users, data sources, output audiences, supported languages, integrations and any permitted actions. Record unacceptable uses explicitly, because a tool deployed for summarization may gradually be used for triage or patient advice when its capabilities appear convenient.
Draw a simple system boundary. What parts are supplied by a model provider, what is implemented by the deploying organization, what comes from retrieved data, and where does a human approve the result? Identify which components can change without the deployment team’s direct control. Vendor updates, new source documents and revised permissions can modify behavior. The risk assessment should specify who notices those changes and how they will be re-evaluated. This decomposition prevents the mistaken claim that every bad output is solely a “model hallucination” rather than a failure of retrieval, authorization, user interface or operational procedure.
Identify harm pathways, not abstract concerns
Fairness risk may arise if a hiring aid misreads career breaks differently across groups. Privacy risk may arise if a search assistant reveals a personnel record to someone who lacks permission. Security risk may arise when malicious text in a retrieved document induces an agent to call an authorized tool for an unauthorized purpose. Factuality risk may arise when the assistant cites an outdated tariff. Each problem has a different pathway, affected population and control surface. Map them in a scenario format: trigger, system behavior, exposure, impacted party and consequence. A vague entry labeled “bias” provides too little information to test or manage.
Include less obvious operational harms: a high false-positive rate that consumes investigators’ time, an inaccessible interface, excessive dependence on a model provider, or the removal of a human fallback from a high-stakes service. User context matters. A wrong trivia answer has a different impact from a wrong entitlement explanation sent to thousands of customers. The assessment must consider severity and realistic exposure, not only technical probability. Harm that is rare but irreversible may warrant a stringent control even if a vendor demonstration rarely reproduces it.
Use evaluation methods suited to the risk
Different risks require different evidence. Factual reliability can be tested using independently verified reference answers and source-support checks. Security can be tested through permission-denial cases and prompt-injection attempts relevant to the deployed tools. Fairness may require disaggregated outcomes across appropriately defined groups and contextual review of the decision process, subject to law and privacy constraints. Privacy analysis may examine data minimization, consent where required, retention and cross-boundary access. None of these is captured adequately by one percentage labeled “AI quality.”
Construct a dataset reflecting real user inputs, ambiguous cases, edge conditions, source changes and multilingual use where relevant. Preserve labels and evaluation rationale so results can be reproduced after a model or prompt update. Human assessment can uncover subtle context failures that automated scoring misses, but reviewers need consistent criteria and training. If two reviewers disagree strongly, that disagreement itself is evidence that the evaluation task needs refinement. Measure error severity as well as count; a harmless phrasing deviation and a fabricated financial guarantee should not contribute identically to one pass-rate figure.
Likelihood must reflect the deployment context
A common risk-register practice assigns numerical likelihood and impact scores, multiplies them and ranks the results. Such scales can help compare work, but multiplying arbitrary ordinal labels does not create a scientifically precise risk estimate. Be explicit about uncertainty and exposure. A model that produces unsafe advice once per thousand interactions may matter differently at ten requests a day versus millions. An agent with read-only access presents a different level of consequence than one able to transfer money. Revisit likelihood assumptions when user populations and allowed actions change.
Residual risk matters after controls are applied. Suppose the system uses evidence retrieval, content checks and human approval. Test whether those safeguards actually reduce unsafe outcomes under plausible attack and error scenarios. If users routinely bypass review or approvers cannot inspect sources, the nominal mitigation may provide little protection. Record both the claimed control and evidence that it operates under pressure. A deployment decision should make transparent which risks remain, who accepts them and under which conditions that acceptance expires.
Account for bias without reducing people to metrics
Bias analysis should begin with how the system affects people in a particular context. A language model generating performance feedback can impose cultural expectations in wording; an employment screening tool can inherit historical inequities in training data; a multilingual service may provide much poorer information to smaller language groups. Disaggregated statistics are one part of assessment, but they require care in deciding which groups can be evaluated lawfully and reliably. Sample size, base rates, missing data and selection effects can make simple group comparisons misleading.
Engage subject-matter experts and affected stakeholders where appropriate. A technically high-performing model can still impose unreasonable burdens on a group if complaints are hard to file or correction takes weeks. Assess whether users understand the system’s role and can seek effective recourse. Document meaningful limits on automation and explainability. When evidence is insufficient, an organization may need to narrow the application rather than declare fairness established through a weak metric. The outcome should be improved decision-making, not merely a comforting fairness score.
Third-party and downstream risks belong in scope
If a provider hosts the model, its security controls and data-processing practices matter. But the deploying organization also decides what information to transmit, which users can query the system, how tool calls are authorized, and how outputs become business actions. Assess vendors for versioning, incident support, retention, regional processing, training-data treatment and the ability to disable or roll back unwanted behavior. Examine whether contract terms allow access to sufficient evidence during a serious incident. A vendor assurance report may address infrastructure security without addressing the fairness of the customer’s particular use case.
Downstream recipients may also be affected. A generated customer explanation can be forwarded into a case-management system, copied into a legal response or treated as a definitive human decision. Trace where outputs go after leaving the AI interface. If employees repeatedly paste model suggestions into systems of record, the organization may have created an automated decision-support process without formally recognizing it. Training, interface design and technical boundaries should make it clear what requires independent verification before becoming an official record or decision.
Build monitoring and reassessment into the result
A risk assessment is incomplete without triggers for reassessment: new user groups, broader tool permissions, new model versions, data-source changes, emerging incidents or legal developments. Connect risk owners to monitoring indicators and define what will happen if thresholds are crossed. For a knowledge assistant, examples include an increase in unsupported answers, more requests involving confidential material, or a rise in complaints about wrong policy versions. For an agent, monitor attempted and completed tool actions separately so teams can see unauthorized proposals before they become successful transactions.
Run incident exercises that test more than detection. Can the responsible team pause the feature, identify affected users, preserve evidence and restore a known-good workflow? If the business cannot function without the assistant, the organization may have removed essential human capability too early. Review exceptions and near misses periodically. Many damaging deployments begin with a narrow permitted use and slowly expand through undocumented workarounds. AIGP-ready risk reasoning recognizes those changes as new decisions requiring evidence, rather than assuming the launch assessment remains valid forever.
A decision record reviewers can use
The final assessment should make five things clear: intended use, affected stakeholders, credible failure pathways, controls with supporting evidence, and the person authorized to accept or reject residual risk. If the documentation is lengthy but an executive cannot tell whether a proposed automated action is permitted, simplify the conclusion. If the record says “no significant risk” but has never tested a user with restricted permissions, record the missing evidence. The objective is not to eliminate all uncertainty; it is to make material uncertainty visible and bounded before people rely on the system.
For AIGP study, practice moving from a generic label to a testable scenario and from a test to a governance decision. A company that finds a weakness and pauses deployment has demonstrated a functioning assessment process. A company that files a polished report and deploys anyway has not. This discipline is what turns AI risk from a compliance conversation into an operational control that protects both people and the organization’s ability to innovate responsibly.