AI Opportunity Canvas Template

AI problem framing: is AI needed, value hypothesis, data availability, feasibility, risk tier preview, success metrics, non-AI alternatives, go/no-go

IA & DonnéesCompletIndustry practice; PAIR People + AI Guidebook; EU AI Act screening (Art. 5, 6, 50)opportunity canvasMis à jour 22 oct. 2026

Ouvrir dans l'éditeurTélécharger .md

Mode d'emploi: Use it when an AI idea first appears, before the AI Use Case Intake or any PRD. Fill the problem statement and the 'Is AI needed' questions first, then the non-AI alternatives. The main pitfall is treating model capability as value instead of a measurable change in a user outcome.

Aperçu

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.

Document control

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

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

Canvas at a glance
Problem and users
Is AI needed
Value hypothesis
Data availability
Feasibility
Risk tier preview
Success metrics
Alternatives without AI
Assumptions and experiments
Go / no-go decision
Glossary and references

1. Canvas at a glance

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

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

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

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

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

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

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

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

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

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

11. Go / no-go decision

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

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.

Modèles associés

IA & Données