Tool
AI Readiness Review
A more rigorous instrument for launch review. Five screening questions come first, then 27 criteria across seven dimensions. Under each criterion, the labels marked "Based on" name the standards and guidelines it draws on; the key at the bottom of the page explains each one. Some criteria are marked as gates.
1Screening — five questions asked before scoring
- S1Does the output influence a decision about a person’s employment, finances, health, housing, legal status, education, or benefits?
- S2Can the system take an action, or commit a result, without a human confirming it first?
- S3Does the feature process personal, sensitive, or identifiable data?
- S4Will non-expert, vulnerable, or unsupported users rely on the output without a specialist intermediary?
- S5Are the effects of a wrong output slow, costly, or impossible to reverse?
D1Capability disclosure
- D1.1Users are told they are interacting with an AI system, clearly and at or before first interaction.
- D1.2Expected reliability is communicated in terms the user can act on, not as an unqualified capability claim.
- D1.3Scope boundaries are stated: the interface communicates what the system is not for.
- D1.4Expectation-setting is staged across the experience rather than front-loaded into a single disclaimer.
D2Output legibility
- D2.1Uncertainty is expressed per output and reflects actual model confidence rather than a fixed decorative label.
- D2.2The reason for a given output is available at the point of decision, in plain language.
- D2.3Output is traceable to the inputs, records, or rules that produced it.
- D2.4Confidence signals and explanations are conveyed non-visually as well as visually.
D3Human agency and oversight
- D3.1The user can see what the system proposes to do before it takes effect.
- D3.2A person can disregard, override, or reverse the output without engineering assistance.
- D3.3Consequential actions require explicit human confirmation; the system does not execute them silently.
- D3.4The design actively counters automation bias rather than encouraging uncritical acceptance.
D4Uncertainty and failure design
- D4.1An explicit “cannot determine” state exists and is structurally distinct from a confident answer.
- D4.2Low-confidence output receives different visual and interaction treatment from high-confidence output.
- D4.3A designed recovery path exists for AI-specific errors, separate from generic system error handling.
- D4.4Failure is contained: one bad output does not block, corrupt, or silently alter unrelated work.
D5Equity and accessibility
- D5.1The AI-specific interface has been tested with assistive technology, not only reviewed visually or inherited from a component library.
- D5.2Performance disparities across user subgroups, languages, or regions have been measured rather than assumed absent.
- D5.3AI-generated accessibility content is human-reviewed before it is relied upon.
- D5.4The experience adapts to user context and stakes rather than offering one undifferentiated path.
D6Demonstrated value
- D6.1The efficiency or quality claim is measured against a real pre-AI baseline, not estimated.
- D6.2Complexity is genuinely removed rather than displaced into a downstream step, another team, or a later moment.
- D6.3A granular feedback mechanism exists and demonstrably routes into system improvement.
- D6.4Post-deployment monitoring is defined, with a named owner and a threshold that triggers action.
D7Accountability record
- D7.1Known limitations are documented in a form that actually reaches the people who deploy and use the system.
- D7.2A named human owner is accountable for this feature’s behavior in production.
- D7.3An impact assessment covering affected individuals and groups was completed before launch.
KeySources — what each “Based on” label refers to
- AI Act Art. 50 EU AI Act, Article 50: transparency duties, including telling people when they are interacting with an AI system.
- HAX G1–G18 Microsoft’s Guidelines for Human-AI Interaction, eighteen guidelines for how an AI feature should behave with the people using it.
- AI Act Art. 13 EU AI Act, Article 13: transparency and the information a system must provide to the people who deploy it.
- NIST AI 100-1 NIST’s AI Risk Management Framework 1.0, a U.S. framework for identifying and managing AI risk.
- PAIR Guidebook Google’s People + AI Guidebook, design guidance for AI-powered products.
- NIST AI 600-1 NIST’s Generative AI Profile, which applies the AI Risk Management Framework to generative AI.
- ISO/IEC 42001 The international standard for AI management systems.
- WCAG 2.2 W3C’s Web Content Accessibility Guidelines, version 2.2.
- W3C AI-A11y W3C work on accessibility and AI.
- AI Act Art. 14 EU AI Act, Article 14: human oversight of high-risk AI systems.
- Parasuraman 1997 Parasuraman and Riley (1997), research on how people use, over-rely on, and neglect automation.
- Mosier 1996 Mosier and Skitka (1996), research on automation bias in human decision-making.
This page lists the instrument (AIRR v1.0). This page does not score a system or assign a tier; use it as a checklist. A Gate badge shows the risk tier recorded for that criterion in the instrument.