Connecting AI to ERP and Business Systems: An Engineering Guide

Connecting AI to an ERP is mostly not an AI problem. It is an integration problem, an access-control problem and an operations problem, and the model sits at the end of that work rather than at the start of it.

This is a guide to the parts that decide whether such a system is usable in production.

There is no single ERP integration mechanism

The first thing worth stating plainly: ERPs do not share an integration model.

Some expose a documented REST or SOAP API. Some expose a database you may read but must not write. Some expect file exchange on a schedule. Some have an integration layer sold separately. Some have an API that covers a third of what you need and a support note explaining that the rest is available via a table nobody will guarantee.

Any guide — including this one — that says "connect to your ERP's API" is describing the best case. Plan the discovery step honestly: what interfaces exist, what they cover, what they are permitted to do, and what is contractually supported.

Access before capability

Decide the access model before anything reads a record.

Identity. The layer needs an identity of its own — a service account with scopes — and, separately, a way to know who is asking. These are not the same thing, and conflating them produces a system where every user can see everything the service account can see.

Permission inheritance. The safe default is that a person can only get answers from records they could already open in the source system. This is harder than it sounds, because most ERPs express permissions in a model that does not map cleanly onto a retrieval index. It is still the right target, and where it cannot be met exactly the gap should be a stated constraint rather than an accident.

Least privilege. A read-only integration that only reaches the modules in scope is smaller, safer and easier to get approved than one with broad access "so we do not have to come back later".

Getting data out

Direct interfaces

APIs and database views, where they exist and are supported. Preferred: they are current by definition, and they carry the source system's own semantics.

Files and documents

Supplier files, exports, scanned documents, PDFs. Common in practice, and the place where most of the interpretation work lives. Treat every file as untrusted input with a schema you assert, not a shape you assume.

Legacy interfaces

Fixed-width exports, ancient endpoints, a scheduled job someone wrote years ago. These work, and replacing them is often out of scope. Wrapping them is usually the right move: put a validated interface in front, and leave the thing behind it alone.

Scheduled versus event-driven

Events give you freshness; schedules give you predictability and are far easier to reason about when something goes wrong. Many systems only realistically support a schedule. Freshness is a requirement to state explicitly — "within fifteen minutes" is a design input, "real time" usually is not.

Retrieval and grounding

Once data is reachable, the question becomes what the model is given.

Retrieval selects the records relevant to a question. Grounding requires the answer to be derived from those records and keeps the reference back to them.

Two decisions matter more than the rest:

• What is indexed and what is fetched live. Indexing is fast and can go stale. Live fetching is current and slower. Operational figures — stock, order status, capacity — usually need to be live, because a stale number presented confidently is worse than no number.
• What the reference is. A finding should be able to name the system and the record it came from. Without that, nothing downstream can be checked, and the audit trail has a hole where the evidence should be.

Read and write are different projects

Reading is an integration exercise. Writing is a change to the business's system of record, and should be scoped, reviewed and released as such.

A sensible progression:

1. Read only. Answer questions, correlate, explain. Genuinely useful, and low risk.
2. Prepare. Produce a draft action — a purchase order, a status change — that a person reviews and releases.
3. Write, narrowly. Specific, validated operations with audit trails, on records where the consequence of an error is understood.

Most systems should stop at the second step for a long time, and some should stop there permanently.

Validation and the failure modes

Assume every boundary lies to you occasionally, and design so it fails visibly.

• Schema validation on everything entering the system, including from your own ERP. Fields change.
• Entity resolution. The same order is two identifiers in two systems. Decide the mapping deliberately, and surface unmatched records rather than dropping them.
• Conflicting sources. Decide which system is authoritative per field. Where it is genuinely ambiguous, present both.
• Partial availability. One system is down. The answer should say so, not quietly answer from the remaining three as though nothing is missing.
• Silent staleness. The worst failure mode, because nothing appears broken. Timestamps on the data, and a visible age when it is old.

Audit and observability

If the system prepares or takes actions, the trail is part of the product.

Record what was retrieved, what was found, what was recommended, who approved it and what was written. Structured logging around every integration point, so "why did the number change" is answerable without reproducing the conditions.

This is also what makes the system defensible internally. The first serious question after go-live is usually about a specific decision on a specific day.

Production

Deployment is where these systems tend to be under-specified. The parts that need answers before go-live: where it runs and what it may reach; how credentials are stored and rotated; what happens when the ERP is upgraded; who is on the other end when it stops; and how a change is tested against something other than production.

None of that is AI work. All of it decides whether the AI work survives contact with an operation.

Common questions

Do we need a data warehouse first? Not necessarily. A warehouse helps for analytical questions over history. Operational questions usually need current state from the source systems, which is a different path.

Can this work with an on-premise ERP? Yes, and the deployment topology becomes a design constraint — where the layer runs relative to the systems, and what may cross which boundary. That is scoped per engagement.

How long does the integration part take relative to the AI part? In our experience the integration, access and validation work is the larger share. That ratio surprises people who scoped the project as an AI project.

---

The layer this describes is covered under system integration; what gets built on top of it under Operational AI and AI engineering; and the engineering practices behind it under technology & engineering.