AI use-case selection is a portfolio discipline: how an organization maps candidate workflows, tests value hypotheses against data readiness and risk class, and decides what to pilot, scale, pause, or refuse. This page owns that method—framing, scoring, build/buy/partner choices, pilot design, and scale criteria. It is not a dump of every industry vertical. For domain depth, link out to guides such as healthcare AI, finance AI, and retail AI. Operating-model scaffolding lives with enterprise AI; policy rituals with AI governance.
Most failure is not “we picked the wrong model.” It is use-case tourism: dozens of demos without owners, metrics, or exit criteria; pilots that cannot graduate; and high-risk automations shipped because a competitor announced something similar. A disciplined portfolio treats AI opportunities like a product backlog with risk tiers—not like a brainstorming mural.
Use-case portfolio framing across sectors
Frame the portfolio as a set of decision or workflow interventions, not as a list of model types. Each candidate should name: the decision or task, the user who acts, the system of record touched, the reversible versus irreversible actions, and the metric that would prove value. “Add generative AI” is not a use case. “Draft first-pass support replies with human send” is.
Group candidates by value theme and by shared platform needs. Themes might include document throughput, forecasting, personalization, agentic orchestration, or knowledge retrieval. Shared needs might include identity, logging, evaluation harnesses, or approved model endpoints. Grouping reveals whether you are funding ten one-offs or a few enabling platforms—aligned with how enterprise AI programs fund platforms versus embedded squads.
Maintain an explicit not-doing list. Refusals for legal, ethical, data, or strategic reasons prevent teams from rediscovering the same bad idea under a new vendor name. Publish the refusal rationale at a level builders can understand so shadow IT does not fill the gap.
Refresh the portfolio on a cadence. Markets, regulations, and model capabilities change; so do internal systems. A quarterly re-rank with intake from business units beats an annual strategy offsite that freezes a slide deck while production realities move.
Maintain a single intake channel even if many teams propose ideas. Multiple backdoors recreate tourism under new labels—“innovation challenge,” “vendor day,” “hack week”—without changing the WIP limit. Publish cycle times from intake to decision so proposers trust the process.
Tag dependencies explicitly: identity, document corpus, feature store, human review queue, or approved model endpoint. A use case that looks small may unlock—or be blocked by—a platform bet. Portfolio reviews should show critical path, not only ranked ROI fantasies.
Link vertical depth only when a use case enters that domain’s risk and data regime. A generic “customer reply assist” stays in the portfolio method; a clinical documentation assist must inherit healthcare constraints from the healthcare AI guide without copying that encyclopedia into this page. The portfolio is the map; vertical guides are the terrain detail.
Value hypotheses
A value hypothesis states who benefits, which costly error or delay shrinks, and how you will measure it within a defined window. Prefer operational metrics—time-to-resolution, defect escape, conversion with quality constraints, analyst hours returned—over vanity metrics like prompts sent or seats provisioned.
Separate efficiency, quality, and growth hypotheses. Efficiency claims need baseline process times and load. Quality claims need error taxonomies and sampling plans. Growth claims need attribution discipline so model lifts are not confused with seasonality or campaign spend. Write the counterfactual: what happens if we improve the process without a model?
Estimate unit economics early, even roughly. Inference cost, human review cost, integration cost, and failure cost often dominate license fees. A use case that looks cheap in a demo can be expensive at volume if every output needs expert review. A use case that looks expensive can be cheap if it removes rare but catastrophic errors.
Require a product owner with budget and a workflow owner with authority to change the process. Hypotheses without owners become slideware. Hypotheses owned only by an innovation lab rarely survive contact with production SLAs.
Write the harm hypothesis beside the value hypothesis. Who is hurt if the system is wrong, slow, or biased? Value without harm framing produces launches that finance loves and risk cannot defend. Include second-order effects: deskilling, alert fatigue, or customer distrust after one viral failure.
Time-box learning goals separately from value goals. Some pilots exist to learn whether data is usable; call them discovery bets with smaller spend and no production write access. Conflating discovery with value delivery keeps zombie pilots alive.
Express value in units operators already manage: minutes per case, defects per thousand, leakage dollars, or conversion with complaint rate held flat. If you cannot name the unit, you do not yet have a hypothesis—you have a theme. Themes belong in strategy memos; hypotheses belong in pilot charters.
Data readiness
Data readiness asks whether you can lawfully access, correctly define, and reliably refresh the inputs the use case needs—and whether labels or retrieval corpora match the decision being automated or assisted. Availability in a lake is not readiness. Readiness includes lineage, quality metrics, access control alignment, and an owner who can answer “what if this field is wrong?”
For predictive machine learning, readiness means label definitions that match the production decision, stable features, and leakage checks. For generative AI and RAG, readiness means curated, permissioned corpora, chunk quality, refresh cadence, and evaluation questions that reflect real work—not only embedding coverage.
Score readiness honestly: green (production-grade), amber (usable with known gaps and mitigation), red (do not pilot automation). Amber cases can still proceed as human-in-the-loop assists with narrow scope. Red cases should fund data products first, not model shopping.
Document prohibited and sensitive classes of data up front. Many use cases die—or should die—when teams discover that the “obvious” training set cannot be used. Policy discovery mid-pilot wastes trust and budget.
Include ACL and residency checks in readiness scoring. A perfect corpus that cannot be queried under user permissions is not ready for RAG. A feature table that cannot leave a region is not ready for a global model. Readiness is socio-technical: contracts and identity matter as much as null rates.
Plan labeling or curation budget in the use-case card. “We will use the lake” without curation hours is a red score wearing green paint. For generative assists, curation of canonical answers often dominates model choice in early ROI.
Risk class mapping
Map each use case to a risk class using impact, reversibility, data sensitivity, autonomy level, and regulatory exposure—not model novelty. Internal draft generation over public marketing copy differs from eligibility automation or safety-critical recommendations. Governance programs usually bind classes to required artifacts: evaluation packs, override paths, monitoring, and approval levels.
Re-class when scope expands. A read-only assistant that gains write access to customer records crosses classes even if weights are unchanged. Treat capability expansion as a portfolio event. Autonomy from AI agents that can call tools raises risk even when the underlying language model is familiar.
Include misuse and over-reliance in the risk view. A medium-impact tool used as if it were authoritative creates high impact in practice. Training and UX that force verification reduce class drift caused by automation bias.
Connect risk class to go-live gates before the pilot starts. Retrofitting controls after a viral internal launch is how organizations accumulate ungoverned endpoints.
Map residual risk after controls, not inherent risk alone. A high-inherent use case with strong human approval, logging, and narrow scope may be acceptable; a medium-inherent use case with silent writes to a system of record may not. Document residual risk owners by name.
Align classes with incident playbooks before go-live. If nobody knows how to pause the system on a holiday weekend, the class is fiction. Tabletop a failure once during the pilot window.
Build, buy, or partner
Build when differentiation lives in proprietary data, tight workflow integration, or constraints vendors will not meet. Buy when the workflow is commodity and the vendor’s evaluation evidence, security posture, and exit terms are acceptable. Partner when you need domain co-development without owning the full stack—common in regulated verticals.
Use AI vendor evaluation criteria for buy and partner paths: data handling, eval methodology, subprocessors, latency and cost at your volumes, and contractual rights to test and exit. Do not treat a polished demo as evidence of production fitness.
Hybrid patterns are normal: buy inference or a vertical SaaS feature, build the orchestration, evaluation, and system-of-record integration. Clarify who owns model updates, prompt changes, and incident response so gaps do not appear between vendor and internal teams.
Revisit the choice when unit economics or risk posture changes. A buy decision that made sense at low volume may become a build or renegotiate decision at scale—and the reverse is also true when a vendor productizes what you were about to custom-build.
Estimate switching costs at selection time. Embeddings, prompt libraries, proprietary eval sets, and user habits create lock-in even when weights are commodity. Prefer vendors and architectures that allow export of prompts, logs, and evaluation artifacts.
For partner paths, define co-owned roadmaps and dispute resolution. Domain partners who control labels can stall product progress; product partners who control UX can hide model limitations. Write escalation paths into the SOW.
Pilot design
A pilot is a bounded experiment with success thresholds, failure thresholds, population scope, duration, and a named decision review. It is not a perpetual soft launch. Write what you will measure, what would cause stop, and what production controls must exist before any expansion.
Prefer shadow mode and sampled human comparison before autonomous actions. For generative assists, measure groundedness, edit distance, and time saved with quality held constant. For predictive models, measure calibration and error costs on slices that matter—not only average accuracy. Borrow practices from AI testing so pilots produce reusable evaluation packs.
Limit concurrent pilots that compete for the same scarce experts and the same production systems. Portfolio congestion creates false negatives (good ideas starved) and false positives (noisy wins claimed everywhere).
Communicate to affected staff what the pilot is and is not. Surprise scoring of employees or customers destroys trust even when the model is technically fine. Notice, feedback channels, and human escalation are part of design—not afterthoughts.
Staff the pilot like a product slice: engineering, domain expert, evaluator, and risk partner—not only an enthusiast and a vendor SE. Understaffed pilots produce ambiguous results that get spun as success. Pre-register analysis plans to reduce p-hacking on weak lifts.
Capture qualitative notes systematically. Interview users about trust, extra checking time, and workarounds. Quantitative time-saved metrics miss quiet rework. Fold qualitative themes into the scale decision packet.
Scale criteria
Scale only when the pilot meets pre-declared thresholds on value, reliability, risk controls, support readiness, and unit economics—and when a product owner commits to ongoing ownership. “Users liked it” is insufficient if edit rates are high, costs are unbounded, or monitoring is absent.
Define what scale means: more users, more geographies, higher autonomy, or deeper system write access. Each dimension has different control requirements. Geographic scale may trigger new regulatory classes; autonomy scale may require kill switches and stronger eval gates.
Fund production hardening explicitly: on-call, drift monitoring, evaluation regression, documentation, and training. Pilots that “scale” by copying a notebook into a cron job create silent operational debt.
Plan retirement criteria at the same time as scale criteria. Use cases should exit when value disappears, risk rises, or a better pattern replaces them. Eternal pilots and immortal models both corrode the portfolio.
Require support runbooks, cost anomaly alerts, and evaluation regression in CI before calling a use case scaled. Marketing launch is not scale. Scale is boring reliability under load with named owners and a retirement path.
When expanding autonomy, demand a new risk review even if the model is unchanged. Autonomy is a product change. When expanding geography, demand locale evaluation slices and legal sign-off for the new regime.
Anti-patterns (use-case tourism)
Use-case tourism collects logos and demos without committing to owners, metrics, or refusals. Symptoms include endless proof-of-concepts, duplicate tools for the same workflow, success defined as “we shipped a chatbot,” and strategy decks that list verticals instead of decisions.
Other anti-patterns: optimizing for model novelty over workflow fit; starting with the highest-risk automation to “show ambition”; ignoring data readiness until after vendor selection; measuring only engagement; and copying a competitor’s press release into your backlog without their constraints or their failure modes.
Counter tourism with intake forms that force decision naming, risk class, readiness score, and owner; with a WIP limit on active pilots; and with public portfolio reviews that celebrate shutdowns as much as launches. A healthy portfolio has fewer, sharper bets—and clear links to vertical depth pages when a bet enters a regulated domain.
AI use-case work succeeds when hypotheses are falsifiable, data and risk are scored before demos, pilots produce evidence packs, and scale is earned. Map the portfolio; do not tour it.
Another anti-pattern is metric shopping after the fact—changing KPIs until the pilot “wins.” Pre-declare primary metrics and allow secondary learning metrics, but do not move the goalposts to protect sunk cost. Leadership should reward clean kills.
Stop celebrating the number of use cases in flight. Celebrate evidence quality and production outcomes. A portfolio of three scaled systems beats thirty demos when the goal is durable value under governance.
Vendor-led tourism deserves special mention. Roadmaps built from a single SE’s slide deck inherit that vendor’s product gaps as your strategy. Require at least two independent evidence sources—internal shadow tests and one alternative approach—before a buy-path use case enters the active WIP limit.