Generative AI in ERP makes sense when it shortens the path from a question to verified information or a controlled action in the system. An LLM assistant can retrieve data, explain a variance, prepare a summary, and propose an operation for approval. In a manufacturing company, the success of this type of project depends primarily on data quality, access permissions, and integration between ERP and shop-floor information.

For an operations director, four questions matter more than whether the system simply “has AI”: where the assistant gets its data, what it can see, whether it can write anything back to the system, and who approves its actions. These questions help distinguish a useful solution from an impressive interface.

Artificial intelligence in ERP systems is not limited to a single language model. The environment may include forecasting models, document classification mechanisms, OCR, anomaly detection algorithms, and an LLM that understands instructions written in natural language and prepares a response.

ERP remains the source of transactions, business rules, documents, and permissions. An LLM should not become an alternative source of truth. Its role is to make data easier to access, combine context from several sources, or trigger a defined system function.

An AI assistant usually answers questions, summarizes information, or prepares a proposed action. An agent can perform several steps, for example, retrieve data, compare it with a document, and prepare a change for approval. Generative AI in ERP can therefore start with read-only access and progress to controlled execution of operations.

An ERP chatbot may provide the conversational interface, while the broader LLM ERP architecture connects natural-language requests with business data, permissions, and functions.

The best starting point is the process itself. You can evaluate it using a four-S test: Source, Scope, Save, and Sign-off. It helps determine whether generative AI in ERP has the data required for the task and whether the level of autonomy matches the process risk.

This test protects the company from purchasing functionality without a clear answer as to where generative AI in ERP is supposed to reduce work. If employees spend most of their time searching for information, write access will make little difference. If the goal is operational automation, simply talking to the data will not be enough.

The first use case for generative AI in ERP is relatively easy to test. Instead of building a report or applying a set of filters, a user can ask which orders scheduled for this week are missing required materials or which purchase orders are already past their delivery date.

The value comes from shortening the path to information. The answer should be based on current data and respect the user’s permissions. If a manager does not have access to another company’s data, the assistant should not expose it either. It is also worth requiring the system to provide a path from the answer back to the source record so the user can verify the information quickly.

A list of delayed orders rarely explains the cause of the problem. A manager wants to know whether the deadline is at risk because of a missing component, unavailable workstation, longer cycle time, a schedule change, or a quality issue.

This is where generative AI in ERP begins to depend on data outside the ERP itself. The business system may know the plan, BOM, due date, and material availability, while execution data, downtime information, or quality inspection results may reside in MES, SCADA, or a quality system. The data must be linkable through an order, product, operation, batch, or another shared identifier.

If the flow is inconsistent, the next step should be to improve ERP data synchronization with production. A language assistant will not fix an incorrect item number, a missing batch number, or a status that is updated several hours after an event occurs. Orders, operations, BOMs, material consumption, execution statuses, and quality results are typical examples of data exchanged between ERP and production.

An assistant can collect information that a user currently checks across several reports. Generative AI in ERP can prepare a list of orders requiring attention, material shortages, delivery-date changes, and records with incomplete data. For a planner, this type of view is useful when it leads to specific records rather than ending with a descriptive message.

This does not replace BI. A dashboard is better suited to KPIs and trends calculated according to a defined methodology. An assistant works well for ad hoc questions, exception searches, and moving from a result to the underlying detail. Both tools can use the same data sources, but they address different needs.

A change in a component delivery date may affect several production orders, warehouse requirements, and the shipment date. Collecting these dependencies is a good use case for an assistant because a person still makes the decision but does not need to reconstruct every relationship manually.

Generative AI in ERP can find the relevant records, collect the information, and prepare material for the decision. Changing a date, quantity, or purchase order can remain the responsibility of the planner or buyer. The company automates the collection of context, not responsibility for the decision.

Demand forecasting, risk classification, and anomaly detection require methods selected for the specific problem and available data. An LLM can explain a result, combine it with other information, and answer follow-up questions, but it should not automatically be treated as the right model for every analytical task.

For that reason, generative AI in ERP may consist of several mechanisms working together. A forecasting model calculates expected demand, ERP provides order and inventory data, and the language assistant explains the change and points to elements that require attention. This division of roles is easier to control and test than assigning every stage to one model.

Documents are a good area for automation because the output can be compared with a specific source. The system can read data from a document, compare it with ERP records, and prepare the next action—for example, completing missing information or reporting a discrepancy.

In a manufacturing company, generative AI in ERP can support delivery confirmations, purchasing documents, and other back-office processes. A good candidate includes many similar cases, a clear procedure for handling exceptions, and an outcome that is easy to verify. If every document is different and the correct decision depends on the knowledge of several people, the pilot will be harder to evaluate.

A step above read-only access is the execution of operations. An assistant or agent can prepare a change, create a record, or call a function exposed by the system. Permissions, operation logging, and the point at which a person can review the change before execution become especially important here.

This is also where AI agents for ERP become relevant. An agentic AI ERP architecture can perform several connected steps, such as retrieving information, evaluating conditions, preparing an operation, and passing it to a person for approval.

For processes that affect inventory, delivery dates, commitments, or finances, a reasonable first version of generative AI in ERP is: “prepare the action and show it for approval.” Only pilot results can demonstrate which actions are predictable enough to justify greater autonomy.

If a question concerns order execution, downtime, or batch quality, ERP data alone may not be enough. MES adds order and operation context, SCADA or a historian stores process parameters, and the quality system contains inspection results. Generative AI in ERP needs access to these sources only when they are required to solve the specific problem.

You do not need to integrate everything before the first pilot. It is better to select one use case and determine which information is required to produce a correct answer. Our article on how to prepare your data before implementing AI in manufacturing explains this relationship using data from PLCs, SCADA, MES, and ERP.

Semantics also matters. An integration that transfers the value status = 1 does not explain whether the machine is running, waiting, operating in manual mode, or reporting an error. You can read more about this relationship in our article on industrial APIs and data semantics across ERP, MES, and SCADA.

The U.S. National Institute of Standards and Technology uses the term confabulation for situations in which generative AI creates and confidently presents incorrect or false content. NIST describes this risk in its Generative Artificial Intelligence Risk Management Framework profile.

In ERP, an error may involve a quantity, date, supplier, customer, or interpretation of a status. A response that simply sounds correct therefore cannot be the criterion for trusting an assistant.

Safe generative AI in ERP should use defined sources, respect user roles, make it possible to verify the basis of an answer, and require approval whenever an operation changes data. The organization should also determine where prompts and data are processed, who can access the history, and how incorrect responses are handled.

The best candidate occurs frequently, uses clearly defined data, and makes it possible to determine quickly whether the result is correct. One example is a daily search for production orders at risk because of material shortages, provided the required information is already available and the process has a defined owner.

Before starting, check six things:

A narrow scope can also be a good choice because AI adoption among Polish companies remains at an earlier stage than the EU average. According to Eurostat data on AI use by enterprises in 2025, at least one AI technology was used by 8.4% of Polish enterprises with 10 or more employees, compared with 20.0% across the EU. These figures cover different industries and AI applications, so they should not be interpreted as statistics on ERP implementations.

Generative AI in ERP should start with a process where the organization knows the data sources, the user, and what a correct outcome looks like. If the necessary context also exists on the shop floor, the company should review the flow of information between ERP, MES, SCADA, warehouse, and quality systems. Technical integration alone is not enough if individual systems interpret status, time, product, or events differently.

ERP integration with production and other plant systems helps organize the flow of data and the context required for generative AI in ERP. The first project does not need to end with an autonomous agent. If generative AI in ERP shortens the path from a manager’s question to a verified answer and makes its source visible, the company already has a measurable starting point for the next stage.

An AI native ERP platform may provide some of these capabilities by design, but companies do not need to replace an existing ERP simply to test the concept. The appropriate architecture depends on the process, available APIs, permissions, and the required level of control.

Yes, provided the system exposes the required data and integration mechanisms or the ERP vendor supplies its own AI layer. The available scope depends on the ERP version, APIs, permission model, and solution architecture. The company should therefore evaluate the specific process rather than relying only on the system’s name.

You do not necessarily need an AI native ERP. In many cases, an existing system can support an ERP chatbot, an assistant, or controlled AI agents for ERP through APIs and an appropriate integration layer.

Not in a typical use case. BI is better suited to fixed KPIs, governed metric definitions, and recurring reports. An LLM assistant is useful for ad hoc questions, exception searches, explaining information, and moving from a result to a specific record or action.

Usually not. Access should follow the task and the user’s role. If a process only requires read access to production orders and material availability, granting permission to modify data increases risk without providing a benefit for that use case.

Choose one recurring question or activity, identify the information sources, verify their consistency, and assign a process owner. If the team can clearly define a correct answer and measure time or the number of manual steps, you have a reasonable starting point.