Your salesperson can now draft a credible campaign brief. A support specialist can investigate a technical failure. A marketer can interrogate a financial model. None of them has changed jobs, but the work has already crossed functional boundaries.
If you lead product, AI, or an internal transformation, your immediate problem is not predicting which titles will disappear. It is deciding what people may attempt, what they may own, how their work will be checked, and which old responsibilities must make room for the new ones.
The task envelope is moving before the org chart
Most job descriptions describe bundles of responsibilities. AI changes those bundles one task at a time. It gives someone enough capability to start adjacent work without necessarily giving them the judgment, authority, or context to finish it safely.
That behavior is already visible at meaningful scale. In more than 800,000 work-related ChatGPT messages from U.S. users, 61.5% involved generic work shared across occupations, 21.8% involved work inside the user’s occupation, and 16.8% involved work outside it. Once the generic work is removed, cross-role activity accounts for 43.5% of the occupation-specific messages.
The crossover is especially pronounced in functions that routinely turn ambiguous information into documents, recommendations, or decisions. Outside-role work represented 77% of occupation-specific messages in customer experience, 75% in design, 69% in human resources, 56% in legal, and 53% in marketing. Financial calculation and computer troubleshooting were among the most frequently borrowed activities across functions.
This does not show that marketers have become finance professionals or that support specialists have become engineers. It shows that more people can produce a first pass, investigate a problem, or formulate a better request before a specialist becomes involved.
That distinction matters. A task can cross a boundary while accountability stays where it belongs. A marketer may explore revenue scenarios without owning the forecast. A salesperson may draft a campaign direction without becoming responsible for marketing strategy. A support specialist may narrow down a technical fault without receiving permission to change a production system.
Smaller organizations have a particularly strong incentive to work this way because they have fewer specialists available for every handoff. Among users with typical message volume, cross-role work represented 18.9% of messages in workspaces with two to five seats, compared with 16.3% in workspaces with more than 100 seats. The difference is not enormous, but the operating logic is clear: when expertise is scarce, a useful first pass can prevent work from sitting in a queue.
These message patterns show what people attempted. They do not establish that the output was accurate, useful, approved, or faster to complete. They also do not demonstrate that formal jobs have changed. Treat them as evidence of expanding task range, not proof of productivity or replacement.
For every borrowed task, separate three management questions:
- Permission: Is this person allowed to use AI to explore, draft, recommend, decide, or act?
- Accountability: Who remains answerable for the quality and consequences of the result?
- Capacity: Which existing work will stop, shrink, or move if this becomes a recurring responsibility?
The capacity question is easy to avoid because AI makes the new work look cheap. That is how role expansion turns into hidden work intensification. If someone repeatedly absorbs tasks from another function, do not merely add those tasks to the performance plan. Remove lower-value work, formalize the broader role, or restore the original handoff.
Write a task contract for cross-functional AI work
A vague policy such as use AI responsibly will not help an employee decide whether a polished answer is safe to use. Neither will a blanket rule that every AI output needs human review. The reviewer, evidence, and depth of review should depend on what the output can change.
Use a task contract for each recurring workflow that crosses a functional boundary. This is a short operating specification, not a new job description. It should answer seven questions:
- What outcome is the person trying to produce?
- Which data, documents, and systems may the AI use?
- What may the person explore or draft independently?
- What may the person recommend but not decide?
- Which evidence or test must accompany the result?
- Who owns approval and any resulting action?
- What uncertainty, missing input, or failure sends the work back to a specialist?
Write the boundary in operational language. Can help with finance is too broad. A useful version would be: The product manager may use approved revenue data to draft pricing scenarios and explain the assumptions; the finance owner verifies the source data, calculation, and forecast treatment before the scenario enters a plan.
That wording preserves the benefit of exploration while making it clear that generating a calculation is not the same as approving one.
| Task condition | Employee authority | Required control |
|---|---|---|
| Internal, reversible exploration | Explore alternatives and produce a draft | Show inputs and label assumptions before the work is reused |
| Output affects a customer, forecast, policy, or shared system | Prepare a recommendation | A named owner checks it against the relevant system of record or acceptance criteria |
| Output moves money, commits a legal position, changes production, or changes access | Prepare analysis only; do not act independently | The accountable domain owner verifies the work and performs or explicitly approves the action |
The highest-risk failure is often not visibly bad output. It is a plausible answer received by someone who lacks the domain experience to recognize what is missing. A neat financial model can contain the wrong source period. A legal draft can omit an obligation that was never supplied as context. A technically reasonable fix can create a wider system failure.
Place review at the point where the work becomes consequential. A support specialist can investigate logs in a read-only environment, summarize likely causes, and prepare a proposed resolution. A system owner should still approve a production change. A marketer can model a scenario, but a finance owner should verify the inputs and assumptions before money is committed. AI can reduce the cost of preparing the decision without relocating responsibility for it.
A good cross-functional workflow therefore makes the handoff thinner, not invisible. The specialist receives a structured problem, relevant evidence, attempted analysis, and explicit uncertainty. Less time is spent reconstructing the request, while specialist judgment remains available where it has the most value.
Train people to recognize the capability boundary
Prompt fluency is not the same as professional judgment. In a randomized exercise involving 758 BCG consultants, AI improved quality ratings by more than 40% on tasks within the model’s capability range. On a task outside that range, AI users were 19 percentage points less likely to reach the correct answer. The group that received a prompt-engineering primer performed worst on that out-of-range task.
Those results came from particular tasks and participants, so they should not be treated as a universal productivity estimate. The management lesson is still useful: a person can become better at eliciting convincing output faster than they become better at judging it.
Train on one real workflow at a time. Give people the same inputs, constraints, and imperfect information they encounter at work. A useful enablement exercise should leave the team with these reusable artifacts:
- A clear definition of an acceptable final outcome, not merely a strong-looking first draft.
- The approved context and systems of record that the workflow may use.
- Examples of correct output and examples containing subtle but consequential failures.
- A verification method, such as recalculating a value, checking a cited record, running an existing test, or comparing the result with an approved example.
- Stop conditions that tell the user not to continue without specialist help.
- A named escalation owner who can resolve ambiguity instead of merely reviewing everything.
Make the failure examples difficult enough to expose misplaced confidence. If every exercise ends with the model producing an obviously good answer, employees learn that review is ceremonial. Include missing data, conflicting instructions, outdated context, and an answer that is articulate but unsupported. Ask the employee to identify the failure, explain its consequence, and choose the appropriate escalation path.
Measure performance at the approved-output boundary. Raw prompt counts, message volume, and token consumption show engagement, not business value. A team can generate much more text while creating more review work for everyone else.
For a cross-role workflow, track:
- Time from the initial request to an approved result.
- Specialist review time, not just the operator’s drafting time.
- The share of outputs accepted without substantive correction.
- Rework caused by missing context, incorrect reasoning, or policy violations.
- Escalations and whether they occurred before or after consequential action.
- Failures that reached customers, financial plans, production systems, or other downstream work.
Do not automatically treat a high early escalation rate as failure. It may show that employees are correctly recognizing uncertainty. The dangerous pattern is falling escalation combined with rising rework or downstream defects. That usually means confidence is increasing faster than judgment.
Productize stable workflows, then update the role system
People usually discover valuable AI workflows through flexible tools first. They gather files, explain the task, correct the answer, move the output into another system, and ask for approval. That manual phase is useful because it reveals what the real workflow requires.
It should not remain manual forever. Consider turning the workflow into an internal product when several of these conditions appear:
- People repeatedly collect the same inputs or copy the same files.
- They correct the same model mistakes or restate the same constraints.
- The output moves through the same systems in the same order.
- Permissions and approval steps are predictable.
- Several employees need the workflow, but each has built a different version.
- The organization needs a consistent record of inputs, outputs, reviews, and failures.
Build after the workflow has survived real use under human supervision. Automating an unstable process only makes its ambiguity faster and less visible.
A dependable internal AI product should ask for the required inputs, retrieve approved context, limit tool permissions, run workflow-specific checks, and display evidence beside the answer. It should hide model choices that the employee does not need to make. The review step should sit immediately before the consequential decision, with the accountable owner, rather than appearing as a generic approval box at the end.
Use real accepted and rejected examples as evaluations. Record why reviewers changed an output, because repeated corrections reveal missing context, weak instructions, inadequate validation, or a task the model should not handle. This turns human review into product feedback instead of permanent manual cleanup.
Once the workflow is reliable, update the surrounding role system. Otherwise the technology and the organization will describe two different jobs.
- Job descriptions should name the outcomes an employee may own and the decisions that remain outside the role.
- Performance measures should reward approved quality, cycle time, and sound escalation rather than the volume of AI-generated output.
- Career paths should recognize stronger framing, verification, and decision-making, not just facility with a particular model interface.
- Hiring exercises should include a plausible but flawed AI output and ask the candidate to test it, identify missing context, and decide whether to escalate.
- Workforce planning should account for responsibilities removed as well as responsibilities added.
Avoid adding generic AI proficiency to every role. It is too vague to guide hiring or performance. Define the actual capability instead: supply the right context, produce a first pass, verify specified claims, recognize a boundary, and involve the correct specialist.
This is also how AI changes the value of specialists. Their work shifts away from receiving poorly formed requests and reproducing standard first drafts. More of their time can go toward defining rules, reviewing consequential exceptions, improving shared workflows, and handling cases where context or judgment cannot be compressed into a prompt.
Key takeaways
- AI expands roles at the task level before titles, reporting lines, or formal responsibilities change.
- Separate permission to attempt a task from accountability for its consequences.
- Use task contracts to define inputs, authority, validation, approval, and escalation for recurring cross-functional work.
- Train employees to detect convincing failures, not merely to produce polished answers.
- Measure approved outcomes and total review effort; message or token volume is only an engagement signal.
- Productize workflows once inputs, corrections, permissions, and approval points become repeatable.
Start with one cross-functional workflow that is already happening informally. Write its task contract, run it on real work, and measure the path to an approved result. If quality holds and the same manual steps keep returning, turn it into a shared product. If it does not, tighten the boundary or return the work to the specialist. Roles can expand safely, but only when capability, capacity, and accountability expand deliberately with them.
References
