Connecting AI to ERP and Office Workflow Systems: APIs, Permissions and Data Boundaries

The safest way to connect AI to enterprise resource planning (ERP) and office automation/workflow (OA) systems is not to let it change records on day one. Grant capability in four levels: read, recommend, write back, then execute autonomously. Each level needs stronger identity checks, approval, logging and rollback because the closer AI gets to a real business action, the greater the cost of an error.

"Integration" means more than obtaining an API endpoint. It makes AI a participant in a business chain: it may see orders, contracts and employee information, produce a recommendation, or alter a document state. Before discussing models and interfaces, use the workflow mapping method for pre-automation work to show where data originates, who confirms it and where the final record lands.

Start by separating integration into four risk levels

Read is the lowest-risk level. AI queries an order, inventory position or approval status through a restricted interface and answers in the session without changing the source. Read-only is not risk-free: excessive extraction, cross-department queries or sending sensitive fields into an unsuitable model environment can still expose data. But the business record itself cannot be corrupted, so faults are easier to isolate.

Recommend adds a proposed result after the read: replenishment candidates for a buyer, a summary of differences for an approver, or a follow-up draft for a salesperson. The recommendation should be visually separate from factual fields and carry its basis, timestamp and source. Fluent prose must not hide missing information. A person retains the decision at this level; AI does not press confirm.

Write-back sends a human-confirmed, structured result into ERP or OA, such as adding a note, creating a draft document or filling a classification. The risk has moved from "the answer was wrong" to "the record was changed incorrectly". The interface must validate fields, state and version, record the confirmer, and recognise duplicate submissions. Autonomous execution lets the system submit, route or trigger a downstream action when conditions are met. It belongs only in narrow cases with explicit rules, reversible impact and prompt interception of exceptions.

The four levels are not maturity badges, and a project does not have to reach the last one. Many high-impact processes should remain at recommendation level indefinitely and can still be valuable. Payments, official seals, employee discipline and external commitments may deserve human approval even when automation is technically possible. The selection method for AI workflows and agents can help choose an architecture, but an agent label never justifies broader permissions.

Derive interfaces from business facts, not from an open database

Integration design begins by naming the source of truth. ERP or OA remains authoritative for order value, supplier status, approval decisions and other formal records; AI may consume those facts or propose a change. Do not let a model connect directly to a production database, invent its own queries or bypass system checks merely to speed development. Schema changes, soft-deletion rules and migrated permission logic can make direct access return an incomplete truth while evading the audit controls already present in the source application.

A more controllable design exposes narrow business capabilities: "list my pending approvals", "return the visible summary of this order", or "create an expense draft" rather than "query the order table". Responses contain only fields needed for the current task, and write endpoints accept only permitted changes. Business rules stay inside the business system, so a prompt cannot bypass mandatory fields, limits or state-machine constraints.

The interface catalogue needs business semantics: calling purpose, data owner, eligible callers, input and output, freshness, timeout behaviour, exception destination and shutdown method. In particular, distinguish a live fact from a cached summary. If the AI sees last night's inventory snapshot, it must display that timestamp rather than describe the number as available now. An endpoint returning data proves connectivity; whether that data can support the decision is a separate acceptance question.

Carry identity through the chain instead of acting as one superuser

A common shortcut is to give the AI service one powerful shared account for every employee. It accelerates a prototype but cannot answer three essential questions: who initiated this request, whether that person was entitled to see this record, and whose name belongs on the resulting action. A safer design preserves user identity, service identity and approval identity simultaneously, with a distinct responsibility for each.

After sign-in, the platform builds a request context from the employee's role, department and current task. The AI service calls an interface using its own restricted credential. Where human approval is required, the approver's identity and the approved version join the record. Authorisation frameworks such as OAuth 2.0 provide a general model for delegated access, but the mechanism must fit the existing identity estate. The important properties are a short-lived, narrowly scoped, revocable credential and a backend that still re-evaluates permission.

NIST's zero trust architecture states that network location or asset ownership alone should not create implicit trust. For ERP and OA integration, that means deciding every access from the subject, resource and context rather than assuming that entry through an internal AI portal permits every query. Use the management framework for AI data boundaries to classify sensitivity; the integration layer then enforces that boundary as visible fields, record scope and calling conditions.

A recommendation must pass a verifiable gate before write-back

Recommendation interfaces often make a subtle mistake: generated values are prefilled into formal fields, leaving the user to press save. A completed-looking form encourages scanning rather than review. A better design presents source facts, the AI proposal, the exact difference and its evidence side by side. When a critical field lacks a basis, the save action should remain unavailable.

Write-back endpoints need deterministic checks, not another conversation with the model. Code and source-system rules validate type, length, mandatory fields, enumerated values, amount relationships and document state. Submit the source record version too. If someone changes the document while the approver is reviewing it, show a conflict and require fresh confirmation instead of overwriting new facts with an old recommendation. Idempotency keys should ensure that repeated clicks, network retries and duplicate messages apply the same business intent only once.

Human confirmation also needs tiers. A business user may confirm an ordinary note, while a change to price, payment or an external commitment requires the relevant authority. The tiered checklist for reviewing AI output helps match review depth to impact. Approval must target a frozen version: the person approves the content on screen, and the backend must not ask the model to rewrite it after approval and submit something else.

The threshold for autonomous execution is controllable failure

Autonomous execution suits narrow actions with stable rules and reversible outcomes: creating a draft for later review when all required information is present, or routing a low-risk task to an unambiguous queue. It should not connect open-ended judgment directly to high-impact action. If outsiders can manipulate the input, the model must guess missing facts, the result cannot be reversed, or one error can spread in bulk, the action belongs back at recommendation level or with a person.

Separate the executor from the model. The model proposes a structured intent; a policy layer checks user permission, action allowlist, field constraints, frequency, maximum impact per run and approval requirements; only then does it call the business interface. A model can therefore emit an out-of-bounds instruction without gaining the ability to carry it out. Putting every safety rule in the prompt is insufficient: a prompt is not an authorisation system and cannot replace backend enforcement.

Every execution should leave evidence that can reconstruct the event: initiator, input and data versions, model recommendation, policy that allowed it, endpoint called, source-system response and any human takeover. A log entry saying only "success" is not enough, but copying complete sensitive content into every log is not appropriate either. Store the identifiers, summaries and versions needed for investigation, subject to retention and access controls.

Rollback is a rehearsed business path, not an undo button

Read and recommendation levels are comparatively simple to retreat from: close the entry point and send users back to the old screen. Write-back and execution may already have created documents, started approvals or notified downstream systems, so switching off the AI service is not a rollback. Define compensation by action type: delete a draft, restore an old field version, withdraw a document in approval, notify recipients of a correction, and name the person who handles actions that cannot be compensated automatically.

Rollback also requires reconciliation. Determine which requests succeeded during the incident, which timed out but committed, and which remain in a queue by using business identifiers and idempotency keys. Without that view, teams submit again after recovery and create duplicates. Keep the former workflow available until the new path has survived its observation period, and rehearse the switch. A document that merely says "roll back if required" does not constitute rollback capability.

Moving an integration experiment into production also requires monitoring, ownership and operational exception handling. What separates an AI pilot from production provides the broader production-readiness checklist. The test of an integration is not whether a demonstration created one record successfully, but whether the team still knows how to stop, investigate and restore service when a real exception arrives.

Use an integration scorecard before advancing a level

Before each advancement, business, IT and security owners should inspect six kinds of evidence: the business scope is explicit; interfaces expose only necessary fields and actions; user, service and approver identities are traceable; normal, unauthorised, incomplete, duplicate, timed-out and conflicting inputs have been tested; logs can reconstruct a request; and shutdown, compensation and reconciliation have been rehearsed. These six areas form a project checklist, not a universal pass rate. Add thresholds that match the impact of the action.

Acceptance needs real but controlled exceptions, not just happy-path samples. Ask an unauthorised employee to request another department's order, deliver the same write message twice, change the source document during confirmation and force the downstream endpoint to time out. Observe whether the system rejects, degrades or hands over appropriately. A control is credible only after the team has watched the failure path.

Connecting AI to ERP and OA joins natural-language judgment to formal business records. The sound order is to establish truth and accountability, then open read access; make recommendations verifiable before allowing write-back; and prove that exceptions can be contained and actions compensated before considering autonomy. Calling an API is only the technical starting point. Integration is complete when errors have a bounded effect and the business can recover.