Why AI integration costs vary

An assistant that drafts a reply leaves the final decision with the person reading it. Connecting that assistant to a customer database changes the job. A misunderstood email can now become an incorrect record. If the database accepts an update but the confirmation never arrives, the integration also needs a way to find out what happened before trying again.

We think this change in what the software is allowed to do explains much of why two AI integration quotes can be difficult to compare. Both may describe the same visible feature while including very different amounts of work around it. Permissions, review and recovery become part of the price because they determine what happens after the model produces its answer.

In this article, we follow one request from an inbox to a business system and look at where that work comes from, including the charges that continue after launch. We give no price range. We don't publish one, and the sections below explain why a single figure would say little about a particular project.

Comparable quotes follow one request to the end

We use "AI integration" to mean a model connected to a task a team already runs, with agreed permissions in the systems that task touches. A chat tool whose answers a person copies into another system by hand is a different purchase.

Consider a hypothetical service request arriving by email. A model extracts the relevant details, a member of staff checks the draft, and the approved fields go into a business system. Even this small process contains several decisions. The integration needs permission to change a record, and someone needs to decide what happens when information is missing or the reviewer rejects the draft.

A supplier could quote for only the extraction step. Another could include the review screen, the connection to the destination and the handling of failed updates. Both would be describing an AI integration. The difference becomes visible when the proposal follows a request all the way through, including the cases that cannot proceed normally.

Conflicting records and an unavailable destination are part of that picture, as is the person responsible for the result. In our view, a price is easier to interpret once those responsibilities are clear.

Work remains after the first useful draft

The first useful draft answers one question: whether the model can help with the information in the request. There is still work between that result and a system the team can use. The incoming message has to reach the model, the reviewer needs a way to correct it, and the approved fields have to reach the right destination under the right permissions.

Access can change the design. A destination with no usable interface, or an account the organization cannot authorize, may require a different connection. That uncertainty affects both the work and the delivery date, which is why we confirm the named systems, their interfaces and the access during scoping.

Testing and handover take time too. The person taking over needs to be able to find a failed request, understand whether it can be retried and see which limitations remain. The client's team also contributes time: explaining the process, providing suitable test inputs, arranging access and reviewing the results. That effort exists even when it does not appear on the supplier's invoice.

Running the system brings its own charges

The implementation fee pays for building the agreed system. Running it can bring separate charges for model usage, hosting, software licences, monitoring and maintenance. Which costs apply depends on the design and the providers chosen for the project.

For the email example, a request processed twice can mean another model call. A long attachment can require more processing than a short message. Human review also continues after launch, and the time available to check drafts may become a constraint when the queue is busy.

We think an operating estimate is most useful when it connects each charge to what drives it and names who pays it. It should use the selected providers' current rates and terms, and say which assumptions came from a test workload. Actual usage can differ. Alerts, usage limits and a way to pause the process make those differences easier to manage.

Questions that make quotes comparable

A lower quote may leave work with the client's team or exclude a difficult connection. A higher quote may include something the project does not need. We suggest putting the same questions to each supplier:

1. Which single workflow and which named systems are included?
2. What inputs and access must your team provide?
3. What actions may the integration take, and which require approval?
4. Which normal cases, exceptions and failures will be tested?
5. What evidence will support acceptance, and who reviews it?
6. What happens when the scope changes or a dependency blocks progress?
7. Which code, configuration and operating notes are handed over?
8. Who owns maintenance, and what support is included after handover?
9. Which recurring charges are separate from the fixed implementation price?

Written answers give both sides something more useful than a feature name and a total. They show how much of the work each proposal actually covers.

Recovery from a failed request belongs in the design

Return to the update whose confirmation never arrives. The destination may have accepted the record, even though the integration cannot yet tell. An automatic retry could create a duplicate. What should the integration do next? The answer has to be designed: a way to check what the destination holds, and a way for someone to stop the process while the problem is investigated.

We would raise that case before implementation, when the expected result can still shape the work. Denied permissions, incomplete inputs, repeated events, rejected drafts and unavailable dependencies deserve the same attention. An irreversible action also needs an agreed review or recovery procedure before it is enabled.

Our guide to testing an AI assistant explains how expected outcomes become test cases and how to record their limits. Failed and untested cases remain part of the evidence. Passing an agreed set of checks supports a decision about that system, without guaranteeing that every future case will succeed.

Some tasks do not need a custom build

Some tasks already fit a feature in the organization's software. Others can be handled by a fixed rule. Those options still have access, review and maintenance needs, but they may remove the reason for a custom AI build. We check for them first.

Our build-versus-buy guide explores those choices. Where the usefulness of AI remains uncertain, a proof of concept can investigate a specific question before a separate production project is agreed.

How we scope an integration

At Lua Haus, an AI integration engagement covers one workflow and named systems, with agreed permissions, tests and a handover. We agree the work and a fixed price before it starts.

This article cannot say what a particular integration should cost. The workflow boundary, the interfaces, the quality of the inputs, the exceptions, the allowed actions and the acceptance checks shape a quote, and they differ from one project to the next. For the same reason, we have no standard delivery deadline.

A first conversation can begin with a short description of the task, the systems involved, the person who would own the result, and any timing or budget constraints. Confidential documents, customer records and credentials should stay out of email. Sample data and access can follow through an agreed channel once it is clear what the project needs.