User guidance, monitoring, and the governance crosswalk
Lesson 5 of 5 in The Responsible AI Lens: Well-Architected for Trustworthy AI.
A released system owes its stakeholders two ongoing debts: honesty about what it is, and vigilance about what it becomes. The last two focus areas collect them.
User guidance (RAIGT, 5 BPs) starts from a transparency strategy: decide deliberately what each stakeholder group — end users, deployers, affected non-users — needs to know to make the informed choices about engaging with the system that the transparency dimension promises. The flagship artifact is the system card (RAIGT01-BP02, labelled High): a single place where stakeholders find the system’s intended use cases and limitations, its responsible-AI design choices, and its deployment and performance-optimisation guidance. It is the system-level sibling of the model card — documenting the whole assembled service, guardrails and retrieval and all, rather than one model’s weights.
Monitoring (RAIMON, 7 BPs) closes the lifecycle — and opens it again. Its purpose, in the lens’s words, is understanding the actual benefits and risks in operation, as opposed to the estimated ones your risk registry has held since design. Three themes structure it. Monitoring for deviations: the release evaluation becomes your baseline, and production behaviour is compared against it to catch drift — with a governance prerequisite most engineering guides skip: monitoring means observing people’s interactions, so obtain the consent that observation requires. Responding to feedback: user reports and complaint channels are monitoring instruments, and thresholds should define when a deviation escalates to a human-oversight trigger — the point at which people, not dashboards, must intervene. Decommissioning: obligations to contributing and downstream stakeholders survive the system — the lens is one of the few frameworks that treats honoring obligations during and after decommissioning as a first-class practice, covering the data contributed, dependencies downstream, and the users who must be transitioned rather than abandoned.
The loop back is deliberate: monitoring evidence feeds the risk registry, updated risks reshape release criteria, and a system that drifts past its criteria faces the same gate it faced at launch — release, iterate, narrow, or retire.
| Lens focus area | ISO/IEC 42001 | NIST AI RMF | EU AI Act (provider duties unless noted) |
|---|---|---|---|
RAIUC — Use case | Clause 4 context of the organisation; A.6 life-cycle (objectives, requirements) | MAP — establish context and categorise the system | Defining the intended purpose — the concept classification (Art 6, Annex III) hangs on |
RAIBR — Benefits and risks | A.5 AI system impact assessment (RAIBR03-BP03 itself cites this family) | MAP risks in context; MANAGE their treatment | Art 9 risk management system; Art 27 FRIA for certain deployers |
RAIRC — Release criteria | A.6 design and verification/validation criteria; clause 6 objectives | MEASURE — selecting metrics and thresholds | Art 15 accuracy and robustness — declared metrics travel in the Art 13 instructions for use |
RAIDP — Dataset planning | A.7 data for AI systems | MAP + MEASURE — data provenance and representativeness | Art 10 data and data governance |
RAISP — System planning | A.6 design; A.9 responsible use | MANAGE — risk treatment through design | Art 14 human-oversight measures built into the system; Art 50 machine-readable marking of synthetic content |
RAIER — Evaluate and release | A.6 verification and validation records | MEASURE — TEVV before deployment | Art 9(8) testing against defined metrics; Art 43 conformity assessment before placing on the market |
RAIGT — User guidance | A.8 information for interested parties | GOVERN — transparency and documentation policies | Art 13 transparency and instructions for use; Art 50 disclosure to affected persons |
RAIMON — Monitoring | Clause 9.1 monitoring and measurement; A.6 operation and monitoring | MEASURE in operation; MANAGE the response | Art 72 post-market monitoring; Art 73 serious-incident reporting |
Use the crosswalk the way the sibling module taught: the mapping runs through evidence, and it is lossy in both directions. The same risk registry entry is a RAIBR artifact in a lens review, an A.5 impact-assessment record in the AIMS, a MAP output in an RMF profile, and raw material for an Article 9 risk-management file — write it once, cite it four times. But no cell in that table is an equivalence: ISO/IEC 42001’s organisational clauses (leadership, competence, internal audit) have no lens counterpart, and the lens’s engineering specificity — paired tests, corroboration, statistical confidence — exceeds anything the standard requires. The lens is the how underneath frameworks that specify the that.
And remember which sibling covers what: this lens interrogates the use case across its lifecycle; the GenAI Lens module covers the six-pillar view of the workload — throughput, guardrail wiring, cost, sustainability. On a real generative system you will quote both in the same improvement plan, and file both under the same Well-Architected workload in the WA Tool.
Tool: Responsible AI Lens Index — Browse the full best-practice index: all 99 RAIUC-to-RAIMON best practices with plain-language summaries, risk labels, and links to the official pages — the reference to keep open during a real review.
Key terms: system card, post-market monitoring, drift monitoring, crosswalk, AI management system
Interactive checkpoint quiz (1 questions) — open this page in a browser to take it.