Case Study: Cross-Functional AI Program at a Fortune 500

A Fortune 500 industrial-and-services group stood up a cross-functional AI program across six functions in eighteen months, anchored by a shared platform that owned model routing, observability, governance, and the sandbox, and operated through function-specific implementation teams that delivered use cases inside marketing, operations, finance, HR, customer service, and risk. The program cleared four stage gates, sustained a quarterly executive review, and produced outcomes that aggregated across functions into a single board narrative.

The board mandate that started the program was specific. Pick six functions, fund a shared platform, run the work through stage gates that bound spend before scale, and produce a quarterly review that an audit committee can defend. The mandate was deliberately operational rather than aspirational — no five-year transformation strategy, no slide deck of moon-shot use cases, just a phased plan with named owners and a cadence that the executive layer could hold without bespoke air cover.

This case study walks the shape that produced the outcomes — the shared-platform composition, the function-team RACI, the four stage gates, the quarterly review structure, the measured outcomes across the six functions, and the lessons that replicate down-market into mid-market and large-mid-market programs. The company is unnamed at the company's request; the numbers and shape have been reviewed for accuracy by the program lead and the executive sponsor. The audience is the executive sponsor or program lead designing a comparable cross-functional rollout, not the analyst evaluating a vendor pitch.

The company entered the program with the shape most large enterprises share by 2026 — pockets of AI work inside individual functions, no shared infrastructure across them, three different vendor relationships that the procurement team could enumerate and two more it could not, an internal audit finding from the prior quarter that surfaced a data-handling exposure inside a marketing pilot, and an executive team that had agreed in principle that AI mattered but disagreed in practice about who owned what. The board mandate that started the program was the response to that finding — fund a real program, six functions, eighteen months, gated.

Three failure modes were already visible from the prior state. The first was tool sprawl — each function had selected its own vendor, sometimes its own model, often its own evaluation approach. The procurement team counted seventeen distinct AI spend lines across the six functions; the platform team that stood up later was able to consolidate that to a managed roster of four routed models plus two specialty vendors, with the rest either retired or routed through the platform sandbox.

The second was governance theatre. The company had a written AI policy that nobody referenced in real decisions, an ethics statement that lived on the intranet, and a privacy review process that operated only for projects that someone proactively routed to it. The audit finding that started the program had surfaced precisely because the governance documents existed but did not bite — a marketing pilot had used customer data in a model evaluation without routing the use case through privacy review, and the postmortem cited the policy as documented but unenforced.

The third was outcome incoherence. Each function reported its AI outcomes in the units that function happened to favour — marketing in lift, operations in cycle time, finance in cost recovery, HR in time-to-fill. The board could not aggregate the outcomes into a single picture; the executive layer could not tell whether the spend was producing value commensurate with the risk. The case study's outcome framework — five comparable metrics across all six functions — exists because of this specific failure mode.

The program shape that emerged from the mandate had two halves that the case study returns to repeatedly. The shared platform owned the capabilities every function needed once — model routing, observability, governance, the sandbox — so that no function had to re-buy them. The function-specific implementation teams owned the use cases that depended on domain context — the marketing knowledge of which campaigns matter, the operations knowledge of which workflows are bottlenecks, the finance knowledge of which controls cannot be bypassed. The shape generalises down-market; the specifics in the rest of this case study explain why.

The shared platform was the program's most consequential structural decision. Rather than letting each function build its own routing layer, its own evaluation harness, its own data governance, its own development sandbox, the program funded a single platform team that owned all four capabilities and published them as services the function teams consumed. The platform team was small — six engineers, one product lead, one security partner — and remained small throughout the eighteen months. Scaling the platform team was an explicit non-goal; the platform was infrastructure, not headcount.

The four capabilities below were the platform's scope from the charter. Each had a named lead inside the platform team, a published service definition, and a consumption pattern that the function teams could rely on without bespoke negotiation. The platform did not deliver use cases; it delivered the capabilities that made use case delivery cheaper, safer, and faster for the function teams.

The platform's economic case rested on a simple counterfactual. If each of the six functions had built its own routing layer, its own observability, its own governance, and its own sandbox, the company would have funded six parallel platform efforts at a total cost the program estimated at roughly five times the shared platform's actual cost — and produced six different audit surfaces, six different vendor relationships per capability, and six different data-governance interpretations. The shared platform was cheaper, safer, and faster than any plausible decentralised alternative.

The platform team's discipline on what it did not do was as important as its scope. The platform did not write the marketing team's segmentation prompts. It did not own the operations team's ticket-routing workflow. It did not adjudicate the finance team's control choices. Centralising delivery inside the platform team is the failure mode the program lead names most often when other companies ask for replication advice — once the platform starts delivering use cases for the function teams, the platform becomes the bottleneck, the function teams stop owning their outcomes, and the program loses the distributed-ownership property that makes it scale.

The function-specific implementation teams were the program's second structural half — the half that produced the use cases that produced the outcomes that the quarterly review aggregated. Each of the six functions named a function-AI lead, an engineering pair seconded from the function's existing technical capacity, and a business owner who reported into the function's leadership. The function team owned the use case end to end — discovery, evaluation, pilot operation, scale decision, embed into business-as-usual.

The shared backbone made the function teams smaller than they would otherwise have been. A typical function team across the six was four to six people total — the lead, the engineering pair, the business owner, and one or two domain partners on partial allocation. Without the shared platform, each function team would have been ten to fifteen people because each would have absorbed its own routing, observability, governance, and sandbox responsibilities. The platform's leverage came from reducing the per-function headcount cost, not from removing the function teams themselves.

The choice matrix below summarises how the program drew the line between the platform and the function teams across the four decision categories where the line was most contested. Each row states the contested decision, the chosen owner, and the reasoning that the program lead defended in monthly committee meetings when functions periodically pushed for the alternative.

The most contested decision in the first six months was use-case selection. Two of the six functions initially pushed for a centralised use-case selection process where the platform team would adjudicate which use cases met the bar for funded engineering support. The program lead refused on the same reasoning as the platform's no-use-case-delivery rule — centralising selection would make the platform team responsible for outcomes it could not own, and would convert the platform from infrastructure into a gatekeeper. The function teams retain selection; the committee reviews backlogs quarterly; the program has held the line.

The function-team composition also evolved. By month nine, two of the six functions had absorbed a dedicated AI product manager into the function team because the function's use-case volume justified the role. Two others remained with the original four-person team because their use-case volume did not. The program design did not prescribe a standard function-team size; it prescribed a standard function-team shape, and let the size scale with the function's actual demand.

The four stage gates were the program's spend-control mechanism. Every use case across the six functions cleared the same four gates in sequence — discovery, pilot, scale, embed — with explicit pass criteria, named approvers, and a budget envelope per gate that capped spend before scale. The gates also slowed down failing pilots before they consumed resources better spent elsewhere; the program retired roughly one-third of pilots at gate two, which the program lead consistently named as one of the program's most important features.

The four gates below name the milestone, the owner, the budget envelope as a percentage of total program spend, and the pass criteria the committee evaluated. The percentages are the company's actual averages across the eighteen-month program; individual use cases varied around the means within ranges the committee documented at each gate.

Gate two — pilot to scale — was the program's most consequential spend-control point. The roughly one-third of pilots retired at this gate represented work that would have absorbed scale-stage resources without producing outcomes proportional to the spend. The gate's pass criteria were strict by design — measurable outcome against a documented baseline, eval evidence across safety and bias dimensions, and an explicit customer-impact assessment from the business owner. The program lead defended the strictness in every monthly review against pressure to soften the criteria for promising-but-flat pilots.

The gate four transition to business-as-usual was the program's scalability lever. Use cases that completed embed transferred engineering responsibility from the function-AI lead — a finite resource — to the function's standing engineering capacity, which freed the function-AI lead to pick up the next use case. Without the embed transition, the function-AI lead would have accumulated maintenance load across every use case the function shipped, and the function's capacity to deliver new use cases would have collapsed by month twelve.

The quarterly executive review was the cadence that converted the program from a project the board had to chase into a rhythm the board could rely on. The review was a half-day standing meeting, chaired by the executive sponsor, attended by the program lead, the platform product lead, all six function-AI leads, and the governance partner. The output was a quarterly governance review document that the audit committee received without re-instrumentation, with a standing structure that made quarter-over-quarter comparison straightforward.

The standing agenda had six items in a fixed order. The order mattered — the review opened with outcome aggregation so the executive layer entered the rest of the agenda with the value-side context, then moved through gate audit, platform health, governance fitness, function backlogs, and next-quarter commitments. The committee resisted re-ordering the agenda even when individual quarters had specific issues that would have been faster to address out of order; the order was the artefact, not just the content.

The quarterly review's most under-rated feature was its durability. The program survived a CFO transition in month fourteen and a CIO transition in month seventeen, in both cases because the quarterly review had already established a rhythm and an audience that did not depend on either executive's personal attention. Programs that depend on bespoke executive sponsorship rather than a standing cadence consistently collapse at the first leadership transition; the quarterly review was the cadence that prevented that failure mode in this program.

The next-quarter plan also served as the program's commitment-tracking artefact. Each quarterly review opened by walking the prior quarter's plan against actual — what committed, what cleared, what slipped, what was retired. The walk was honest about misses; programs that hide misses lose board confidence faster than programs that name them and assign owners to address them. The program lead defended the honest-misses convention in every quarterly review.

The outcomes framework was the layer that converted function-level wins into board-legible aggregate value. Each of the six functions reported its outcomes against the same five metrics — cycle-time reduction, deflection rate, cost-to-serve, capacity reclaimed, customer-impact score — even when the raw activity inside the metric looked different. Customer service's deflection rate meant something different from finance's deflection rate, but both were the same shape of metric, comparable at the framework level if not at the unit level.

The chart below is the aggregate eighteen-month outcome across the six functions, reported in the units the program's quarterly review used. The numbers are illustrative averages drawn from the case study's final quarterly review; individual functions varied around the aggregate within ranges the program documented at the function level. The chart is the shape the audit committee received, redacted for this case study.

The aggregate numbers above are the shape that mattered for the audit committee, but the function-level decomposition mattered more for the program itself. Customer service led on deflection rate; operations led on cycle-time reduction; finance led on cost-to-serve; HR led on capacity reclaimed; marketing led on customer-impact score. Risk did not lead on any single metric but contributed across all five through the embedded governance and the audit-trail capabilities that the platform delivered. No function led on every metric; the framework was designed to surface comparative strength rather than rank winners.

The honest framing the program lead defended at every quarterly review was that the aggregate outcomes were not attributable entirely to the AI program. The functions had concurrent transformation efforts — process redesign, sourcing changes, tooling investments — and isolating AI's contribution from those concurrent efforts was not possible at the precision the audit committee might have wanted. The program reported AI as a contributing factor against documented baselines rather than as the sole driver of the outcomes; the audit committee accepted the framing, in part because it was honest about its limits.

The shape this case study describes — shared platform plus function-specific teams plus stage gates plus quarterly review — replicates down-market with adjustments. The platform's scope shrinks at smaller scale; the function teams collapse into fewer functions; the stage gates remain but operate with lighter artefacts; the quarterly review compresses into a monthly executive cadence. The structural property that holds across all scales is the separation between shared infrastructure and local implementation; the specifics scale up or down with the company's actual demand.

Four lessons hold across replications. Each names what the Fortune 500 program lead and the executive sponsor identified as the highest-leverage learning, and how it generalises to programs at different scales. The lessons are the shape that other companies asking for replication advice most often need; companies that try to replicate without these specific adjustments tend to reproduce the failure modes the program originally avoided.

The replication work is where the case study's real value to other companies sits. The Fortune 500's specific numbers matter less than the program shape and the four lessons that held across the eighteen-month run. Companies that try to replicate the numbers without the shape consistently under-deliver; companies that replicate the shape with their own numbers consistently produce comparable outcomes at their own scale. The shape is the replicable artefact, not the numbers.

For teams considering a comparable rollout, our AI transformation engagements include the program design, the platform-team stand-up, the function-team RACI, and the first two stage gates' worth of cadence operation — so the team inherits a working program shape rather than a slide deck it has to convert into operating artefacts while also delivering the use cases. The companion 90-day governance plan and the 100-point agent-stack readiness checklist are the artefacts the program teams in this case study referenced most often when standing up the governance and platform layers.