Upskilling in the Age of AI

Pharmaceutical manufacturing organizations frame AI adoption as a procurement and governance problem — which tools to buy, which to permit, how to control them. The framing is wrong. The binding constraint on AI value in regulated industry is neither the tools nor the rules; it is whether the workforce has the skill to turn capable tools into defensible work.

The real barrier is a skills gap, not a tooling gap

The pharmaceutical industry talks about AI adoption as if the hard questions were procurement and permission: which models are validated, which vendors are compliant, which tools the policy will allow. These are real questions, but they are not the binding constraint. An organization can buy the most capable tools on the market and permit them freely and still capture almost no value, because the constraint that actually determines outcomes is whether the people using those tools have the skill to turn them into defensible work.

Skill, here, is not prompt-writing cleverness. It is the literacy to know what a model can and cannot do — where it is reliable, where it confabulates, and how to tell the difference in a context where being wrong has regulatory consequences. A process scientist who can prompt a language model to draft a deviation investigation but cannot recognize when its causal reasoning is plausible nonsense has not been upskilled; she has been handed a faster way to be confidently wrong. The skill that matters is the judgment to interrogate an output rather than transcribe it.

This is sharper in regulated manufacturing than almost anywhere else, because GxP data carries epistemic bias: it encodes the assumptions, sampling choices, and blind spots of the validated processes that generated it. A model trained or prompted on that data inherits those blind spots. The skilled analyst is the one who knows this — who treats an AI output as a hypothesis to be tested against process knowledge, not an answer to be pasted into a controlled document. The gap between owning capable tools and having a workforce that can wield them with that kind of judgment is the real gap. Closing it is the work.

That is the cleanest statement of the problem, and most organizations are failing on both halves at once. The tools and the rules matter — and as I argue below, getting the rules right is genuinely hard — but they are not where adoption succeeds or fails. Skill is. And the failure to build it is largely self-inflicted.

The misdiagnosis: treating access as risk

The conventional argument for restrictive AI governance runs as follows: GxP environments require data integrity, audit trails, and validated systems; commercially available AI tools do not meet these requirements; therefore access must be limited until compliant solutions exist. The argument is correct about regulatory requirements and wrong about the problem it is solving. You cannot build skill on tools that people are not allowed to touch. Restriction does not pause the skills problem — it widens it, because the workforce stops developing capability inside the institution at exactly the moment the technology is moving fastest.

Restriction also fails on its own terms, because it does not actually stop AI use. Employees experiment anyway, on personal devices, in the gap between sanctioned systems and the work in front of them — what Mollick calls the “secret cyborg” dynamic.¹ The organization bears the risk of this behavior, as outputs cross from uncontrolled tools into GxP-adjacent workflows without traceability, while capturing none of the learning. The GxP/non-GxP boundary is not the boundary between safe and unsafe AI use; a model influencing a controlled decision through an undocumented personal-device pathway is inside the risk domain no matter how the tool is classified. Restriction does not close that gap. It moves the risk — and the skill-building — out of the organization’s field of view.

Underneath the compliance language sits a quieter assumption, and this is where trust enters the argument. To withhold capable tools in the name of safety is, at root, to assert that the workforce cannot be entrusted with them. That assertion is what starves skill development, because skill is built through sanctioned, supported, accountable use — not through a permission queue. As one practitioner framing puts it: it is an insult to our employees to tell them they cannot use these tools because we do not trust them. Trust is not the argument, but it sits underneath it: an organization that does not trust its people will not give them access, and a workforce without access cannot become skilled.

User innovation and the manufacturing workforce

Eric von Hippel’s research on user innovation established that breakthrough innovations in many industries originate not from central R&D functions but from the practitioners who use products and processes to solve their own problems.² Users innovate when they have both the need and the means — domain expertise combined with access to tools capable of addressing that need. When an organization concentrates innovation resources centrally while restricting practitioner access, it systematically suppresses its highest-value source of use-case discovery.

This maps directly onto pharmaceutical manufacturing. The people closest to the process — operators, process scientists, quality analysts, automation engineers — hold the domain knowledge required to locate where AI creates genuine value: which alarm patterns are truly anomalous versus instrument drift, which deviation records encode causal assumptions worth interrogating, which documentation rituals are consuming skilled time that could be redirected to process improvement. A central governance team cannot generate these insights from the outside. They emerge from practitioners working real problems with capable tools — which is precisely the activity that builds skill as a byproduct.

Von Hippel’s model carries a further implication, with a caveat. Users freely reveal their innovations to one another — but the documented cases are cross-firm communities of independent users, not employees inside a single competitive organization, where sharing is not automatic.³ Inside the firm, that connective tissue has to be built deliberately. A center of excellence that creates sanctioned experimentation channels, documents what employees discover, and rewards ingenuity publicly is that infrastructure: it converts individual discovery into organizational capability. Without it, each person’s innovation stays local and ephemeral. With it, the organization accumulates a compounding library of domain-specific applications grounded in operational reality.

Collective intelligence as organizational architecture

Thomas Malone’s research on collective intelligence demonstrated that groups, like individuals, vary in their capacity for intelligent problem-solving — and that the variance is explained not primarily by individual IQ but by social perceptiveness, equal participation, and the quality of information-sharing within the group.⁴ Later work extended these predictors to online, asynchronous collaboration as well, suggesting collective intelligence is a general organizational property rather than a context-specific one.

For an organization deploying AI, the implication is direct. The goal is not to substitute machine intelligence for human intelligence; it is to raise the collective intelligence of the human-machine system. An organization that deploys AI to a small, technically specialized tier while excluding the broader workforce is not becoming more collectively intelligent. It is concentrating capability in a narrow group while the majority remains in a low-agency, low-skill relationship with the technology — which is exactly the participation deficit Malone’s research identifies as the thing that suppresses group intelligence.

This is what reframes the center of excellence from a gatekeeping function into a connective one. The conventional model — a central team that approves use cases and deploys vetted solutions to passive end users — optimizes for control and starves participation. The connective model publishes developments, facilitates peer learning, documents practitioner discoveries, and builds the feedback loops through which individual experimentation becomes shared capability. Even the most experienced practitioners are learning week to week as new models arrive; the aim is not expertise hoarded by a few but a learning organization in which each person’s discovery accelerates everyone else’s.

How skill is built: sandboxes, not classrooms

If the skills gap is the barrier, the obvious question is how skill is actually built — and the answer is not a training catalog. The kind of judgment described above is not acquired in a classroom and then switched on when access finally arrives. It is built by doing: supervised, sanctioned, hands-on work on real problems with real tools. Training divorced from tooling decays before it is ever used. Upskilling that works is participation-based — people learn the tool by using it inside boundaries they understand.

The environment that makes this safe is a sandbox: a bounded space where practitioners work with capable tools on real or realistic data, with explicit limits and a defined path for escalating anything promising. It is the opposite of unfettered access — access made observable and accountable, which is exactly the condition under which the shadow tier dissolves, because experimentation that was happening on personal devices now happens where the organization can see it, support it, and learn from it. I develop the sandbox model — its data, tool, and process variants and the guardrails each requires — at length elsewhere.⁷⁸ What matters here is the pedagogy, not the plumbing. Each variant, in effect, says the thing restrictive policy refuses to say: we trust you enough to let you try.

A hackathon is the sandbox compressed into an event — and the fastest way to turn this progression into something an organization can watch happen. Give cross-functional teams a bounded window, realistic data, capable tools, and a problem drawn from their own work — a recurring deviation pattern, a documentation ritual that consumes skilled hours, an alarm-classification nuisance — and skill-building that would otherwise accrue through months of episodic experimentation is concentrated into days. The format does several things at once that map directly onto the argument already laid out: it forces the equal participation and dense information-sharing Malone identifies as the drivers of collective intelligence; it surfaces von Hippel’s user innovations from the practitioners closest to the process; and it makes every output observable, because the work happens in the open rather than on a personal device. The key is that a hackathon is not a one-off morale event. Run on a cadence and wired into the connective center of excellence — which captures what teams build, hardens the promising prototypes, and hands them to the steward escalation path described below — it becomes a renewable engine for converting individual discovery into organizational capability, and a low-stakes proving ground where a practitioner moves up the competency ladder in public.

Competency built this way is a progression, not a binary — from supervised use, to independent use, to guiding others and shepherding their work toward deployment, which is to say the skill ladder and the steward role described next are the same structure seen at two heights. This is not theoretical: industrial AI-upskilling curricula built on precisely this learning-by-doing pedagogy already exist, and my own data-stewardship and front-line enablement programs for the regulated-manufacturing community use participation-based, scope-defined practice as their core method rather than lectures followed by hope. What most organizations lack is not the curriculum but the willingness to grant the access it requires.

The AI steward: distributing the governance skill

Enabling experimentation is only half the problem. The other half is ensuring the path from informal, AI-assisted work to validated, auditable deployment preserves regulatory integrity — and that path is where most governance frameworks go silent. My answer, developed in full elsewhere,⁷⁸ is the AI steward: a distributed secondary role modeled on the business data steward, pairing domain expertise with AI literacy and embedded inside existing functional teams rather than a separate department. The steward monitors responsible use, shepherds promising applications along a defined escalation path — sanctioned experimentation, documented use case, proportionate risk assessment, and, where warranted, formal validation under change control — and owns the continuous post-deployment review AI uniquely demands.

The point worth isolating here is that last duty, the least understood. Unlike conventional validated software, AI systems can change behavior through vendor-initiated model updates outside the organization’s control, and in a GxP context such an update may trigger revalidation — the formal re-checking a validated system requires whenever it is materially altered. The judgment about whether a given update constitutes a change requiring formal change control is, in most pharmaceutical organizations today, simply unassigned. The steward makes that ownership explicit and places it with people equipped to exercise it — itself a form of distributed, deliberately cultivated skill.

The two-speed model: building capability at the right velocity

Differentiation, not uniformity, is the right response to this complexity: a two-speed model that lets each part of the organization move at the pace its regulatory exposure warrants. Non-GxP functions — IT, HR, commercial — should experiment broadly and fail cheaply to build the organizational AI muscle that later adoption in regulated contexts will depend on. GxP-adjacent functions — quality, regulatory affairs, process development — move deliberately, because AI acceleration there must preserve the oversight properties I have elsewhere called the Attributable–Observable–Correctable (AOC) test for a defensible GxP decision.⁸ I treat the full model, including its three-speed refinement, in the companion white paper; here it is enough to see what becomes possible when skill and tooling finally meet.

A complex assessment framework that once demanded months of development effort — or, more likely, was never built because the investment could not be justified — can now be translated by a domain expert working with AI coding tools into a functional web application in days. The AI Data Assessment Tool, a practitioner-built application implementing the AI Assurance Framework, is one such case: it scores a site’s data readiness against the framework’s assurance criteria — a workbook’s worth of assessment logic, turned into working software by a domain expert rather than a software team. Nothing was automated away and no headcount displaced; a capability that did not previously exist was created, because the binding constraint had been economic, not technical. That is von Hippel’s user innovation operating at the level of a single skilled practitioner — a direct illustration of Winston’s framing of near-term AI value as the opening of new possibilities rather than the automation of old ones.⁶

The long game: intelligence preservation

One risk is underweighted relative to the attention it gets: not job loss, but intelligence loss. Two modes of AI use pull in opposite directions. The first creates capability that never existed — the additive mode of the assessment tool above, where a skilled practitioner simply did more. The second quietly absorbs the analytical and documentation work through which people build judgment in the first place; when AI does that work and the workforce never builds the skill, expertise atrophies — the process intuition that separates a genuine quality signal from an instrumentation artifact, the regulatory literacy that makes a risk assessment defensible. This is Malone’s collective-intelligence argument extended over time,⁵ and the design response I have elsewhere called intelligence preservation:⁸ deploy AI not to automate existing work as aggressively as possible but to redirect human capacity toward the work that builds and maintains expertise. The end state is not a smaller workforce doing the same work faster. It is a more genuinely expert one — every employee a manager of their own AI ecosystem, relieved of throughput work so that judgment, process improvement, and cross-functional problem-solving get the attention they were always owed. Getting there is not a procurement decision or a policy decision. It is a decision to treat the workforce’s skill as the asset that determines whether the tooling and governance investments return anything at all.