Focus tour I: use case, benefits and risks, release criteria

Lesson 3 of 5 in The Responsible AI Lens: Well-Architected for Trustworthy AI.

The first three focus areas happen before a line of the system exists, and they are where the lens earns its governance keep. Together they run the argument: define the problem precisely (RAIUC), enumerate what could go right and wrong (RAIBR), and commit — in writing, in numbers — to what the system must demonstrate before anyone may release it (RAIRC). Everything later in the lifecycle either satisfies these commitments or renegotiates them in the open.

RAIUC — Use case: define the problem before the solution (11 BPs)

The use case is the problem you are solving with an AI system, and the focus area forces a discipline most projects skip: a high-level use-case description plus a minimal description of the AI solution — system inputs, system outputs, and the type of AI (traditional, generative, or agentic) — before architecture begins. Its questions walk you through defining the specific problem, identifying the stakeholders, refining the use case, assessing the impact on existing workflows, and identifying requirements and approvals — who inside and outside the organisation must say yes.

Two scoping rules carry legal-sounding weight. Multiple related use cases — recognising faces of missing children versus locating an actor’s scenes in a video — get the framework applied to each use case independently, because their risks and release criteria differ even when the model is shared. And a general-purpose system gets no framework at all: the lens repeats here that it is not appropriate for chat with anyone about anything.

RAIBR — Benefits and risks: enumerate both sides of the ledger (17 BPs)

The lens treats benefits and risks as technically symmetrical: both are built from events — input-output pairs in an interaction — whose likelihood and impact you estimate per stakeholder group. A helpful interaction benefits a stakeholder; a harmful one damages them. The asymmetry is informational: use cases are defined by working backwards from desired benefits, so risks take more effort to find than benefits — you must deliberately hunt categories of harmful events, per responsible-AI dimension, that nobody wanted to imagine.

For each potential harm the focus area prescribes a qualitative estimate of likelihood and impact severity, mapped to an overall risk level, and the running result is a risk registry — the document that every later focus area reads and writes. One more definition to file precisely: the risk that remains once the actual implementation meets the use case is the residual risk, and the lens computes it later, from operational evidence — not from design-time optimism.

RAIRC — Release criteria: commit to numbers before you build (16 BPs)

Release criteria are the lens’s answer to the oldest governance failure in software: deciding whether a system is good enough after falling in love with it. RAIRC has you derive testable criteria from the use case and the risk registry — for each relevant dimension, select metrics that measure it, then set thresholds the system must meet, with attention to the statistical confidence your evaluation will need for the claim to mean anything. A fairness criterion might bind a fairness metric per stakeholder group; a veracity criterion might cap the rate of factually incorrect answers on a curated test set.

The craft is in the word testable. "The system should be fair" is a hope; "score parity across named user groups within a stated margin, at a stated confidence, on a stated dataset" is a release criterion. Write them while you still might walk away — that is the design principle responsible by design operating as intended. (A numbering footnote for your index: RAIRC03’s best practices skip BP06 in the official document.)

RAIBR03-BP03, read closely

The High-labelled best practice assign an overall risk level to each potential harm is a compressed risk-management course. Build a consistent risk matrix — for example, one-to-five scales for likelihood and severity, combined into low/medium/high/critical. Estimate likelihood realistically: how often have similar systems failed, how robust are your mitigations, and include misuse scenarios, not just technical faults. Assess severity through the full scope of consequences — immediate impact on individuals, broader community effects, and long-term damage to trust in AI. Document your reasoning so others can review it, and have multiple people assess independently. Its cited resources point at the NIST Risk Management Framework and ISO/IEC 42001’s AI system impact assessment — the lens knows exactly which governance instruments it is feeding.

Interactive sorting exercise: A design review produces these statements. Sort each into the focus area whose questions it answers.

Interactive checkpoint quiz (1 questions) — open this page in a browser to take it.