Responsible AI checklist for designers: what to review before launch

A practical checklist for designers building AI features: data, expectations, errors, user control and transparency, with questions you can answer today.

info Quick Definition
A responsible AI checklist is a list of questions the team answers before launching an AI feature. Its goal is to find design risks while they are still cheap to fix, not after a user finds them.

Why a checklist and not only principles?

Responsible AI principles are easy to agree with and hard to apply. “Be fair” or “be transparent” does not tell anyone what to change on the screen. A checklist turns each principle into a concrete question that someone on the team can answer with evidence.

Reference design guides point in the same direction. Google’s People + AI Guidebook is organized in chapters that follow the product development flow, and each one comes with a worksheet to turn the guidance into action (Google PAIR, People + AI Guidebook). Microsoft organizes its HAX Toolkit into guidelines, a design library, patterns, a workbook and a playbook for exploring common failures before launch (Microsoft HAX Toolkit, About). The checklist below is a practical synthesis of these approaches, not an official standard.

What should you review before launch?

1. Need and scope

  • Does the AI solve a problem the user has, or does it only show that we have AI?
  • What happens if we do not use AI? Is the alternative still acceptable?
  • Which decisions does the user make, and which does the system make?

2. Data

  • What data enters the model, including attachments, history and retrieved context?
  • Is training use separated from the use needed to provide the service? See consent to train on user data.
  • Do we know how long data is kept and who can see it?

3. Expectations

  • Does the interface say it is an AI and that it can make mistakes?
  • Are concrete limits shown, such as the knowledge cutoff or the lack of access to certain data?
  • Does the tone make users believe something false about what the AI knows or feels? See anthropomorphism.

4. Errors

  • How is an error detected, and what happens when the system does not detect it?
  • Can the user correct the result in place, without redoing the task?
  • Is there undo for any action the AI executes? See AI errors and how to recover.

5. Control

  • Can the user stop, edit or reject the response at any time?
  • Do high-impact actions ask for confirmation before running?
  • Is there a path to a person when the AI falls short?

6. Accessibility

  • Does a screen reader announce generation states without repeating the whole response? See accessibility in AI interfaces.
  • Is there an alternative to color for showing confidence or warnings?

7. Measurement

  • What does it mean for the feature to work well, and which metric would signal that it is causing harm?
  • Who reviews failed cases, and how often?

Which laws and standards should you keep in view?

The checklist is not a standard, but it rests on frameworks that are. Status as of November 2026:

  • EU AI Act. It entered into force on 1 August 2024 and general application began on 2 August 2026, transparency rules included. The reform known as the “AI Omnibus”, in force since 27 July 2026, postponed the high-risk obligations to 2 December 2027 (systems in the Annex III areas) and 2 August 2028 (regulated products, Annex I) (European Commission).
  • NIST AI RMF 1.0. A voluntary framework published on 26 January 2023, with the functions Govern, Map, Measure and Manage. A Generative AI Profile exists (NIST-AI-600-1, 26 July 2024), and NIST states that the framework is being revised (NIST).
  • ISO/IEC 42001:2023. Published on 18 December 2023, it specifies requirements for establishing and maintaining an AI management system inside an organization (IEC Webstore).

If the product is offered in the EU, which obligations apply depends on the case. That question is for the legal team.

How do you use it without making it a formality?

Three simple rules:

  • Answer with evidence. A “yes” without proof does not count. Each answer should point to a screen, a text or a concrete data point.
  • Mark what you do not know. An unanswered question is an open risk, and it needs an owner and a date.
  • Review it on every major change. A new model or a new data source can change almost every answer.

Example

Illustrative example: a team designs an assistant that suggests replies to customer emails. When they go through the checklist, they find that the assistant stores drafts even when the user does not send them (point 2), that there is no way to undo an automatic send (point 5), and that the suggestion text says “I recommend this reply” without indicating it was generated (point 3). The three fixes are small: a draft notice, a confirmation before sending and a visible “Suggested by AI” label. None of them requires rebuilding the feature.

How to apply it tomorrow

  1. Copy the checklist into a shared document and assign one owner per section: design, engineering, legal or product.
  2. Answer the seven sections in a single one-hour session. Whatever cannot be answered in that hour moves to an open risks list, with an owner and a date.
  3. For every “yes”, paste the link to the screen, the text or the test that proves it. If there is no link, change the answer to “no”.
  4. Before each launch, review only what changed since the last time. If the model or the data source changed, review all seven sections again.

At this pace, the checklist stops being a formality and becomes a short conversation the team repeats.

Common mistakes

  • Using the checklist once, at the end of the project.
  • Having only the design team answer it, without engineering or legal.
  • Ticking “yes” everywhere without showing evidence.
  • Treating privacy and transparency as legal text instead of part of the flow.
  • Leaving failure cases off the list because the team only tests the happy path.
  • Believing that an approved checklist makes a feature responsible forever.

Sources

Frequently asked questions

What is a responsible AI checklist?
It is a list of questions the team answers before launching an AI feature, to review data, expectations, errors, user control and transparency.
Who should use the checklist?
Designers, product managers and engineering together. Many answers depend on technical decisions, such as which data is stored or how reliable the model is.
When should the checklist be reviewed?
At the start, to define scope, and again before launch and after every major change in model or data, because the risk changes with them.
Does the checklist replace a legal review?
No. It surfaces design risks and questions for the legal or privacy team, but it does not determine regulatory obligations.