Leading Cross-Functional AI Transformation

A fictional building-materials distributor with warehouses in nine countries spent a year telling every function to find uses for AI. The company, its people, and its figures are invented. By the end of the year six efforts were running, each paid for from its own function’s budget and each bought from a different supplier: a drafting assistant for customer service, invoice coding in accounts payable, a demand-forecasting model in supply planning, an applicant-ranking tool in recruiting, a proposal generator in sales, and a slotting optimizer in the warehouses.

The new VP of AI Transformation reports to the chief operating officer and controls none of those budgets. Her first month produces three findings. The recruiting tool surfaced only because a supplier invoice reached her desk; no list of AI uses existed. Customer service reported that the drafting assistant had cut handling time, while finance’s credit team was falling behind on credit-memo requests, and nobody had connected the two. And the chief human resources officer asked what the company would tell employees about their jobs, a question no one could answer. None of these is a technology problem. They ask who owns a use case, who owns the process it changes, what happens to the people doing the work, how the company will know the benefits are real, and which of these decisions belong to the enterprise rather than to a function.

She can rely on the platform organization’s decisions about shared services and how teams reach them, which are covered in Platform Engineering Leadership Decisions in an AI-Enabled Enterprise. Her job starts where the platform ends, with the business functions that use it.

Who owns an AI use case

A use case, in this article, is one AI-supported change to one piece of work in one function: drafting credit requests, coding invoices, ranking applicants. The outcome of a use case belongs to the function whose work changes. Only the customer service director can redesign how agents handle contacts, set the quality bar for a draft, and decide what to do with the time it frees. An AI office that claims the outcome is claiming something it cannot change, and a function that claims only the tool has handed its responsibility to the supplier. A U.S. Office of Management and Budget memorandum on federal AI governance (M-25-21, April 2025) makes a similar point: it encourages agencies to give the authority to identify, assess, mitigate, and accept risk for an AI use case to the officials accountable for that use case’s mission outcome.

Outcome ownership alone leaves gaps, because one use case involves several distinct decisions. The register should assign each to a named role, which is what decision rights mean in practice.

• The business owner holds the budget, sets the goal, and answers for adoption and benefit.
• The process owner has authority over the end-to-end process the use case changes, which may cross several functions.
• The system owner builds or configures the AI system and operates it, whether that is an internal team or a supplier-managed service, and answers for performance, change control, and incidents.
• The data owner decides what data the use may touch.
• The risk owner accepts the residual risk after controls. For most uses that is the business owner; for uses with serious consequences it is an executive or a risk function with authority the business owner lacks.

One person may hold several roles in a small use case. What matters is that every decision has a name beside it, and that testing is not done only by the people who built the system. The NIST AI Risk Management Framework Playbook recommends separating development from testing so that course correction can be independent, and it expects executive leadership to take responsibility for decisions about AI risk while delegating the power, resources, and authorization to act at each appropriate level.

The first thing the VP builds is a register with one entry per use, not per tool, following the pattern of an AI system inventory. One model can serve a harmless internal search and a customer-facing refund draft, and those two uses carry different risks. She assembles the first version from contracts, supplier invoices, and a request to each function head. It shows that two functions have bought the same drafting capability under different terms.

Funding follows the same logic. A function pays to build and run its own uses, because money should follow the benefit claim: the function that books a saving should carry the cost of producing it. The center pays for what several uses share, such as model access, evaluation tooling, and training, the pattern described in Every Team Had Its Own Key. A central pool that funds use cases directly gives functions a free option and weakens ownership. Pure function funding duplicates shared components and hides total spend. The register’s job is to make the total visible, so the portfolio can be compared against the capacity of the people who must absorb it, as in Ninety-Four Projects, Every One Approved. What she does not hold is the right to choose which work a function should improve.

A process owner sees the handoff the function cannot

A process owner is the person with authority over how an end-to-end process works, including its handoffs, measures, and rules, however many functions perform its steps. The role matters most where an AI tool speeds up one step and changes the load on the next.

The distributor’s order-to-cash process runs from a customer’s order through delivery, invoicing, disputes, and payment. When a delivery arrives damaged or short, the customer contacts customer service, and an agent files a credit-memo request. Finance’s credit team reviews each request against delivery records and photos before issuing the credit. Before the drafting assistant, filing a request was tedious enough that agents often deferred it until the customer called back. The assistant drafts the request from the contact notes, and agents now file more of them.

Assume the requests rise from 1,800 to 2,700 a month. The credit team has three analysts with 120 review hours a month each, 360 hours in all, and a request takes ten minutes to review. Capacity is therefore 21,600 minutes divided by 10, or 2,160 requests a month. Before the assistant, the team handled 1,800 requests, which is 300 hours and 83 percent of its time. Afterward the demand is 2,700 requests, or 450 hours, which is 125 percent of the time available. The backlog grows by 540 requests a month. After four months 2,160 requests are waiting, exactly one month of the team’s capacity, so a new request waits about a month for review if the queue is worked in order. The customer experiences the whole interval from complaint to credit, and that is the interval nobody was measuring.

Each function’s report is accurate. Customer service saved time and finance is overloaded. Neither function’s goals cover the handoff, and neither head can fix it alone, because each remedy sits in a different budget or risk decision.

Remedy	Review hours needed per month	Hours needed as a share of hours available	Who must decide or pay	What it risks
Change nothing	450	125% (of 360 hours)	No one	Credits wait ever longer; customers escalate
Add a fourth analyst (480 hours)	450	94% (of 480 hours)	Finance budget	Almost no slack; a bad month rebuilds the queue
Have the assistant attach delivery records and photos so review takes seven minutes	315	88% (of 360 hours)	Customer service builds it; finance defines what counts as complete evidence	Wrong evidence attached by the draft moves errors upstream into the review
Approve small credits without review (assumed to be 40 percent of requests)	270	75% (of 360 hours)	A risk owner accepts residual loss	Errors and abuse below the threshold go unseen unless sampled

Each row is arithmetic on the same assumptions: 2,700 requests at ten minutes is 450 hours, at seven minutes is 315 hours, and 60 percent of 2,700 at ten minutes is 270 hours. The evidence-package remedy rests on a seven-minute review time that is a target, not a measurement. At eight minutes the team is exactly full, since 21,600 divided by 2,700 is 8. At nine minutes capacity falls to 2,400 requests and the backlog still grows by 300 a month. The remedy therefore has to be piloted, and review times measured, before anyone relies on it.

The VP does not own order-to-cash, and she should not. The role has to exist whether or not AI does, and an AI office does not know the process well enough to judge a credit policy. In the distributor the head of order-to-cash operations in finance shared services becomes the process owner, with a written charter: authority over the handoff rules between customer service and finance, a standing weekly review of the queue, and a headline measure of days from customer contact to credit issued. With the VP she chooses the evidence package and adds a temporary contract analyst while it is built; a fourth analyst lifts capacity to 2,880 requests a month, above the 2,700 arriving. The small-credit remedy goes to the risk owner as a sampling pilot, because approving credits without review is a risk decision that neither department may make by default.

What happens to the people doing the work

Customer service has 40 agents with 120 productive hours a month each, so 4,800 hours. The assistant is used on 9,000 of 12,000 monthly contacts, 75 percent. After subtracting the time agents spend checking and editing drafts, it saves two minutes per contact. That is 18,000 minutes, or 300 hours a month, which is 2.5 full-time equivalents and 6.25 percent of the team’s capacity. Spread across 40 agents it is 7.5 hours each. Seven and a half hours a month is not a position. It becomes one only if schedules can be rebuilt so the freed time accumulates where the contact center can remove it, and only if contact volume stays flat.

The company can use released capacity in several ways: absorb growth in contacts, raise quality, move people to other work, leave openings unfilled, or reduce headcount. With 15 percent annual attrition among 40 agents, six agents leave in a year, so 2.5 full-time equivalents is five months of departures left unfilled. That is the optimistic reading. Half of the 300 hours reappears as extra review work in finance, as the previous section showed, leaving 150 hours, or 1.25 full-time equivalents, which is 2.5 months of departures. The workforce decision depends on a net figure that only a cross-function view can produce.

The VP asks the chief executive and the chief human resources officer to decide what the company will do with released capacity before the benefit figures are published. This is a judgment, not a research finding, but the mechanism is easy to see. Staff who expect a good result to end in dismissal have reason to avoid the tool, to hide workarounds, or to report their use of it as lower than it is, and then the measurements the benefit case depends on stop being reliable. A public commitment to redeploy or not to backfill also costs something, because it narrows what the company can do if volumes fall. The decision belongs to the executive team and not to a single function head, because it sets a precedent for every other function.

The gains also differ across people. In a study of 5,179 customer support agents who received a generative AI assistant, Brynjolfsson, Li, and Raymond found that productivity measured as issues resolved per hour rose 14 percent on average, 34 percent among novice and lower-skilled workers, and little among experienced and highly skilled workers. A staffing formula built on the average would misjudge a team whose gains come mostly from its newest members, and the same pattern changes how people learn the job and what experienced staff are asked to do. A separate field experiment with 758 consultants found a sharper boundary. On tasks inside the AI’s capability, consultants using it completed 12.2 percent more tasks, 25.1 percent faster, at higher rated quality. On one task chosen to fall outside that capability, they were 19 percentage points less likely to produce a correct answer than consultants without it. The study’s authors call this irregular boundary the jagged frontier.

For customer service the lesson is concrete. Agents need to learn which categories of contact the assistant drafts well and which it drafts confidently and wrongly. Checking a draft is a skill that needs training, time, and the evidence behind the draft, which is why an approval click is weak evidence of human oversight. A target that rewards only speed invites automation bias, the habit of accepting output unread. Each affected role needs a written account of what changes: the agent becomes an editor and reviewer, the accounts payable clerk handles the exceptions the coding model refuses, the planner challenges forecasts instead of building them. Their managers need measures suited to the transition, a subject developed in The Training Was Delivered and Nothing Changed.

Some uses touch employment directly. Annex III of the EU AI Act lists, among its high-risk uses, systems intended for recruitment or selection, including filtering applications and evaluating candidates, and systems used to make decisions about the terms of work relationships, to allocate tasks based on individual behavior, or to monitor and evaluate workers’ performance. Article 26(7) requires an employer to inform workers’ representatives and the affected workers before putting a high-risk system into use at work. A 2026 amendment, Regulation (EU) 2026/1744, moved the application date for these obligations for Annex III systems to December 2, 2027, with transition rules for systems already on the market, as the high-risk AI system entry explains. The applicant-ranking tool is the kind of system the list describes. Consultation with employee representatives takes time and shapes how the tool is used, so the distributor starts it now, with the recruiting function as business owner and the legal team as risk owner. Article 4 separately asks providers and deployers to take measures to support the AI literacy of their staff, and the distributor treats that as a baseline for every function.

Governance that decides, and benefits counted once

A governance structure for this work needs a written list of the decisions it makes. A standing body without one decides little, which is what the fictional logistics group found in Thirty People in a Room Every Month. The distributor needs three kinds of decision, each with a named holder. The first is whether a new use may start: its risk tier, the data it touches, and the supplier terms. The AI office holds this gate, with legal and security input, and commits to a stated response time, because waiting is the price of control, as decision latency measures. The second is whether a running use continues, scales, or stops. The business owner and finance decide it quarterly against capacity and evidence written at approval. The third is whether a claimed benefit is real, which finance validates. A governance body is appropriate only for questions that exceed delegated authority; residual risk for an ordinary use stays with that use’s risk owner.

Benefit claims need a ledger with one entry per claim, a unit, an owner, and a validation by finance. The unit matters because hours released, cash saved, and revenue gained are different things. Hours become cash only through an action: a position not backfilled, overtime avoided, a contract reduced. Until then they are capacity, and the ledger should say so. The related practice of benefits realization adds an owner and a test to each claim, and Live for a Year, Used by a Third shows how to measure adoption by completed cases through the intended path rather than by access.

The customer service figures show why the ledger needs a counting rule. In the first draft of the portfolio summary, customer service reported 300 hours as productivity and the same effect again as 2.5 avoided hires, which at 120 hours each is another 300 hours. The summary added them. That is double counting, and the finance partner removes it.

Line	Hours per month
Customer service: time saved, as first reported	300
Customer service: avoided hires (2.5 full-time equivalents), the same effect reported again	300
Portfolio summary as first drafted	600
The effect counted once	300
Less added credit-memo review work with no change to the handoff (450 minus 300)	150
Net with no change to the handoff	150
Less added review work with a seven-minute review (315 minus 300)	15
Net with a seven-minute review, if the pilot confirms it	285

The net figure of 285 hours is 2.375 full-time equivalents, and it is still a statement about capacity. It becomes a financial benefit only when the executive team’s decision on released capacity is carried out and finance sees the result in expense. The ledger records the forecast, the observation, and the attributed effect as separate entries and keeps them separate in every report.

Enterprise scope and domain scope

A decision belongs at enterprise scope when it creates obligations that bind the whole company, such as law, contracts, or security posture; when it allocates something shared, such as model capacity, data, or specialist time; or when its consequences fall on a function other than the one deciding. It belongs to the function when it depends on knowledge only that function has. Most decisions answer both ways, so a placement table helps more than a principle.

Decision	Where it sits	Reason
Risk tiers and which uses need review before launch	Enterprise	One definition, because legal and security obligations attach to the company
Minimum supplier terms: data use, retention, model changes, exit	Enterprise	Contracts bind the company, and three functions negotiating separately will accept three different positions
Model access, credentials, quotas, and cost allocation	Enterprise platform	A shared resource that one team’s traffic can exhaust for others
Which work to improve, and with which use case	Function	Depends on knowledge of the work, within the portfolio’s capacity
Workflow design, quality thresholds, and adoption plan	Function	The function must live with the redesigned work
Handoff rules between functions	Process owner	The consequence lands outside the function that changes its step
What happens to released capacity and roles	Executive team with HR	Sets a company-wide precedent and affects trust everywhere
Benefit definitions and validation	Finance	One counting rule, applied independently of the claimant
Baseline AI literacy training; role-specific training	Enterprise; function	The baseline is common; the tasks differ by role

Supplier choice is the contested row. The recruiting tool was bought under terms nobody reviewed: whether the supplier could train on applicant data, what happened when it changed the model, and how the company could leave. Those terms are an enterprise matter. Which tool suits slotting inside a warehouse is not. The VP therefore sets minimum contract terms and an approved route for buying, and the functions choose within it, with a defined exception process for suppliers that cannot meet the terms.

The mistake runs in the other direction too. If the gate reviews every parameter change in the slotting optimizer, requests queue, functions learn to describe their work as something other than AI, and the register stops being accurate. The gate should cover changes that alter the risk tier, the data, or the supplier, not every tuning decision. The same memorandum shows a public version of this split. It requires each agency to designate a Chief AI Officer who promotes adoption and governance in coordination with other officials and maintains the agency’s AI use case inventory. It also requires the largest agencies to convene a governance board with representatives of IT, cybersecurity, data, budget, legal counsel, and privacy and, where relevant, human capital, procurement, and the officials implementing AI in program offices. The central role holds the register and the process; the program offices hold the outcomes.

What the VP takes to the next review

At the quarter’s end she brings the chief operating officer a register with every use, a named owner for each role, and a process owner for order-to-cash with a charter. She brings the credit queue, with the weekly review of its backlog and the measured review time from the evidence-package pilot, because that single number decides whether finance needs another analyst. She brings the executive team’s decision on released capacity, and a ledger in which the customer service benefit appears once, at 285 hours if the pilot holds and 150 if it does not. She does not bring a claim that the program is working. Whether it is depends on measurements that do not exist yet.

She asks the same questions of every new use case:

• Who is the business owner, and who holds each of the other roles for this use?
• Which process does it change, who owns that process, and what does the next step downstream receive?
• What is the net effect across functions, and which benefits are counted in more than one place?
• What will the company do with released capacity, and who decided?
• Which people use the output without being able to check it, and what do they have to check it with?
• Which decisions here bind the whole company, and who made them?

References

• NIST, AI Risk Management Framework Playbook: Govern.
• U.S. Office of Management and Budget, Memorandum M-25-21: Accelerating Federal Use of AI through Innovation, Governance, and Public Trust, April 3, 2025.
• Erik Brynjolfsson, Danielle Li, and Lindsey Raymond, Generative AI at Work, NBER Working Paper 31161.
• Fabrizio Dell’Acqua and coauthors, Navigating the Jagged Technological Frontier, Harvard Business School Working Paper 24-013, 2023.
• EU Artificial Intelligence Act, Annex III: High-risk AI systems.
• EU Artificial Intelligence Act, Article 26: Obligations of deployers of high-risk AI systems.
• Digital Omnibus on AI, Regulation (EU) 2026/1744, amended application dates and Article 4.
• European Commission, AI Literacy: Questions and Answers.