Choose what deserves your time and money
Your organisation may have many ideas for using AI. It cannot do all of them well at once.
AI can generate proposals faster than people can judge, fund and absorb them. Protecting that capacity is part of the portfolio’s purpose. Include work created or supported by AI even when the resulting product contains no AI. This guide helps you choose what to support, how much to invest next, and when to change direction.
Start with three questions: What would improve? What have we learned? What should we do next? Use them for new ideas and work already under way.
This guide is for leaders, sponsors and anyone responsible for a group of AI investments. A small business can use a short shared record. A larger organisation may use its existing investment committee. You do not need a new management layer or software tool.
For step-by-step help, use the Portfolio Implementation Guide. The AI Product Flow Framework explains their shared principles.
What is an AI portfolio?
An AI portfolio is the collection of AI-related work that an organisation funds, oversees or runs. It can include research, services, staff tools, products, shared information and ongoing support. Include required work, such as meeting an obligation, as well as new opportunities. The AI portfolio is a view within your organisation’s wider portfolio. When a choice trades AI work against other work, take it to whoever decides that wider portfolio.
A bet is a limited commitment of time, money or effort to answer a question. Someone owns it. The record says what the limit is and what would cause the work to stop or return for review.
For example: “Allow two weeks to find out whether AI can help staff prepare accurate answers. Keep a person responsible for checking every answer.” This is a testable request. “Transform customer service with AI” is a direction that still needs a useful next step.
A bet may support several products. One product may receive several rounds of support. A completed research bet can inform a build decision; it does not grant permission to build. Money already spent is part of the history, not a reason to spend more.
See the whole set of choices
Before you support the next step
Whose situation improves? What else could we do?
What have we spent? What will the next step and ongoing use cost?
Who can do, check and support the work? What would have to wait?
What could go wrong across several products? Who can respond?
Make one clear decisionName the next action, owner, limits and review point.
Example used in these guides: a service organisation wants people to receive a correct answer without repeating their request. It is considering better intake, a knowledge service and a response service. These are possible product responsibilities, not necessarily three applications. The example is invented to explain the approach.
At portfolio level, the question is whether this work deserves resources alongside other needs. The family and product guides explain how the parts fit and how to test one part.
Six habits that keep investment useful
Look beyond each team’s result
Two teams may each save time while creating more work for a third team. Ask about the whole service. Look for duplicated effort, shared costs and work that is being displaced.
Products do not have to use the same solution to support the same goal. Compare the choices before paying to standardise them.
This is Judgement: judge the whole service, not each team’s result.
Spend in steps as you learn
An attractive proposal is a prediction. Start with the smallest useful question that could change your decision. Increase support when the results justify it.
Value may mean better service, safer work, a stronger policy decision or less risk. Required work does not have to invent revenue. If a proposed solution fails, the obligation may still need another solution.
This is Restraint: commit enough to answer the next question.
Leave enough time to check and support the work
AI can produce more than people can review. Count the time needed for checking, specialist advice, joining work together and ongoing support.
Agree how much work can be active at once. This is a work-in-progress limit. Show what is waiting and why. Adjust the limit with the people doing the work. A full queue is a reason to make a choice, not to approve work without checking it.
This is Restraint: keep active work within the capacity to judge it.
Check the benefit after work starts
Keep expected benefit separate from observed benefit. Faster draft writing may help, but extra checking can consume the time saved. Include training, adoption, AI usage charges, maintenance and support.
Research can be useful when it changes a decision or rules out an unsuitable idea. A report alone does not prove a saving. Nor does time released automatically become a cash saving.
This is Evidence: compare what was promised with what happened.
Notice risks that several products share
Several products may rely on the same supplier, AI model, source information or checking tool. One failure could then affect all of them. This shared reliance is called concentration.
Find out who owns each important dependency, which products rely on it and what happens if it changes or fails. A good local test may leave this wider risk unresolved.
This is Accountability: name an owner for each shared dependency.
Keep people able to question the result
People need the time, skills and authority to challenge AI-assisted work. They must also be able to intervene and recover from mistakes.
AI can help prepare comparisons and summaries. Its answers still need sources and suitable checks. Two AI tools agreeing may reflect the same underlying mistake. Review whether automation is also removing opportunities for staff to develop the skills they will need later.
This is Adaptation: keep people able to notice problems and change course.
Make the next decision clear
AIPF uses three phases to ask different questions. A gate is the decision at the end of a phase. It can happen within an existing review; it does not require another meeting.
| Phase and everyday question | What you need to see | What the decision sends back |
|---|---|---|
| 1 — Validate, Show, and Set Boundaries. Is this worth a small test? | The need, an understandable example, alternatives, uncertainties, proposed limits and available reviewers. | The question to test, owner, time or money allowed, AI limits and next review. |
| 2 — Prove the End-to-End Evidence Slice. What did the small test show? | Results from a narrow path through the work; failures, costs and what remains unknown. | The next allowed step, changes needed, conditions and evidence still due. |
| 3 — Decide and Operationalise. Should we continue, change, stop or expand investment? | Evidence of value, costs, risks and people able to run and support it. | The agreed use, owners, support, limits and triggers for another review. |
“Prove” in Phase 2 means gather evidence for the specific question. It does not mean prove the whole product will succeed. “Operationalise” means make ongoing use workable, with people and support in place.
| Decision | What it means |
|---|---|
| Proceed | Support the next step within stated limits, which may be smaller than requested. |
| Revise | Change the idea, scope or approach before continuing as proposed. |
| Defer | Wait for a named condition, with someone responsible for checking it. |
| Stop | End this commitment and deal with remaining responsibilities. |
| Merge | Combine overlapping bets under one owner, keeping their histories. |
| Rebalance | Move money, people or scope between bets; show who gains and what waits. |
| Scale | Support wider use when results and operating support justify it. This is available only at Gate 3. |
All the other decisions can be made at any gate. A stop condition can interrupt work at any time. A disappointing result, incident, cost increase or changed AI behaviour can reopen an earlier decision.
Write down the decision, reasons, disagreements, owner, exact scope, limits, next review and which gate it belongs to. Keep the Framework’s decision states distinct; in particular, a recommendation, a funding commitment and release are separate permissions. One decision may cover more than one of these when the decision-maker has the authority and records it clearly.
Make each responsibility someone’s job
An accountability means someone remains answerable for the result. Assign the five responsibilities below through existing roles. They do not require five new posts.
| Existing AIPF name | In everyday work, this person makes sure… |
|---|---|
| Portfolio | The choices serve the organisation, priorities are clear, trade-offs are made, the overall risk is accepted and the portfolio gate decision has one owner. |
| Financial, Value, and Benefits | Spending and ongoing costs can be checked, and claimed benefits are compared with what happened. |
| Concentration and Risk | Risks from shared suppliers, sources and AI controls are identified and reported across bets, so the Portfolio owner can accept or reduce them. |
| Decision-Capacity | Enough skilled people can review the work, and the active-work limit is respected. |
| Workforce and Competence | People can question, use, stop and recover AI-assisted work. |
Name an owner for each responsibility. In a small organisation, one person may hold several. Product and family owners still answer for their own work. The Portfolio owner, or a portfolio board acting under that accountability, holds the portfolio gate decision.
The expenditure owner is the person answerable for spending under the organisation’s existing rules. This may be someone other than the product owner. Preparing a portfolio report does not give anyone spending authority.
Keep five useful records
AIPF calls these artefacts: records or views that help people decide. They can be tabs in a spreadsheet, linked notes or views in an existing system. They need not be five new documents.
Keep each fact in one agreed source and link to it. When a summary is updated, keep the source, date and important limits visible. Use the Framework’s shared information checklist for detailed fields.
The list of bets — AI Bet Ledger
Show what each bet is for, its reference, spending owner, related products or family, decision and next request. Include the evidence, limits, expected and observed benefit, costs and stop or review condition.
Separate money already spent, money already promised and estimates of future cost. Keep the decision states distinct: “test finished” does not mean “build approved”. Mark missing information as unknown, not zero.
Example: BET-017 is approved for a small test. Its wider service rollout remains a proposal.
Who can review the work — Decision-Capacity Ledger
Show the reviews needed, skills required, time available, active-work limits and waiting items. Distinguish waiting for evidence from waiting for someone to judge it. Include support demand when it affects what the organisation can sustain.
Example: two bets need the same specialist. Choose their order instead of assuming both can start.
Shared points of failure — Model and Vendor Concentration Register
Show common suppliers, AI models, information and checking arrangements. Link each to affected bets, owners and response options. Several reports based on one source are still one source, not independent confirmation. Built from: each family’s Shared Substrate Map and product dependencies; collect only what those maps do not already hold.
Example: three services rely on one knowledge source. A change to that source needs review by all three owners.
Promises compared with results — Benefits Realisation Map
For each benefit, keep an identifier, owner, measure, starting position, observation period and result. Explain which products contributed. Include added work and harm as well as gains. Count a shared outcome once. Built from: Family Benefits Maps and product Acceptance Records.
Example: fewer repeated requests is one service outcome, even if intake, knowledge and response products all helped achieve it.
What AI may do — Autonomy Boundary Map
Show permitted AI actions, who owns the permission, required checks and when a person must intervene. Link to the tested controls in the Product Guide’s AI Model Harness, explained there as the working rules and checks around AI use, and to common controls in each family’s Shared Substrate Map.
Example: AI may prepare a response; a trained person checks it before it reaches the customer. Permission to draft is not permission to send.
The same applies to AI doing Portfolio work: summaries need source checks, calculations need testing, and actions need explicit permissions and human review. Linking to a Product’s harness evidence does not by itself validate a Portfolio assistant’s different task.
Connect portfolio, family and product decisions
| Guide | Main question | What it shares |
|---|---|---|
| Portfolio | Where should we put our resources next? | Purpose, spending and work limits, decision authority and evidence needed. |
| Product Family | How should related products work together? | Shared needs, handoffs, costs, test results and limits on reuse. |
| Product | Does this product help, and is it fit to use? | User findings, tests, costs, benefits, accepted scope and remaining uncertainty. |
Results move towards the decisions they inform. Decisions return to the people who must act on them. Keep the same source links and qualifications in both directions.
For example, the portfolio allows one further service test and requires human review of every response. The family identifies which handoffs are affected. The product owner updates the work list and acceptance checks. No one quietly drops the human-review condition.
Use a family only when there is a useful shared decision. A product can connect directly to the portfolio. Work within an existing delegation can continue without a second approval merely because leaders can see it.
Start with one real choice
Take a decision that is already due. Name the outcome, next question, resource limit and person responsible. Find the evidence that could change the choice. Record what was decided and return to the result.
Use short learning cycles and finish important work before starting more. Improve the process when it adds effort without helping a decision. The five shared AIPF values are judgement, evidence, restraint, accountability and adaptation: think carefully, check what happened, limit the next commitment, name the owner and change course when needed.
Sources
Further reading
Atlassian’s Agile guide provides an accessible introduction to small steps, feedback and adapting plans. Its work-in-progress explainer explains limits on active work. AIPF applies these ideas to the choices and review capacity described here.
LeSS and Scrum.org’s Scaling Scrum material inform the companion guides’ treatment of work across teams. They do not supply AIPF’s portfolio funding rules. The Portfolio Implementation Guide shows how to put this guide into practice.
Earlier versions used P3M3 to distinguish investment oversight from delivery, without adopting its maturity model.
Acknowledgements
Authors
Written by Rick Molony and Ghulam Akbar, with AI assistance.
Licence
This guide is offered under the Creative Commons Attribution 4.0 International licence.
Help improve this page
Found a problem or a better way to explain it? Suggest a correction or improvement.