AI connected to business data should not receive more access or more operational autonomy than a specific task requires. Control starts with AI permissions, continues with records of inputs, outputs and changes, and ends with clear accountability for the person who approves or rejects an executive action.
This matters particularly when an AI process does more than summarise documents or prepare a reply draft. It may read ERP data, suggest postings, prepare orders, change statuses, create documents or trigger an integration. In such a process, technical control is not a separate IT topic. It determines who can do what, on which data and with whose approval.
A conventional application generally executes a predefined set of rules. An AI component can interpret unstructured content, connect several sources and suggest a next step. That useful flexibility also introduces further questions:
The answer is not one setting or one policy. It requires process design that connects the business role, technical permission, evidence record and escalation route. An AI upgrade for business processes is meaningful only after these responsibilities are clearly separated.
The principle of least privilege means giving a user, service or AI component only the access needed for a specific task. In an AI process, this applies to data, tools and executive actions.
For example, AI that prepares a summary of outstanding items for a finance team may need read access to selected document and due-date data. It does not need access to payroll, the full HR module, changes to partner master data or the ability to send a payment order to a bank.
It is useful to distinguish several permission levels:
These levels should not be treated as permanent labels for a single tool. The same AI component can have a different role across processes. Reading warehouse data to prepare an order proposal is not the same as automatically changing a supplier order.
Permissions should therefore be linked to a business role and process, not only to a technical account. A financial controller, procurement team, production manager and external service provider may need different views of the same process. Connected operations require this kind of alignment between operational connections and accountability.
An AI audit trail is a record that enables reconstruction of a meaningful part of the process. It does not have to mean retaining every technical detail without limits. It should contain enough information for business review, investigation of deviations and explanation of a decision within the defined scope.
For a process affecting business records, it is useful to capture:
The record needs to distinguish an AI output from a business decision. If AI suggests an expense classification and an accountant changes the proposal before posting, the audit trail should show both steps. Otherwise, it is not possible to establish reliably whether an issue originated in the input, the AI recommendation, the process rules or the human review.
Record design should also consider data protection. A log does not need to duplicate the full content of every document when an identifier, summary, source reference and controlled access to the original record are sufficient for review. The organisation should define retention periods, log access and the masking of sensitive data according to its own obligations and risk assessment.
The most important process boundary sits between a recommendation and execution.
A recommendation can be a ranked supplier list, a suggested account, an alert about a production deviation, a customer reply draft or a proposed priority for work orders. It informs a person but does not change the business state.
An executive action changes data, an obligation or external communication. Examples include posting a document, changing a price, opening an order, sending a purchase order, changing a delivery status or activating an integration with another system.
This boundary helps determine the appropriate level of human control over AI. For a recommendation, exception-based or sample-based review can often be appropriate, depending on risk and potential harm. For an executive action, the organisation needs to decide explicitly whether it requires individual approval, approval based on threshold rules or stricter segregation of duties.
Automation of a low-risk executive action can be justified where the action is clearly limited, reversible, well tested and monitored. Even then, it should not become an invisible process. It needs a record of the action, a process owner, stop thresholds and the ability to disable automation.
Consider a process in which AI reads an incoming invoice, extracts data, suggests a supplier, cost centre and account, and prepares a posting proposal.
A safer process flow can look like this:
In this example, AI can accelerate preparation but does not take over accounting responsibility. The process owner remains accountable for rules, permissions, control points and the handling of exceptions.
Human control of AI is not only an approval button. It needs a clear answer to what happens when the process lacks sufficient grounds for a safe decision.
It is useful to trigger escalation when:
Escalation needs a named recipient. This may be the business process owner, accountant, procurement manager, security owner or another authorised decision-maker. It is also important to define in advance what that person receives for review: source data, the AI proposal, the reason for the alert, relevant rules and available response options.
Stricter control can slow part of a process. A broader audit trail increases storage costs, access-management needs and the volume of data to review. Individual approval for every action can create a bottleneck, particularly at high volumes.
The opposite choice also has a cost. Overly broad AI permissions increase the consequences of a mistaken instruction, faulty integration or unsuitable output. Missing records make correction, internal review and learning from deviations more difficult. Full automation without a clear process owner can blur accountability precisely when business harm occurs.
Control should therefore not be identical in every case. Its scale should reflect the data type, business impact, reversibility of the action, contractual and regulatory obligations, and frequency of exceptions. Frameworks such as the NIST AI Risk Management Framework 1.0 can help structure risk assessment. Organisations operating in the European Union should also follow the European Commission's official information on the AI Act and consider its application to their own context.
Before connecting AI to an ERP or another business system, select one limited process and answer several specific questions:
This checklist turns a general wish for human control of AI into a reviewable business design. To assess permissions, decision flow and integration boundaries for a specific process, Talk to the ORKA team with a description of the process, systems involved and actions AI should only propose or may potentially execute.