Ask anyone who has delivered AI into a real business where the time went, and the answer is rarely “the model”. Choosing and prompting a model is often a matter of days. The weeks go to everything around it: the ERP from 2009, the database only one person understands, the vendor API that behaves differently from its documentation, and the customer records stored in three systems with three different spellings.

This is the unglamorous part of AI adoption, and it is where most projects stall. This article sets out a practical approach to integrating AI with the systems you already run — without replacing them first.

Why AI projects stall at integration

AI demos are built on clean inputs: a tidy document, a well-formed question, a sample dataset. Production inputs come from your existing systems, and those systems were built for different purposes, by different people, over many years.

Three problems show up almost every time:

  • Access. The data the AI needs sits in systems with no API, a restrictive API, or an API nobody has the credentials for.
  • Quality. The data exists but is inconsistent: duplicates, free-text fields, missing values, conflicting records.
  • Process. The system of record is not the whole story — part of the workflow happens in email, phone calls or someone’s spreadsheet.

None of these are AI problems. All of them decide whether an AI project succeeds.

Step 1: Map before you build

Before writing any code, map what you are dealing with:

  • Systems: every system the solution must read from or write to, its owner, and how it can be accessed.
  • Data: where each piece of information lives, and which system is the source of truth when two disagree.
  • Workflow: how the work really happens today, including the off-system parts.

This mapping is the core of a discovery phase, and it is the cheapest point at which to discover that the integration you assumed would take a day will take a month.

Step 2: Measure the data

Do not trust descriptions of the data — measure it. Pull a real sample and count: how many records, how many duplicates, which fields are reliably filled, how often free text replaces structured values.

The results often change the plan. An AI that extracts data from invoices is a very different project if half the invoices are photographs. A customer-service agent behaves very differently if a quarter of customer records are duplicates.

Step 3: Choose the least invasive integration

Integration options, from least to most invasive:

  1. Read-only access through an existing API or a reporting database.
  2. Writing back through the official API, with the same permissions a human user would have.
  3. Working through the user interface, with an agent that operates the application the way a person does — slower and more fragile, but sometimes the only option for systems with no API.
  4. Changing the legacy system itself — rarely worth it for a first project.

Start as far up that list as you can. Read-only integrations carry little risk and let you prove value before anyone has to approve writing into a production system.

Step 4: Add a layer, do not replace the system

The most reliable pattern is to leave legacy systems in place and add a thin layer between them and the AI:

  • an integration layer that reads from and writes to the old systems through stable, tested interfaces;
  • a clean data view that resolves duplicates and normalises formats for the AI’s use;
  • the AI component itself, which only talks to the clean layer.

This keeps the AI insulated from the quirks of each system, makes it possible to swap models without touching integrations, and means the legacy system can be replaced later without rebuilding the AI.

Step 5: Keep humans in the loop where data is weakest

Where data is incomplete or ambiguous, design the AI to hand the case to a person rather than guess. A system that confidently processes most cases and routes the rest to a human is far more useful — and far safer — than one that attempts everything.

Over time, the cases humans handle become exactly the examples you need to improve the system.

Step 6: Plan for adoption

The last obstacle is rarely technical. People who have done a job the same way for years need to see that the new system makes their day easier, and they need to trust it.

Involve the people who will use the system from the first week, show them early versions, and treat their complaints as requirements. A system that is technically complete but not used has not been delivered.

Who does this work

This kind of project needs someone who can move between the business, the legacy systems and the AI — writing production code while also sitting with the people whose work is changing. It is the reason the forward deployed engineer model has spread from AI vendors to the businesses buying AI: one senior engineer, embedded with your users and your data, who owns the outcome rather than a ticket list.

Whoever does it, the principle is the same. The model is the easy part. The value is in making it work with what you already have.