Module 8 · 95 min
AI Strategy, Portfolio & Economics
Where to Place the Bets, and Why. Opportunity and use-case prioritisation, portfolio choices, buy/build/partner decisions, vendor strategy and due diligence, total cost of ownership, ROI and value realisation, funding and operating-model choices. The central question: what should we pursue, and why?
- Frame AI strategy as a set of choices under scarcity — capital, leadership attention, integration capacity, clinical change capacity and data access — rather than as a list of technologies to adopt.
- Turn an AI idea into a strategic opportunity by attaching it to a service problem, a value hypothesis and a named route to realising the value.
- Compare candidate use cases on value potential, strategic fit and reuse, feasibility, evidence confidence and delivery burden, without collapsing them into a single misleading score.
- Use 'high value but not ready' as a deliberate portfolio position with a stated readiness gap, instead of a rejection or an indefinite pilot.
- Build a portfolio that balances near-term productivity, clinical value bets, enabling capabilities and longer-horizon options, and identify the shared capabilities that unlock several use cases at once.
- Name the full cost stack of an AI deployment — acquisition, integration, data preparation, evidence, redesign, training, oversight, infrastructure, compliance, monitoring and exit — and separate fixed from variable and one-off from recurring.
- Distinguish cashable from non-cashable benefit, and trace a claimed benefit through operational mechanism, measurable KPI, financial or clinical consequence and named owner.
- Recognise misalignment between who pays and who benefits, and say what that implies for funding and sequencing.
- Express an economic case as scenarios with stated assumptions and uncertainty rather than as a single-point return figure.
- Choose between buy, build and partner on capability, differentiation and maintenance appetite, and run a vendor diligence conversation covering lock-in, data rights, version control and exit.
- Make and defend fund, fund-conditionally, hold and stop decisions across a constrained portfolio.
Buy, build or partner — and how to diligence a vendor
Buy, build or partner is usually argued as an ideology — we are not a software company; we cannot let a vendor own our data — when it is a decision with reasonably clear criteria. The question is not which is better in general. It is which is better for this capability, given what differentiates the organisation and what it is willing to maintain for a decade.
The under-considered word is maintain. Building is not an alternative to paying; it is an alternative to paying a vendor. Someone must own the model, revalidate it when the population shifts, patch it, document it, and be available when it fails at three in the morning in year six. Organisations that can build frequently cannot sustain, and the resulting orphaned system is worse than either option.
Buy
The capability is commodity or near-commodity, speed matters, external scale and evidence already exist, and it is not a source of differentiation. Speech recognition, general document handling and established imaging triage usually sit here.
What you accept: Roadmap dependence, version changes on the vendor's schedule, and a switching cost that grows with every year of accumulated configuration.
Build
The capability is genuinely differentiating, depends on proprietary workflow or data, needs deep integration or control, and the organisation has both the capability and a credible appetite to maintain it for the system's whole life.
What you accept: Full ownership of validation, monitoring, incident response, documentation and succession planning for the people who built it.
Partner or hybrid
An external model or product is needed, but workflow, integration and data ownership should stay internal. Common shape: vendor model, internal orchestration, contractual data rights, joint evidence generation.
What you accept: More complex accountability. Write down who owns evidence, who owns incidents, and who decides on version changes — the boundary is where this option succeeds or fails.
Nine factors that decide it
Switching cost and lock-in
How much configuration, training, integration and workflow assumption accumulates in the supplier's product, and what leaving would cost in year four rather than year one.
Interoperability and exportability
Whether outputs, configuration and history can be exported in a usable, documented format. Not the presence of an API — the presence of everything you would need to leave.
Data rights and derived data
What the supplier may do with your data and with what is derived from it, including model improvement. State it in the contract; the default answer in a standard licence is often broader than expected.
Model and version change control
Whether you are notified before a material model change, whether you can defer it, and what revalidation the supplier performs and shares. A silent upgrade invalidates local validation.
Roadmap dependence
How much of the case rests on functionality that does not exist yet. Value the product you can buy today, and treat the roadmap as an option rather than an asset.
Implementation and support quality
Who implements, with what track record in comparable settings, and what support looks like in month eighteen rather than during the sales process. Ask for a reference site that has been live for two years.
Evidence relevance and transparency
Whether the evidence concerns this version, this population and this workflow — appraised with Module 6's tools rather than re-litigated here — and whether limitations are disclosed without prompting.
Commercial durability
Whether the supplier is likely to exist and support this product in five years, and what happens to your deployment if it is acquired or the product is discontinued.
Exit and decommissioning plan
Written before signature: data export format, transition support, record retention and who pays. The best time to negotiate an exit is when you are still deciding whether to enter.
Vendor diligence: what to ask, and what a strong answer sounds like
Nine questions worth asking in the room, with what a strong answer sounds like. They are commercial and operational questions — evidence appraisal belongs to Module 6 and should be run separately rather than folded into a procurement conversation.
How does the price change with volume, users and future modules?
- Why it matters
- Per-encounter and per-call pricing turns success into cost. A case built on pilot volumes can invert at scale.
- A strong answer sounds like
- A published pricing structure with worked figures at three volumes, and a stated cap or renegotiation trigger.
What exactly does implementation include, and what will we have to do?
- Why it matters
- The internal share of implementation is the most under-estimated cost line in the whole case.
- A strong answer sounds like
- A named split of responsibilities with estimated internal days by role, drawn from comparable deployments.
How and when do you change the model, and what do we get?
- Why it matters
- A material version change can invalidate local validation and alter behaviour clinicians have adapted to.
- A strong answer sounds like
- Advance notice, release notes describing behaviour change, revalidation evidence, and an option to defer for an agreed period.
What rights do you take over our data and anything derived from it?
- Why it matters
- Default licence terms frequently include improvement rights that the buying organisation has not consciously agreed to.
- A strong answer sounds like
- A narrow, specific clause, no derived-data rights by default, and willingness to amend it before signature.
If we leave in year four, what do we take and what does it cost?
- Why it matters
- Exit terms are cheap to agree before signature and expensive to negotiate afterwards.
- A strong answer sounds like
- A documented export format covering configuration and history, defined transition support, and costs stated up front.
Which of your reference sites has been live longest, and may we speak to them?
- Why it matters
- Deployments look similar at go-live and differ enormously at eighteen months, when the real support experience shows.
- A strong answer sounds like
- A named site live for two or more years, offered without conditions on what may be discussed.
What does the ongoing oversight burden look like for our staff?
- Why it matters
- Review time is usually the largest recurring internal cost and is rarely volunteered by a supplier.
- A strong answer sounds like
- Measured review times from comparable sites, with the distribution rather than only the median.
What have you seen go wrong at other sites, and what changed as a result?
- Why it matters
- A supplier who cannot name a failure has either not been deployed at scale or is not being straight with you.
- A strong answer sounds like
- Two or three concrete examples with the product or process change each one produced.
Who is accountable when the system contributes to a patient safety incident?
- Why it matters
- The answer has to exist before go-live, not be discovered during an investigation.
- A strong answer sounds like
- A clear split of duties, an agreed incident process with timescales, and cooperation obligations written into the contract.
One asymmetry to keep in view: nearly every factor above becomes more expensive to fix after signature and costs almost nothing to settle before it. The diligence conversation is the cheapest risk-reduction activity in the whole investment.
Sources & evidence · 4 sources
This module cites public or consensus guidance, scholarly literature, technical documentation.
Content reviewed: September 2026. Publication dates of the individual sources are shown in each citation.
World Health Organization. Health technology assessment of medical devices, 2nd ed. Geneva: WHO; 30 May 2025. ISBN 9789240110878.
WHO's practical guidance on health technology assessment as a multidisciplinary evaluation of clinical, economic, organisational, ethical and social implications, intended to support efficient allocation of resources. It frames the discipline of assessing value before adoption; it is guidance on process, not evidence about any particular technology, and it does not prescribe the prioritisation categories used in this module.
Open sourceNational Institute for Health and Care Excellence. NICE HealthTech programme manual (PMG48): early-use HealthTech guidance assessments. Published 14 July 2025; updated 17 December 2025.
Describes how NICE assesses promising health technologies where evidence is still developing — weighing unmet need, potential value for money, the nature of remaining uncertainty and what further evidence generation is required, including workforce and system efficiency impacts. Directly relevant to staged commitment and to treating a weak evidence base as a reason to size a first investment as learning. It is a UK process manual, not a general economic method.
Open sourceNational Institute for Health and Care Excellence. Introducing CHEERS-AI: improving health economic evaluation reporting for AI technologies. NICE blog, 31 October 2024.
Introduces an AI-specific extension to health economic evaluation reporting, covering transparency about input data, model functionality, conflicts of interest and the assumptions behind claimed economic effects. A reporting standard: it improves how an economic case is described and audited, and following it does not make the underlying case correct.
Open sourceBinkley CE, Bouslov D, Zaidi A, et al. An early pipeline framework for assessing vendor AI solutions to support return on investment. npj Digit Med. 2025;8:368. doi:10.1038/s41746-025-01767-z
Proposes an early-stage framework for triaging vendor AI proposals around strategic alignment, shared accountability, measurable value and risk, with an impact/value case covering the problem, the solution landscape, quantifiable objectives and costs. Supports the case for structured early triage before procurement; it is a proposed framework rather than validated evidence that using it improves investment outcomes.
Open source
Capstone Board Pack
Add what you just learned to your own strategy document while it is fresh.