Human–AI collaboration: allocating tasks, decisions and responsibility

Separate assistance from authority

Human–AI collaboration assigns observable work to a model, deterministic checks to software, and accountable judgments to people. A plausible proposal does not authorize sending it, changing a price or modifying access. This article uses human responsibility, external permission enforcement and traceable work as design principles; it does not assert that a particular platform has implemented every control. Define the accepted outcome and intolerable failure first. Merely placing a person somewhere in a workflow is insufficient. Effective oversight depends on what that person can inspect, whether rejection is possible, and whether review time is realistically available.

Scroll the diagram horizontally to read

Describe actions instead of vague job titles

Break an actual task into intake, evidence selection, drafting, checking, approval, execution and confirmation. For each action, name inputs, expected outputs, tools, permitted data and the accountable role. Access to public research during drafting does not imply access to every customer record. Replace a broad instruction such as assist legal with a bounded task: identify differences from the approved template, cite source passages, and make no contractual commitment. This description supports behavioral tests and reveals when specialist judgment is required. It also prevents every failure from being dismissed as a problem that a more elaborate prompt will solve.

Explain capability, uncertainty and the next step

HAX places AI interaction in the contexts of first use, ongoing use, mistakes and change over time. [S1] A practical interface should show the source material being processed, whether the output is a candidate or approved version, missing information and any proposed external effect. A high-confidence badge cannot replace evidence. Let reviewers open the relevant passage and date for important assertions. When users correct something, distinguish a change to this draft from a proposal to update a shared rule. Otherwise one contextual preference can silently become organization-wide behavior. Users need a reliable expectation of what the system will do after each confirmation.

Make the human checkpoint usable

Provide the original request, output differences, key evidence, unresolved questions and proposed action. Separate the judgment that content is usable from authorization to execute it. An editor may assess wording while another role confirms the destination and version. Risk-based sampling can support routine draft checks, but sampled content quality does not authorize payments, deletion or publication. If reviewers see only conclusions, cannot access evidence or receive more requests than they can examine, reduce the automated scope. Counting accepted dialogs is not proof of meaningful oversight. Measure review effort and rejection reasons so the process can be improved rather than merely documented.

Enforce boundaries outside the model

OWASP describes indirect prompt injection through external material and discusses controls including least privilege and human approval for high-risk actions. [S2] Identity, scope and tool arguments should therefore be validated by application code. The model proposes a tool request; it cannot grant itself access. A website instruction to send a contact list is source content, not user authorization. The receiving tool must check the acting identity, writable scope and current approval. A model statement that permission was obtained is not a credential. Rejection should preserve an explanation and an escalation path, while preventing a retry through another tool that bypasses the same restriction.

Keep work state outside the conversation

Represent waiting for data, draft, awaiting review, returned, approved, executing, complete and uncertain as distinct states. A handoff card records the current version, evidence, completed actions, unresolved decisions, next permitted step and stop conditions. A new person or tool reads that versioned record and rechecks access before continuing. Conversation summaries can provide context but should not be the only authoritative state. Keep reusable procedures, confirmed company facts and temporary task context separate. An instruction that was appropriate for one urgent request should not silently be embedded in a permanent capability definition. This separation also makes later correction possible.

Reconcile external actions before retrying

Before sending a message, creating a ticket or publishing content, record the intended version, destination and deduplication identifier. Retain the service receipt afterward. A timeout can mean the service accepted the action but the response was lost. Represent this as an uncertain outcome and inspect the remote record or reconcile manually before retrying. Regenerating a sentence that says completed proves nothing about delivery. This is a proposed reliability contract, not a guarantee provided by model reasoning. Test timeouts, duplicate requests, expired identity and partial success, and name the person who can reconcile, resend or withdraw an action when the available evidence remains ambiguous.

Create a concise collaboration contract

Keep example inputs beside prohibited behavior. The business owner defines success and trade-offs; the data custodian defines readable scope; engineering enforces tool limits; a reviewer assesses content and exceptions; an authorizer confirms external effects. One individual may fill several roles without making every permission implicit. Record trigger, deliverable, permitted actions, disallowed actions, evidence requirements, review criteria, return reasons, escalation recipient and service expectations. For execution, add approved version, destination, action, expiry, receipt reference and reconciliation owner. Update the contract and its tests when scope or risk changes. Adding a general warning to the prompt is not equivalent to changing the operating boundary.

Illustrative scenario: preparing a commercial proposal

Imagine a sales team preparing a new proposal. AI classifies interview notes, identifies missing information and drafts from confirmed material. The project owner checks the interpretation of needs. Finance checks pricing and payment conditions. An authorized person confirms the version and recipient before the system sends anything. A note saying the customer agreed, without supporting evidence, remains an unresolved assertion. This is a hypothetical workflow, not a reported engagement. Compare total review time, corrections and returns during a trial. Measuring only the seconds needed to generate a document can conceal an increase in the human effort required to remove unsupported promises.

Test whether responsibility survives failure

Use missing evidence, contradictory inputs, expired approvals, wrong recipients, injected instructions and service timeouts as exercises. Verify the resulting state, evidence and escalation recipient rather than merely checking whether the assistant asked someone to confirm. Restart a task and see whether another operator can identify the approved version and whether the external effect occurred. Record untested boundaries and the actual review workload. If supervision becomes a sequence of blind acceptances, narrow the task and improve inspectability before increasing autonomy. A well-designed collaboration process makes stopping, correcting and continuing normal operations rather than exceptional interventions that only the original designer understands.

Questions about review, self-approval and parallel work

Must a person reread every generated word? Choose checks based on risk, evidence and reversibility, while retaining explicit authorization for consequential effects.

May AI approve its own draft? Its self-report should not become permission; content assessment and execution authority require external rules and accountable roles.

Will several people and agents always finish faster? Only if outputs are separable and integration is controlled. Allocate nonoverlapping work, name an integrator and serialize writes to shared authoritative data. Otherwise parallelism creates conflicting versions and more review. Concurrency is a resource choice; an accepted, correctly authorized result remains the measure of success.

Sources and evidence boundaries

1. S1 · Guidelines for Human-AI Interaction

   Microsoft HAX Toolkit · Accessed 2026-10-22

   Supports the cited principle; operational steps and illustrative scenarios are editorial recommendations rather than reported customer results.

2. S2 · LLM01:2025 Prompt Injection

   OWASP Gen AI Security Project · Accessed 2026-10-22

   Supports the cited principle; operational steps and illustrative scenarios are editorial recommendations rather than reported customer results.