# Integrating an AI pilot with the systems you already run

> AI integration with existing systems: map what the pilot touches, set read and write access, decide who it acts as, plan for failure and test on a copy.

- URL: https://www.ornsoft.com/blog/integrate-ai-with-existing-systems/
- Published: November 11, 2026
- Updated: November 11, 2026
- Author: OrNsoft team, OrNsoft Corporation
- Category: Production AI
- Publisher: OrNsoft (https://www.ornsoft.com/)

AI integration with existing systems means deciding, for each system an AI pilot touches, what it may read, what it may write, who it acts as, and what happens when that system is slow, down or says no. It is one of the five open decisions that stall pilots, and it is easier to settle on one page before go-live than in the first week of production.

**Integrating an AI pilot means connecting it to the systems your operation already runs, with access, identity and failure behavior decided in advance for each one.**

This article is for operators and technical owners with an AI pilot that works on its own and now has to work inside the operation. It gives five decisions, an example of the one page you keep per system, and a way to test before go-live. If you are earlier in the journey, start with [why AI pilots stall](/blog/why-ai-pilots-stall/).

> **Key takeaways**
>
> - **List the systems first.** A pilot that runs on exported data has not been integrated.
> - **Give read access by default.** Add writes only where the pilot needs them.
> - **Gate by consequence.** Irreversible or external actions wait for a named approver.
> - **Decide failure behavior per system.** An unanswered or failed call should fail safe.
> - **Rehearse on a copy.** Test the connections before real data and real customers.

## What does AI integration with existing systems involve?

It is the work between "the model gives good answers" and "the operation runs on it." The pilot has to read the records your people use, and in some cases change them. Each connection has an owner, a set of permissions, and a way to fail.

Teams can leave this work to the end, because the pilot looked fine on its own. The same open decision appears in the page that defines production: scope, criteria, security and approvals are all written down before go-live, as described in [define production for an AI system](/blog/define-production-for-an-ai-system/).

## Which systems does the pilot touch?

Start with a list, with one row per system. Include the obvious ones, such as the system of record, and the quiet ones, such as a shared mailbox or a spreadsheet someone updates by hand. For each, write down five things.

![An illustrative table with one row per system: what the AI reads, what it writes, who it acts as, and what happens if the system is down.](../../../assets/blog/integrate-ai-with-existing-systems/integration-map.png)

The rows in the image are examples. Yours will name your own systems, and the owner of each system should read their row.

## What should the AI be allowed to read and write?

Apply the principle of least privilege: each entity gets the minimum access it needs to do its job. NIST's glossary states it as the [principle of least privilege](https://csrc.nist.gov/glossary/term/least_privilege), and it is the right default for a pilot that is about to meet real systems.

Then sort the actions by consequence.

![Three tiers: reads need no gate, reversible writes need none or a sampled review, and irreversible or external actions need approval before they run.](../../../assets/blog/integrate-ai-with-existing-systems/access-tiers.png)

Reads and reversible writes can run at machine speed. Anything irreversible or external, such as sending a message to a client, paying, deleting or changing an access right, waits for a named owner with a backup. The design of that step is in [approval gates for sensitive automated actions](/blog/approval-gates-for-ai-actions/).

## Who does the AI act as?

Every write in another system carries an identity. Give the pilot a named service role, with only the permissions its job needs, and name the person who owns that role. Do not reuse a personal login, because then nobody can tell later whether a person or the system made the change.

Write down how access is granted, who can change it, and how it is removed. Your security team will ask, and having the answers on one page helps that review.

## What happens when a connected system fails?

Systems are slow, they go down for maintenance, and they change. Decide the behavior for each one before go-live.

1. **A read fails.** The answer should say it could not check, and ask a person. A confident answer from stale data is the worse outcome.
2. **A write fails.** Retry once if the action is safe to repeat. After that, stop and alert the owner.
3. **An approval is not answered.** The action does not run, the owner is alerted, and the case goes back to a queue a person already works.
4. **A system changes.** Name who tells the pilot's owner when a connected system changes its fields or rules, and who checks the pilot afterward.

Put the answers in the production page, next to the approvals.

## How do you integrate AI with legacy systems that have no API?

Some systems your operation depends on offer no clean way in. The rules in this article still apply: least privilege, a named owner, and a decided failure behavior. Work through the options in this order.

1. **A supported route the system owner already offers.** Ask the owner of the system what is available: a supported integration, an export, or a report. A route the owner already supports is the one they can maintain.
2. **A scheduled file or database read, with a read only account.** If the system can write a file on a schedule, or allows a read only database account, the pilot can read from that. Name who owns the account and who is told if the file does not arrive.
3. **A person for the writes.** Where the pilot cannot safely write into the system, it prepares the change and a person enters it. That keeps the write behind a named approver, and the record shows who made it.

Whichever route you choose, write it into the one page for that system, with the failure behavior beside it. If the only route would need broad access, treat that as a finding for the business owner and the technical owner to decide, before go-live.

## How do you test the integration before go-live?

Rehearse it. Use a copy of real data and the real connections where you safely can, and score the results on cases from your own operation.

- **Run the failure cases on purpose.** Switch a connection off, delay it, send it a malformed record, and check that the pilot behaves as the page says.
- **Check the permissions.** Confirm the service role can do what it should and nothing else.
- **Score the outcomes.** Use a test set built from your own cases, as described in [how to evaluate AI agents](/blog/how-to-evaluate-ai-agents/).
- **Write down what you found.** Each gap becomes a decision for the business owner or the technical owner.

## Where do teams get stuck?

Three patterns repeat.

- **The pilot ran on an export.** It never touched a live system, so the first real connection is also the first real test.
- **Nobody owns the connection.** The pilot's team assumes the system owner will handle it, and the system owner has not been asked.
- **Failure was never discussed.** The first outage becomes the first time anyone decides what the pilot should do.

Each one comes from the same cause: the integration was treated as plumbing and not as a set of decisions.

## What should you do next?

Take one pilot and list the systems it touches, one row each. For each, write the five fields: what it reads, what it writes, who it acts as, what happens if it is down, and who owns it. A blank field is your next conversation. For the full path from pilot to production, see [AI pilot to production](/blog/ai-pilot-to-production/) and [how to move an AI pilot to production](/blog/how-to-move-an-ai-pilot-to-production/).

Our forward-deployed engineers work directly with your business and technical teams on this work. Read how it runs on the [forward-deployed engineering page](/forward-deployed).

Bring us the problem, not the specification. [Book a call](/contact). One call is enough to know whether we can help.

## Questions

### What is AI integration with existing systems?

Deciding, for each system an AI pilot touches, what it may read, what it may write, who it acts as, and what happens when that system is slow, down or refuses. It is the work that connects a pilot to the operation.

### Why do AI pilots stall at integration?

A pilot can run on exported data or a test account. In production it has to reach the systems your people use, with real permissions, and nobody has decided who approves that access.

### Should an AI system have write access?

Only where it needs it. Start with read access. Allow reversible writes with sampled review. Put anything irreversible or external behind an approval before it runs.

### Who should the AI system act as in other systems?

A named service role with the minimum permissions its job needs, owned by a named person. Avoid sharing a personal login.

### What should happen when a connected system is down?

Decide it in writing for each system. A safe default is that the action does not run, the owner is alerted, and the case returns to a queue a person already works.

### How do I test an integration before go-live?

Rehearse on a copy of real data, with the real connections where possible, and score the results on cases from your own operation. Record what you tried and what you found.