# AI Launch Readiness Review: [AI feature or product] [version]

> Launch readiness review for an AI feature, model or agent: launch
> scope and tier, a gate checklist with named owners (product,
> evaluation results against thresholds, red team findings, safety and
> guardrails, privacy and DPIA, security, transparency notices under
> Article 50 of the EU AI Act, legal and regulatory register check,
> human oversight, monitoring and incident runbooks, rollback,
> documentation such as the system card and model card, accessibility
> and support readiness), exceptions and conditions, the go/no-go
> decision record and the post-launch review. It complements
> `dev/service-readiness` (production readiness of the service) and
> `product/launch-checklist` (cross-functional launch tasks) with the
> AI-specific gates. Legal gates reference Regulation (EU) 2024/1689 as
> amended by Regulation (EU) 2026/1744 and the other laws in your
> applicability register. Replace every `[bracketed]` value and every
> row marked *Example*. This is a documentation format, not legal
> advice.

<!--
Guidance: How to use this template
- Start the review when the launch date is proposed, not the week
  before. Gates with long lead times (DPIA, red team, external
  evaluation, regulatory notices) need weeks.
- Set the launch tier in section 2 first: it decides which gates are
  mandatory and who approves.
- Every gate has one accountable owner and points to evidence. "Done"
  without a link is not evidence.
- Thresholds in section 4 are fixed before the evaluation runs; do not
  move them to fit the result. Record any change as an exception.
- Run `dev/service-readiness` for the service itself and
  `product/launch-checklist` for marketing, sales and support tasks;
  link them in section 3 rather than repeating their content.
- Hold the post-launch review (section 9) on the date set in the
  decision record, even if nothing went wrong.
-->

## Document control

<!-- Guidance: Identify the release, the decision owner and every gate owner. One review per launch decision; a re-launch after a no-go gets a new version. -->

| Field | Value |
|---|---|
| Document ID | [ALR-2026-001] |
| AI feature or product | [Name, version or commit] |
| Model(s) | [Provider, model, snapshot or version] |
| Launch tier | [Tier 1 / Tier 2 / Tier 3, see section 2] |
| Target launch date | YYYY-MM-DD |
| Markets and user groups | [Regions, languages, customer segments] |
| Version | [0.1] |
| Status | [Draft / In review / Go / Go with conditions / No-go / Launched / Post-launch reviewed] |
| Owner (decision owner) | [@product-director] |
| Approvers/reviewers | [@responsible-ai-lead], [@security-lead], [@privacy-lead], [@legal], [@sre-lead], [@support-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Related documents | [Use case intake], [AI risk assessment], [Evaluation plan], [Red team report], [System card], [Service readiness review], [Launch checklist] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Decision owner | [@name] | [Go / Go with conditions / No-go] | YYYY-MM-DD |
| Responsible AI or safety lead | [@name] | [Concur / Object] | YYYY-MM-DD |
| Security lead | [@name] | [Concur / Object] | YYYY-MM-DD |
| Privacy lead or DPO | [@name] | [Concur / Object] | YYYY-MM-DD |
| Legal counsel | [@name] | [Concur / Object] | YYYY-MM-DD |

### Revision history

<!-- Guidance: Record changes to scope, tier, gate status and the decision. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Review opened |
| 0.5 | YYYY-MM-DD | [@name] | *Example:* Gate G-04 failed; launch date moved two weeks |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Go with conditions recorded |

## Contents

<!-- Guidance: Keep aligned with the headings below. -->

1. [Launch scope](#1-launch-scope)
2. [Launch tier](#2-launch-tier)
3. [Gate checklist](#3-gate-checklist)
4. [Evaluation results against thresholds](#4-evaluation-results-against-thresholds)
5. [Red team findings](#5-red-team-findings)
6. [Regulatory and transparency checks](#6-regulatory-and-transparency-checks)
7. [Exceptions and conditions](#7-exceptions-and-conditions)
8. [Go/no-go decision record](#8-gono-go-decision-record)
9. [Post-launch review](#9-post-launch-review)
10. [Glossary and references](#10-glossary-and-references)

## 1. Launch scope

<!-- Guidance: Define exactly what ships: capabilities, users, markets, channels and limits. A vague scope makes every gate ambiguous. Pitfall: approving "the assistant" and then shipping new tools or a new model under the same approval. -->

### 1.1 What is launching

| Item | Value |
|---|---|
| Description | *Example:* An AI assistant in the customer portal that answers billing questions from the knowledge base and can create a refund request for a human agent to approve |
| Capabilities in scope | *Example:* Answer questions, summarise account history, draft refund requests |
| Capabilities out of scope | *Example:* Approve refunds, change account details, give legal or tax advice |
| Tools and actions | *Example:* Read-only billing API; create-draft refund API |
| Users | *Example:* Logged-in consumer customers, 18 and over |
| Markets and languages | *Example:* EU and UK, English, French, German |
| Channels | *Example:* Web portal and mobile app |
| Rollout plan | *Example:* 5% of users for two weeks, then 25%, then 100% |
| Change from previous release | *Example:* First launch |

### 1.2 Release stages

Each stage has its own gate. Expansion to the next stage needs the
stage gate criteria in section 8 to hold for the whole stage period;
a breach sends the release back to hold or rollback.

```mermaid
flowchart LR
  A["Internal dogfood"] --> B["Limited preview 5%"]
  B --> C{"Stage gate: metrics within limits?"}
  C -->|Yes| D["25% rollout"]
  C -->|No| R["Roll back or hold"]
  D --> E{"Stage gate"}
  E -->|Yes| F["General availability"]
  E -->|No| R
  F --> G["Post-launch review"]
```

## 2. Launch tier

<!-- Guidance: Tier by impact, autonomy, audience and regulatory exposure. The tier decides which gates are mandatory and who decides. Align it with the risk tier from the use case intake. -->

| Tier | Criteria (any one) | Mandatory gates | Decision owner |
|---|---|---|---|
| Tier 1, High *(Example)* | High-risk under the AI Act or similar law; actions with financial, legal or safety effect; vulnerable users; new frontier model | All gates; external red team; executive sign-off | Executive sponsor with responsible AI board |
| Tier 2, Medium *(Example)* | Customer-facing generative output; personal data; tool use limited to drafts | All gates except external red team | Product director |
| Tier 3, Low *(Example)* | Internal tool, no personal data, no actions | G-01, G-02, G-05, G-06, G-11, G-12 | Engineering manager |

Tier assigned: [*Example:* Tier 2, because the assistant is
customer-facing, uses account data and drafts refund requests; no
autonomous financial action.]

## 3. Gate checklist

<!-- Guidance: One row per gate. Status values: Pass, Pass with condition, Fail, Not applicable (with reason). Every Fail blocks launch unless an exception is approved in section 7. -->

| Gate | Area | Criterion | Owner | Status | Evidence |
|---|---|---|---|---|---|
| G-01 *(Example)* | Product | Scope, users and success metrics agreed; use case intake approved | [@product-lead] | Pass | Intake AI-UC-2026-031 |
| G-02 *(Example)* | Evaluation | All launch-blocking metrics meet thresholds (section 4) | [@ml-lead] | Pass with condition | Eval report EV-12 |
| G-03 *(Example)* | Red team | No open critical or high findings; medium findings have owners and dates (section 5) | [@red-team-lead] | Pass | RT-2026-007 |
| G-04 *(Example)* | Safety and guardrails | Input and output guardrails configured and tested; refusal behaviour matches policy | [@safety-lead] | Pass | Guardrails spec GR-004 |
| G-05 *(Example)* | Privacy | DPIA completed or screened out; data minimisation, retention and processor terms confirmed | [@privacy-lead] | Pass | DPIA-019 |
| G-06 *(Example)* | Security | Threat model reviewed; prompt injection and tool abuse controls tested; secrets and access reviewed | [@security-lead] | Pass | TM-022 |
| G-07 *(Example)* | Transparency | AI interaction notice and content marking in place where required (section 6) | [@product-lead] | Pass | Transparency plan TRN-001 |
| G-08 *(Example)* | Legal and regulatory | Applicability register checked for this scope; obligations due by launch met | [@legal] | Pass | AIREG-001 rows EU-003, KR-001 |
| G-09 *(Example)* | Human oversight | Human approval for refund drafts; escalation to human agent available in every conversation | [@ops-lead] | Pass | Oversight design HO-003 |
| G-10 *(Example)* | Monitoring | Quality, safety and cost dashboards live; alerts with thresholds and owners | [@sre-lead] | Pass | Dashboard links |
| G-11 *(Example)* | Incident response | AI incident runbook, severity matrix and on-call rota cover this feature; serious incident reporting routes known | [@sre-lead] | Pass | Runbook RB-AI-02 |
| G-12 *(Example)* | Rollback | Kill switch and model version rollback tested in staging within the last 14 days | [@sre-lead] | Pass | Drill record |
| G-13 *(Example)* | Documentation | System card and model card (or provider card) published internally; user-facing help updated | [@tech-writer] | Pass | System card SC-011 |
| G-14 *(Example)* | Accessibility | Conversation UI meets WCAG 2.2 AA; screen reader test passed | [@accessibility-lead] | Pass | A11y report |
| G-15 *(Example)* | Support readiness | Support agents trained; macros and escalation paths for AI errors ready | [@support-lead] | Pass | Training log |
| G-16 *(Example)* | Service readiness | `dev/service-readiness` review passed for the serving stack | [@sre-lead] | Pass | PRR-044 |
| G-17 *(Example)* | Cross-functional launch | `product/launch-checklist` tasks complete for marketing, sales and partners | [@pm] | Pass | Launch checklist |
| G-18 *(Example)* | Vendor | Model and tool vendors assessed; contract terms on data use and incidents in place | [@procurement] | Pass | Vendor questionnaire VRQ-009 |

## 4. Evaluation results against thresholds

<!-- Guidance: List the launch-blocking metrics from the evaluation plan, the threshold set in advance, the result and the confidence. Include subgroup and language breakdowns where performance may differ. Pitfall: reporting the average and hiding a failing language. -->

| Metric ID | Metric | Threshold (set before testing) | Result | Sample | Pass? |
|---|---|---|---|---|---|
| EVM-001 *(Example)* | Answer correctness on billing golden set | At least 92% | 94.1% | 1,200 questions | Yes |
| EVM-002 *(Example)* | Correctness in German | At least 90% | 88.7% | 400 questions | No: condition C-01 |
| EVM-003 *(Example)* | Groundedness (claims supported by retrieved sources) | At least 97% | 98.3% | 1,200 | Yes |
| EVM-004 *(Example)* | Harmful content rate on adversarial set | At most 0.5% | 0.2% | 2,000 | Yes |
| EVM-005 *(Example)* | Correct refusal on out-of-scope requests (legal or tax advice) | At least 95% | 96.4% | 500 | Yes |
| EVM-006 *(Example)* | Tool-call accuracy for refund draft creation | At least 98% | 98.9% | 600 trajectories | Yes |
| EVM-007 *(Example)* | Personal data leakage across accounts | 0 cases | 0 | 300 probes | Yes |
| EVM-008 *(Example)* | p95 latency | At most 4 s | 3.1 s | Load test | Yes |
| EVM-009 *(Example)* | Cost per conversation | At most [amount] | [amount] | Pilot | Yes |

Evaluation plan reference: [`ai-data/llm-evaluation-plan` or
`ai-data/agent-evaluation-plan` document ID]. Model version tested:
[version]; must match the version in section 1.1.

## 5. Red team findings

<!-- Guidance: Summarise the red team report. Critical and high findings must be fixed and retested before launch, or carried as an approved exception with compensating controls. -->

| Finding ID | Severity | Summary | Status | Retest | Owner |
|---|---|---|---|---|---|
| RT-007-F01 *(Example)* | High | Indirect prompt injection via a knowledge base article caused a refund draft for another account | Fixed: account binding enforced in tool layer | Passed YYYY-MM-DD | [@security-lead] |
| RT-007-F02 *(Example)* | Medium | System prompt partially disclosed under role-play | Mitigated: output filter; residual risk accepted | Passed | [@safety-lead] |
| RT-007-F03 *(Example)* | Low | Assistant over-apologises and promises refunds informally | Open: prompt update planned | Planned YYYY-MM-DD | [@product-lead] |

Summary: [*Example:* 23 findings: 0 critical, 1 high (fixed), 6 medium
(4 fixed, 2 accepted), 16 low (backlog). Coverage across OWASP LLM and
agentic categories recorded in the red team report.]

## 6. Regulatory and transparency checks

<!-- Guidance: Confirm the obligations that must be met by launch for this exact scope, using the applicability register. For the EU, Article 50 transparency obligations apply from 2 August 2026 (machine-readable marking for generative systems already on the market before then from 2 December 2026 under Article 111(4)). Check high-risk classification even if the answer is no. -->

### 6.1 Register check

| Register row | Obligation | Due | Met at launch? | Evidence |
|---|---|---|---|---|
| EU-003 *(Example)* | Inform users they interact with AI (Art. 50(1)) | 2 August 2026 | Yes | Screenshot of disclosure |
| EU-004 *(Example)* | Machine-readable marking of synthetic content (Art. 50(2)) | 2 August 2026 | n/a: text answers in chat; exported PDFs carry metadata | Transparency plan |
| EU-HR *(Example)* | High-risk classification check (Art. 6, Annex III) | Before launch | Not high-risk: no creditworthiness or essential service eligibility decision | Intake section 6 |
| GDPR *(Example)* | DPIA where processing is likely high risk (Art. 35) | Before processing | Yes | DPIA-019 |
| KR-001 *(Example)* | Advance notice of AI use (Korea) | In force | n/a: not offered in Korea | Scope |

### 6.2 Notices shipped

| Notice | Where | Wording reference | Languages | Accessible? |
|---|---|---|---|---|
| AI interaction notice *(Example)* | Chat header and first message | LBL-001 | EN, FR, DE | Yes |
| Limitations notice *(Example)* | Help page and footer link | HELP-AI-01 | EN, FR, DE | Yes |
| Privacy notice update *(Example)* | Privacy policy section 7 | PN-2026-03 | EN, FR, DE | Yes |

## 7. Exceptions and conditions

<!-- Guidance: An exception lets launch proceed despite a failed or incomplete gate. Each needs a reason, compensating controls, an owner, an expiry date and an approver at the level the tier requires. Conditions are commitments attached to a go decision. -->

| ID | Type | Gate | Description | Compensating control | Owner | Due or expiry | Approved by |
|---|---|---|---|---|---|---|---|
| C-01 *(Example)* | Condition | G-02 | German correctness below threshold | Launch German at 5% only; human review of a 10% sample; fix before 25% stage | [@ml-lead] | YYYY-MM-DD | [@product-director] |
| X-01 *(Example)* | Exception | G-03 | RT-007-F02 residual risk accepted | Output filter plus monitoring alert on prompt-like strings | [@safety-lead] | Review at post-launch | [@responsible-ai-lead] |

Rejected exception requests: [*Example:* request to skip the rollback
drill (G-12) was rejected; launch moved by three days.]

## 8. Go/no-go decision record

<!-- Guidance: Record who attended, what was decided and why, with dissent. A Go with conditions lists the conditions by ID. Pitfall: a decision taken in a chat thread with no record. -->

| Item | Value |
|---|---|
| Meeting date | YYYY-MM-DD |
| Attendees | [@product-director], [@responsible-ai-lead], [@security-lead], [@privacy-lead], [@legal], [@sre-lead], [@support-lead] |
| Gates passed | *Example:* 17 of 18 pass; G-02 pass with condition |
| Decision | [Go / Go with conditions / No-go] |
| Conditions | *Example:* C-01 |
| Exceptions | *Example:* X-01 |
| Dissent recorded | [*Example:* none / names and reasons] |
| Rollout start | YYYY-MM-DD |
| Stage gate criteria | *Example:* harmful content rate below 0.5%, escalation rate below 15%, no severity 1 or 2 AI incident |
| Post-launch review date | YYYY-MM-DD (for example 30 days after general availability) |
| Decision owner signature | [@name], YYYY-MM-DD |

```mermaid
stateDiagram-v2
  [*] --> InReview
  InReview --> NoGo: blocking gate failed
  InReview --> Go: all gates pass
  InReview --> GoWithConditions: conditions approved
  NoGo --> InReview: fixes made, new version
  Go --> Launched
  GoWithConditions --> Launched
  Launched --> RolledBack: stage gate breached
  RolledBack --> InReview
  Launched --> PostLaunchReviewed
  PostLaunchReviewed --> [*]
```

## 9. Post-launch review

<!-- Guidance: Compare what happened with the evaluation and the stage gate criteria. Close or extend conditions and exceptions. Feed findings into post-market monitoring and the next evaluation set. -->

### 9.1 Results

| Measure | Expected | Observed | Comment |
|---|---|---|---|
| Correctness (sampled human rating) *(Example)* | At least 92% | 91.5% | German improved after fix; French drift noted |
| Escalation to human agent *(Example)* | Below 15% | 12% | Within range |
| AI incidents *(Example)* | None of severity 1 or 2 | One severity 3 (wrong fee explanation) | INC-AI-014 closed |
| User complaints mentioning the assistant *(Example)* | Below [n] per week | [n] | |
| Cost per conversation *(Example)* | At most [amount] | [amount] | |

### 9.2 Conditions and exceptions status

| ID | Status | Evidence | Next step |
|---|---|---|---|
| C-01 *(Example)* | Closed: German correctness 92.4% | Eval run EV-15 | None |
| X-01 *(Example)* | Extended 90 days | Alert history | Replace with structural fix |

### 9.3 Lessons and follow-ups

[*Example:* Add French drift cases to the golden set; move the
rollback drill to an automated weekly job; feed the severity 3
incident into the post-market monitoring plan.]

## 10. Glossary and references

<!-- Guidance: Define the terms used in gates and list the documents this review relies on. -->

| Term | Meaning |
|---|---|
| Gate | A criterion that must be met, or formally excepted, before launch |
| Launch tier | Classification that sets mandatory gates and decision level |
| Condition | A commitment attached to a go decision with an owner and due date |
| Exception | Approved deviation from a gate with compensating controls and expiry |
| Golden set | Fixed, versioned evaluation dataset with reference answers |
| Kill switch | Control that disables the AI feature quickly without a deployment |

References:

- Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744,
  Articles 6, 26, 50 and Annex III (consolidated text).
- Regulation (EU) 2016/679 (GDPR), Article 35.
- WCAG 2.2 (W3C Recommendation).
- Related templates: `ai-data/ai-use-case-intake`,
  `ai-data/ai-risk-assessment`, `ai-data/llm-evaluation-plan`,
  `ai-data/agent-evaluation-plan`, `ai-data/ai-red-team`,
  `ai-data/guardrails-spec`, `ai-data/ai-content-transparency-plan`,
  `compliance/ai-regulatory-applicability-register`,
  `ai-data/ai-system-card`, `ai-data/model-card`,
  `ai-data/ai-post-market-monitoring`, `ai-data/ai-incident-report`,
  `dev/service-readiness`, `product/launch-checklist`.

## Standard and licence note

Based on common launch-gate practice for AI systems, with legal checks
based on Regulation (EU) 2024/1689 (the Artificial Intelligence Act)
as amended by Regulation (EU) 2026/1744 (Articles 6, 50 and Annex III)
and Regulation (EU) 2016/679, Article 35. The text is original; no
legislative or standard text is reproduced, and the thresholds shown
are examples, not regulatory values. Check the consolidated texts on
EUR-Lex and your applicability register for current obligations and
dates. This is a documentation format, not legal advice. Template
licence: MIT.