Every successful AI rollout inside a regulated function has the same hidden architecture, and it is not the tool and it is not the training program. It is a small group of people, usually no more than six, who become the function's living proof that the new way of working is faster, safer, and better, and who quietly absorb the friction that would otherwise stall adoption for everyone else. These are your AI champions: the first six power-users. Get them right and they pull sixty writers up the curve behind them. Get them wrong, or burn them out, and you are left with an expensive tool, a certification pathway no one finishes, and a function that has concluded the whole thing was a fad. This lesson is how a Function Strategist identifies the right six, enables them to succeed, and protects them from the failure mode that kills more AI programs than any technical problem: champion burnout. The champions are not a nice-to-have layer on top of the strategy. In a change effort, they are the strategy's circulatory system.

Why Six, and Why Power-Users and Not Just Volunteers

The number is not magic, but the order of magnitude is deliberate. In a function of fifty to seventy writers, six champions is roughly one per eight to twelve people, which is the ratio at which peer support stays personal and reachable rather than diffusing into a help desk no one uses. Fewer than four and a single departure or a single bad quarter collapses the whole support structure; more than eight and the champion identity dilutes, coordination overhead climbs, and the role stops being special enough to motivate the people in it. Six is the size that lets you cover the function's main sub-disciplines, regulatory writing, CMC, pharmacovigilance, clinical operations, medical affairs, with enough redundancy that no single champion is a single point of failure, while keeping the group small enough to meet, align, and move as one.

The harder design decision is who they are, and the instinct to recruit volunteers is a trap. The writers who volunteer first for an AI initiative are frequently the enthusiasts, the people drawn to the novelty of the technology, and enthusiasm for the tool is not the same as credibility with the skeptics. A champion's job is to change the mind of the senior medical writer with twenty-five NDAs who is convinced the AI cannot write a benefit-risk integration, and that writer is not persuaded by an excited junior colleague who loves gadgets. They are persuaded by a respected peer whose regulatory judgment they already trust, who has produced a defensible Module 2.5 the hard way for years, and who now demonstrates that the AI-assisted way is genuinely better. Credibility is the scarce ingredient, and it cannot be conferred by a title. It is earned in the work, which means your champions must be drawn from the people the function already respects.

This is why the strongest champion is often someone you have to persuade rather than someone who raised their hand. The respected senior writer who is mildly skeptical, not hostile but unconvinced, is the highest-value champion you can recruit, because their conversion is itself the most powerful adoption argument the function will ever see. When the person everyone expected to resist becomes the person demonstrating the workflow, the resistance narrative collapses. The cost is that recruiting them is real work: you have to address their objections honestly, give them a problem worth their judgment, and let them arrive at conviction through their own hands rather than your slide deck. That work is the highest-leverage time you will spend on the entire program.

The Identification Criteria That Actually Predict Success

You can make the selection rigorous rather than intuitive, and you should, because a defensible selection process is also how you justify the time-allocation cost to a CRO. The first criterion is functional credibility: the candidate is a writer or specialist whose work product the function already trusts, ideally someone certified at Level 3 or capable of reaching it quickly, because a champion who cannot themselves produce a defensible AI-assisted artifact cannot teach anyone to. The second is teaching disposition: the willingness and ability to explain a workflow to a peer without condescension, because a brilliant user who cannot transfer the skill is a productivity asset, not a champion. These two are necessary, and many strong individual users fail the second.

The third criterion is influence topology, which most programs ignore and which often matters most. Map who in your function people actually go to with a hard question, and you will find the informal nodes, the writers whose desk everyone stops by, who are not necessarily the most senior on the org chart. A champion who sits at a high-traffic node propagates a workflow far faster than an equally skilled champion who sits in an isolated corner of the network. The fourth criterion is resilience and bandwidth: champion work is emotionally and cognitively taxing, and a candidate who is already at the edge of burnout from their day job, however talented, will not survive the added load, which is the failure mode the last section addresses in detail. Select for someone with genuine slack, or create the slack as a condition of the role.

The fifth criterion is distribution across the function's risk surface. You want champions positioned where the AI work is both highest-value and highest-risk: the Module 2.5 integration point, the ICSR narrative pipeline, the comparability-protocol workflow, the central-monitoring signal triage. A champion embedded in a high-stakes workflow becomes the local expert on its specific failure modes, the person who knows exactly how a fabricated cross-reference shows up in their artifact and exactly which verification step catches it. That localized, artifact-specific expertise is worth more than generic AI fluency, because the function's risk is artifact-specific. Selecting champions by where the risk lives, not just by who is enthusiastic, is what turns the champion network into a distributed quality control rather than a fan club.

Enablement: Time, Tools, Air Cover, and a Direct Line

Naming someone a champion and then giving them nothing is the most common way to set them up to fail, and it is also the cheapest mistake to avoid. The first and most important enablement is protected time. A champion who is expected to do their full day job plus champion the rollout in the cracks will do neither well and will resent both. Carve out a defined, defended fraction of their capacity, often ten to twenty percent, and treat it as a non-negotiable allocation that their line manager has agreed to in writing, because the line manager who quietly claws back that time when a deadline looms is the most common cause of champion failure. The time has to be real, named, and protected at the management level, or it is not protected at all.

The second enablement is privileged access, both to the tools and to you. Champions should be on the leading edge: early access to new model versions, the sandbox where workflows are prototyped before they are validated for production, and a direct line to the strategist and to the vendor's technical contacts. When a champion hits a wall, the question must be answered in hours, not weeks, because a champion blocked on a problem they cannot solve loses credibility with the very peers they are meant to convince. This privileged access is also a reward in itself, a tangible sign that the champion role carries real standing, which is part of how you keep the role attractive enough to retain the people in it.

The third enablement is air cover, which is the strategist's personal job. Champions will be asked to do things that cut across the org chart, to challenge a senior writer's workflow, to push back on a line manager who is reclaiming their time, to escalate a vendor problem, and they cannot win those battles on their own authority. The strategist who recruited them must be visibly, repeatedly willing to spend their own political capital backing the champion in the moment it counts. A champion who gets undercut in front of their peers the first time they push back will never push again, and the whole network goes quiet. Air cover is not a one-time endorsement; it is a standing commitment that the champion can invoke, and the function watches closely whether the strategist actually honors it.

What Champions Actually Do: The Real Job Description

A champion's work divides into three modes, and naming them helps you design the role and measure it. The first mode is demonstration: the champion does real, high-visibility work AI-assisted and lets their peers see the result and the method, the genuine artifact and the genuine verification log, not a sanitized demo. Demonstration is the most persuasive thing a champion does, because it is proof rather than assertion, and it must be honest, including the parts where the AI was wrong and the champion caught it, because a demonstration that hides the failure modes teaches the dangerous lesson that the tool can be trusted. The second mode is support: answering the steady stream of "how do I do this" and "is this output safe" questions from peers, which is where the influence-topology criterion pays off and where the load can become crushing.

The third mode is feedback, and it is the one most programs waste. Champions sit at the exact interface where the designed workflow meets reality, and they are the first to see where the workflow breaks, where the verification step is too slow to be followed faithfully, where the system prompt produces a recurring failure, where a vendor capability falls short of the claim. A strategist who builds a real channel for champion feedback into the governance process gets an early-warning system for workflow problems that would otherwise surface as an inspection finding. A strategist who treats champions as a one-way broadcast layer, push the workflow out and never listen back, wastes their most valuable property: champions are the only people who see the workflow as it is actually executed, not as it was designed. The feedback mode is what makes the champion network a sensing organ for the whole function.

These three modes also tell you what a champion is not. A champion is not a help desk, not a validation function, and not a replacement for the certification program. They accelerate adoption and surface problems; they do not own the tool's validated state or sign off on other people's work product. Keeping the role bounded matters, because a champion role that quietly expands to absorb every AI-related task in the function is a champion role that burns out, and an unbounded role is also an ungovernable one. The strategist defines what the champion does and, just as importantly, what the champion explicitly does not do, and defends that boundary against the organization's tendency to dump every AI question on the nearest enthusiast.

Champion Burnout: The Failure Mode That Kills Programs

Champion burnout is the single most common way a promising AI program dies in its second year, and it is almost always a design failure rather than a personal one. The mechanism is predictable. A champion is genuinely good and genuinely generous, so peers route more and more to them, and because the champion cares, they say yes. The support load grows past the protected-time allocation, the demonstration work that earned them credibility gets squeezed out by the constant interruptions, and their own day-job deliverables start slipping. They are now doing three jobs, being praised for the rollout, and quietly resented by their line manager for the missed deadlines. Within a few months the most capable person in your champion network is exhausted, cynical, and looking to step back, and when they go quiet, the peers who relied on them conclude the program has lost momentum.

The prevention is structural, not motivational, and it starts with honoring the protected time as a ceiling and not just a floor. When the support load exceeds the allocation, the answer is not to ask the champion to absorb it; the answer is to add capacity, route overflow to a second-tier support structure, or formally expand the allocation with the line manager's agreement. You must monitor champion load the way you monitor any other system approaching saturation, with an actual signal, not a vague sense that someone seems tired. Track the volume of support requests, watch for the champion's own deliverables slipping, and check in directly and regularly about whether the load is sustainable, because the most conscientious champions are precisely the ones who will not raise their hand until they are already past the edge.

The second prevention is rotation and recognition. A champion role should not be a life sentence; build in the expectation that champions rotate out after a defined tour, mentoring their replacements, which both prevents burnout and widens the function's pool of capable users over time. And the recognition must be real, in the performance review, in compensation, in visible standing, because a role that costs a writer real effort and slowed personal output but earns them only a vague reputation is a role the best people learn to decline. The strategist who treats champion well-being as a monitored, resourced, rewarded part of the program rather than as inexhaustible goodwill is the strategist whose program is still alive in year three. The champions carry the rollout; the strategist's job is to make sure the rollout does not carry off the champions.

Measuring and Defending the Champion Investment

The champion program costs real money, the protected time of six respected people is not cheap, and a CRO will ask what it returns. The honest answer is that champions are the conversion mechanism between the AI investment and its adoption, and adoption is what turns the modeled ROI into realized ROI. You can make this measurable. Track adoption velocity, the rate at which non-champion writers reach Level 2 certification and begin producing defensible AI-assisted artifacts, and you will typically see it move fastest in the sub-disciplines where a strong champion is embedded and slowest where there is none. That differential is your evidence that the champions, not just the tool, are driving the curve, and it is the kind of evidence a CRO can act on.

You should also measure the feedback channel's output, because the early-warning value of the champion network is real and defensible. Count the workflow problems, recurring failure modes, and verification-gap discoveries that champions surfaced before they reached production or an inspection, and attach to each an estimate of the cost avoided. A single fabricated-cross-reference pattern caught by a champion in the sandbox, before it propagated across Module 2.5 and 2.7.3 and surfaced as a Day 74 Information Request, can justify the entire champion program's annual cost on its own. The champion network is not just an adoption accelerant; it is a distributed quality-sensing capability, and framing it that way to a CMO or a Quality Council reframes the cost from soft change-management spend to hard inspection-risk reduction.

Finally, defend the program against its own success. The most dangerous moment for a champion program is the quarter after it works, when adoption looks broad and an executive asks why you are still funding six champions if everyone is already using the tool. The answer is that adoption is not the same as discipline, that the eighteenth-month erosion of vigilance is real, and that the champions are the standing immune system that catches the drift before it becomes a finding. A program that disbands its champions the moment adoption looks complete is a program that has mistaken the calm before the first serious incident for permanent health. The champions are how the function stays disciplined after the novelty wears off, which is exactly when discipline is hardest and matters most.

Key Takeaways

• Recruit roughly six champions for credibility, not enthusiasm, and prize the convertible skeptic above the eager volunteer. Six is the ratio that keeps peer support personal while covering the function's sub-disciplines, and the respected senior writer who is mildly skeptical is the highest-value champion because their conversion is itself the most powerful adoption argument the function will ever see.
• Select on five criteria: functional credibility, teaching disposition, influence topology, resilience and bandwidth, and distribution across the risk surface. A champion embedded where the AI work is highest-value and highest-risk becomes the local expert on that artifact's specific failure modes, turning the champion network into a distributed quality control rather than a fan club.
• Enable champions with protected time, privileged tool and strategist access, and personal air cover, or you set them up to fail. The protected time must be a written, management-honored allocation, and the strategist must visibly spend political capital backing the champion in the moment it counts, because a champion undercut in front of peers the first time they push back never pushes again.
• Champion burnout is the design failure that kills more AI programs than any technical problem. Conscientious champions absorb growing support load past their allocation until their own deliverables slip and they go quiet; prevent it structurally by treating protected time as a ceiling, monitoring load with a real signal, building in rotation, and making recognition real in review and compensation.
• Measure champions as the conversion mechanism from AI investment to realized adoption and as a distributed quality-sensing organ, and defend them against their own success. Adoption velocity by sub-discipline proves the champions drive the curve, sandbox-caught failures avert Day 74 surprises, and disbanding champions when adoption looks complete mistakes the calm before the first incident for permanent health.