The question almost always arrives the same way, and almost always at the same point in the conversation: "does that mean we have to change systems?". The short answer is no, in most cases. It is worth understanding why, because this is where companies postpone for a year a decision they could have made in an afternoon.
The management software a company runs today, whether an off-the-shelf ERP, a CRM or an application built to measure ten years ago, holds the record of what happened. Orders, invoices, customers, stock, hours. Artificial intelligence does not come to replace that record. It comes to read what is there, cross it with the rest of the company's information and act on it: prepare, classify, answer, write back. They are different layers, which is exactly why they can coexist.
What "integrating AI" actually means
It helps to bring the term down from the clouds. Adding AI to an existing system means three concrete things, in sequence.
First, the AI system has to be able to read what matters: the ERP fields, the CRM history, the PDFs on the file server, the messages in a shared inbox. Second, it has to reason over that with the right context, which in practice means finding the five documents that matter among ten thousand and not inventing what it did not find. Third, it has to be able to do something with the result: create a record, update a status, send a draft for approval, raise a task.
Fail the first step and there is no project at all. Fail the third and what you are left with is a nice lookup tool that nobody uses after three weeks, because it still requires the person to go into the system and do the work by hand.
The three ways to reach the data
There are essentially three routes, and choosing between them is the technical decision with the largest effect on the budget.
Through the system API. This is the clean path. The ERP or CRM exposes a documented interface, the integration uses it to read and write, and the system vendor keeps supporting everything as normal. When an API exists, this is always the option.
By reading the database directly. Many locally installed systems have no usable API but do have a database you can reach. The correct practice here is to read from a replica and never write directly: the system stays the single owner of writes, and the risk of corrupting data disappears. It takes more work, because it means understanding a data model nobody documented, but it works.
Through the document layer. A huge share of a company's knowledge was never in a structured system at all. It lives in proposals, contracts, reports, tender documents, emails. Indexing that body of material and making it searchable in natural language is often the project with the best return, and it is what we describe in the article on the digital brain of a mid-sized company.
In practice almost no real project uses only one of these routes. The typical pattern is API for the main system, a replica for the legacy nobody wants to touch, and indexing for everything that lives in files.
What pushes the price up
The language model is the cheap, predictable part. What moves the budget is access to the data.
A system with a documented API and reasonably organised data is ordinary engineering work with a reliable estimate. A closed system, undocumented, with fifteen years of free-text fields where every branch invented its own convention, can cost twice as much to reach the same visible result. It is uncomfortable to explain in a proposal, because the client sees the same final screen in both cases, but it is the reality of the work.
The second factor is the level of autonomy. An agent that reads, prepares and proposes is considerably simpler than an agent that executes actions with financial impact. The second requires designing approvals, decision logging and reversal, and that engineering is a real part of the cost. The concrete ranges are set out in the article on what it costs to implement AI in a company.
When replacing the system really is the answer
There is one case where integration does not solve the problem, and it is worth being straight about it.
When the process you want to automate does not exist in the system. When half the operation lives in parallel spreadsheets because the ERP never anticipated that way of working, the problem is not a lack of AI: it is that the system does not model the business. Putting an agent to read spreadsheets that somebody fills in by hand automates the symptom and leaves the cause untouched.
In those cases the conversation moves elsewhere, and becomes about building the system the process actually fits. That is the comparison we draw between custom software and off-the-shelf suites such as Primavera, PHC or SAP. There too, the honest answer is not always to build.
What to confirm before you start
Before asking for proposals, four things are worth answering internally, because they determine price and timeline more than any technical decision that follows.
- Which concrete process. Not "use AI in sales", but "prepare the response to quote requests that arrive by email". The narrower the better, for a first project.
- How many hours a week that process consumes today. Without this number there is no way to know whether the investment pays for itself, nor to demonstrate afterwards that it did.
- Where the data sits and who controls access. If the ERP is managed by an external vendor, they will have to be part of the conversation, and that carries timelines of its own that do not depend on you.
- Which actions the AI may take alone and which require approval. This is a management decision, not an engineering one, and it is better taken before the system is built.
On the compliance side, a project that handles customer or employee data carries concrete obligations that are better designed in from the start than bolted on at the end. We wrote about that in detail in the article on GDPR and the AI Act before putting AI agents into production.
The shortest path
Pick the most tedious, most repeated process in the operation, the one everybody already knows. Measure the time it takes. Add AI to that process, using the systems you already have. If the numbers work, you widen it; if they do not, you lost little and learned where the data was, which is work that serves everything that comes next.
That is exactly what we do in the diagnosis: we look at the systems already in place, identify how the data can be reached and tell you what it costs and how long it takes. If the numbers do not add up, we say so before starting. The diagnosis is free and carries no commitment. You can talk to us or see how we approach AI integration in enterprise systems.