A human–AI operating model for professional services

AI agents should not be treated as digital staff members with undefined authority. Professional-services firms need an operating model that connects machine capabilities to named human accountability, governed knowledge and controlled workflows.

A human–AI operating model defines:

1. who owns each client or business outcome;
2. what work an agent may perform;
3. which decisions remain human-only;
4. how work is supervised and recorded;
5. who owns the end-to-end workflow;
6. what information the agent may access;
7. when work must stop or escalate; and
8. how service quality is assessed.

The objective is not to maximise autonomous activity or assume that introducing agents will reduce headcount. It is to allocate tasks appropriately among human judgement, machine capability and organisational controls—and then measure whether that design improves the service.

This operating model is one component of AI workforce orchestration for professional services, which coordinates people, AI systems, workflows, information, governance and measurement.

Start with named human accountability

An AI system can retrieve information, generate content, recommend an action or execute a permitted step. The firm should still assign internal accountability for the resulting professional or business outcome to an authorised human role.

This assignment clarifies governance inside the firm. It does not determine legal liability, transfer statutory or professional obligations, or ensure that controls will work as intended. Those questions depend on the circumstances and applicable law, regulation, professional duties and contracts. Firms must support documented accountability with appropriate authority, training, monitoring and review.

A material AI-enabled workflow may need several roles:

• Outcome owner: Accountable within the firm for the client or business result.
• Workflow owner: Responsible for the complete process, including hand-offs, controls and exceptions.
• Professional reviewer: Determines whether work satisfies the firm’s acceptance criteria and applicable professional standards.
• Knowledge owner: Maintains the approved sources used by the workflow.
• Control owners: Set requirements for areas such as privacy, security, records and technology risk.
• System owner: Manages the agent, integrations, access and technical performance.

These responsibilities may belong to different people. An engagement partner might own the client outcome while an operations leader owns the workflow. The operating model should document how their decision rights interact and who can stop or change the workflow when they disagree.

The US National Institute of Standards and Technology’s Artificial Intelligence Risk Management Framework 1.0 includes governance outcomes concerning documented roles, responsibilities and communication for AI risk management. The Australian Government’s voluntary Guidance for AI Adoption provides guidance for organisations adopting and using AI responsibly. Neither resource, by itself, establishes that a firm’s allocation of accountability is legally sufficient or operationally effective.

Design roles around tasks and decisions

Existing job descriptions are usually too broad to govern human–agent collaboration. Firms should decompose work into tasks, decisions and hand-offs.

A starting allocation might look like this:

Activity	Human responsibility	Permitted agent contribution
Accept client instructions	Confirm authority, intent and scope	Capture or summarise instructions
Conduct research	Select the method and assess relevance	Search approved sources and organise findings
Draft work	Set the position and approve the final output	Prepare a draft from authorised context
Make a consequential judgement	Decide and document the rationale	Present evidence, inconsistencies or options
Execute an approved action	Set authority and monitor exceptions	Perform the action within defined limits
Assure quality	Set standards and decide whether work is acceptable	Run specified checks and flag deviations

This is a design template, not a universal allocation. Appropriate roles depend on the service, consequences of error, applicable obligations and the firm’s ability to detect problems.

Set delegation boundaries by risk

Delegation is not a binary choice between human and automated work. A practical model uses several levels:

1. Assist: Retrieve, summarise, classify or format information.
2. Draft: Produce work that requires human review before use.
3. Recommend: Propose an action or decision, supported by available evidence.
4. Act with approval: Prepare an action and execute it only after human authorisation.
5. Act within guardrails: Execute defined, reversible actions and report exceptions.
6. Prohibited: Do not perform the task.

The permitted level should reflect:

• potential effects on clients or third parties;
• reversibility of an action;
• sensitivity of the information;
• financial or contractual authority;
• need for professional judgement;
• novelty or ambiguity;
• reliability and currency of available knowledge; and
• the likelihood that an error will be detected before it causes harm.

Repetition does not necessarily make a task low-risk. A standard communication can still disclose the wrong client information or create an unintended commitment.

For material workflows, maintain a delegation register identifying permitted activities, required approvals, prohibited actions and escalation triggers. Review it whenever the workflow, model, information, integration or risk profile materially changes.

Build supervision into the workflow

Human review is useful, but it is not a complete control strategy. Reviewers can lack context, miss errors or approve outputs mechanically. A stronger operating model combines preventive, detective and corrective controls.

Preventive controls

Preventive controls constrain the workflow before an action occurs:

• approved tools, models and information sources;
• access based on role and business purpose;
• mandatory inputs;
• financial, transaction or authority limits;
• restricted output destinations; and
• blocked actions for prohibited uses.

Detective controls

Detective controls identify potential problems:

• validation against business rules;
• source links or citations for factual outputs;
• reconciliation with systems of record;
• anomaly and exception flags;
• activity and approval logs; and
• targeted or risk-based human review.

Corrective controls

Corrective controls define the response to failure:

• stop or suspend the affected workflow;
• reverse an action where possible;
• route the case to an authorised person;
• notify relevant control owners;
• preserve records needed for investigation; and
• revise access, instructions or tests before resuming.

Control design should be proportionate to the workflow’s risks and tested rather than assumed to work. For a broader treatment of accountability, privacy, security and vendor controls, see governing an AI-enabled workforce in Australia.

Assign ownership across the complete workflow

An agent may perform only one part of a service, but risks often emerge at the hand-offs between steps. Optimising an isolated task does not ensure that the complete workflow will be dependable.

The workflow owner should understand:

• where instructions enter the process;
• which systems and people supply information;
• where the agent retrieves, generates or acts;
• when human review or approval occurs;
• which system records the authoritative result;
• how exceptions leave and re-enter the workflow; and
• who can suspend, modify or retire the process.

Task ownership and workflow ownership should not be confused. A practitioner may review an output without owning the integrations, escalation queues or upstream knowledge that produced it. The workflow owner coordinates those dependencies while the outcome owner retains internal accountability for the result.

A useful workflow record identifies each step, responsible role, permitted system action, required input, approval point, evidence captured and escalation route. It should cover the complete service rather than only the agent’s activity.

Define escalation before exceptions occur

“Refer unusual cases to a human” is not an adequate escalation rule. The operating model should specify the trigger, destination, interim state and authority of the receiving role.

Escalation triggers may include:

• missing, conflicting or unverified source information;
• a request outside the agent’s approved purpose;
• unexpected personal, confidential or potentially privileged information;
• failure of a mandatory validation;
• an action above a financial or contractual threshold;
• disagreement between systems or reviewers;
• suspected privacy, security or professional-conduct issues;
• repeated quality failures; or
• an instruction to bypass, conceal or alter a control.

Each exception should go to someone capable of resolving it. A technical failure may go to the system owner, a professional judgement to a senior practitioner, and suspected data exposure to the firm’s established privacy and security response functions.

The safe default should also be explicit. Where authority, evidence or a required control cannot be established, higher-risk actions should stop rather than continue silently.

Element	Required definition
Trigger	The event, threshold or uncertainty that initiates escalation
Destination	The authorised role or response function receiving the case
Interim state	Whether work pauses, continues within limits or is reversed
Resolution	Who can approve, reject, remediate or resume the workflow

Escalation data can also reveal operating-model weaknesses. Recurring exceptions may indicate poor instructions, unsuitable delegation, incomplete knowledge, weak integrations or an unrealistic acceptance threshold—not simply individual error.

Give agents access to governed knowledge

Professional work depends on contextual knowledge: client files, precedents, methodologies, policies, templates and expert judgement. Broad access may improve retrieval while increasing confidentiality, privacy and quality risks.

For each workflow, define:

• which repositories the agent may search;
• which identity and permissions govern access;
• whether information may cross client or engagement boundaries;
• which sources are authoritative;
• how version and currency are indicated;
• whether outputs must identify their sources;
• what interaction data is retained; and
• how access is reviewed and removed.

A named knowledge owner should maintain each approved corpus, manage conflicting material and withdraw obsolete sources. Where the firm has not established which source is authoritative, the workflow should expose that uncertainty rather than allow an agent to resolve it silently.

Information authority and authority to use information are different. A document may be the current source of truth while still being unavailable for a particular client, purpose or system. Access decisions should account for applicable privacy, confidentiality, privilege, contractual, records, workplace and professional obligations. Applicability depends on the firm, activity, jurisdiction, information and engagement.

This article provides general information, not legal advice. Firms should obtain advice appropriate to their circumstances.

Assure the complete service

Model performance is only one part of service quality. Quality assurance should test the complete workflow: inputs, retrieval, instructions, integrations, human decisions, actions and final outputs.

A service-level assurance model can include:

• acceptance criteria for material outputs;
• representative test cases;
• checks for defined critical errors;
• comparison with an agreed reference set;
• risk-based review sampling;
• tracking of overrides, rework and escalations;
• periodic reviews of access and delegation; and
• investigation of recurring failure patterns.

Thresholds should reflect consequences. An internal discussion draft does not require the same controls as material sent to a client.

Useful measures include cycle time, first-pass acceptance, reviewer effort, rework, exceptions and client-service outcomes. These measures can test whether the operating-model hypothesis is supporting measurable improvement against the agreed baseline. They do not establish in advance that AI will improve productivity or service quality.

See how to measure AI workforce ROI for a broader measurement framework covering cost, capacity, quality, risk, adoption and commercial effects.

How orchestration changes management

Human–AI orchestration should not be reduced to a headcount-replacement programme. It changes what managers need to manage.

In addition to assigning work and reviewing outputs, managers may need to:

• design work at task and decision level;
• allocate authority between people and systems;
• manage queues, hand-offs and exceptions;
• monitor whether controls operate as designed;
• maintain usable organisational knowledge;
• distinguish systemic failures from individual errors; and
• rebalance capacity as workflow demand changes.

Managers remain responsible for coaching, judgement and client context. Their role may also extend to designing the conditions under which routine work occurs and ensuring that exceptions receive appropriate attention.

Any released time should be treated as a capacity hypothesis rather than an automatic commercial benefit. Firms need evidence that capacity can be redirected to valuable work without increasing review effort, rework or risk.

A target operating-model checklist

For every material human–agent workflow, document:

1. Outcome: What service or business result does the workflow support?
2. Accountability: Which authorised human role owns that result within the firm?
3. Roles: Who operates, reviews, supports and controls the workflow?
4. Delegation: What may the agent assist with, recommend or execute?
5. Boundaries: Which decisions and actions remain human-only?
6. Workflow: Who owns the complete process and its hand-offs?
7. Knowledge: What information may the agent access, and who owns it?
8. Controls: What prevents, detects and corrects failure?
9. Escalation: Which events stop or reroute the workflow, and to whom?
10. Evidence: What records show how work and approvals were completed?
11. Quality: Which measures determine whether the workflow is acceptable?

If these elements are unclear, the firm has an AI tool inside a process—not yet a complete human–AI operating model.

Once the model is defined, the separate challenge is putting it into operation through controlled workflow selection, testing and adoption. See the AI workforce orchestration implementation roadmap for that deployment sequence.

Move from isolated tools to accountable workflows

The important question is not how many agents a firm can deploy. It is whether people, governed knowledge and machine execution can be combined in a controlled workflow that supports dependable professional work.

Discuss your operating-model requirements with Digital Sanctum to identify where human–agent delegation may be appropriate and where accountability, knowledge or control design needs attention first.