AI Feasibility Study: What It Should Contain and Cost

An AI feasibility study answers one question before you spend build money. Can this specific use case work with your data, systems, budget and legal position, and is it worth doing? A good one covers four kinds of feasibility: data, technical, economic, and organizational including compliance. For a single use case it takes one to three weeks and ends in a written go, no-go, or go with conditions.

That last part is what many feasibility studies miss. Plenty of documents with the title are really proposals. Every use case turns out feasible, and the recommended platform happens to be the author's. The running cost is nowhere to be found.

If you want an AI feasibility study template, the four sections below are it. Then come cost, duration, the difference from a proof of concept, and the red flags that give a sales document away.

Data feasibility

Data feasibility asks whether the data the use case depends on exists, is good enough, and can be used for this purpose. It decides AI use case feasibility more often than the model does. It is also the part most often answered from interviews instead of from the data itself.

• Where each input lives, who owns it, and how it can be read: API, export or direct database access.
• A measured sample of a few hundred real records, with numbers. The share missing a required field, the share in a format the system cannot read, the share in another language.
• Whether a set of examples with known correct answers exists, or what it would take to build one. Without it, nobody can measure accuracy.
• Whether the sample looks like production. Last year's clean archive is not this year's inbox.
• Whether personal data is involved, and any contract terms that restrict how the data may be used.

Technical feasibility

Technical feasibility asks whether a model can do the task to the standard the business needs, inside the systems you already have. The standard matters more than the model. 'It works' means nothing until someone says what accuracy, on which cases, at what latency.

• An accuracy threshold agreed with the business before any testing. For example, the share of extracted fields that must be correct without a human edit.
• A measurement on real examples, usually 50 to 100, against that threshold. Hand-picked demo cases do not count.
• Where the model would run, with the reason: a provider API on an EU region endpoint, a private cloud deployment, or open weights on your own hardware.
• The integration surface. What the system reads from, what it writes to, and what breaks when either side changes.
• Failure handling. What happens when the model is wrong, unsure or unavailable.

A study that names a model but no threshold has done the easy half. Picking a model takes an afternoon. Agreeing what correct means can take a week, and that week is the valuable part.

Economic feasibility: expected return and running cost

Economic feasibility is where a study earns its fee. It should put a number on the return, a number on the build and a number on the running cost. It should also show the arithmetic, so you can argue with it.

A worked illustration. A support team handles 4,000 tickets a month. If drafted replies save three minutes on 60 percent of them, that is 120 hours a month. At a loaded cost of €35 an hour, that is roughly €4,200 a month.

Against that sits the build. One AI feature inside existing software usually falls between €10,000 and €25,000 on our published pricing. Then the running cost: model usage, hosting, monitoring, and someone checking quality every week. At that volume the model bill on a current mid-tier model is usually a few hundred euros a month or less. Review time and maintenance often cost more than the model.

Payback in that illustration lands somewhere between three and eight months, depending on the build and the running cost. That is a reasonable project. Halve the volume or the time saved and it becomes a marginal one, which is exactly what the study should tell you.

• Expected return per month, with the assumptions written out: volume, time saved, hourly cost, cost of an error.
• Build cost as a range tied to a defined scope, not a day rate.
• Running cost per month: model usage per case times volume, plus hosting, monitoring and human review.
• Payback period, and the volume or accuracy below which the project is not worth doing.

That last item is the one an honest study includes and a sales document leaves out. Knowing where the project stops paying is as useful as knowing where it pays.

Organizational and compliance feasibility

This part asks whether your organization can carry the system, and whether the law allows it in the form proposed.

• A named process owner, and a decision on who reviews outputs and who acts when the model is wrong.
• What changes for the people doing the work today, and whether anyone asked them.
• GDPR: the personal data involved, the lawful basis for this new purpose, where processing happens, and the processing agreement with any model provider.
• An EU AI Act classification of the use case, with the reasoning written down.
• Who maintains the system after launch, and from which budget.

On the AI Act, classification follows the use case, not the model or the hosting. Most business software, such as internal copilots, document search and support assistants, is limited or minimal risk. The Article 50 transparency duties have applied since 2 August 2026. After the Digital Omnibus, high-risk obligations for Annex III areas such as employment, credit scoring and education apply from 2 December 2027.

If a use case is high risk, the Omnibus also matters for company size. Small mid-caps, under 750 employees and up to €150 million turnover, now share some SME relief. That includes simplified technical documentation and proportionate quality management. A good study says which of these rules apply to you. It does not recite all of them.

What an AI feasibility study should cost, and how long it should take

For one use case at a mid-sized company, expect one to three weeks of senior time. One week is enough when the data sits in one system and the use case is a common one. Three weeks is right when the data needs labeling or the use case touches a regulated decision.

In our view, a proper AI feasibility analysis for one use case should cost roughly €5,000 to €15,000. Our own reference points: a five day review of a single existing AI feature is €4,500 to €6,500. A two week readiness assessment covering several candidate use cases is €9,500 to €14,000. Both are fixed fee and end in a written document.

Two prices should prompt questions. Free usually means the study is part of a sales process, and its conclusion was settled before it started. Well above €20,000 for one use case can be justified, for example by heavy data labeling or a regulated decision. More often it is a strategy program carrying a feasibility label.

AI feasibility study vs proof of concept vs readiness assessment

The three get confused because they all happen before a build and cost roughly the same. They answer different questions.

A proof of concept answers a narrower question than people expect. It shows that a model can produce plausible output on a sample, which is almost always true and rarely the issue. It does not tell you whether the data holds up at volume, or what production will cost to run.

An AI feasibility assessment asks the wider question for one use case. A readiness assessment asks it for the company: which use cases, in which order, and whether the foundations can carry any of them. In most cases the order that works is simple. Run a readiness assessment when you do not yet know the use case, and a feasibility study when you do. Add a proof of concept only when the feasibility work finds a genuine technical unknown. Many projects never need the third step.

Red flags: when the feasibility study was really a sales document

A study written to close a deal reads differently from one written to inform a decision. These are the signs we look for when someone asks us for a second opinion on AI project feasibility.

• Every use case is feasible. A supplier whose studies never conclude no is not studying anything.
• The recommended platform is the author's own product or partner, and no alternative was priced.
• There is a build cost and no running cost.
• The data section describes systems and fields but quotes no numbers from a real sample.
• Accuracy claims come from a demo with hand-picked inputs, and no threshold was agreed beforehand.
• The compliance section says 'GDPR compliant' and stops. No lawful basis, no processor, no AI Act classification.
• The next step is a large build with no checkpoint and no stated condition for stopping.
• It arrived as slides, and the reasoning behind each conclusion is not written down anywhere.

One more, about who wrote it rather than what it says. Authors who will never build anything tend to produce an architecture diagram without a cost per query. Authors who will build it have a reason to inflate the scope. The defense is the same for both: insist on running costs and a stated reason to stop.

Our own answer to that tension is a fixed fee that comes off the build. If Resser builds what the assessment recommends within six months, on a project above €50,000, the fee comes off the first invoice. If you take the document to another supplier, that is a fair outcome too. Advice from people who also build it tends to be specific about cost, because they may have to deliver at that price.