AI Project Canvas: A Template for Scope, Data, and Decisions

An AI project canvas is a short working template that connects a real problem to the people, information, checks, and decisions needed to solve it with AI. Use it before selecting a model or building a prototype. A completed canvas should make the next test clear and show which assumptions are still unproven.

You can keep the canvas in a document, then use fenbs to retain the resulting tasks, human decisions, and shared context for connected assistants. The useful outcome is an agreed boundary for the work, rather than a page where every box sounds confident.

What belongs on an AI project canvas?

Start with the person doing the work and the difficulty they face. “Use AI in support” is a direction, not a problem statement. “Help a support reviewer find the approved return policy before drafting a reply” identifies a user, a need, and a place to inspect the result.

Include the non-AI alternative. A better index or a clearer form may solve the difficulty with less maintenance. The canvas should let the team discover that answer without treating the absence of a model as failure.

For the broader authorization document, use a project charter; for the delivery sequence after scope is agreed, use a project plan. This canvas focuses on the questions that make an AI experiment worth starting.

How do you fill in the template without hiding unknowns?

Use short statements and mark each as observed, proposed, or unresolved. Link important observations to evidence. Avoid asking an assistant to invent business facts merely to finish the page; a blank with an owner is more useful than an unsupported answer.

Project name and canvas owner:
Problem observed:
People affected:
Current workflow and non-AI alternative:
Desired outcome:
Actions explicitly outside scope:
Approved input sources and owners:
Expected output:
Human review and approval point:
Main risks and affected people:
Manual fallback and stop conditions:
Baseline and success measures:
Pilot examples and evaluation method:
Decision owner and review date:
Unproven assumptions:
Next task, owner, and required evidence:

Keep assumptions separate from decisions. A team may assume that the policy library is current, while deciding that every answer must cite an approved policy. The assumption needs a check; the decision sets a rule for the trial.

The NIST AI Risk Management Framework↗ (opens in a new tab) is a useful reference for considering the people affected by AI and the evaluation of its risks. This canvas is a practical planning aid, not an official NIST template or proof that its guidance has been met.

What does a filled-in example look like?

Imagine a small equipment retailer trying to help support staff draft return-policy answers. These are invented planning examples, not a customer result. The team starts with internal drafts because sending an incorrect policy promise could create avoidable work for customers and staff.

• Problem: reviewers spend time locating the approved policy section for an incoming question.
• Users: support reviewers handling ordinary product returns; disputed or unusual cases remain with the support lead.
• Inputs: an approved policy library and invented customer questions for the initial test.
• Output: a draft response with the relevant policy link and any missing information listed.
• Boundary: AI cannot send messages, authorize refunds, or promise an exception.
• Measures: correct policy selection, unsupported statements, review effort, and handling of ambiguous questions.
• Owner: the support lead decides whether the pilot continues after inspecting the checked examples.

The next task is to establish which policy versions are approved, rather than immediately build a chat interface. That task may reveal conflicting instructions. Resolving the conflict first gives the experiment a dependable answer to learn from.

In fenbs, record the boundaries against AI authorizing refunds or sending messages as Decisions and rules, with the human who approved them. That makes the canvas useful to the team’s connected assistants, as explained in how fenbs works.

How should you describe data access and risks?

Name each input source and its owner. State what the trial actually needs instead of saying “company data.” Record where the information will be processed, who can see it, and what approval is required before use. Leave secrets and personal records in their approved systems.

The FTC guide to protecting personal information↗ (opens in a new tab) recommends keeping only information needed for the business purpose and understanding who has access. For the example retailer, invented questions can test the first draft workflow without copying customer identities into the canvas or an AI app.

Describe a risk as an event with consequences. “Privacy” is too broad to guide a test. “A draft includes another customer’s details” tells the reviewer what failure to look for and gives the owner a reason to stop the pilot immediately.

Which measures make the canvas testable?

Choose measures tied to the problem, then include checks for harmful mistakes. For support drafting, measure whether the response uses the correct policy and how much reviewer correction it needs. A confident tone or a long answer does not establish that the customer will receive accurate information.

Keep several examples aside for evaluation instead of using every example to improve the instructions. Include ordinary questions, missing information, and requests outside scope. Write expected behavior for each, including when the assistant should say it cannot establish an answer.

Agree on the decision rule before seeing the results. It might require the team to fix every unsupported policy promise before expanding the trial. Have the decision owner assess the whole workflow, including review and fallback, rather than choosing a single attractive metric.

How does the canvas become an actionable project?

Convert unknowns into tasks with an owner and a visible result. “Check data” becomes “confirm the approved policy source and record the owner’s approval.” Keep the original canvas concise and update it when a human decision changes the scope.

Use a project proposal when the next step is asking someone to fund or authorize the work. If implementation follows, app generators and automation projects cover those separate build questions.

Revisit the canvas when new data, users, or actions enter the workflow. A draft-only assistant and an assistant allowed to send messages need different review boundaries. Reusing the old page without revisiting those boundaries can conceal a substantial change in responsibility.

How to do this with fenbs

1. Create a free account and add a project named for the problem you are investigating.
2. Save a concise canvas summary as project context, with links to approved supporting material. Do not put sensitive source records into the summary.
3. Add tasks for the uncertain inputs, pilot examples, and review. Give each task a plan explaining the evidence needed to finish it.
4. Record the scope and review boundaries a person approves in Decisions and rules. Ask a connected assistant to read the context before working.
5. Save progress before stopping, including the next check and anything waiting on a person. Record the review decision when the owner makes it.

fenbs does not train a model or calculate evaluation results. It is useful for keeping the agreed project record available across connected assistants; a plain document can be sufficient for a single short planning discussion. Find more practical workflows in the AI at work hub.