AI Integration Project Cost: Systems, Permissions and Change

AI project estimates concentrate on the model and spend their time on integration. The systems an AI capability must read from and act on determine the effort, and their quality varies enormously — one well-documented API and one legacy system with a nightly file export are not comparable units of work. This guide covers scoping it honestly, drawing on FISTA Solutions' AI agents delivery. It complements ai agent cost by use case and ai modernization cost.

Why does system count dominate?

Because each system is a separate integration with its own interface, authentication, data model, pagination, rate limits, and error behaviour. Six systems is six integrations, not one integration done six times.

Effort also grows faster than linearly, because reconciling entities and definitions across systems is work that none of the individual integrations requires. Two systems need one reconciliation; six need considerably more.

System characteristic	Effort	Maintenance
Modern documented API	Low	Low
Undocumented or partial API	High	High
Delegated authorisation supported	Low	Low
Service account only	High, architectural	Ongoing risk
File export or batch only	High	High
Screen automation required	Very high	Very high

Why is authorisation propagation hard?

Because many systems were built for service-account integration rather than delegated user access. Propagating the acting user's permissions through to the source system is what prevents an AI capability from granting every user its own broad access.

Where a system does not support it, the options are unattractive: accept the exposure, build a permission mirror that must stay synchronised, or restrict the capability. That decision is architectural and should be made early rather than discovered during build. See what is a confused deputy attack.

What about systems without APIs?

A different order of effort. File exports on schedules, direct database access, or screen automation are all fragile, slow to build, and expensive to maintain, and each introduces failure modes the others do not.

A single such system can exceed the cost of several well-documented ones, which is why a survey that counts systems without assessing their interfaces produces estimates that are wrong by a large multiple.

Why is each integration a maintenance obligation?

Because the source system changes independently. APIs are versioned and deprecated, schemas evolve, authentication is updated, and vendors change behaviour without consulting integrators.

Every integration therefore requires ongoing attention, and that recurring cost scales with system count. Estimates that treat integration as a build cost understate the total substantially over a system's life.

Why does change management matter to cost?

Because an integration that works technically and changes no behaviour has delivered nothing. The benefit comes from people working differently — trusting the output, skipping the step it replaces, escalating rather than working around it.

That is organisational work, it is frequently unresourced, and it is why technically successful projects deliver disappointing returns. It belongs in the cost estimate as a line rather than as an assumption.

How should integration be scoped?

By surveying the systems before committing. For each: does it have an API, is it documented, does it support delegated authorisation, how does it notify change, and who owns it. Those five answers produce an estimate that survives contact with the build.

Half a day per system spent on that survey changes estimates more than any amount of solution design.

What reduces the cost?

Fewer systems. A capability that reads from three systems instead of six is more than half as cheap, because the reconciliation work falls away too. Narrowing scope to the systems that genuinely matter is the largest available saving and the one teams resist, because every stakeholder wants their system included.

What should you do first?

List the systems your intended capability must touch and check which support delegated user authorisation. That single question separates straightforward integrations from architectural problems, and it is answerable in a day.

How does the second project compare?

Substantially cheaper if the first built shared infrastructure. Authorisation propagation, connector patterns, error handling, and observability are the same problems in every integration, and solving them once as platform capability makes each subsequent project a matter of the specific system rather than the whole stack.

Organisations that build each AI project as a standalone integration pay the full cost repeatedly. That compounding is the strongest argument for treating the first project as platform-building rather than as a point solution, even though it makes the first estimate larger.

What is the role of middleware?

Useful where it already exists and rarely worth introducing for an AI project alone. An organisation with an established integration layer should use it; one without should weigh the cost of introducing one against the number of integrations planned, because middleware carries its own operational burden and learning curve.

How FISTA Solutions helps

FISTA Solutions surveys system interfaces and authorisation models before estimating, treats systems without delegated authorisation as architectural decisions rather than build tasks, budgets integration maintenance as recurring, resources change management as a line rather than an assumption, and narrows system scope where the value does not justify the integration, through AI agents, AI enablement, and forward deployed engineers. The record behind the approach is 150+ projects for 50+ companies with 99.9% uptime.

To estimate an integration before it estimates you, message FISTA on WhatsApp, or read ai agent cost by use case.