The short answer
To integrate AI into existing systems, start from the systems, not the model. Establish what your infrastructure, throughput and tolerance for failure can absorb, map how data and tasks will move between the model and everything around it, and design for how models behave: slow, variable and occasionally wrong. That means queues, timeouts, retries, fallbacks and human review from the first day.
Add the new capability alongside what already runs, so no working process depends on an unproven one. Order the changes so the first ones return something people can use early, and measure each step against the old way of working.
Start from the estate, not the model
Most AI plans are sized against the model. The harder questions are about the estate that has to carry it: the applications, databases, networks and processes already running the business.
- Infrastructure. An outside service needs network access, rules on what data may leave, and a contract. A model on your own servers needs suitable hardware and people to run it.
- Throughput. How many requests arrive at peak, how large they are, and how quickly each answer must come back.
- Failure budget. How much delay or error each process can absorb before a customer, a deadline or a regulator is affected. A monthly report can wait an hour; a checkout screen cannot wait ten seconds.
- Interfaces. How data gets in and out of each system: a modern interface, a database, a scheduled export, or nothing but a screen.
AI in legacy systems
Older systems set the terms more often than they block the work. Read from a database copy or a scheduled export rather than the live system, so the model's load never slows the system of record. Write back through the system's own import routine so its validation rules still apply. Driving the old screens as a person would is a last resort: it works until the screen changes.
Map how data and tasks move
A model is one component in a chain that already exists. For each use, write down:
- Trigger and input. What starts the work, and what the model receives. Strip out anything it does not need.
- Output. Structured fields a system can check, rather than free text another system has to interpret.
- Destination and owner. Where the result goes, from a review queue to a system of record, and who answers for it when it is wrong.
Settle the AI layer and the architecture underneath it together: built months apart by separate teams, the two rarely fit.
Design for how models actually behave
Most components answer in milliseconds, give the same answer to the same request and fail loudly. Model calls can take seconds, vary from one call to the next, and can be wrong while sounding certain. The design has to absorb that.
- Queues and timeouts. Put model work on a queue so the system that asked can carry on, and give every call a time limit with a defined outcome when it runs out.
- Safe retries. Retry with a growing pause between attempts, and make every action safe to repeat, so a retry cannot create the same invoice twice.
- Validation. Check each output before use: expected structure, values in range, totals that add up, codes that exist in the master data.
- Fallbacks. When the model is slow, down or wrong, the work goes to the previous process, a simpler rule or a person. A bad answer should degrade the experience, not stop the process.
- Human review. Decide in advance which cases a person must see: high values, failed checks, anything that changes a system of record.
A hypothetical example shows why throughput belongs in the design. A team receives 2,000 documents a day and each model call takes 10 seconds. One at a time, that is 20,000 seconds, about 5.6 hours, before a single retry. Four at once brings it to about 1.4 hours, but four times the capacity then has to be there at the peak.
Common integration patterns
Most AI integration work falls into four patterns.
| Pattern | What it needs | Main risk |
|---|---|---|
| Assistant beside an existing tool | Access from inside the tool people already use, read access to the work on screen, a clear way to accept or reject each draft | Drafts accepted without being read |
| Document processing pipeline | Intake where documents arrive, extraction into fixed fields, validation, a review queue for exceptions, an import route into the destination system | An extraction error that passes validation and reaches a system of record |
| Retrieval over internal documents | An index kept current, each document's access rights carried into it, answers that cite their sources | Showing users material they are not cleared to see, or answering from outdated documents |
| Agents acting through existing systems, with approval | Narrow access through each system's own interfaces, approval for every change to data, a record of every step | A wrong action in a live system |
The first three read and draft, which makes them the safer place to start; add agents once the controls are proven. Our guide to AI agents for enterprise covers those controls.
Add capability alongside, not in place
The quickest way to lose a year is to make a working process depend on an unproven one. Run the new path beside the old one and move work across in steps: first in shadow, where the model processes real work and its output is compared with what people did; then assisting, where it drafts and people decide; then a defined class of cases routed through it while everything else runs as before. Keep a single switch that sends all work back to the old path without a new release.
Diagnostics that point at the right layer
When an integrated process fails, the first question is where: the input, the search, the model, the validation or the downstream system. Log each stage separately, with one reference that follows every item through the chain, so a fault is traced to its layer instead of argued over between teams.
Data access and permissions
- The model sees only what the user could see. An assistant that ignores the source system's permissions becomes a way around them. Check access at each request, not once when the index is built.
- Least access per integration. One service account each, with reading kept separate from writing.
- Know where the data goes. An outside service receives every input, so check what the provider keeps and whether it can be used to improve other models. Running the model on your own servers removes the question; see our guide to a private LLM on your own servers.
- Record every access. Who asked, what the model read, what it returned and where the output went.
Sequence the changes
Sequence decides how much of a program a firm gets through.
- Pick one process with an owner, real volume and a measured baseline.
- Start read-only. The model reads and drafts, people decide. It returns something visible early and touches no system of record.
- Add validated, structured outputs feeding a review queue.
- Write back through existing interfaces, with approval for each change.
- Automate narrow classes of case once the record supports it, and keep spot checks.
Be clear about which steps are settled practice. Drafting with review, document retrieval and validated extraction are well understood; agents acting across several live systems are newer and belong later.
Measure the results
Measure the current process before you build, or there will be nothing to compare with. Track time per item, errors found in review, how often people change the model's output, the share of items handled without a fallback, and the full cost per item including review time. Keep a fixed set of past cases with known answers and rerun it whenever the model, its instructions or the data change: model behavior shifts with updates, and the test set shows it before users do.
How Lualdi Advisors does it
AI Integration: models into operations
Lualdi Advisors starts with whether the system can take it: what the current infrastructure, throughput and failure budget will genuinely absorb, and which parts of the plan the system cannot support yet. It then designs how data and tasks pass between the model and the systems around it, so the AI layer and the architecture underneath are settled together.
Because model calls are slow, variable and occasionally wrong, it designs the queuing, retries and fallbacks so a bad answer degrades the experience instead of stopping the process. Capability is added alongside what runs today, with the diagnostics to show which layer a fault came from. The changes are ordered so the early ones return something visible, and the firm says which steps are settled practice and which are still experimental.
Questions
What is AI integration?
AI integration is the work of connecting a model to the systems, data and processes a business already runs, so its output arrives where people work and its failures are contained. The data flows, error handling, permissions and sequencing matter more than the choice of model.
How do you integrate AI into legacy systems?
Read from database copies or scheduled exports rather than the live system, and write back through the system's own import routines so its validation still applies. Keep the old process running beside the new one until the results justify switching.
Where should a business start with AI integration?
With one process that has an owner, real volume and a measured baseline, in a read-only form where the model drafts and people decide. It returns something visible early without putting any system of record at risk.
What happens when the AI gives a wrong answer?
In a well-designed integration, outputs are validated before use, and failed or uncertain cases go to a person or the previous process. A wrong answer affects one item, not the whole process.
How do you measure whether an AI integration is working?
Compare it with the old process on time per item, errors found in review, how often people change its output and the full cost per item. Rerun a fixed set of past cases whenever the model or the data changes.
