An AI agent in ERP gains access not merely to data, but to processes that change the company's obligations: procurement, payments, inventory balances, contract terms, and HR records. That is why the central question of implementation is not "can the agent perform the operation", but "who has the authority to make the decision whose consequences that operation will lock in".
The practical boundary lies between decision preparation, execution within pre-approved limits, and independent choice that creates material consequences. In the conservative governance model proposed here, such independent choice is not delegated to the agent; mandatory human involvement is determined by applicable law, the classification of the system, and the specific process. Assess the materiality of consequences by potential harm, impact on rights or employment, reversibility of the error, and cumulative effect; specific thresholds are set per process, not universally for the whole ERP. When a threshold is exceeded, execution stops; the agent may only prepare materials and hand the decision over to an authorized employee. In this article, independent choice means that the agent itself sets the objective, introduces an exception, or changes conditions outside pre-approved rules. Limited execution means only selecting a specific action within those rules and limits; the model has no authority to expand them. For each action, fix in advance the permitted operation and its limits, system-verifiable conditions, mandatory stop reasons, and the responsible role. The process owner approves and revisits these limits; the ERP owner or the control function ensures their independent technical enforcement; the person receiving an exception must have the authority and the time to make a decision.
Also check cumulative risk: a set of individually minor operations can together change the financial position or the distribution of capabilities. So set limits not only for a single operation, but also for their volume, frequency, and total effect over a period.
Delegating a Task or Authority
The instruction "reconcile the invoice against the order and the goods receipt" permits a verifiable result: the agent shows the discrepancies and the record references. The instruction "sort out all problem invoices" already permits the choice of actions – change the payment details, approve an exception, put the document on the payment run. If such actions are technically available to the agent, the vague wording becomes a de facto delegation of authority.
The table distinguishes three modes of autonomous work – analysis, preparation, and limited execution – plus a protective stop state with handover of the decision to a human.
| Working mode or protective state | Agent behaviour | Who sets or selects the action |
|---|---|---|
| Analysis | Finds discrepancies, gathers context, offers options | With the authorized employee |
| Preparation | Creates a draft request, journal entry, or reply without final posting | With the employee who checks and approves |
| Limited execution | Selects and performs a specific pre-authorized action while verifiable conditions hold | The agent makes the operational choice only within rules and limits approved by a human; changes to rules and exceptions are decided by an authorized human |
| Stop and handover | Stops the action and hands the materials to the responsible person | With the person holding the relevant authority |
The agent must not be able to change its own rights, limits, or authorization rules, nor the data by which the system checks the admissibility of its particular action. Changes to that data must go through a separate authorized process.
How to Define the Limit of Autonomy in ERP
Assess not the name of the function, but the specific action and its consequences. The agent may, for example, route incoming invoices to a processing type by predefined criteria, provided this does not change the payment order or other material decisions. Changing a supplier's bank details has a different risk and authority profile.
For each action, answer five questions:
-
What effect is created? A recommendation, a draft, a change to master data, an obligation to a counterparty, and sending a payment are different levels of impact.
-
Can the conditions be reliably verified before execution? A formal field match does not prove that the operation is justified economically. If verification requires assessing disputed circumstances, the agent would better prepare materials for a human.
-
What is the cost of the error and how reversible is it? Fixing a draft is easier than recalling a payment or removing the consequences of a wrong personnel decision.
-
Is there a conflict of authority? The agent must not simultaneously create the grounds for an operation, approve an exception, and execute it merely because it can call all three ERP functions.
-
Where do the instructions and data come from? The text of a supplier's email, a comment on an invoice, or an attachment is data to be processed, not a source of new authority for the agent.
From this follows a working rule: the more significant the consequences and the harder the independent verification, the narrower the execution rights should be, and the sooner a stop-and-handover route to a human is needed. This is a management principle for configuring the process, not a universal legal threshold.
Human Oversight Must Be Meaningful
When an operation requires individual human approval – by law, corporate authority, or internal process – a formal "Approve" button does little if the employee sees only a confident model conclusion and has no time to check the grounds. In that case, meaningful oversight implies access to source documents, visibility of the detected discrepancies, a clear description of the proposed action, and a real ability to reject it before execution. The reviewer needs time, competence, and the authority to stop the process.
Limited execution without separate approval of each operation is another mode of oversight, not an exemption from it. The action's conditions must be verified independently in the system; the agent must not change policy or bypass these checks; actions and constraint triggers must be logged, and for exceptions there must be a stop-and-handover route to a human. Such a mode is permissible only in compliance with applicable law, corporate authorities, and internal control requirements. The conclusion that the AI Act by itself does not set a universal manual approval for each operation applies only to the scope of that Regulation and does not cancel other obligations.
Regardless of the legal classification, when designing an ERP process it is useful to check whether oversight has become decorative. If a person routinely approves proposals in batches, does not see primary data, or cannot cancel an action, the "human in the loop" label does not describe the actual level of control.
Architecture of Permissible Delegation
The authority boundary cannot be reliably held by a single natural-language instruction. It must operate in ERP and in the intermediary services through which the agent obtains its tools.
Access rights and identity. Give the agent a separate technical identity and rights for specific operations, objects, and process stages. Separate reading, preparation, modification, and final posting; do not automatically inherit the broad rights of the employee on whose behalf the agent runs. In the log, every action must be unambiguously linked to the agent identifier, the human who initiated it and, where required, the employee who approved it.
Independent execution conditions. Limits, permitted operation types, approval rules, and prohibitions must be checked outside the model. The agent may propose an action, but must not be able to rewrite the rule under which it is permitted.
Separation of duties. For sensitive operations, keep initiation, verification, and approval independent. If a human approves an exception to a rule, record what exactly they saw and which action they authorized, not merely the fact that a button was pressed.
Working with untrusted content. Emails, invoices, and attachments may contain commands addressed to the agent. Their content should be treated as information about a business transaction; it must not alter system instructions, the approval route, or access rights.
Logging and stopping. Investigating an incident requires traces of the original request, the data used, the proposed and executed action, the constraints that triggered, and human approval, if there was one. There must also be a way to quickly disable execution without depriving employees of access to ERP itself.
Three Situations Where the Boundary Is Especially Visible
The architectural measures above apply uniformly, but the specific limits and handover route depend on the potential damage and the reversibility of the operation.
Supplier invoice. The agent reconciles the document against the order and the goods receipt, flags discrepancies, and prepares a draft. This is preparation, not payment execution: the agent does not change the payee's details, does not approve exceptions, and does not release a payment. If ERP does not respond after the draft is created, the agent first checks the document state in ERP itself and only then decides whether a repeated request is permissible.
Inventory replenishment. The agent may calculate the requirement and prepare an order. It may place the order automatically only within a predefined set of items and suppliers, with current ERP data and within quantity and amount limits; the system verifies these conditions independently of the model. A new supplier, unusual terms, or any exception returns the process to preparation and human decision.
Personnel process. The agent may check document completeness, match information, and prepare a structured analysis for an authorized employee. In the conservative governance model proposed here, the final choice on matters that materially affect rights or employment remains with a human; the agent does not determine the outcome on its own. This is a recommendation, not a universal AI Act requirement for manual approval of every decision: mandatory human involvement depends on applicable law, the classification of the system, and the specific use. Annex III, point 4, classifies as high-risk certain systems for recruitment and selection, decisions on working conditions, promotion or termination of relationships, allocation of tasks based on individual characteristics, as well as monitoring and evaluation of workers; Article 6(3) allows a narrow exception, but systems that perform profiling of natural persons remain high-risk. Hence, not all HR automation is automatically high-risk, and legal classification and the scope of the agent's authority are two different decisions. Annex III of the AI Act.
What to Fix Before Launch
Before launch, the process owner approves the matrix of actions, limits, stop conditions, and those responsible for exceptions; every change of authority is recorded with its grounds, date, and approving roles. After the pilot and further in operation, the process owner together with the control function reviews the logs of actions and escalations at a pre-set frequency. An out-of-cycle review is triggered by an incident or dangerous deviation, a change of model, data, ERP tools, process, limits, or applicable requirements. Until the assessment is complete, the affected authorities are suspended or narrowed; resumption or expansion is allowed after re-verification of the scenarios, a documented decision by the owner, and an updated matrix version.
Record the resulting mode and its justification together with the process owner and the conditions for the next review.
Legal Framework
The requirements of the AI Act depend on the purpose and classification of the specific system. High-risk systems require human oversight, but this does not mean mandatory manual confirmation of each operation. Therefore, the delegation boundaries described in the article are engineering recommendations, not a universal interpretation of the law. Before implementation, check the applicability of the regulation to the specific scenario and the current version of the AI Act.