AI Workforce Operating Model Design: Role Definitions and Human-AI Task Boundaries

A step-by-step playbook for operations directors and transformation leads to design an AI workforce operating model: covering role definitions, task routing rules,...

Overview

An AI workforce operating model is the governance document that defines how AI agents and human workers share responsibility for a business unit's work. It is produced before deployment, not after. Teams that skip the operating model and deploy first typically face three problems within the first 90 days: unclear accountability when AI produces a wrong output, inconsistent escalation behavior because nobody agreed on the rules, and no basis for reviewing whether the AI is performing at the expected standard.

This playbook walks a team through the design of the operating model in nine steps. The output is a document the team can use to onboard new members, review AI performance, and audit accountability.

Prerequisites:

• A named business unit or team scope (this playbook covers one business unit at a time).
• Access to current role descriptions and task lists for the team.
• A named operating model owner who will maintain the document after the initial design.
• Agreement from the team lead or manager that this process will be followed before AI deployment begins.

Inputs: Existing role descriptions, task lists, volume and complexity data, delegation of authority policy (if applicable).

Outputs: Operating model document containing: task classification table, role table (human and AI roles), task routing decision tree, escalation matrix, boundary documentation, and review schedule.

Time to complete: Two to three working sessions of 90–120 minutes each for a team of 5–15 people.

Step 1: Define the scope

Who acts: Operating model owner, team lead. Output: A written scope statement that names the business unit, the team members included, the task categories in scope, and the AI systems being deployed.

Write the scope statement before the classification session. It should answer:

• Which team or business unit does this model cover?
• Which AI systems are being deployed to this team?
• Which task categories are in scope (e.g., "inbound email processing", "document review", "data entry")?
• Which tasks are explicitly out of scope for this operating model (e.g., "strategic planning", "external negotiations")?

A scope statement that is too broad will make the classification session unmanageable. A scope statement that is too narrow will leave gaps that the team fills with informal practice.

Done when: Scope statement is written, reviewed by the team lead, and confirmed as the starting point for the classification session.

Step 2: List and classify tasks

Who acts: Operating model owner, team representatives (at least one person from each major role). Output: Task classification table.

For each task category in scope, classify the task against three dimensions:

Volume: How many instances of this task occur in a typical week or month?

Complexity: Rate 1–5. 1 = fully structured, deterministic, same process every time. 5 = highly variable, requires significant judgment, context from multiple sources, or novel reasoning.

Risk: Rate 1–5. 1 = fully reversible, low consequence if wrong. 5 = irreversible, high consequence if wrong (financial, legal, reputational).

Classification result (from volume, complexity, and risk combination):

Record the classification for each task. Where team members disagree on a classification, use the higher risk rating (err toward more human involvement) until the AI has established a performance baseline.

Example task classification table:

Done when: Every task category in scope has been classified and the classification table has been reviewed by the team lead.

Step 3: Define AI and human roles

Who acts: Operating model owner, HR representative (optional), team lead. Output: Role table defining each AI role and each human role in the new operating model.

For each AI role, document:

• Role name (e.g., "Email Triage Agent", "Document Review Agent").
• Tasks assigned (from the classification table: AI-routed tasks).
• Output format (what the AI produces: a category label, a draft response, a recommendation).
• Boundaries: what this AI role cannot do, what it cannot access.

For each human role, document:

• Role name (existing or revised).
• Tasks retained (AI-assisted and Human-required tasks).
• Oversight responsibilities (which AI-routed tasks this role audits by sample).
• Escalation authority (which decisions this role can make at escalation).

Done when: Role table is complete, every task category is covered by at least one role (AI or human), and no task category has an ambiguous ownership.

Step 4: Design the task routing decision tree

Who acts: Operating model owner, team lead. Output: Task routing decision tree (documented as a flowchart or decision table).

The routing decision tree answers: given an incoming task, how does the system decide whether it goes to the AI agent, to AI-assisted review, or directly to a human?

The decision tree should be based on observable task attributes, not on the AI's self-assessment of confidence. Routing decisions based on AI confidence scores alone can be gamed or unreliable. Prefer routing based on:

• Task category (from the classification table).
• Task attributes that can be identified at intake (e.g., ticket category, sender type, document type, amount field).
• Explicit flags (e.g., customer marked "enterprise", "escalation requested", "legal matter").

Example routing decision tree (simplified):

1. Is the task explicitly marked as an escalation or enterprise account request? → Human-required.
2. Does the task involve a financial amount above the threshold? → Human-required.
3. Does the task match a category in the AI-routed list? → AI-routed.
4. Does the task match a category in the AI-assisted list? → AI-assisted.
5. Otherwise → Human-required (default to human when classification is unclear).

Document the decision tree so that it can be implemented in the routing configuration and also read by the team.

Done when: Decision tree is documented and reviewed by the team lead. At least two people have traced a sample task through the tree and confirmed the routing is correct.

Step 5: Design the escalation matrix

Who acts: Operating model owner, team lead, manager. Output: Escalation matrix defining triggers, escalation paths, and resolution accountability.

The escalation matrix answers: when a task leaves the AI-routed or AI-assisted path, who handles it, by what deadline, and with what authority?

For each escalation type, document:

Done when: Escalation matrix is complete, every AI-routed and AI-assisted task type has an escalation path, and every escalation path has a named role (not a named individual: roles survive team changes, individuals do not).

Step 6: Document boundaries and exclusions

Who acts: Operating model owner, manager, legal or compliance representative (if applicable). Output: Boundary document listing what AI agents in this operating model cannot access, cannot decide, and cannot communicate externally.

The boundary document should cover:

Data access boundaries: Which data systems can the AI read? Which are explicitly excluded? For example, HR data, audit logs, customer financial records above a certain tier: document the exclusions explicitly, not just the permissions.

Decision boundaries: Which decisions cannot be made by AI, even if the AI produces an output? Example: issuing a refund above a threshold, sending a legal notice, terminating a service.

Communication boundaries: Can the AI send external-facing communications? Under what conditions? Who reviews before sending?

Boundary change process: When boundaries need to be changed: for example, to give the AI access to a new data source: what approval is required?

Done when: Boundary document is reviewed by the team lead and, where applicable, by legal or compliance. It is signed off as the authority for what AI agents in this operating model are permitted to do.

Step 7: Set performance measurement criteria

Who acts: Operating model owner, team lead. Output: Performance measurement criteria for AI roles and revised criteria for human roles.

For each AI-routed task type:

• What is the quality metric (accuracy rate, error rate, customer satisfaction)?
• What is the monitoring frequency (daily, weekly)?
• What is the threshold that triggers a review (error rate above X, escalation rate above Y)?

For each human role with new oversight responsibilities:

• What are the revised KPIs (see the HR Leader Guide)?
• What does the oversight audit require (sample size, review frequency)?

Done when: Performance measurement criteria are documented for both AI roles and human oversight roles.

Step 8: Set the review schedule

Who acts: Operating model owner. Output: Written review schedule with named dates and responsible party.

The operating model is not a one-time document. Set a review schedule:

• Monthly: Review AI performance metrics against the measurement criteria. Flag any metric outside threshold.
• Quarterly: Review task classification table. Have any task types changed in complexity or risk since the last review?
• Semi-annually: Review boundary document. Have any new data sources, decision types, or communication channels been added?
• Annually: Full operating model review including role table, routing decision tree, and escalation matrix.

Done when: Review schedule is recorded in the operating model document with named dates for the next 12 months and a named owner for each review.

Step 9: Approve and version the document

Who acts: Manager, operating model owner. Output: Version-controlled operating model document with approval record.

Before the AI workforce deployment begins, the operating model document must be approved. Record:

• Document version (start at v1.0).
• Approval date.
• Approving manager name and role.
• Next review date.

When the operating model is updated, increment the version number and record a change summary. Teams should be able to look at any historical version and understand what the operating model was at that time.

Done when: Version 1.0 of the operating model document is approved, signed, and stored in the team's document repository.

Diagram

See the accompanying diagram (ai-workforce-operating-model-map-desktop.svg) showing the operating model map with task types, routing decisions, human oversight points, and feedback loops.

Reusable artifact: operating model template

The following sections should appear in every operating model document produced by this playbook:

1. Scope statement: team, AI systems, task categories in scope and out of scope.
2. Task classification table: task, volume, complexity, risk, classification.
3. Role table: AI roles and human roles with task assignments and boundaries.
4. Task routing decision tree: observable attribute-based routing logic.
5. Escalation matrix: trigger, path, resolver, deadline, authority.
6. Boundary document: data, decision, and communication exclusions.
7. Performance measurement criteria: AI quality metrics and human oversight KPIs.
8. Review schedule: monthly, quarterly, semi-annual, annual dates with owners.
9. Approval record: version, date, approver.

Worked example: task classification session for a customer operations team

A 12-person customer operations team handles inbound inquiries across email, chat, and phone. The team lead and operating model owner hold a 90-minute classification session. The task list compiled in advance has 8 task categories.

The classification session starts with the highest-volume tasks. Email triage (600 per week, Complexity 2, Risk 1) classifies as AI-routed. Standard response drafts for common questions (300 per week, Complexity 2, Risk 2) classify as AI-routed. The team notes that both tasks together account for 75% of weekly volume. If these two categories are routed to AI, the residual human work shifts substantially toward higher-complexity handling.

Billing dispute resolution (40 per week, Complexity 3, Risk 3) generates disagreement in the session. One team lead rates complexity as 2 (the process is defined), the operations manager rates it as 4 (edge cases require significant judgment). The classification rule applies: when team members disagree, use the higher risk rating. Classification: AI-assisted, with the AI preparing an initial summary and recommendation and a human making the final decision.

Refund authorization above the threshold (8 per week, Complexity 2, Risk 5) classifies as human-required despite low complexity, because the risk rating of 5 (financial and reputational consequence if wrong) is determinative. No amount of AI assistance changes this classification until the AI has established a performance baseline in lower-risk tasks.

The session produces a task classification table that becomes the foundation for the routing decision tree in Step 4. The team lead signs the table as the starting point for the operating model document.

Failure modes

Producing the operating model after deployment. Teams that build the operating model retroactively after AI is running find that informal practices have already filled the gaps. The operating model then describes what should happen rather than what does happen. Build it before deployment.

Classification that defaults to AI-routed. Pressure to maximize AI handling can push teams to classify tasks as AI-routed when the complexity and risk ratings would indicate AI-assisted or human-required. Use the classification rubric rather than judgment about what is "probably fine".

Routing decision tree based on AI confidence scores alone. AI confidence scores are model outputs that may not reliably predict task complexity in a given domain. Supplement or replace them with observable task attributes.

Escalation matrix without deadlines. An escalation path that says "route to manager" without a deadline is not an SLA. The escalation matrix must include resolution deadlines.

Operating model reviewed only annually. AI capabilities change, task volumes shift, and new task categories appear. Monthly metrics review and quarterly classification review catch problems before they compound.

Done when (whole playbook)

• Task classification table is complete and reviewed.
• Role table covers all task categories with no ambiguous ownership.
• Routing decision tree has been traced for representative sample tasks.
• Escalation matrix has paths for every escalation type with deadlines.
• Boundary document is approved.
• Performance criteria are documented for AI roles and human oversight roles.
• Review schedule is set.
• Operating model document v1.0 is approved and stored.

Primary references

• NIST AI Risk Management Framework, source checked 2026-11-05
• AWS Bedrock Responsible AI, source checked 2026-11-05
• Amazon Bedrock Agents documentation, source checked 2026-11-05
• Amazon Bedrock monitoring documentation, source checked 2026-11-05