Assessing an AI project's feasibility before choosing a model.

This page examines the organisational and economic conditions that can make a project impractical or unsustainable.

To estimate them, the intended service must be clear. This page does not assess the technical complexity of a solution that gives correct, useful answers to the expected requests, or the work needed to build it. Those are separate aspects of feasibility that call for a technical assessment. Passing the checks below does not, on its own, guarantee the quality of the answers.

The availability of data and the people who can prepare it is an initial investment to estimate.

• Where is the required data, and who can authorise access and use?
• Is it sufficiently complete, current and representative of the intended work?
• Who can extract, correct, organise and describe it with the necessary metadata?
• Are labelled examples or reference results needed? Who can prepare and verify them with domain expertise?
• What people, time and costs will this work require? How will the data be kept up to date?

Labelling is not necessary for every AI project: it depends on the task and approach. When it is needed, the business must be able to produce and verify reliable labels. Even without labels, preparing and maintaining data can account for a substantial part of the investment.

The first check concerns the information that must enter the AI workflow:

• Can the client's data be sent to an external AI service?
• Does it include personal or confidential data, or data subject to contractual or regulatory restrictions?
• What terms does the provider offer for processing, retention and location?
• Can the data be minimised or anonymised? If pseudonymised, what could still link it to a person?

Pseudonymisation can reduce risk, but data that can still be linked to a person remains personal data. If some data cannot be sent to an external service, would the project still work without it? Could the request be reframed, or the sensitive information kept in a separate, controlled stage? If the model needs that data to produce a useful result, the environment and workflow must meet the relevant constraints.

Boundaries and security controls for the AI application →

Once the data constraints are clear, estimate the practical requirements:

• Response time: how long can a user wait for each request?
• Concurrency: how many requests will run at once, both normally and at peak times?
• Continuity: what availability and growth are required?
• Total cost: what does each request cost at the expected volume? What will data preparation, integration, human review and infrastructure management add?
• Production operation: who will oversee the service, collect reports and detect any decline in result quality? What data, people and budget will be available to respond?

These factors must be considered together. A solution may be too slow, costly or capacity-limited for the workload, or incompatible with the project's data. Work continues after release: monitoring and subsequent intervention bring costs and responsibilities that must be planned from the start.

The choice depends on data, performance, costs and operational capacity.

Managed AI services accessed through APIs

Services such as OpenRouter, the OpenAI API or managed cloud provider APIs can offer straightforward access to models and scalable capacity. They may suit a project when its data can be used under the service's terms and reducing operational work matters.

Check costs, data retention and location, use for training, and the applicable agreements. With an intermediary such as OpenRouter, the model provider also matters, particularly if routing can change. Managed cloud APIs may offer different network and geographic options: the service's name alone says little about its privacy arrangements.

Models on dedicated cloud resources

Another option is to run a model on dedicated cloud resources, such as GPU machines on Azure or AWS. This gives more control over the model, network and access, but means operating the model and paying for the infrastructure. Privacy and compliance still depend on configuration and applicable agreements.

Models in a local environment

A model on your own infrastructure can give more control over the data's path, but requires hardware, updates, monitoring and maintenance. GPU memory limits which models will run; response time and capacity also depend on computing power, request length and concurrent users. Before choosing this route, measure latency and workload on the proposed hardware with representative tests.

The choice needs explicit constraints and an estimate of the work the business must support.

1. What service is intended, and which data is essential?
2. Can the business provide, prepare and update the data, including labels or reference answers if needed? What initial investment is required?
3. Which data can be sent to external services? Is the service still viable if some data cannot be sent?
4. What response times, availability and request volumes are required?
5. What total cost is sustainable, including initial preparation and production operation?
6. Who will monitor the service, detect any decline in quality and respond over time?
7. What level of control over the infrastructure and internal management is required?
8. Which option best meets these constraints: a managed API, dedicated cloud resources or local infrastructure?
9. Once these constraints are clear, which candidate models might meet the task, and which technical tests will assess their quality?

These answers clarify the constraints and investment required before choosing the infrastructure.

A practical example: applications with built-in AI →

The next step: model selection, costs and continuity →

A selection of primary sources supporting the criteria above:

• NIST — AI Risk Management Framework, Core (opens in a new tab): testing and measuring quality before release, data assessment and production monitoring.
• OpenAI — evaluation best practices (opens in a new tab): success criteria, test cases, metrics and repeated checks to assess answer quality.
• Microsoft — evaluating answers in RAG systems (opens in a new tab): a concrete example of assessing relevance, grounding and completeness.
• Google Cloud — data labelling (opens in a new tab): the role of labelled data in projects that need it.
• EDPB — summary of its pseudonymisation guidelines (opens in a new tab): pseudonymised data remains personal when it can be linked to a person.
• OpenAI — API data controls (opens in a new tab): data use, retention and available controls.
• OpenRouter — privacy policy (opens in a new tab): data handling and differences between model providers.
• Microsoft — model deployment types (opens in a new tab): processing location, performance and billing options.
• vLLM — request memory configuration (opens in a new tab): how GPU memory, request length and concurrency relate.