The cost of integrating AI into an existing application is not the price of one model request. The real budget includes process analysis, controlled access to data, application integration, the interface people use to review results, evaluation with real examples and monitoring after release.
For a clearly bounded capability, the Web Hat Solutions published range for a custom application with AI integration is EUR 1,500 to EUR 8,000. A narrow integration can stay near the lower end. A workflow with several data sources, rules, approvals and security requirements naturally moves toward the upper end. Work required to repair or rebuild the existing application is estimated separately.
The useful question is not only how much AI costs. It is which repeatable outcome the application must produce, for how many cases and with what level of control. That is the basis of a budget that remains credible after the first demonstration.
Key ideas in this article
- A production integration includes data, rules, review, security and monitoring, not only a model API.
- The existing application architecture and data quality can change the budget more than the visible AI feature.
- Development cost, provider usage, infrastructure and maintenance must be estimated separately.
- A narrow pilot should have measurable success criteria and should not be presented as a complete production system.
- Return should be measured per processed document, request, conversation or other meaningful business unit.
What AI integration actually includes
In a serious project, the model is only one component. The application decides what information may be sent, how the response is validated, what happens when information is missing and who can approve an action. Two features that look similar in a demonstration can therefore have very different production costs.
A complete integration connects interpretation with deterministic application behaviour. The model may classify, extract, summarize or draft. The application still handles identity, permissions, storage, required fields, duplicate detection, notifications and the action history.
- Audit the existing technology, interfaces and operating limits.
- Define the AI task and an acceptable, testable result.
- Prepare and limit the data used by the capability.
- Connect a provider or an approved self-hosted model.
- Build deterministic rules for validation and exceptions.
- Provide a review and correction interface for people.
- Add monitoring, usage limits, logging and a manual fallback.
Three useful planning bands
A controlled pilot in the EUR 1,500 to EUR 3,000 area can cover one use case, one clear data source and complete human review. Its purpose is to establish whether the available data can produce the required quality and whether the saved effort justifies the next stage.
A EUR 3,000 to EUR 8,000 production integration can include a complete workflow, permissions, exception handling, a review interface, monitoring and one or more stable integrations. A multi-department system, agent tool access, dedicated infrastructure or legacy reconstruction needs a separate estimate.
These are planning ranges, not fixed packages. Scope, risk and the state of the application determine the real estimate.
Initial cost and ongoing cost are different
Initial development covers discovery, architecture, integration, application rules, user experience and testing. Ongoing costs can include model tokens, document or image processing, search, storage, infrastructure, security updates and periodic evaluation.
Traditional application cost can often be approximated from user count and infrastructure. AI usage also varies with document length, retrieved context, model choice, the number of steps and retries. Monthly cost should therefore be calculated per useful business outcome rather than only as one provider invoice.
- Development and data preparation.
- Provider usage and external service limits.
- Application infrastructure, search indexes and logs.
- Maintenance, security and model or prompt changes.
The condition of the existing application matters first
An application with documented APIs, sound authentication and structured data can receive a new capability with limited disruption. A legacy system with mixed responsibilities, undocumented dependencies or fragile data access may need stabilization before any model is connected.
AI integration does not repair weak architecture. Adding a probabilistic component on top of unreliable data and unclear permissions increases the number of failure modes instead of reducing them.
Data quality and accessibility shape the estimate
Consistent fields, readable documents and controlled sources reduce preparation work. Duplicate files, inconsistent naming, missing history and unclear access rights increase both implementation and evaluation effort.
The team should provide representative examples, including difficult and incomplete cases. A small set of ideal examples produces an attractive demonstration but says little about production quality.
The output and the consequence of an error change the design
Classifying a request into five approved categories is easier to validate than generating a complete commercial document. An internal summary carries a different risk from an answer sent automatically to a customer.
As the consequence of error grows, the project needs stricter output schemas, deterministic checks, broader evaluation, clearer escalation and stronger human approval. Those are application capabilities and must be included in the budget.
Integrations, response time and volume add different costs
Connecting CRM, ERP, email, calendar, document storage or billing requires authentication, field mapping, error handling and service-specific limits. The cost comes not only from connecting but from preserving consistency when one system is unavailable.
Overnight archive processing can use economical asynchronous jobs. A customer assistant that must answer in seconds has different availability and performance needs. One hundred similar documents per month are also different from tens of thousands of variable files.
Autonomy and sensitive data increase responsibility
A capability that proposes information is simpler than one that can modify records, send messages or initiate financial operations. Tool access requires a distinct identity, least privilege, parameter validation, approval and an immediate way to disable the action.
Personal data, contracts, financial information and trade secrets require decisions about providers, processing regions, retention and logs before data is sent to any AI service.
How to reduce cost without reducing control
The strongest saving is to narrow the problem. One capability that removes a recurring operational difficulty can create more value than a general assistant connected to every company system.
- Start with one case type and a representative evaluation set.
- Keep exact business decisions in conventional code.
- Send only the context required for the task.
- Use smaller models for routine classification and escalate ambiguous cases.
- Batch work that does not require an immediate response.
- Track cost per accepted result and correction rate.
Measure return through the workflow
A useful estimate starts with monthly volume, current minutes per case, internal labour cost, preventable errors and expected operating cost. Human review time must be included rather than treated as free.
For requests, compare processing time before and after integration. For documents, measure accepted fields and corrections. For support, track time to a useful answer and correct escalation. If the capability cannot be measured, expansion decisions will remain subjective.
Information needed for a credible estimate
Describe the current process from input to final outcome. Provide anonymized examples, the systems that must be connected, the user roles, the monthly volume and the errors that must be blocked. Separate the essential first release from later ideas.
This evidence shows whether the next step should be a pilot, a complete integration or modernization of the application first. It also protects the project from vague promises and hidden operating costs.
Common questions
AI integration is not normally a one-time cost only. Development is a project cost, while provider usage, infrastructure and maintenance can continue after launch.
Many applications can technically be extended, but missing APIs, weak architecture or poor data may make the work disproportionate. An application audit should come before a fixed promise.
The most famous or expensive model is not automatically necessary. Restricted tasks can work with smaller models, conventional rules or a combination selected through evaluation.
A pilot is appropriate when the problem is measurable but the available data and model quality have not yet been proven. It needs a success threshold and a clear decision at the end.
Official technical references
A good budget does not buy AI in general. It funds one precise, verifiable capability that is integrated well enough to remain useful in daily work.
