A review checklist for AI features before a public launch

Imagine a launch review that takes forty minutes. The team demos the feature, shows eval scores, confirms the model is current, and ships. A week later, a user discovers that the assistant will summarize another customer’s support ticket if they paste its ID into the chat box. The eval suite never tested that boundary because it measured answer quality, not authorization.

AI features fail on the seams: between the model and the data, between the prompt and the permissions, between the demo and the bill. A review that only looks at model output will miss nearly all of them.

This is a checklist for the review that happens before public launch, written to be run rather than admired. It assumes a feature that real users will touch, with real data behind it, and it is organized so that each section can be assigned to a different reviewer.

How to run this review

Three rules make the difference between a checklist that catches problems and one that produces a signed document nobody reads.

Every item needs evidence, not assurance. "We handle rate limits" is not a result. A dashboard link showing the 429 rate over the last seven days is. Where evidence does not exist, the item is unverified, which is a different state from passed.

Separate blockers from advisories. A blocker stops the launch. An advisory is a known gap with an owner and a date. Mixing them produces either a launch that ignores everything or a review that blocks on trivia. The list below marks blockers; everything unmarked is an advisory unless your product's risk profile says otherwise.

Run it before the launch date is announced. A review that happens four days before a committed date is a negotiation, not an assessment. The useful version happens when there is still room to change the design.

Role	Owns
Feature owner	Scope, evaluation, failure UX, rollout
Backend / platform	Permissions, quotas, latency, observability
Security	Data boundaries, injection, output handling
Support / success	Debuggability, escalation, user-facing copy
Finance or product ops	Cost model, plan limits, disclosure

If your team is three people, one person wears several hats. That is fine. What is not fine is nobody owning a row.

The three defects behind most AI incidents

If you read post-incident writeups of AI features, a small number of root causes recur. They are worth naming up front, because they tell a reviewer where to spend attention when time is short.

Cross-boundary data exposure. The model returns something the requester should not have. This usually is not a model failure at all. It is retrieval before authorization, a cache key that omits the tenant, or a service account with broad read access standing in for the user's own credentials. It is a high-severity category and can often be tested with two accounts and deliberately chosen foreign identifiers.

Unbounded spend. A loop, a scraper, a retry storm, or a single power user turns a modeled monthly cost into a finance escalation. The tell is that nobody can state the maximum daily spend, because no cap exists. This one is trivially preventable and routinely skipped, because the cost model lives in a spreadsheet that nobody connected to an alarm.

Silent degradation. The feature keeps returning something when it should return nothing. Truncated summaries, empty retrieval presented as "no results", a fallback model answering a question it was never meant to handle. Users cannot distinguish these from correct answers, so the failures accumulate quietly until trust breaks.

Everything else on this checklist matters, but these three are the ones that end launches. If you have limited review capacity, spend it here and treat the rest as follow-up work with owners.

Scope and data boundaries

Start here, because a feature that reads the wrong data cannot be rescued by a better prompt.

• Is the data set the feature reads explicitly enumerated? Not "the knowledge base" — the actual collections, buckets, tables, or endpoints, listed. If the list cannot be written down, the boundary is undefined. Blocker.
• Does the feature read data the requesting user could not open directly? Test with two accounts at different permission levels. This is the single most common serious defect in AI features, and it is invisible in a demo. Blocker.
• Is there any path where retrieved content reaches the model before authorization is applied? Retrieval-time filtering, not post-filtering of the answer. Blocker.
• What happens to data the feature was never supposed to see but received anyway? A user pastes a document into the chat box. Is it stored? Logged? Sent to the provider? Is that consistent with what the privacy notice says?
• Does the feature write anywhere? If it can create, update, or delete, that path needs its own review. A read-only launch is a legitimate scope reduction and often the right one.
• Are file uploads constrained by type, size, and content? Extension checks alone are not validation. Blocker if uploads exist.
• Is there a data-retention decision for prompts, responses, and retrieved chunks? "Forever by default" is a decision, and usually the wrong one.

Prompts, models, and versions

The model is a dependency, and dependencies need to be pinned, versioned, and changeable.

• Is the prompt stored in version control, with a diffable change history? Prompt changes can alter behavior silently and should be reviewed like code. Blocker.
• Is the model identifier pinned to a specific snapshot or version where the provider offers one? "Latest" is not a version. Blocker.
• Is there a documented rollback path for a prompt change? Can you revert in minutes without a deploy? Blocker.
• Are prompts and model versions included in logs alongside responses? Without this, no incident can be reconstructed.
• Is there a policy for model deprecation? If the provider retires the model in six months, who finds out and what happens?
• Are tool definitions versioned with the prompt? A prompt that references a tool the server no longer exposes produces confident nonsense.
• Has anyone reviewed the system prompt for leaked internals? Internal URLs, table names, employee names, and unreleased feature names end up in prompts surprisingly often.

💡 Practical note: store prompts as files with a content hash, and log the hash with every request. When someone reports a bad answer from three weeks ago, the hash is how you find out which prompt produced it.

Permissions and tenancy

If the feature is multi-tenant, this section is where launches go wrong.

• Can a user in tenant A cause the model to retrieve, summarize, or reference tenant B's data? Test by constructing requests with foreign identifiers. Blocker.
• Are caches keyed on tenant and permission scope? A response cache keyed only on the question text is a cross-tenant leak with a hit rate. Blocker.
• Does the model ever receive a tenant identifier it can pass back in a tool call? It should not. Inject it server-side. Blocker.
• Do background jobs that precompute AI output respect the same boundaries as the interactive path? Precomputation is where authorization checks are most often forgotten.
• Is there a test that asserts isolation, and does it run in CI? Two tenants, one feature, an assertion that the outputs differ. This is cheap and it catches regressions.
• What happens when a user's permissions change mid-session? Cached context can outlive the permission that justified it.

Failure UX and degradation

Every AI feature will be slow, rate-limited, and wrong. The only question is what the user sees.

• Is there a designed state for each of: timeout, rate limit, provider outage, empty retrieval, model refusal, malformed tool output, and partial failure? Enumerated and reviewed, not improvised. Blocker.
• Does the feature degrade to something useful, or to a spinner? A non-AI fallback — search results, a template, a link to the manual process — is often the right degraded mode.
• Is the user told when the answer is partial? Silent truncation is the most damaging failure mode because it looks like success. Blocker.
• Are errors specific enough to act on? "Something went wrong" tells the user nothing and generates a support ticket that says the same.
• Can the user retry without duplicating a side effect? If the feature writes, a retry must be idempotent. Blocker for write-capable features.
• Does the feature ever block the rest of the page? The AI panel should fail independently of the surrounding UI.
• Is there an honest empty state? "I don't have enough information to answer that" is a feature, not a defect, and it needs to be written and tested like one.

Cost and quotas

AI features have a marginal cost per use, which makes them unlike most software features. Launch reviews routinely skip this and discover it at the first invoice.

• Is there a modeled cost per request, per user, and per month at expected volume? With assumptions written down, not a single number. Blocker.
• What is the cost of a bad day? A retry storm, a loop, or a scraper can multiply usage by 10x. Is there a hard cap? Blocker.
• Are there per-user and per-tenant limits? Without them, one customer's automation defines your bill.
• Is there an alert at 50, 80, and 100 percent of the monthly budget? With a named person who receives it.
• Does the pricing model survive power users? If the feature is included in a plan, what happens when a customer uses it a hundred times more than the median?
• Is spend attributable per feature and per tenant? If not, you cannot answer "is this feature profitable" after launch.
• Has anyone checked the token accounting against the provider's billed usage? Token counts differ across tokenizers and change with model snapshots.

Latency and capacity

• What is the p50 and p95 end-to-end latency, measured on production-like data? Not on a laptop with a warm cache. Blocker.
• What is the first-token latency, if the feature streams? This is the number users actually feel.
• Does the feature have a timeout, and is that timeout derived from a patience budget rather than a library default? Blocker.
• What happens at 5x expected load? If the answer is "the provider rate-limits us", the failure UX from the previous section is now load-bearing.
• Is AI traffic isolated from batch traffic in the same quota pool? A nightly re-index can starve the product.
• Are retries capped, and is there a single retry owner in the stack? Nested retries multiply silently.
• Does the feature hold a database connection or a worker slot while waiting on the model? Long-held resources turn a slow model into an outage elsewhere.

Evaluation and quality gates

An AI feature without an evaluation set is a feature whose quality is defined by the last person who looked at it.

• Is there a golden set of real examples with expected outcomes and enough coverage for the launch decision? Real, not synthetic-only. Blocker.
• Does the eval cover the failure cases, not just the happy path? Ambiguous input, missing context, adversarial input, out-of-scope questions. Blocker.
• Is there a numeric threshold for launch, agreed in advance? "Looks good" is not a gate.
• Is the eval run automatically on prompt and model changes? A gate that requires someone to remember is not a gate.
• Are quality results broken down by segment? Aggregate accuracy hides a feature that works for the majority and fails for a specific customer type.
• Has anyone measured false-confidence? Not "is the answer right" but "does the answer sound right when it is wrong". This is the metric most correlated with user harm.
• Is there a process for turning production failures into eval cases? The set should grow from incidents, not stay frozen at launch.

Observability and debuggability

Support will be the first team to see problems, and they will not have access to your logs unless you plan for it.

• Can support find a specific conversation from a user-provided detail (timestamp, email, ticket ID) in under two minutes? Blocker.
• Is the full request traceable: prompt version, model, retrieved documents, tool calls, token usage, latency, and the final output? Blocker.
• Are traces retained long enough to investigate a complaint within your support SLA? Define the window explicitly and check it against privacy and retention requirements.
• Is there a way to replay a request against a candidate fix without touching production? This turns a debugging session into a test case.
• Are prompts and responses logged without leaking secrets or unnecessary personal data? Logging everything is its own incident.
• Can you answer "how many users got a wrong answer today" with data rather than anecdotes? If not, you do not have observability, you have logs.

Abuse, injection, and output handling

Public launch means hostile input. This section is not optional for anything that reads user content.

• Is the system prompt treated as public? Assume it will be extracted, and make sure that is not harmful. Blocker.
• Can content the model reads contain instructions that change its behavior? Retrieved documents, pasted text, and tool results are all injection surfaces. Blocker.
• Is model output ever rendered as HTML or executed? Sanitize, and never trust the model to produce safe markup. Blocker.
• Are tool calls authorized server-side, per call, regardless of what the model asked for? The model's request is untrusted input. Blocker.
• Is there a limit on what an authenticated user can spend in a session? Both for cost and for abuse.
• Can the feature be used to exfiltrate data through a link, an image, or a markdown render? Auto-loaded images and clickable links are a classic channel.
• Is there a way to detect and block a single account using the feature as a free API? Rate limits per user, not just per key.

Legal, privacy, and disclosure

• Does the privacy notice describe what is sent to a third-party model provider, and how long it is retained? Blocker.
• Are provider data-retention and training terms consistent with your commitments? Check the current terms; they change.
• Does the feature process regulated data — health, financial, children's, or employee data? If so, the review needs someone who knows the applicable rules.
• Is AI involvement disclosed where users could reasonably be misled? A person should know when they are talking to a model, and when content was generated.
• Are generated citations, links, and figures verified or labeled as unverified? A fabricated citation is a legal problem as well as a quality problem.
• Does the feature produce content that could be defamatory or discriminatory? Who reviews that risk, and what is the response plan?
• Is there an accessibility review? Streaming text, live regions, and keyboard access are easy to forget and hard to retrofit.

Rollout, kill switch, and on-call

• Can the feature be disabled for all users in under a minute, without a deploy? Blocker.
• Can it be disabled for one tenant? During an incident, the loudest complaint is often from the one customer whose data shape breaks it.
• Is the flag independent of the deploy pipeline? If turning it off requires a build, it is not a kill switch.
• Is there a staged rollout: internal, then a small percentage, then general? With a defined metric to watch at each stage.
• Does on-call know what this feature is and what its failure looks like? An alert that says "AI errors elevated" is not actionable at 3 a.m.
• Is there a runbook with the first five diagnostic steps? Including where to find traces and how to check provider status.
• Is there a rollback plan for the data, not just the code? If the feature wrote something wrong, reverting the deploy does not fix it.

Run a misuse-and-failure session, not just a demo

Before public exposure, schedule a short structured session with someone who did not build the feature. Give them two test accounts with deliberately different permissions and ask them to try normal and adversarial tasks. The goal is not to “red team” the model with clever jailbreaks alone; it is to exercise the product boundaries that a real user can reach.

Try at least these paths:

1. Ask for another tenant’s record using a valid-looking identifier.
2. Put instructions inside a document or message the model is asked to summarize.
3. Ask for a write action that the user cannot perform in the ordinary UI.
4. Change the underlying record after retrieval but before approval.
5. Make the provider time out after a tool may have completed.
6. Submit a malformed file, an oversized input, and a mixed-intent request.
7. Trigger an empty retrieval result and confirm the product does not invent an answer.
8. Disable the model endpoint and verify that the page and non-AI workflows still work.

For each attempt, capture the input, expected policy outcome, actual tool calls, state changes, user-visible response, and trace ID. A successful refusal in the chat is not enough if the tool already executed. Conversely, a scary-looking prompt is not a vulnerability if authorization denies the action and no data crosses the boundary.

This session should include both a normal and a restricted user, and at least one person from support or operations who will receive the failure report after launch. Developers know how the feature is supposed to work; support knows how users describe it when it does not. That difference is useful evidence, not overhead.

Make blockers measurable and advisories owned

The label “blocker” should refer to an observable release condition, not a reviewer’s general discomfort. Examples include an unresolved cross-tenant read, a write tool that does not enforce authorization server-side, an unbounded retry path, or a public launch with no way to disable the feature. These conditions can be tested and the release can stop until they are fixed.

An advisory is not a permission to forget the issue. It needs a named owner, a target date, and a trigger that would promote it to a blocker. For example, a known latency tail may be acceptable for an internal pilot but become a blocker before the product is offered in a real-time workflow. A missing per-tenant cost dashboard may be tolerable at a low-volume preview but not after self-serve access is enabled.

Avoid converting every checklist item into an arbitrary numeric threshold. If you choose a limit—acceptable override rate, eval pass rate, queue age, or spend cap—write down why that threshold matches the feature’s risk and how it will be measured. A number without an owner or an action is decoration; a threshold connected to rollout or rollback is a control.

The sign-off record

A review that produces no artifact is a conversation. Keep a short record per section: owner, evidence link, status, and any accepted risk with a date.

{
  "feature": "support_summarizer",
  "reviewed_at": "2026-10-14",
  "release": "2026.10.3",
  "sections": {
    "data_boundaries": {
      "status": "pass",
      "evidence": ["SEC-4471", "isolation-test-ci#812"],
      "owner": "security"
    },
    "cost_quotas": {
      "status": "pass_with_advisory",
      "evidence": ["fin-model-sheet-v3"],
      "advisory": "per-tenant cap defaults to unlimited for enterprise; owner: platform; due: 2026-11-01",
      "owner": "platform"
    },
    "evaluation": {
      "status": "pass",
      "evidence": ["eval-run-2291", "golden-set-v4 (118 cases)"],
      "owner": "feature"
    }
  },
  "blockers_open": 0,
  "approved_by": ["eng-lead", "security", "product"]
}

The value is not the JSON. It is that every "pass" points at something a skeptic could open, and every accepted risk has a name and a date attached.

The one-page version

If you only have thirty minutes, these are the items that have historically caused the most damage. Treat them as the mandatory subset.

1. Two users with different permissions cannot see each other's data through the feature. Test it, don't reason about it.
2. Caches are keyed on tenant and permission scope.
3. There is a designed, reviewed UI for timeout, rate limit, empty retrieval, and refusal.
4. The prompt and model are versioned and rollback is possible in minutes.
5. There is a hard cap on spend per day and per tenant.
6. A kill switch exists outside the deploy pipeline.
7. Support can trace one conversation end to end in under two minutes.
8. Model output is never rendered as trusted HTML, and tool calls are authorized server-side.
9. The privacy notice matches what actually leaves your infrastructure.
10. One person is on the hook for watching the metrics for the first 72 hours.

Ten items will not cover everything. They cover the failures that turn a launch into an incident, and they are cheap enough to check before every release rather than only the first one.

The broader point is that an AI feature's risk profile is dominated by the system around the model, not the model itself. The prompt is the part everyone reviews, and it is rarely the part that breaks. Data boundaries, permissions, failure states, and cost caps are unglamorous, they do not demo, and they are what a launch review is actually for.