Integrating AI with legacy systems

The short answer

In most enterprise AI projects, the model is a small part of the work and the integration is the project. Teams budget the reverse and then wonder where the schedule went.

The good news is that this part is ordinary engineering with known patterns. It is slow and unglamorous, not mysterious.

The four kinds of interface you will meet

A real API. Documented, authenticated, reasonably current. Integration is measured in weeks and the project is about the AI.

An old API. Exists, partially documented, behaves in ways the documentation does not describe. Most of the work is discovering the real behaviour.

Batch only. Files exchanged on a schedule. Fine for analysis, structurally incompatible with a decision that has to happen while the user waits.

No interface. Access means the database directly, a vendor gateway, or screen level automation. Each option carries a different flavour of long term pain.

Batch windows and the freshness problem

This is the constraint that kills more designs than any other. If the data updates overnight, a decision made at two in the afternoon is based on yesterday, and no amount of AI fixes that.

So establish freshness before you design. Ask how current the data actually is, not how current it is supposed to be. Then decide honestly whether the decision tolerates that lag. Some do. If yours does not, the project is a data pipeline project first, and pretending otherwise just moves the discovery to month four.

Permission propagation

Legacy systems often have their own permission model, and it rarely maps cleanly onto whatever your application uses. The shortcut is a service account with broad rights, and it is taken constantly.

That shortcut is how AI systems end up surfacing records the asking user should never see. The requesting identity has to travel all the way to the query, which is more work up front and the difference between a system you can expand and one that gets frozen after a review. Same point as guardrails.

Blast radius and writes

Reading from a legacy system is a compatibility problem. Writing to one is a risk problem, because these systems frequently have no meaningful rollback and downstream processes you have not mapped.

Start read only. When writes become necessary, make them idempotent, scope them narrowly, log every one with enough context to reverse it manually, and put a human in front of anything irreversible.

Assume there is a downstream consumer nobody remembered. In systems of this age there usually is.

The staging environment problem

Many legacy systems have no realistic staging environment. What exists is stale, partial, or shared with another team's testing.

Say this out loud early, because it changes everything about how you work: heavier reliance on contract tests, careful use of read only production access for discovery, and a rollout plan that assumes the first real test is in production. It is workable. It is not workable if discovered late.

Change approval is a schedule risk

In regulated or large organisations, the calendar cost of getting a change approved often exceeds the engineering cost of making it. This never appears on a plan, and it is a leading cause of the gap between a pilot estimate and reality, which we covered in why pilots fail to reach production.

Map the approval path in week one. Who signs, what they need, how long it takes, and whether an AI component triggers an additional review nobody has done before. Start those conversations before you need them.

How to sequence the work

Touch the hardest integration first, not last. The instinct is to build the impressive part and connect later, which back loads all the risk into the phase where you have already spent the budget.

Prove you can read real data with real permissions in week one, even if the AI is a placeholder. That single result de-risks more of the project than any amount of model work, and it turns your estimate into something grounded.

What this means for planning

Budget integration as the majority of the project, not a phase at the end. Expect discovery to change the estimate, and set the expectation that it will. The cost buckets are in what it costs.

And pick a partner who asks pointed integration questions in the first meeting. Vagueness there is the clearest predictor of a repricing conversation later, which is why it is on the list in how to choose a partner, and why we start from your systems rather than from the model when we build production AI, end to end.