Key question: Can this problem be solved this way with AI—and should it be?
This AI Value Canvas (AVC) domain contains two connected Canvas elements:
- AI Opportunity Fit tests whether AI is necessary and proportionate to the task.
- Solution Concept / Interaction Flow makes the proposed workflow, human authority, and fallback path concrete.
Start with the user problem and the work that must be done. Do not start with a model, chatbot, or agent. The appropriate outcome may be a process change, a search improvement, a human service, or a decision to stop.
Element: AI Opportunity Fit
Why this?
AI is justified only when it improves a defined task enough to outweigh its added uncertainty, operating burden, and risk. A solution can be technically possible and still be the wrong choice.
Use this test before committing to a solution concept:
- Task variability — Does the task involve ambiguous language, varied documents, changing context, or judgment that fixed rules cannot handle well?
- Outcome difference — What user or business outcome should improve, compared with the current method?
- Decision consequence — What happens if the output is wrong, late, missing, or acted on without review?
- Evidence — What observation, sample of real work, prototype result, or operational record supports the proposed approach?
- Fallback — Can a person or existing process safely complete the work when the system is uncertain or unavailable?
A language-heavy task is not, by itself, a reason to use a large language model (LLM). Choose the simplest approach that can meet the requirement. A spreadsheet, formula, deterministic calculation, bounded LLM call, or retrieval-augmented generation (RAG) may be sufficient. A deterministic calculation applies defined rules and produces the same result for the same inputs. An agentic workflow—an LLM system that dynamically plans or selects among multiple steps and tools—fits only when the steps genuinely vary and the consequences can tolerate its failure modes.
Mandatory Why-AI decision record
Complete this record for every opportunity. It is not optional, and “AI can automate it” is not an answer.
#### 1. Define the decision
Record all of the following in plain language:
- Exact task: the user, moment of work, input, and expected output. Avoid broad labels such as “improve customer service.”
- Linked Customer/User Segments, Jobs to Be Done, and Pains & Gains: name the relevant Canvas records and explain how this task addresses them.
- Affected groups and user/decision consequence: identify the direct user, people affected by the output, and operational groups. State what can happen if the output is wrong, late, missing, or acted on without review, what authority it has, and whether a person must decide or approve.
- Evidence: links or references to the observed workflow, representative inputs, user research, system records, prototype tests, or other material used in the comparison.
- Remaining uncertainty: what is not yet known, how it could change the choice, who will test it, and by when.
#### 2. Compare every option
Assess each row against the exact task. State its fit, limits, evidence, and why it is selected or rejected. “Not considered” is not acceptable; if an option cannot apply, explain why.
| Option | What to test | Decision record prompt |
|---|---|---|
| Process or training | Can clearer ownership, a better hand-off, a template, or training remove the problem? | What process change would be tried first, and what evidence says it is insufficient or sufficient? |
| Rules or search | Is the work deterministic, or can structured search return the needed answer? | Which rules, fields, or search improvements cover the task? Where do they fail? |
| Spreadsheet, formula, or deterministic calculation | Can an auditable calculation, decision table, or spreadsheet produce the required result from defined inputs? | What inputs, logic, owner, and error checks are needed, and where does this approach cease to fit? |
| Simple model | Would a bounded classifier, extractor, ranker, or forecast meet the need? | What is the input, predicted label or score, and review path for errors? |
| Human support | Is a trained person, specialist queue, or service redesign safer or more useful? | What human capability is needed, and what constraint makes this option unsuitable or preferable? |
| Bounded LLM call | Can one constrained prompt transform, classify, extract, summarize, or draft from supplied input? | What input is provided, what output format is required, and what prevents the response from taking actions? |
| Retrieval-augmented generation (RAG) | Does the task require answers grounded in an approved, searchable knowledge source? | Which sources may be retrieved, how will the answer show its sources, and what happens when retrieval is incomplete or conflicting? |
| Agentic workflow | Do the steps, tool choices, or order genuinely vary by task and require coordination? | Why do a fixed workflow, a bounded LLM call, or RAG not meet the task? Which actions remain subject to human authority? |
Record the decision, including the option chosen, the options rejected, the reason, and the condition that would trigger a revisit. Link this record to the named Customer/User Segments, Jobs to Be Done, Pains & Gains, and the relevant assumptions in Data & Model Considerations, Risks & Guardrails, and Value & Metrics of Success.
Worked illustration: a bounded answer draft
Illustrative example — not a performance claim. An HR operations team receives policy questions written in varied language. The exact task is: “Draft a response to an employee’s leave-policy question using the current approved policy, for an HR adviser to review before sending.” A wrong answer could affect an employee’s leave decision, so the draft has no authority and the adviser remains responsible for the sent response. The sent response tells the employee that AI assisted the draft, identifies the relevant policy source and uncertainty, and gives a route to seek correction or escalation.
The team records the following as hypotheses to test against the current human-only process:
- Process and training may improve how advisers find policies; the team tests whether this meets the required response quality and timeliness without creating a reusable first draft.
- Rules and search may locate relevant documents; the team tests whether they can meet the required clarity and contextual accuracy for varied questions.
- A spreadsheet or formula may calculate leave balances from defined fields, but is not expected to interpret varied policy questions; the team confirms this against representative inputs.
- A simple model may classify question type, but the team tests whether classification alone improves the adviser’s work enough to justify its use.
- Human support is the baseline, fallback, and final decision-maker. The team records its current quality, capacity, response time, and the constraint that any proposed solution must improve without weakening review.
- A bounded LLM call with approved policy excerpts is tested for a structured draft with cited source passages.
- RAG is considered if the policy set is too large to supply as input and retrieval quality can be tested.
- An agentic workflow is rejected unless evidence shows that a variable tool sequence is necessary; the proposed task has no independent action.
The remaining uncertainty is whether approved sources are complete, advisers find citations useful, and the bounded draft improves the human-only baseline. The next test uses a versioned, representative set of routine, ambiguous, and outdated-policy questions; a review rubric; and a comparison with the current human-only process. Advisers review every output; the system does not send messages or update employee records.
Element: Solution Concept / Interaction Flow
Why this?
A solution concept is not a feature description. It is a clear account of what starts the work, what the AI does, what the person can see and control, and what happens when the system cannot proceed safely.
Design the interaction before building. This makes intended authority visible and establishes explicit boundaries against unplanned system influence.
Choose an interaction mode explicitly
Choose one mode for each consequential point in the workflow. Augmentation comes first by default: begin with Recommendation or Approval. Move to Alert only when the task, evidence, and guardrails justify limited autonomous action.
| Mode | What the system does | Human authority | Appropriate starting point |
|---|---|---|---|
| Recommendation | Presents a draft, ranking, prediction, or next-best action with relevant context and sources where available. | The person decides and acts. The system does not take the consequential action. | Default for new, uncertain, or high-consequence decisions. |
| Approval | Prepares or stages a proposed action and waits. | An authorized person reviews, edits if needed, and explicitly approves before the action occurs. | Use when the workflow benefits from automation but the action has meaningful consequences. |
| Alert | Takes a narrowly pre-authorized, reversible action or routes a case, then alerts the accountable person. | The person monitors, can intervene, and handles exceptions. | Use only for bounded, low-consequence actions with a tested fallback and clear ownership. |
AVC guardrail: Do not use Alert for decisions or actions affecting employment, credit, insurance, healthcare, essential services, disciplinary action, financial transfers, physical safety, or similarly high-impact decisions. Use Recommendation or Approval, with human review before action.
Illustrative example — not a performance claim. A procurement copilot recommends fields for a purchase request. The requester checks the recommendation and enters it in the procurement system: Recommendation. If the system prepares a purchase order, an authorized buyer must approve before it is issued: Approval. It may route an incomplete request back to the requester and alert the buyer, if routing is reversible and pre-authorized: Alert. It must not change supplier bank details without a separate authorized approval path.
Required workflow template
Document one workflow for the proposed scope. A diagram may accompany it, but it does not replace these fields.
| Workflow field | Record |
|---|---|
| Trigger | What initiates the work: a user request, scheduled event, threshold, or source-system change? |
| Inputs and sources | What data, documents, messages, and systems are used? Identify the approved source for each material input and any data that must not be used. |
| Privacy, data-protection, and sectoral review | For personal or sensitive data, name the owner who determines applicable requirements before use. Record permitted purpose, minimum data, retention, access, vendor or cross-border considerations, approvals, and whether to proceed, rescope, or not use the data. |
| AI action | What does the system do: retrieve, extract, classify, rank, draft, calculate, call a tool, or coordinate a defined sequence? State the model approach and constraints. |
| Output | What exactly is shown, written, routed, or staged? Specify format, required citations or evidence, and whether the output is a recommendation, an approval request, or an alert. |
| User Action and Workflow Handoff | What action does the user take after the output? Name the existing system or workflow that receives it, and state what happens when the user accepts, edits, or rejects it. |
| Affected-person disclosure and recourse | Where people are affected, state the AI disclosure, sources and material uncertainty shown, correction, contest, or escalation route, decision authority, and expected response time. Where relevant, assess material differences in error, access, or recourse across affected groups. |
| User authority and system of record | Who can accept, edit, reject, approve, or override? Which named system holds the final decision or transaction? The AI interface is not the system of record unless explicitly designed and governed as one. |
| Failure and uncertainty path | What happens for missing data, unsupported or invalid output, low-quality retrieval, hostile retrieved content, conflicting sources, tool failure, or a user dispute? Name the safe fallback and what the system is prevented from doing. |
| Escalation and no-reviewer path | Name the escalation trigger, destination, expected response, interim authority, and safe outcome if no reviewer is available. For consequential actions, fail closed: do not bypass approval; use the manual-service or deferred-response route. |
| Feedback reuse boundaries | Select whether feedback supports case correction, prompt or rule improvement, training, or no reuse. Name the owner and review cadence. Record detailed privacy controls in Risks & Guardrails. |
Source note: For processing within its scope, consult the primary text of the GDPR (Regulation (EU) 2016/679); it does not determine requirements in other jurisdictions.
Evaluation, launch, and change decision
Before launch or expansion, set a risk-proportionate evaluation and release decision. Set thresholds before testing based on the task consequence, affected groups, authority, and fallback; do not borrow a universal numerical threshold.
| Decision field | Record |
|---|---|
| Representative test set and review method | Define versioned, representative cases; the expected outcome or acceptable range; permitted sources; a review rubric or sampling method; and a comparison with the current workflow where one exists. |
| Evaluation and launch thresholds | What evidence and results must be met to launch, expand, or remain in the current mode? Include task quality, safety and authority adherence, human-review evidence, and group-based outcome review where relevant, proportionate to the risk. |
| Failure-path tests | Which relevant adverse cases will be tested before launch: missing or conflicting sources, unsupported output, hostile retrieved content, tool or service outage, reviewer unavailability, or another use-case-specific failure? |
| No-go conditions | What result, missing control, unresolved uncertainty, or failed test prevents launch or expansion? |
| Accountable release owner | Who has authority to approve release, defer it, or stop it? |
| Re-evaluation triggers | Re-evaluate before continuing when there is a material change to the model, prompt, source, tool, permission, or policy. State the owner and required review. |
| Monitoring and response triggers | What signals trigger rollback, suspension, or review after launch, and who can take each action? |
Use real examples of inputs and outputs during design. Do not rely only on a happy-path demonstration. The failure and uncertainty path is a required part of the flow, not an exception to document later. These evaluation requirements apply to every AI workflow. Agentic workflows need the additional tool-use evaluation below.
Worked illustration: recommendation flow
Illustrative example — not a performance claim. A service manager needs a weekly view of unresolved customer issues.
- Trigger: Every Monday, the manager requests a review of open tickets.
- Inputs and sources: The system receives ticket text, status, date, and assigned team from the service platform. The service platform is the source for ticket status.
- AI action: A bounded LLM call groups supplied tickets into proposed themes and drafts a short summary. It cannot update tickets or contact customers.
- Output: A visible recommendation lists proposed themes, ticket links, and the text used to form each theme.
- User action, workflow handoff, and system of record: The manager accepts, edits, or rejects the summary. For an accepted or edited theme, the manager uses the linked tickets to prioritise follow-up; an authorized staff member records any assignment, priority, or escalation in the service platform. A rejected theme creates no ticket change and its tickets remain in the normal queue. The service platform remains the system of record.
- Failure and uncertainty path: If ticket text is missing, the output marks the ticket “insufficient information” and leaves it unchanged. If a theme is disputed, the manager corrects or rejects it and the ticket remains in the normal queue.
- Feedback to improvement: Accepted, corrected, and rejected themes are sampled by the service operations owner each month. The owner updates the task instructions or stops the feature if the review shows the task is not reliable enough.
Add agentic design only when the Why-AI record supports it
For this Canvas, an agentic workflow is a system in which an LLM dynamically plans or selects among multiple steps and tools to pursue a task. A single response, a fixed sequence, or RAG alone is not agentic.
Do not add an agent merely because several steps exist. First test whether a deterministic workflow, bounded LLM call, or RAG design handles the work. Agentic design may be justified when the next step genuinely depends on the task context, the necessary tools are bounded, a safe fallback exists, and the cost of a wrong or incomplete action is acceptable for the chosen interaction mode.
When agentic design is justified, add the following to the Solution Concept / Interaction Flow:
Tool register and authority boundaries
Maintain a tool register before implementation and update it when a tool, permission, or action changes. Every agentic design must name its kill switch, test that it reaches a safe state, and assign authority to invoke it.
| Tool-register field | Record |
|---|---|
| Tool and owner | The service or interface, and the accountable owner. |
| Task purpose | The specific step this tool supports. |
| Data accessed | The data classes, approved source, and information the tool must not access. |
| Permitted actions | The smallest set of reads, writes, or external calls needed for the task. |
| Least-privilege permission | The scoped identity, environment, and time limit used by the tool. Do not give an agent a general user or administrator credential. Use NIST SP 800-53 Rev. 5 Update 1, AC-6 (Least Privilege) as a control reference. |
| Approval boundary | Which actions must pause for an authorized human, including external communications, record changes, payments, access changes, and other consequential actions. |
| Checkpoint and fallback | When the workflow must show its work, ask for confirmation, stop, or route to a person. |
| Kill switch | Name the mechanism that stops the agent and reaches a safe state, the test that proves it works, and the role authorized to invoke it. |
| Audit evidence | The inputs, tool calls, outputs, approvals, and final outcome that must be logged. |
Use least privilege per tool. An agent that can read a customer record does not automatically need permission to edit it, download it, send it elsewhere, or query unrelated records. Place approvals before consequential actions, not only after an alert. Add checkpoints after material tool calls, before irreversible steps, and whenever the workflow lacks the evidence needed to continue.
Evaluate the task, not the demo
Define task success before testing. Build a golden dataset: a versioned set of representative tasks with expected outcomes, allowed sources, required approvals, and known failure cases. Run the same tasks through an evaluation harness that records completion, incorrect outcomes, unsafe tool attempts, stops, retries, cost, and human intervention.
Measure at least:
- Task-completion rate: completed tasks that meet the predefined success criteria, divided by attempted tasks.
- Safety and authority adherence: whether the workflow stayed within tool permissions, approval boundaries, and stop conditions.
- Human-review outcomes: sampled review of high-stakes outputs and all escalated or consequential cases, with reasons for corrections or rejection.
- Cost per completed task: total run cost for the evaluation period, including model, retrieval, tools, and required human review, divided by tasks completed to the success definition.
Include routine cases and adversarial cases such as misleading instructions in a retrieved document, missing information, conflicting sources, repeated tool failures, and a request outside the agent’s authority. This is red-teaming: deliberately trying to make the design fail safely before it reaches users.
Treat an LLM-assisted assessment as supplementary evaluation evidence, not the release authority. Compare it with human-labelled examples, document disagreement, and retain human review for high-stakes outputs.
Illustrative example — not a performance claim. An agent is proposed to investigate a supplier-delivery exception. Its permitted tools read the order record and delivery status, draft an exception summary, and stage a message to the supplier. The tool register prohibits changing orders, releasing payment, or sending the message. The agent must stop if the order record and delivery source conflict; a buyer reviews the evidence and approves any supplier message. Evaluation counts a task complete only when the summary identifies the relevant order, uses permitted sources, follows the stop condition when needed, and leaves the message un-sent until approval.
Handoff to Risks & Guardrails
This page establishes the authority and workflow decisions. The detailed risk catalogue, control design, control owners, testing, incident response, retention, and monitoring belong in Risks & Guardrails. Do not treat this handoff as a reason to defer safety decisions: the workflow above must already name its authority boundaries and safe fallback.
A documented 12-month pre-mortem is required in the Risks & Guardrails handoff: “It is 12 months later and this failed — what happened?” Record the plausible failure, affected groups, early warning, owner, and guardrail to test.
At minimum, carry these named failure modes and their concrete guardrails into that element:
| Failure mode | Minimum guardrail to specify in Risks & Guardrails |
|---|---|
| Task-specific error propagation | Test whether an erroneous intermediate result changes later actions or outputs. Where it does, add checkpoints at material steps; validate required outputs before the next tool call; and stop and escalate when validation fails. |
| Runaway loops or token-cost spirals | Maximum iterations, time, and spend per task; a kill switch; and alerts when limits are reached. |
| Tool misuse | A tool register, least-privilege permissions, action allowlists, and approval before consequential actions. |
| Prompt injection | Treat retrieved and tool-returned content as untrusted; separate instructions from data; restrict tool actions and test hostile inputs. |
| Data exfiltration through tools | Data-access scopes, approved destinations, outbound controls, and logs of data sent to each tool. |
| Ungrounded, unsupported, or harmful output | Approved-source boundaries, source visibility where relevant, review at the chosen Recommendation or Approval boundary, a visible correction path, and a safe manual fallback. |
| Bias, disparate error, access, or recourse | Proportionate assessment of affected groups; relevant group-based testing and monitoring; and an owner for remediation or rescoping. |
| Privacy and feedback reuse | A documented pre-use determination, data minimisation, permitted reuse boundary, retention and access controls, and a route for applicable data-rights requests. |
| Affected-person disclosure or recourse failure | Timely notice where required, an accessible correction or contest route, response expectations, and an authorized person who can correct or reverse an outcome. |
| Model, prompt, source, or vendor drift | Version records, review triggers, change approval, re-evaluation against the representative test set, and rollback or rescoping conditions. |
| Vendor dependency, deprecation, or exit failure | Name an owner for model, product, pricing, terms, and service-level change. Define triggers for a vendor or model deprecation, material price or terms change, loss of service, or unacceptable dependency; maintain a proportionate, costed migration or exit path that covers data, configurations, records, workflow fallback, and any parallel run; and test the path before the dependency becomes urgent. |
| Unobservable intermediate steps | Full audit logs of plans, inputs, tool calls, outputs, approvals, and stops; access for accountable reviewers. |
Source notes: The prompt-injection guardrail is informed by OWASP Top 10 for LLM Applications 2025, LLM01: Prompt Injection. The risk, governance, testing, and monitoring concepts in this handoff are informed by NIST AI 600-1 (2024), Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. Apply both sources proportionately and alongside applicable legal, sectoral, contractual, and internal requirements.
The Risks & Guardrails record should identify the risk owner, residual risk, test method, monitoring signal, escalation path, and kill-switch authority where relevant for each applicable failure mode. For a vendor-dependency risk, also record the exit or migration owner, trigger, authority, funding source, and date of the most recent path test.
Handoff to Value & Cost
Carry the chosen workflow into Cost Drivers. Model the full lifecycle cost of retrieval, tools, evaluation and testing, human review and approvals, logging, monitoring, fallback or manual service, and exit or migration. Use Build / Buy / Partner to record the delivery choice, vendor or partner dependencies, and exit assumptions; do not leave them as technical implementation details.
Before moving on
The two elements are ready for review when the team can show:
- a completed Why-AI decision record that compares all eight options;
- the exact task, linked Customer/User Segments, Jobs to Be Done, Pains & Gains, affected groups, decision consequence, evidence, and remaining uncertainty;
- a chosen Recommendation, Approval, or Alert mode for consequential points in the flow, with no prohibited high-impact use of Alert;
- a workflow with a User Action and Workflow Handoff, human authority, disclosure and recourse where people are affected, an escalation and no-reviewer path, a system of record, and a safe failure path;
- risk-proportionate evaluation and launch thresholds, no-go conditions, change and monitoring triggers, and an accountable release owner;
- a documented 12-month pre-mortem in the Risks & Guardrails handoff;
- and, if agentic design is proposed, a tool register, approval boundaries, a named and tested kill switch with assigned authority, an evaluation plan, and a cost-per-completed-task measure.
If the answer is still “an AI assistant will help with this,” the Canvas is not yet specific enough to support a build decision.