Responsible AI Checklist
A pre-launch checklist for PMs shipping AI-powered features. Covers transparency, fairness, privacy, human oversight, and accountability — with sign-off tracks for legal, security, and leadership. Free to copy, download, and use. No signup required.
# Responsible AI Checklist **Feature:** [Name] **PM:** [Name] **Date:** [Date] **Review stage:** [ ] Design [ ] Pre-launch [ ] Post-launch audit --- ## Instructions Work through each section before shipping any AI-powered feature. Items marked **[Required]** are non-negotiable. Items marked **[Recommended]** are strongly advised but may be waived with documented justification. Check each box only when the condition is genuinely met — not aspirationally. --- ## 1. Transparency - [ ] **[Required]** Users are informed when they are interacting with AI — not a human and not a deterministic algorithm. - [ ] **[Required]** The AI's purpose is described in plain language in the UI (tooltip, onboarding, or help text). - [ ] **[Recommended]** Users can see why the AI produced a given output (explanation, confidence indicator, or source citation). - [ ] **[Recommended]** Limitations and known failure modes are documented in the help centre or onboarding flow. - [ ] **[Recommended]** If the AI uses personalisation, users are informed what data is used and can opt out. **Notes:** [Any transparency gaps and how they are addressed] --- ## 2. Fairness & bias - [ ] **[Required]** The feature has been evaluated for performance differences across demographic groups (gender, age, language, region). - [ ] **[Required]** Training data sources are documented and known biases are recorded. - [ ] **[Recommended]** Evaluation metrics are disaggregated by user segment, not just overall accuracy. - [ ] **[Recommended]** A process exists to flag and investigate reports of biased output from users. - [ ] **[Recommended]** The feature avoids making decisions based on protected characteristics unless legally permitted and necessary. **Identified biases and mitigations:** [List any known bias issues and how they are handled] --- ## 3. Privacy & data minimisation - [ ] **[Required]** Only the minimum data required to produce the AI output is sent to the model. - [ ] **[Required]** User PII handling is documented and reviewed by legal/privacy. - [ ] **[Required]** If data is sent to a third-party model provider, a DPA (Data Processing Agreement) is in place. - [ ] **[Required]** Users can request deletion of data used to train or personalise the model. - [ ] **[Recommended]** Model inputs and outputs are not stored beyond the minimum retention period. - [ ] **[Recommended]** A privacy impact assessment (PIA) has been completed for high-risk use cases. **Data flow summary:** [Brief description of what data moves where] --- ## 4. Human oversight & control - [ ] **[Required]** Users can override or ignore AI output — the system does not force compliance with AI recommendations. - [ ] **[Required]** A fallback exists if the AI model is unavailable (graceful degradation, not hard failure). - [ ] **[Recommended]** High-stakes decisions (financial, medical, legal, safety) require human confirmation before action. - [ ] **[Recommended]** A "report a problem" mechanism is available in the UI for users to flag bad AI output. - [ ] **[Recommended]** An internal escalation path exists for AI errors that cause user harm. **Human-in-the-loop design:** [Describe where humans can intervene in the AI decision flow] --- ## 5. Accountability - [ ] **[Required]** A named PM owns this feature and is responsible for AI behaviour post-launch. - [ ] **[Required]** An incident response plan exists for AI failure scenarios (wrong output, harmful content, model outage). - [ ] **[Recommended]** KPIs include an AI quality metric (error rate, override rate, user satisfaction with AI output). - [ ] **[Recommended]** A post-launch review is scheduled at 30 and 90 days. - [ ] **[Recommended]** Regulatory requirements (EU AI Act, RBI guidelines, sector-specific rules) have been reviewed and are documented. --- ## 6. Sign-off | Reviewer | Role | Status | Date | |---|---|---|---| | | PM | [ ] Approved [ ] Needs work | | | | Legal / Privacy | [ ] Approved [ ] Waived [ ] N/A | | | | Security | [ ] Approved [ ] Waived [ ] N/A | | | | Engineering Lead | [ ] Approved [ ] Needs work | | | | Leadership | [ ] Approved [ ] N/A | | **Open items before sign-off:** - [ ] [Item 1] - [ ] [Item 2]
How to use this Responsible AI template
Complete the checklist before design is finalised, not before launch
Most teams treat responsible AI as a pre-launch gate. That's too late — transparency and fairness decisions are baked into the design. Run this checklist at the design review stage so you can course-correct before engineering builds something that needs to be rearchitected.
Be honest about [Required] items — don't check boxes aspirationally
The temptation is to check 'Users are informed when interacting with AI' because you plan to add a tooltip eventually. Only check items that are true today. Required items that are unchecked are blockers, not suggestions. If you can't ship with them checked, escalate — don't quietly mark them done.
Use the sign-off table to surface disagreements early
Legal and security sign-off often surface requirements that change the feature design (e.g. a DPA with the model provider, or a data retention constraint). Get these stakeholders into the checklist review early — not 48 hours before launch when there's no time to respond to findings.
Schedule the 30-day post-launch review before you ship
Put the 30-day review on the calendar the day you launch. Teams that plan to review 'after launch' rarely do — the next sprint starts and responsible AI monitoring falls off. A calendar invite with the checklist linked is the minimum viable process.
Want a Responsible AI grounded in your actual customer data?
PMRead ingests your customer interviews, feedback, and Slack threads — and generates PRDs backed by real evidence, not guesses.
Frequently asked questions
Is this checklist required for internal AI tools, or just user-facing features?
Sections 1 (Transparency) and 2 (Fairness) are less critical for internal tools used only by employees. Sections 3 (Privacy), 4 (Human oversight), and 5 (Accountability) apply equally — internal users can be harmed by bad AI output, and internal tools that process customer data still have data protection obligations. Use the full checklist for external features; use sections 3–5 for internal tools.
How does this relate to the AI Product Risk Assessment?
The AI Product Risk Assessment scores and mitigates specific technical risks (accuracy, security, cost). This checklist covers the broader responsible AI principles — transparency, fairness, and accountability — that apply regardless of technical risk scores. Both documents are needed: use the Risk Assessment to catch what can go wrong technically; use this checklist to confirm you've met your ethical and regulatory obligations.
What counts as a 'high-stakes decision' that requires human confirmation?
Any AI output that directly causes a financial transaction, affects employment, influences a medical decision, or creates a legal obligation counts as high-stakes. For product managers: if a user could sue you because the AI was wrong, it's high-stakes. If a user would just be annoyed because the AI was wrong, it's not. Err on the side of human confirmation when you're unsure.
Other free templates