Control remains with the people appointed by the business: the process owner defines the assignment, IT grants authorised access and designated colleagues review exceptions and sensitive actions. Permissions, stopping conditions and evidence of the outcome must be agreed and tested against the actual process.
Assigning work also means assigning oversight
“The team keeps an eye on it” is too vague when a case is stuck. Each process needs an owner of the assignment, someone with authority to approve the relevant actions and a named contact for exceptions. In a business with several legal entities, each case must also belong to a defined entity: permission to work for one company should not be treated as authority to act for the others.
One allocation to discuss is for Finance or Operations to define the outcome and working rules, IT to check accounts, connections and access revocation, and the provider’s contact to handle technical problems within the agreed scope. The business identifies who accepts the output and who provides cover when a colleague is unavailable. Accounting judgements, payments and changes to bank details remain with authorised people.
Defining responsibilities and human oversight is consistent with GOVERN 2.1 and 3.2 in the NIST AI Risk Management Framework 1.0. This reference helps frame the questions; it does not certify an individual implementation.
Which data can it read, and which actions can it take?
Start with the task, rather than the most convenient account. Collecting month-end documents might require access to a dedicated folder and permission to update a checklist. It does not necessarily require access to all company email, employee records or payment functions.
The principle of least privilege described by NIST limits permissions to those needed for the task. Applying it requires checking the actual systems: can read and write access be separated? Can access be restricted by entity, folder, field or recipient? Who stores and renews credentials? If a system cannot support the required level of restriction, that limitation needs to be explicit and addressed before the process starts.
An access matrix should name the source, required data, permitted action, person authorising access and method of revocation. Test a permitted action and a prohibited one: a correct permissions list does not demonstrate that the configuration enforces it. The ERP integration checklist helps prepare this assessment.
Three scenarios to test before launch
These examples are illustrative. They describe controls to agree and test, rather than functions already enabled in every implementation.
Scroll the table horizontally to read every column.
| Situation | Behaviour to configure | Human check |
|---|---|---|
| An invoice lacks a required reference | Flag the missing information and pause the dependent step without inventing a value. | The finance contact confirms the reference or rejects the case; the outcome stays linked to the record. |
| An email supplies new bank details | Do not update the supplier record or initiate a payment; refer the request to the authorised person. | The person follows the company’s verification procedure through its approved channels. |
| The response after a write is inconclusive | Flag the unconfirmed outcome and pause retries that could duplicate the action. | IT or the operational contact checks the destination system before authorising recovery. |
The third scenario deserves particular attention: “no confirmation received” does not mean “nothing happened”. The test should establish how to recognise an already processed case and who decides whether to retry. Unique identifiers, duplicate checks and recovery methods depend on the actual integration.
Approval must relate to a specific action
A request saying “may I continue?” is not enough. The reviewer needs to see the case, source, proposed action, recipient or system involved, and the essential details to check. The effect of rejection and the outcome if nobody responds must also be clear. Silence should not implicitly become permission.
Agree what invalidates an approval: if the amount, document or recipient changes, the process must follow the rule for renewed review. Also establish whether the same person may prepare and approve the work, respecting the business’s existing separation of duties. The guide to finance tasks suitable for delegation helps distinguish operational preparation from sensitive decisions.
An exception needs an owner and a recorded outcome
For every stopping condition, define a recipient, a notification channel and a rule for taking ownership. Sending a notification does not prove that anyone has read it. The process owner needs a way to distinguish new cases, assigned cases, cases awaiting information and resolved cases, using the agreed tools.
An illustrative case record contains the case identifier, entity, reason for stopping, completed steps, missing information, owner and next action. If the named person is unavailable, the procedure identifies cover or keeps the activity on hold. Restarting requires the agreed condition to be met, rather than the notification simply disappearing.
How to check that the work is actually complete
Define the evidence expected in the destination system: an available document, an updated status or an entry matched to the case. Retain the references needed to reconstruct the input, outcome and approval, within the company’s access and retention rules. An operational log helps investigation; it is not a certification and does not guarantee freedom from errors or fraud.
The Security and human oversight page explains the Digital Employee service’s approach: bounded assignments, permissions, approvals, escalation and the ability to reconstruct relevant actions where possible. Permission detail, notifications, log retention, stopping and recovery must be specified for the individual process. They are not universal inclusions to infer from this guide.
Before extending an assignment, review observed errors, outstanding cases and changes to systems or responsible people. To turn these checks into clear supplier requirements, use the provider selection questions for CFOs and IT teams. The useful outcome is an operating agreement stating who authorises the work, when it stops and which evidence shows that it is finished.