A generative AI use case is technically feasible when the data you can supply lets a model reach the quality bar the use case demands, within your technical constraints and at a cost the result can repay. Google’s machine learning guidance names the same five factors: data availability, problem difficulty, prediction quality, technical requirements and cost. Check each candidate against all five, then sort it into one of three buckets before anyone commissions a build: an automatable task (proceed), a speculative ask (do not proceed without a research phase) or a research question (investigate within a bounded scope).
TechnoLynx’s AI engineering services include the GenAI Feasibility Assessment for teams about to commit a generative AI budget: it classifies each candidate use case as automatable, speculative or research, estimates return for the automatable portion, and names explicit go/no-go criteria.
A use case that asks a model to do a repeatable, well-specified task a person does today is a very different proposition from one that asks the model to be smarter than the people who would check its work, and the first is far more likely to show measurable return.
Technical feasibility is not the same question as business viability
Technical feasibility asks whether the system can be built to work. Business viability asks whether it is financially worth building. Microsoft’s Business, Experience, Technology (BXT) framework for ISVs separates the two: business viability, experience and desirability, and technological feasibility are three focus areas, each with its own scored subcomponents. Under the technology heading, Microsoft looks at implementation and operation risks, sufficient safeguards, and how well AI and large language models fit the use case.
Microsoft then combines them to decide which use cases to prioritise: executional fit, the mean of user desirability and technical feasibility, is one axis and strategic business impact the other. BXT places use cases with potentially high business impact that are currently unfeasible, or have low demand, in its “Research” category.
The value of a use case says nothing about whether today’s models can deliver it.
The five factors that decide technical feasibility for a GenAI use case
Data: what you have, and what refining the model will need
Machine learning models need large amounts of high-quality data to produce high-quality output. For generative AI, Google frames the need as enough high-quality, representative examples to refine a model’s output. Google estimates the example counts by technique:
| Refinement technique | Examples typically needed (Google estimate) |
|---|---|
| Zero-shot prompting | 0 |
| Few-shot prompting | tens to hundreds |
| Parameter-efficient tuning | hundreds to around 10,000 |
| Fine-tuning | thousands to tens of thousands, or more |
Google’s guidance puts the range at 10 to 10,000 high-quality examples depending on the use case, and those examples must represent the questions the model will face and the answers it should give. When the use case needs more high-quality, representative examples than you have, the data factor constrains it; see our piece on data labeling and annotation services for GenAI feasibility.
Problem difficulty: realistic capability or super-human ask
METR researchers measured how long a task, timed on skilled humans, frontier models can complete: Claude 3.7 Sonnet reached a 50% success time horizon of about 59 minutes, but its 80% horizon was only about 15 minutes. METR also found models perform worse on “messier” tasks without clear feedback loops or where the agent has to seek out information itself. Those results come from software and ML research tasks with automatic scoring, and METR itself flags that real-world work differs systematically.
The practical reading is a judgement, not a figure to transfer: short, well-bounded tasks with a clear check on the output sit inside current capability, while long, open-ended tasks that need reliable success sit outside it. TechnoLynx steers engagements toward problems that create value at realistic intelligence levels and declines to commit to outcomes that would need super-human capability.
Quality bar: what an error costs in this use case
Google’s guidance asks you to weigh the impact of predictions on users, because the required quality depends on the type of prediction: a recommendation system and a policy-violation flagger do not need the same bar. Generative models add a specific failure mode, fluent output that is wrong, so a GenAI feasibility check has to ask where a person reviews the output before it matters. In an industrial case study of 41 candidate GenAI use cases, researchers judged ease of implementation largely by whether the use case drew on existing information and whether its output had a clear point of human review.
Technical requirements: serving, integration and hardware
The MLTRL authors note that model usage requirements can make or break an ML product: the Netflix Prize solution was never fully deployed because of real-world engineering costs, and engineering teams must convey memory, compute, hardware availability, network privacy and latency constraints to the ML team. Serving constraints differ sharply between cloud, on-premise and hybrid, batch and streaming. Integration with legacy systems and data infrastructure that was never organised for machine learning is common in industrial use cases.
Cost: does it pay for itself to run
Google’s guidance is blunt: most ML projects will not be approved if the solution costs more to implement and maintain than it generates or saves. For generative AI, running cost includes inference on every request for the life of the system, so the estimate needs a per-request cost at expected volume, not just a build cost. Where energy per inference is part of that estimate, see our explainer on MLPerf Power.
For a step-by-step version of these checks, including how data cleanliness is evaluated, see our walkthrough on evaluating GenAI use case feasibility before you build.
Is this use case automatable, speculative or a research question?
Each candidate gets exactly one classification, and each classification means a different commitment.
| Classification | What it looks like | Go/no-go meaning |
|---|---|---|
| Automatable | A repeatable, menial task people do today | Go: estimate return and proceed |
| Speculative | Needs capability beyond current AI, such as being smarter than its reviewers | No-go without a research phase first |
| Research question | An open question that needs investigation before commitment | Bounded go: proceed with a bounded scope |
The case study bears out the automatable end: employees linked AI to repetitive reporting, validation and data checks, one describing it as “AI could do checking for us and we then approved”. The routine, checkable task with a human approval step is the archetype, as with assistants that draft and leave the decision to a person, discussed in AI assistants and the limits of productivity.
The research question deserves honesty more than optimism. When the true answer to “would it be possible to…?” is that it needs investigating, TechnoLynx says so and flags the use case as research territory rather than engineering territory. The MLTRL framework formalises the same split: at its proof-of-principle stage the team chooses between prototype development and continued research, and the authors find the work often bifurcates. Microsoft’s BXT likewise reserves a “Research” category for high-impact use cases that are currently unfeasible.
How do I evaluate data readiness as part of a technical feasibility assessment?
In the industrial case study, the needs employees raised most often were not the ones that could start first: data readiness, rather than demand, determined where adoption began. The same organisation was ready for reporting and retrieval use cases built on existing documents, but not for forecasting, which needed integrated historical data. The authors suggest organisations should expect their first feasible use cases to be the ones built on information that already exists, and that data integration is a prerequisite for forecasting and predictive applications.
We would check four things:
- Quantity against technique: enough representative examples for the refinement method the use case needs (the table above).
- Quality dimensions: noise, missing values, outliers, class imbalance and inconsistency, the dimensions the Data Readiness Report authors propose documenting.
- Labels: general profiling tools miss ML-specific issues such as noisy labels and overlapping classes.
- Access and integration: whether the data exists in sources the system can reach, or still has to be joined across systems.
Neil Lawrence’s data readiness levels (2017) give a common language for this, with three bands, C, B and A, running from accessibility through faithfulness to fitness for the task. Lawrence argues that many failures on large data projects come from not provisioning for data preparation rather than from algorithms. The MLTRL authors make the timing point: data quality and availability issues become huge blockers because teams discover them too late. Fixing readiness once it is found wanting is a separate job, covered in our piece on the data-centric approach to AI in practice.
What a technical feasibility study should include, and what the report must answer
The industrial case study’s output is a useful model: a ranked list of candidate use cases together with the data, system and validation conditions each one depends on. We would have the final report answer, per use case:
- Which bucket it sits in (automatable, speculative, research) and why.
- Which of the five factors constrains it, and what would change that.
- What data it depends on, its readiness, and the gap to close.
- The quality bar, and where a human reviews output.
- Expected running cost against the value of the automated work.
- The go/no-go decision and the measurable criteria a proof of concept must meet.
For the risk entries, MLTRL quantifies each technical requirement as risk = p(failure) × value, with value scored 1 to 10, which surfaces ML vulnerabilities otherwise hidden in other software layers. For the proof-of-concept criteria, MLTRL asks for model performance, computational cost and end-user metrics, not one accuracy number.
Gate the decision on real, representative data
MLTRL’s proof-of-concept stage requires real and representative data, and states that confidence must come from real-world data of the use case even when synthetic data appears to mirror it. Its review at that stage re-checks data readiness: quality, validity and availability.
The framework also warns against the industry default of taking a pretrained model, fine-tuning on your data and jumping to deployment, skipping the integration and validation stages; once the process starts, no technology skips levels. Most projects do not start at the research levels, since an off-the-shelf model can enter at a later stage, but it still goes through validation for its specific datasets and use case.
What skipping the assessment costs the person who approved the scope
Gartner predicted in July 2024 that at least 30% of GenAI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, inadequate risk controls, escalating costs and unclear business value. RAND’s report, based on interviews with 65 data scientists and engineers, cites estimates that more than 80% of AI projects fail, and names expectation failures among the causes. Fortune’s coverage of MIT’s The GenAI Divide report on why generative AI pilots fail reported that about 5% of AI pilots achieve rapid revenue acceleration while the vast majority stall, attributing this to flawed enterprise integration rather than model quality. These are a prediction, an interview study and press coverage of research; they frame the risk and do not measure your project.
Three of the causes they name (data quality, cost, integration) are feasibility factors that can be checked before the budget is committed. Without the check, the sponsor who approved the scope has no defensible assessment behind it. A feasibility assessment is that record: if the project proceeds, it justifies the spend; if it stops, it shows the waste avoided.
Per-use-case feasibility runs once organisational readiness is established. That earlier question has its own method in our guide to assessing enterprise AI readiness before starting a project: readiness first, then feasibility for each use case.
Worked example: three customer-service use cases
Assume a support team with a searchable knowledge base, two years of ticket history in one system, and refund records in a separate billing system. These are assumptions for illustration, not a client case.
- Drafting replies from the knowledge base for an agent to approve. Existing documents, retrieval rather than forecasting, a clear human review point: automatable.
- Fully autonomous resolution of billing disputes. Needs reliable judgement across long, messy interactions, with no human checking before money moves: speculative under current capability.
- Predicting which customers will escalate. Plausible, but depends on joining ticket and billing history that is not yet integrated: a research question gated on data integration.
Same organisation, three verdicts. The same per-use-case sort applies beyond support; our view of generative AI for marketing classifies marketing use cases the same way.
Who can assess whether our GenAI use cases are feasible before we build?
Whether to do this in-house depends on whether your team has people who know current model limits as well as your processes and data; the case study authors note that adoption needs both kinds of knowledge to meet. When choosing a partner, ask whether they will tell you a use case is research rather than quote it as engineering.
The GenAI Feasibility Assessment does not suit organisations still deciding whether to run an AI project at all; start with readiness.
FAQ
What is an example of technical feasibility?
Knowledge-base retrieval for support agents is a typical feasible case: it draws on documents that already exist and has a clear human review point, the two criteria an industrial case study used to judge ease of implementation.
What is a go/no-go criterion?
It is a measurable condition, set before development, that decides whether a project advances. MLTRL ties such decisions to gated reviews at defined stages, such as the proof-of-concept review on real data.
