AI connected to ERP data is valuable when it helps people understand the real state of operations and make a verifiable decision. Risk begins when AI receives incomplete, outdated or misinterpreted context, overly broad data access, or the ability to act without appropriate control. Connecting AI and ERP is therefore not just a technical integration: it is the design of processes, responsibilities and decision boundaries.
ERP brings together the data that gives a business decision meaning: items, customers, suppliers, orders, inventory, production orders, due dates, postings and permissions. Without that context, AI can produce convincing text, but it cannot reliably answer a question that depends on the current state of a process.
For example, the question “Can we promise delivery by Friday?” is not simply a question of available inventory. The answer may depend on confirmed orders, reservations, open production orders, planned receipts, quality status, delivery rules and the permissions of the person asking. Business AI data is therefore not merely a spreadsheet export or an openly available database. It is data connected to business rules, source, time of creation and access rights.
A sound system must be able to separate three things:
This distinction reduces the risk of presenting an assumption as a fact or showing confidential data to a person without a business need.
Value does not come from connecting a model to a database alone. It comes from recurring situations in which an employee spends time finding data, comparing statuses or preparing the next step.
In manufacturing, AI can help explain why an order is at risk: whether material is missing, an operation is delayed, an open dependency exists or the plan has changed. In accounting, it can summarise entries that require review, but it should not present an interpretation as a final posting. In sales, it can prepare an overview of open offers and customer commitments while respecting access rights. In procurement, it can identify deviations between ordered quantities, dates and supplier confirmations.
In each of these cases, a useful AI implementation starts with a specific question:
This approach connects AI to a working process rather than to a general promise of automation. In the context of Connected operations , it is important to view the flow of data between functions, not only an individual screen or a single query.
It is useful to name the level of AI involvement from the outset. These levels bring different business value, but also different risk.
An assistant answers questions, summarises documents or connects relevant ERP records. It may, for example, prepare an overview of orders at risk of delay and identify the records on which that overview is based.
Here, a person still interprets the answer and decides what to do. The key controls are the accuracy of retrieved data, access restrictions based on the user role, and the user's ability to check the source. This is often a sensible starting point because it allows organisations to learn from real user questions without automatically changing business records.
A recommendation goes further. AI may suggest a review priority, a draft response to a customer, a possible processing sequence or a set of entries for review. A proposal is not a decision. It should clearly show which data and rules support it, which assumptions it contains and who confirms it.
Risk increases when a recommendation affects price, delivery date, payment, work scheduling or the customer relationship. In such cases, it is not enough to say that the proposal was “generated by AI”. The process must define the responsible person, the escalation method and situations in which the recommendation must not be used without additional review.
An autonomous action may create a record, change a status, send a message, start an approval workflow or perform another action in the system. This can be justified for a narrowly defined, repeatable and controlled task, but it requires stricter boundaries than an assistant or a recommendation.
Before such an action, the organisation should define the permitted scope, required conditions, value or quantity limits, exceptions, the ability to stop the action and the review of execution records. Not every action is suitable for autonomy. The more difficult the consequences are to reverse, the more financially sensitive they are, or the more important they are to the customer relationship, the more important prior human confirmation becomes.
ERP access rights must not be bypassed because a user interacts through an AI interface. If an employee is not permitted to open a specific document or field in the ERP, AI should not retell the content of that document or include it in a summary.
In practice, this requires clear answers to several questions:
Least-privilege access does not remove every risk, but it prevents the convenience of a conversational interface from becoming a shortcut around established business controls.
In a business setting, it is not enough to retain only the final AI message. A useful decision trail can include the user query, the user's identity or role, time, the sources used and versions of relevant rules, the proposed or executed action, and human confirmation or rejection where it is required.
The purpose of such a record is not to create an impression of complete certainty. It makes practical questions answerable: Why was the proposal created? Which data was available at that time? Who approved the change? Can an error be corrected and the process improved?
Risk management should be planned before wider use, not only after an incident. The NIST AI Risk Management Framework 1.0 provides a framework for considering AI risk management. For organisations following the European regulatory context, the European Commission page on the AI Act is also useful to monitor. These sources do not replace an analysis of an organisation's own process, data and responsibilities.
The first use case should not be the one with the most data, but the one with sufficiently clear boundaries. A good candidate usually has a recurring question, a limited set of sources, a measurable way to check the result and a person who already carries responsibility for the decision.
Consider a production manager who wants to identify orders with elevated due-date risk each day. AI can prepare a list based on order status, material availability and planned dates. The manager checks the source records, assesses exceptions and decides on priority. The system records that the review was prepared, which orders it covered and which decisions were confirmed.
This case has a clear division of work: AI accelerates preparation of the review, ERP remains the source of business status, and the person decides on the intervention. Only after stable use and review should the organisation consider whether it makes sense to automate a narrowly limited action, such as creating a task for additional review.
AI can misinterpret a question, miss an important exception or confidently phrase an answer that is not supported by data. ERP data can also be incomplete, delayed or inconsistent. Integration does not by itself fix the quality of master data, statuses or business rules.
A sound design should therefore allow AI to say that it does not have enough data, show the source and hand the case to a person. It should also test edge cases: unusual item names, partial deliveries, status changes during the day, exceptional permissions and conflicting records.
Responsible AI implementation is not a project in which rules are set once and never reviewed again. User questions, processes, permissions and data change in operation. Controls, records and ownership of the process need to change with them.
Before choosing a tool, select one business decision and map its flow: the input ERP data, user roles, permitted level of assistance, mandatory human review, exceptions and the trail that should remain after the decision. This is a concrete basis for assessing whether an AI and ERP integration is justified for that case.
ORKA's approach to an AI upgrade for business processes can be relevant when an organisation wants to connect this map to real processes and ERP context. To discuss one clearly bounded use case, talk to the ORKA team .