Pick the first enterprise AI use case by scoring candidates on business value, data readiness, risk and integration effort, and start with the one that scores high on value and low on the other three, usually a document, classification or drafting task inside an existing workflow. A pilot costs $30,000 to $80,000 (€26,000 to €70,000, £22,000 to £60,000) and takes six to ten weeks. Taking it to production costs two to three times the pilot, because that is where security, monitoring, evaluation and fallbacks are built. Most pilots stall because nobody budgeted for that second step.
Prices are in US dollars. Euro and pound figures in parentheses are approximate, rounded conversions. Quotes are issued in the currency of your contract.
Most companies have now run an AI pilot. Far fewer have an AI system that staff use every day. The gap is not the technology, which is good enough for a wide range of tasks, and it is not the data, which is usually adequate for the first use case. The gap is the choice of use case and the plan for what happens after the demo. This post gives you a way to score candidates, the honest cost and timeline of a pilot, the reasons pilots stall, and the work that turns a pilot into a system the business depends on.
How do you score candidate use cases?
List every suggestion that has come up, from the board's and from the floor's, and score each on four things. Value is what it saves or earns per year if it works. Data readiness is whether the inputs exist, are accessible and are clean enough. Risk is what happens when the model is wrong, and who notices. Integration effort is how many systems and people the result has to reach. Score each from 1 to 5, and look for high value with low scores on the rest.
| Candidate | Value | Data readiness | Risk if wrong | Integration effort | Verdict |
|---|---|---|---|---|---|
| Classify and route inbound documents (invoices, claims, support emails) | High | Ready, documents already arrive in one place | Low, a person still handles the case | Low, one queue | Start here |
| Draft responses, summaries or reports for a person to approve | High | Ready, needs examples of good output | Low, human approves | Low to medium | Strong first or second |
| Extract fields from contracts, forms and PDFs into systems | High | Ready if the documents are digital | Medium, wrong data enters a system | Medium, writes to the ERP or CRM | Second wave |
| Predict demand, churn or maintenance need | High | Needs two or more years of clean history | Medium, decisions follow the number | Medium | After data work |
| Customer-facing chatbot with authority to act | Medium | Needs full knowledge base and account access | High, errors reach customers | High | Not first |
| Autonomous pricing or credit decisions | High | Needs history and regulatory review | Very high | High | Not in year one |
The pattern is consistent. The first production AI system in most established companies is a reader, a sorter or a drafter that sits inside an existing workflow and hands the result to a person. It is unglamorous and it pays back. What data you need before AI can help your business explains why the first two rows need so little of your own data.
What does a pilot cost and how long does it take?
A well-run pilot takes six to ten weeks and costs $30,000 to $80,000 (€26,000 to €70,000, £22,000 to £60,000). The first two weeks are spent defining what good looks like: a set of real cases with the correct answers, agreed with the people who do the job today. The middle weeks build the system against a general model, with prompts, retrieval over your documents, and the glue to your data. The final weeks measure it against the agreed cases, with the people who will use it in the room. The output is a number, such as 92 percent of invoices routed correctly against a human baseline of 95 percent, and a demo running on real data.
A pilot that does not end with a number is a demo. Demos impress and then stall, because nobody can say whether the thing works. How much does it cost to add AI to an app covers the cost drivers in more detail.
Why do pilots stall?
- The use case was chosen for the demo. A chatbot over the company handbook is easy to show and hard to make valuable. Pilots chosen to impress rarely have a workflow to live in.
- Nobody owned the outcome. The innovation team ran it, the operations team did not ask for it, and when the pilot ended there was nobody whose numbers improved if it went live.
- Good enough was never defined. Without an agreed accuracy target and a human baseline, every error becomes an argument about whether the system is ready.
- Production was not budgeted. The pilot cost $50,000 (€44,000, £37,000), and the proposal to take it live cost $150,000 (€130,000, £110,000), which nobody had planned for. The pilot is quietly filed.
- Security and legal were consulted last. Questions about where the data goes, which model provider sees it and how decisions are logged arrive at the end and stop everything.
- It sat outside the workflow. A separate tool the team had to remember to open. Within a month, nobody did.
Every one of these is avoidable at the start, by choosing a use case the operations owner wants, agreeing the target up front, involving security in week one and budgeting the production phase before the pilot begins. AI business empowerment describes the process-first approach that avoids most of them.
What does production hardening add?
Taking a working pilot to a system the business relies on costs two to three times the pilot and takes another two to four months. The money goes on things the demo did not need.
| Area | What the pilot had | What production needs |
|---|---|---|
| Security and data handling | Sample data, a developer's API key | Access control, data residency decisions, a model provider agreement, redaction of personal data, an audit log of every input and output |
| Integration | A spreadsheet export and a demo screen | Live connection to the queue, the ERP or the CRM, with the result landing where the person already works |
| Evaluation | One test on 100 cases | A growing test set, run on every change, with accuracy tracked over time and alerts when it drops |
| Monitoring | None | Latency, cost per case, error rates, provider outages, and a dashboard the operations lead can read |
| Fallbacks | None | What happens when the model is unsure, slow or unavailable: route to a person, use a second provider, or queue and retry |
| Human review | The developer checked | A confidence threshold below which a person decides, with the person's correction fed back into the test set |
| Change control | Prompts edited live | Versioned prompts and models, tested before release, with the ability to roll back |
None of this is exotic. It is the same discipline any production system needs, applied to a component whose output is probabilistic. Teams that have run production software before find it familiar. Teams that only ran the pilot find it surprising, which is why the budget line matters.
How do you structure the program?
- Score and choose. Two weeks, with operations, IT and security in the room. One use case, one owner from the business.
- Pilot with a target. Six to ten weeks, ending in a measured result against a human baseline and a go or no-go decision.
- Harden and integrate. Two to four months, producing a system inside the workflow with monitoring, fallbacks and review.
- Run in shadow, then live. Four weeks where the system proposes and people confirm, then a staged rollout with the human threshold tightened as accuracy proves out.
- Second use case. Most of the hardening, the provider agreement, the logging, the evaluation harness, is reusable. The second system costs much less than the first.
A pilot is ready to go to production when
- It has a measured accuracy against a human baseline, on real cases.
- A named business owner wants it in their workflow.
- Security has agreed where data goes and what is logged.
- The cost per case is known and lower than the manual cost.
- The production budget, two to three times the pilot, is approved.
How 7L approaches this
7L International builds custom software and AI systems for established organizations from business hubs in New York, London and Athens. Founded during the Greek financial crisis, we have supported more than one hundred organizations, and our approach to AI starts with the process and the decision rather than with the model. We run pilots that end in a number, budget production before the pilot starts, and build the hardening into the same team that built the demo, so nothing is thrown away. Our enterprise software development guide shows where an AI system fits in a wider program, and building software for regulated industries covers the extra care healthcare and finance need. If you have a list of AI ideas and no clear first one, send us the list and we will score it with you.
Frequently asked questions
How much does an enterprise AI pilot cost?
$30,000 to $80,000 (€26,000 to €70,000, £22,000 to £60,000) for a six to ten week pilot that ends with a measured result on real cases, built on a general model with retrieval over your documents and integration to your data. Production hardening, the security, monitoring, evaluation and fallbacks a daily-use system needs, costs two to three times the pilot and takes a further two to four months.
Do we need to train our own model?
For the first use case, almost never. General models read, classify, extract, summarize and draft well enough that the work is in prompting, retrieval over your own documents and integration, not in training. Training or fine-tuning becomes relevant for predictions from your own history, which needs years of clean data, or for tasks so specific to your business that general models cannot learn them from instructions.
What accuracy is good enough for production?
Compare to the people doing the task today, not to perfection. If humans route invoices correctly 95 percent of the time and the system reaches 92 percent with a confidence score, route the confident 80 percent automatically and send the rest to a person. The combined result usually beats the human baseline and frees most of the hours. Agree the target before the pilot starts.
Which model provider should we use, and does our data leave the company?
That is a security and legal decision made in week one, not at the end. Major providers offer enterprise agreements where your data is not used for training and can be kept in a chosen region. Some use cases justify a model hosted inside your own infrastructure. The system should be built so the provider can be swapped, which also gives you a fallback when one is unavailable.
Why did our pilot work but never go live?
Usually one of three reasons: nobody in operations owned it, so there was no one whose numbers improved; good enough was never defined, so every error reopened the question of readiness; or the production cost, which is two to three times the pilot, was never budgeted. All three are fixed by how the pilot is set up, which is why the choice of use case and owner matters more than the technology.