# AI Opportunity Canvas: [Opportunity name]

> Problem-framing canvas for a proposed AI opportunity, filled before any
> intake, PRD or build. It asks whether AI is needed at all, what value it
> creates and for whom, whether the data exists, whether the idea is
> feasible, which regulatory risk tier it is likely to fall in, how success
> will be measured, which non-AI alternatives exist, and ends with a
> go / no-go decision. Based on common industry practice for AI product
> discovery, informed by the Google PAIR People + AI Guidebook and the
> screening questions of the EU AI Act (Regulation (EU) 2024/1689, as
> amended). Replace every `[bracketed]` value and every row marked
> *Example*. This is a documentation format, not legal advice.

<!--
Guidance: How to use this template
- Use this canvas upstream of the AI Use Case Intake (`ai-data/ai-use-case-intake`).
  The canvas decides whether an idea deserves an intake; the intake records
  the formal risk tiering and the required reviews.
- Fill section 1 (problem) and section 3 (is AI needed) before anything
  else. If the problem cannot be stated without the word "AI", stop and
  rewrite it.
- Keep it short and honest: one canvas per opportunity, 60 to 90 minutes
  in a workshop with product, engineering, data and a risk partner.
- Section 9 (alternatives without AI) is mandatory. A canvas without a
  credible non-AI baseline cannot reach "Go".
- Common pitfall: treating model capability as the value. Value is a
  change in a user outcome or a business metric, not "uses an LLM".
-->

## Document control

<!-- Guidance: Identify the opportunity, the sponsor who will fund discovery, and the decision forum that will read the canvas. -->

| Field | Value |
|---|---|
| Document ID | [AIOPP-001] |
| Opportunity name | [Opportunity name] |
| Version | [0.1] |
| Status | [Draft / In review / Decided] |
| Owner | [@product-owner] |
| Approvers / reviewers | [@sponsor], [@ml-lead], [@risk-partner] |
| Business unit | [Unit] |
| Decision forum | [*Example:* AI portfolio review, monthly] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Related documents | AI Use Case Intake (`ai-data/ai-use-case-intake`), AI Feature PRD (`ai-data/ai-feature-prd`) |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Sponsor | [@name] | [Go / Go with conditions / Park / No-go] | YYYY-MM-DD |
| Product lead | [@name] | [Decision] | YYYY-MM-DD |
| ML or data lead | [@name] | [Decision] | YYYY-MM-DD |
| Risk or AI governance partner | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record each workshop and each change in the decision. A canvas that changes from No-go to Go needs a written reason. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft from discovery workshop |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Added data audit results and non-AI baseline |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Decision recorded: Go with conditions |

## Contents

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

1. [Canvas at a glance](#1-canvas-at-a-glance)
2. [Problem and users](#2-problem-and-users)
3. [Is AI needed](#3-is-ai-needed)
4. [Value hypothesis](#4-value-hypothesis)
5. [Data availability](#5-data-availability)
6. [Feasibility](#6-feasibility)
7. [Risk tier preview](#7-risk-tier-preview)
8. [Success metrics](#8-success-metrics)
9. [Alternatives without AI](#9-alternatives-without-ai)
10. [Assumptions and experiments](#10-assumptions-and-experiments)
11. [Go / no-go decision](#11-go--no-go-decision)
12. [Glossary and references](#12-glossary-and-references)

## 1. Canvas at a glance

<!-- Guidance: Fill this one-page summary last, after every other section. Readers of the portfolio review often read only this table. -->

| Block | Summary |
|---|---|
| Problem | [One sentence] *Example:* Support agents spend 6 minutes per ticket searching three knowledge bases for the right policy. |
| Users | [Primary user] *Example:* Tier-1 support agents (about 220 people) |
| Proposed AI capability | [Capability] *Example:* Retrieve and summarise the relevant policy with citations inside the ticket view |
| Why AI | [Reason] *Example:* Questions are phrased freely; keyword search misses 38% of relevant articles in a sample of 200 tickets |
| Value | [Metric and size] *Example:* Cut median handling time by 1.5 minutes per ticket |
| Data | [Readiness] *Example:* Knowledge base available and current; 18 months of resolved tickets with labels |
| Feasibility | [Rating] *Example:* High: retrieval plus summarisation is a proven pattern |
| Risk tier preview | [Tier] *Example:* Internal tier 2; no Annex III area; transparency notice to agents |
| Best non-AI alternative | [Alternative] *Example:* Curated decision tree for the top 30 ticket types |
| Recommendation | [Go / Go with conditions / Park / No-go] |

## 2. Problem and users

<!-- Guidance: State the problem in user terms and size it with evidence. Questions: who has the problem, how often, what does it cost them today? Pitfall: describing a solution ("we need a chatbot") instead of a problem. -->

### 2.1 Problem statement

[Describe the problem without naming a technology. State who is affected,
in which situation, and what goes wrong.]

*Example:* When a customer asks about a refund exception, tier-1 agents
must find the right policy across three knowledge bases that use
different terms. They often escalate instead, which adds a day to the
resolution time and costs the tier-2 team about 900 hours per month.

### 2.2 Evidence

| ID | Evidence | Source | Strength |
|---|---|---|---|
| AIOPP-EV-001 *(Example)* | Median 6.1 minutes of search per ticket in a time-and-motion study of 40 agents | Operations study, YYYY-MM | Strong |
| AIOPP-EV-002 *(Example)* | 27% of escalations closed by tier 2 with a link to an existing article | Ticket analysis, 3 months | Strong |
| AIOPP-EV-003 *(Example)* | Agents rate knowledge search 2.1 out of 5 in the annual tooling survey | Survey | Medium |
| [ID] | [Evidence] | [Source] | [Strong / Medium / Weak] |

### 2.3 Users and stakeholders

| Group | Role in the opportunity | Size | Affected how |
|---|---|---|---|
| *Example:* Tier-1 agents | Primary users | 220 | Use the capability daily |
| *Example:* Customers | Indirectly affected | 40,000 tickets per month | Receive answers based on the output |
| *Example:* Knowledge managers | Data owners | 6 | Must keep articles current |
| [Group] | [Role] | [Size] | [Effect] |

### 2.4 Jobs to be done

List the user jobs in the form "When [situation], I want to [motivation],
so I can [outcome]".

- *Example:* When a customer asks for an exception, I want to see the
  policy that applies to their plan, so I can answer without escalating.
- [Job statement]

## 3. Is AI needed

<!-- Guidance: Answer each question honestly. AI is justified when the task needs judgement over varied inputs, the rules cannot be written down, and errors can be tolerated or caught. Pitfall: choosing AI because it is fashionable or because budget is tied to it. -->

| ID | Question | Answer | Notes |
|---|---|---|---|
| AIOPP-Q-001 | Can the task be solved with fixed rules, a lookup or a better search index? | [Yes / Partly / No] | *Example:* Partly: the top 30 ticket types fit a decision tree |
| AIOPP-Q-002 | Do inputs vary so much that rules break (free text, images, speech)? | [Yes / No] | *Example:* Yes: customers describe the same issue in many ways |
| AIOPP-Q-003 | Is a probabilistic answer acceptable, with some error rate? | [Yes / No] | *Example:* Yes, if the agent reviews before sending |
| AIOPP-Q-004 | Can errors be detected and corrected before harm occurs? | [Yes / No] | *Example:* Yes: agent is the human checkpoint |
| AIOPP-Q-005 | Does the task benefit from personalisation or adaptation over time? | [Yes / No] | [Notes] |
| AIOPP-Q-006 | Is predictability or exact repeatability more valuable than flexibility here? | [Yes / No] | *Example:* No for drafting, yes for refund amounts |
| AIOPP-Q-007 | Would users trust and accept an AI-generated output in this context? | [Yes / No / Unknown] | [Research reference] |

**Verdict:** [AI is needed / AI helps for part of the task / AI is not
needed]. *Example:* AI helps for the long tail of ticket types; the top 30
types are better served by a decision tree.

Automation versus augmentation: state whether the AI performs the task
for the user (automation) or helps the user perform it (augmentation).
Augmentation is the safer default when users value control, take
responsibility for the outcome, or enjoy the task. Record the choice and
the reason.

| Mode | Chosen | Reason |
|---|---|---|
| Automation | [ ] | [Reason] |
| Augmentation | [x] | *Example:* Agents remain accountable for what they send to customers |

## 4. Value hypothesis

<!-- Guidance: Write the hypothesis so it can be proven wrong. Size the value with a simple, visible calculation. Pitfall: counting time saved without asking whether the saved time turns into a business outcome. -->

**Hypothesis:** We believe that [capability] for [users] will result in
[measurable change]. We will know this is true when [metric] moves from
[baseline] to [target] within [period].

*Example:* We believe that cited policy summaries inside the ticket view
for tier-1 agents will cut median handling time on policy tickets. We
will know this is true when median handling time on those tickets falls
from 11.0 to 9.5 minutes within 8 weeks of rollout to the pilot group.

### 4.1 Value sizing

| Driver | Value | Basis |
|---|---|---|
| Policy tickets per month *(Example)* | 18,000 | Ticket system, last 6 months |
| Minutes saved per ticket *(Example)* | 1.5 | Pilot target |
| Hours saved per month *(Example)* | 450 | 18,000 x 1.5 / 60 |
| Escalations avoided per month *(Example)* | 1,200 | 27% of about 4,450 escalations per month |
| Annual value estimate *(Example)* | USD 310,000 | Loaded cost of USD 40 per hour x (5,400 agent hours + about 2,350 tier-2 hours avoided per year) |

### 4.2 Value types

| Value type | Applies | Description |
|---|---|---|
| Efficiency (time, cost) | [ ] | [Description] |
| Quality (accuracy, consistency) | [ ] | [Description] |
| Experience (satisfaction, effort) | [ ] | [Description] |
| Revenue (conversion, retention) | [ ] | [Description] |
| Risk reduction (fewer errors, fraud) | [ ] | [Description] |
| New capability (not possible before) | [ ] | [Description] |

## 5. Data availability

<!-- Guidance: Data decides feasibility more often than models do. Check that data exists, is legally usable for this purpose, is representative, and can be kept current. Pitfall: assuming historical data is labelled correctly or can be reused for a new purpose without a legal basis. -->

| ID | Data asset | Owner | Volume and freshness | Labels or ground truth | Legal basis for this use | Quality concerns |
|---|---|---|---|---|---|---|
| AIOPP-DATA-001 *(Example)* | Knowledge base articles | Knowledge team | 2,400 articles; updated weekly | Not needed for retrieval | Internal content | 12% of articles older than 2 years |
| AIOPP-DATA-002 *(Example)* | Resolved tickets | Support ops | 1.1 million; 18 months | Resolution code by agent | Legitimate interest; check privacy notice | Codes applied inconsistently |
| [ID] | [Asset] | [@owner] | [Volume] | [Labels] | [Basis] | [Concerns] |

Answer these questions in a sentence each:

- **Does an evaluation set exist, or who will build one?** [Answer]
  *Example:* None yet; two senior agents will label 300 tickets with the
  correct article in two weeks.
- **Does the data contain personal or sensitive data?** [Answer]
- **Is the data representative of all user groups and languages in
  scope?** [Answer]
- **Can the data be kept current after launch, and who owns that?**
  [Answer]
- **Are there contractual or licence limits on using this data with an
  external model provider?** [Answer]

Record data readiness as one of: Ready, Ready with work (state the work),
Not ready (state the gap). Readiness: [Rating].

## 6. Feasibility

<!-- Guidance: Rate feasibility in four dimensions. Use a spike or a one-week prototype to replace opinion with evidence when a rating is uncertain. Pitfall: rating technical feasibility from a demo on hand-picked examples. -->

| Dimension | Rating | Evidence | Main unknown |
|---|---|---|---|
| Technical (can a model do it well enough) | [High / Medium / Low] | *Example:* Prototype answered 41 of 50 sample tickets correctly | Accuracy on rare policies |
| Data (section 5) | [Rating] | [Evidence] | [Unknown] |
| Operational (can we run, monitor and support it) | [Rating] | *Example:* Platform team already runs a retrieval service | On-call coverage |
| Economic (cost per use against value) | [Rating] | *Example:* Estimated USD 0.004 per query at 2,500 queries per day | Token growth with long tickets |
| Organisational (skills, change management, adoption) | [Rating] | [Evidence] | [Unknown] |

### 6.1 Rough cost envelope

| Cost item | Estimate | Basis |
|---|---|---|
| Discovery and prototype *(Example)* | 6 person-weeks | Two engineers, three weeks |
| Build to pilot *(Example)* | 14 person-weeks | Retrieval, UI, evaluation harness |
| Inference per month at full rollout *(Example)* | USD 300 | 2,500 queries per day x 30 days x USD 0.004 (about 4 queries per policy ticket) |
| Ongoing ownership *(Example)* | 0.5 FTE | Evaluation, content freshness, incidents |

## 7. Risk tier preview

<!-- Guidance: This is a preview, not the formal tiering. It flags whether the opportunity needs the AI Use Case Intake, a fundamental rights or impact assessment, or legal review before the next stage. Pitfall: deciding the tier from the technology instead of from the use and the people affected. -->

Answer each screening question. Any "Yes" or "Unsure" means the
opportunity must go through the AI Use Case Intake
(`ai-data/ai-use-case-intake`) before build.

| ID | Screening question | Answer | Reference |
|---|---|---|---|
| AIOPP-RISK-001 | Could the use fall under a prohibited practice (for example manipulation that causes significant harm, social scoring, or untargeted scraping of facial images)? | [Yes / No / Unsure] | EU AI Act Article 5 |
| AIOPP-RISK-002 | Is the use in a high-risk area such as employment, education, access to essential services, credit, law enforcement, migration or critical infrastructure? | [Yes / No / Unsure] | EU AI Act Article 6 and Annex III |
| AIOPP-RISK-003 | Is the AI a safety component of a regulated product (for example a medical device or machinery)? | [Yes / No / Unsure] | EU AI Act Article 6(1) and Annex I |
| AIOPP-RISK-004 | Will people interact with the system directly, or will it generate or alter content they see? | [Yes / No] | EU AI Act Article 50 transparency duties |
| AIOPP-RISK-005 | Does the output inform a decision with legal or similarly significant effect on a person? | [Yes / No / Unsure] | GDPR Article 22 and internal policy |
| AIOPP-RISK-006 | Will personal data, special category data or children's data be processed? | [Yes / No] | Privacy review |
| AIOPP-RISK-007 | Can the AI take actions in other systems without a human approving each one? | [Yes / No] | Agent controls (`ai-data/agentic-threat-model`) |

**Preliminary internal tier:** [Tier 1 low / Tier 2 medium / Tier 3 high
/ Prohibited]. *Example:* Tier 2: internal augmentation, human reviews
every output, customer-facing text flows through an agent.

Application dates of the EU AI Act differ by obligation and were changed
by amending legislation. Check the consolidated text on EUR-Lex before
relying on any date.

## 8. Success metrics

<!-- Guidance: Define one primary outcome metric, the model quality metrics that support it, and guardrail metrics that must not get worse. Set targets before the pilot. Pitfall: measuring only model accuracy and calling the product a success. -->

| ID | Metric | Type | Baseline | Target | Measured how |
|---|---|---|---|---|---|
| AIOPP-MET-001 *(Example)* | Median handling time on policy tickets | Primary outcome | 11.0 min | 9.5 min | Ticket system, pilot vs control group |
| AIOPP-MET-002 *(Example)* | Correct article in top 3 results | Model quality | Keyword search: 62% | 85% | Labelled evaluation set of 300 tickets |
| AIOPP-MET-003 *(Example)* | Summary faithful to cited article | Model quality | Not applicable | 95% | Human review of 200 samples |
| AIOPP-MET-004 *(Example)* | Customer satisfaction on policy tickets | Guardrail | 4.3 / 5 | No drop beyond 0.1 | Post-ticket survey |
| AIOPP-MET-005 *(Example)* | Wrong-policy answers sent to customers | Guardrail | 1.8% | No increase | QA sampling |
| [ID] | [Metric] | [Type] | [Baseline] | [Target] | [Method] |

**Kill criteria:** state the result that would stop the opportunity.
*Example:* Stop if, after 8 weeks, handling time falls by less than 0.5
minutes or wrong-policy answers rise above 2.5%.

## 9. Alternatives without AI

<!-- Guidance: Describe at least two serious non-AI options and compare them on the same criteria as the AI option. Pitfall: listing "do nothing" as the only alternative. -->

| ID | Option | Expected effect | Cost | Time to value | Risk | Verdict |
|---|---|---|---|---|---|---|
| AIOPP-ALT-001 *(Example)* | Do nothing | No change | None | Not applicable | Escalation cost continues | Reject |
| AIOPP-ALT-002 *(Example)* | Merge the three knowledge bases and fix taxonomy | Search hit rate up to an estimated 75% | 10 person-weeks | 3 months | Low | Do in parallel |
| AIOPP-ALT-003 *(Example)* | Decision tree for the top 30 ticket types | Covers 55% of policy tickets | 4 person-weeks | 6 weeks | Low; needs upkeep | Do first |
| AIOPP-ALT-004 *(Example)* | AI retrieval and summarisation | Covers long tail | 20 person-weeks plus run cost | 4 months | Medium | Pilot after ALT-003 |
| [ID] | [Option] | [Effect] | [Cost] | [Time] | [Risk] | [Verdict] |

Explain in two to four sentences why the chosen option beats the best
non-AI option, or why they should be combined.

*Example:* The decision tree handles common cases cheaply and
predictably, so build it first. The AI option is justified only for the
remaining 45% of policy tickets, where questions vary too much for rules.
The pilot target in section 8 applies to that long tail.

## 10. Assumptions and experiments

<!-- Guidance: List the riskiest assumptions in order and the cheapest test for each. Pitfall: running a full build to test an assumption a one-day study could answer. -->

| ID | Assumption | Risk if wrong | Test | Success signal | Owner | Due |
|---|---|---|---|---|---|---|
| AIOPP-ASM-001 *(Example)* | Agents will read a summary rather than open the full article | Value does not appear | Wizard-of-Oz test with 8 agents | 6 of 8 act on the summary | [@ux-researcher] | YYYY-MM-DD |
| AIOPP-ASM-002 *(Example)* | Retrieval reaches 85% top-3 accuracy on rare policies | Wrong answers | Offline evaluation on 300 labelled tickets | At least 85% | [@ml-engineer] | YYYY-MM-DD |
| AIOPP-ASM-003 *(Example)* | Knowledge articles can be kept current | Stale answers | Audit of update process with knowledge team | Named owner and weekly review | [@product-owner] | YYYY-MM-DD |
| [ID] | [Assumption] | [Risk] | [Test] | [Signal] | [@owner] | YYYY-MM-DD |

```mermaid
flowchart LR
  A[Idea] --> B{Problem stated<br/>without AI?}
  B -- No --> X[Rewrite problem]
  B -- Yes --> C{AI needed?<br/>section 3}
  C -- No --> N[Pursue non-AI option]
  C -- Yes or partly --> D{Data ready?<br/>section 5}
  D -- No --> P[Park until data exists]
  D -- Yes --> E{Risk preview<br/>section 7}
  E -- Prohibited --> S[Stop]
  E -- Flags --> I[AI Use Case Intake]
  E -- Low --> F[Go decision]
  I --> F
```

## 11. Go / no-go decision

<!-- Guidance: Record the decision, its conditions and the next stage. A "Go with conditions" needs owners and dates for each condition. Pitfall: approving without a kill criterion or a review date. -->

| Criterion | Met | Notes |
|---|---|---|
| Problem is real and sized with evidence (section 2) | [Yes / No] | [Notes] |
| AI is needed for at least part of the task (section 3) | [Yes / No] | [Notes] |
| Value exceeds cost envelope with margin (sections 4 and 6) | [Yes / No] | [Notes] |
| Data is ready or the gap has a plan (section 5) | [Yes / No] | [Notes] |
| No prohibited use; flags routed to intake (section 7) | [Yes / No] | [Notes] |
| Metrics, targets and kill criteria agreed (section 8) | [Yes / No] | [Notes] |
| AI option beats or complements the best non-AI option (section 9) | [Yes / No] | [Notes] |

**Decision:** [Go / Go with conditions / Park / No-go]

**Conditions:**

| ID | Condition | Owner | Due |
|---|---|---|---|
| AIOPP-COND-001 *(Example)* | Complete the AI Use Case Intake before build starts | [@product-owner] | YYYY-MM-DD |
| AIOPP-COND-002 *(Example)* | Ship the decision tree (ALT-003) before the AI pilot | [@support-ops] | YYYY-MM-DD |
| [ID] | [Condition] | [@owner] | YYYY-MM-DD |

**Next stage:** [*Example:* AI Use Case Intake, then AI Feature PRD
(`ai-data/ai-feature-prd`) or Copilot and Agent PRD (`ai-data/copilot-prd`)
if the solution takes actions on behalf of users.]

**Review date:** YYYY-MM-DD

## 12. Glossary and references

<!-- Guidance: Define terms the decision forum may not share and list the documents this canvas relies on. -->

### 12.1 Glossary

| Term | Meaning in this canvas |
|---|---|
| Augmentation | AI helps a person do a task; the person stays in control of the result |
| Automation | AI performs the task without a person producing the result |
| Kill criterion | A pre-agreed result that ends the opportunity |
| Non-AI baseline | The best option that solves the problem without a learned model |
| Risk tier preview | An early, informal estimate of regulatory and internal risk, confirmed later by the intake |
| Wizard-of-Oz test | A test where a person secretly produces the "AI" output to test value before building |

### 12.2 References

- Google PAIR, People + AI Guidebook, chapter "User Needs + Defining
  Success" (living document): https://pair.withgoogle.com/guidebook/
- Regulation (EU) 2024/1689 (Artificial Intelligence Act), Articles 5, 6,
  50 and Annexes I and III, as amended; consolidated text on EUR-Lex:
  https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Related templates: AI Use Case Intake (`ai-data/ai-use-case-intake`), AI
  Feature PRD (`ai-data/ai-feature-prd`), Copilot and Agent PRD
  (`ai-data/copilot-prd`), AI Risk Assessment (`ai-data/ai-risk-assessment`),
  AI Launch Review (`ai-data/ai-launch-review`).

## Standard and licence note

Based on common industry practice for AI product discovery and problem
framing, informed by the Google PAIR People + AI Guidebook (user needs and
the question of whether AI adds unique value) and by the screening
structure of Regulation (EU) 2024/1689, whose articles are referenced by
number and summarised in original words. The text of this canvas is
original. Check the current official version of each source before use,
including the consolidated EU AI Act text, because application dates were
changed by amending legislation. This is a documentation format, not legal
advice. Template licence: MIT.