Responsible AI
Pre-Deployment Checklist · EVO3 2026
Responsible AI Implementation Checklist
Complete this checklist before any AI system touches production. Items marked as blockers must be resolved before deployment — no exceptions.
Sierra Napier-Leach, MPA · EVO3
Red items are deployment blockers
Usage note: This checklist is designed for the team lead or governance owner reviewing an AI system before go-live. Work through it with both the technical lead and the business stakeholder present. Items marked BLOCKER must be resolved — document the resolution before marking them complete.
1. Transparency & Disclosure
Can affected parties understand what the AI is doing and why?
BLOCKER Affected users or clients know they are interacting with or being processed by an AI system.
Disclosure must be explicit — not buried in terms of service. If AI is making decisions about people, those people must know.
BLOCKER There is a human point of contact for people who want to contest or question an AI decision.
"Email us at support" is not sufficient. There must be a named path to human review of AI-driven outcomes.
Every AI-generated output that is shared externally is labeled as AI-generated or AI-assisted — not presented as purely human-authored.
Internal stakeholders can access a plain-language explanation of what the AI system does, what decisions it influences, and what its known limitations are.
You have a documented answer to "how does the system decide X?" for every AI action that affects people or outcomes.
2. Fairness & Bias
Does the system treat people equitably?
BLOCKER The system has been tested on representative samples that include demographic diversity — not just the easiest cases.
If your test set doesn't include edge cases from underrepresented groups, your accuracy numbers are misleading.
You have reviewed the training data or prompt context for sources of historical bias that might disadvantage certain groups.
The system does not use protected characteristics (race, gender, age, religion, disability) as inputs or implicit proxies for decisions.
There is a defined process for receiving, investigating, and addressing fairness complaints from people affected by the system.
Aggregate output patterns are monitored over time — not just individual outputs — to detect systematic bias that emerges at scale.
3. Privacy & Data Protection
Is sensitive data handled responsibly?
BLOCKER PII and PHI are not sent to external AI model APIs without a signed data processing agreement and appropriate legal review.
API calls to third-party models constitute data sharing. Verify your provider's data handling policies before sending sensitive data.
BLOCKER Data minimization is practiced — only the minimum necessary data is passed to AI systems to perform each task.
Do not pass full records when only specific fields are needed. Prompt injection via excess context is also a security risk.
Data retention policies specify how long AI inputs, outputs, and interaction logs are stored — and these policies are actually enforced.
Access to AI-generated insights and interaction logs is restricted to personnel with a legitimate need — not open to the whole organization.
You have verified that your AI vendor does not use your data to train their models — or have explicitly accepted this with full understanding of the implications.
4. Safety & Reliability
Is the system safe to run at scale?
BLOCKER There is a tested, non-technical kill-switch that immediately halts all agent activity without requiring a code deployment.
BLOCKER The system has been tested with adversarial or malformed inputs — not just the happy path.
Prompt injection, malformed data, and edge-case inputs that crash or mislead the agent must be tested before production.
Rate limiting and cost caps are configured on AI API usage — a runaway agent loop cannot produce unbounded costs.
Fallback behavior is explicitly defined for every external dependency failure (model API down, database unavailable, integration timeout).
Monitoring and alerting is configured — you will know within minutes if the system is behaving abnormally, not hours or days later.
All non-idempotent agent actions have deduplication logic — retries on transient failures cannot cause duplicate sends, writes, or notifications.
5. Accountability & Ongoing Governance
Is someone responsible for this system after it goes live?
BLOCKER A named individual has accepted ongoing accountability for this AI system's behavior in production — not "the team" or "engineering."
A formal review cadence is scheduled (at minimum quarterly) to assess system performance, fairness, and oversight boundaries.
There is a documented incident response plan for AI failures — what constitutes an incident, who is notified, and what the remediation process is.
The system's governance documentation is version-controlled and accessible to the responsible team — not stored in one person's memory or inbox.
Sunset criteria are defined — under what circumstances would this AI system be retired or significantly redesigned?
Blocked items slowing your launch?
We help organizations work through HITL governance and responsible AI blockers as part of pre-deployment reviews. Typical turnaround: one to two weeks.