The head of learning at a mid-sized insurer has spent a year telling the rest of the company that its people must become AI-literate to satisfy the EU AI Act, to keep up with skill demand, to not be left behind. Then a board member asks the obvious question: "And your own team? Can your instructional designers actually run an AI-assisted build, verify it, and prove it worked? Or are they where everyone else was eighteen months ago?" The room goes quiet, because the honest answer is that the cobbler's children have no shoes. The L&D function that is supposed to upskill the workforce has not systematically upskilled itself. This lesson is about fixing that, because a learning team that cannot operate AI rigorously cannot teach the company to, and a strategy that skips its own function is a strategy that fails at the first audit.

The Cobbler's Children Problem

L&D has a structural blind spot: it builds capability for everyone except itself. The team that runs the onboarding program, the compliance refresh, and the leadership academy rarely has a deliberate, sequenced, evidence-based development plan for its own AI capability. People pick it up in fragments. One designer is fluent because she taught herself nights and weekends; another quietly avoids the tools and hopes nobody notices; a third uses AI confidently and wrongly, shipping plausible content he never learned to verify. The function looks like it is "using AI" because some individuals are. It is not operating AI, because it has no shared, defensible capability.

A term to anchor the lesson. Function-level capability is the difference between a few individuals who happen to be good with AI and a team that can reliably run an AI-assisted pipeline, every member verifying, every gate owned, every build defensible. Why you care: the Article 4 literacy duty and the company's whole AI-learning strategy rest on L&D being the function that knows how to do this rigorously and can teach it. That duty is a moving target: the in-force text requires employers to ensure a sufficient level of AI literacy, while the Digital Omnibus (endorsed by the European Parliament 16 June 2026, not yet in the Official Journal, so not yet law) would soften the general verb to promote and encourage while leaving the duty to train high-risk-system operators for human oversight untouched. Whichever way it lands, a team that cannot itself run a verified AI build cannot teach the workforce to. If your own team's capability is a scatter of self-taught individuals and quiet avoiders, you cannot certify anyone else's literacy, because you have not built your own. The function that teaches the company must be the most capable, not the least.

The market context makes the gap urgent. LinkedIn's 2025 Workplace Learning Report finds about 71% of L&D professionals are exploring or experimenting with AI but only about 25% use it routinely, which means most learning teams are exactly where the rest of the workforce is: aware, dabbling, not yet operating. Meanwhile the Josh Bersin Company describes AI disrupting a roughly 400 billion dollar corporate-learning market and reports 74% of companies say they are not keeping up with skill demand. The function asked to close that gap for everyone else cannot afford to be a member of the unprepared majority.

Operationalizing the Curriculum for Your Own Team

The good news is that you do not have to invent the development plan. The arc you would use to build any rigorous capability is the arc this very program describes, applied to your own function: from reading an AI module skeptically, to drafting verified content against a source of truth, to running an end-to-end pipeline with human sign-off at every gate, to owning the strategy and governance. The strategist's job is to operationalize that arc for the L&D team itself, with the same discipline, the same evidence, and the same accountability the team would demand of any program it built for the business.

That means treating your own team's upskilling as a real program, not a lunch-and-learn. It has a needs analysis (where is each person on the capability arc, and what does each role actually require). It has measurable objectives (not "be comfortable with AI" but "can ground a draft against a source of truth and produce a verification log"). It has aligned assessment (can they actually do it, demonstrated on a real build, not a quiz they passed). It has accessibility, because your own materials must model the standard. And it has measurement to behavior, because the point is not that the team attended training, it is that the team now ships verified, accessible, measured builds differently than it did before. You would never accept "we ran a workshop" as proof a business program worked. Hold your own function to the same bar.

A learning function that cannot run an AI-assisted build rigorously cannot teach the company to run one. You cannot certify a literacy you have not built in yourself.

Role-Scaled, Not One-Size-Fits-All

The team is not homogeneous, and a single generic "AI for L&D" workshop fails everyone by serving no one precisely. The instructional designer needs deep capability in grounded drafting, alignment, and item validity. The learning technologist needs to understand the data question, whether learner data trains a vendor's model, and the interoperability of AI-built content with the LMS. The facilitator needs to run and debrief AI role-plays and bias-check scenarios. The L&D manager needs to own gates, sign-offs, and the verification workflow. The head of learning needs the strategy, governance, and measurement view. Role-scaled development is the same principle the Article 4 program applies to the business: sufficient capability scaled to role and context, not a uniform tour for everyone.

The Quiet Avoider and the Confident, Wrong User

Two members of the scattered team deserve special attention, because they are the two the plan most often gets wrong. The quiet avoider is the experienced designer who has decided, without ever saying so, that the safest move is to keep her distance from the tools and let the change pass over her. She is not lazy; she is protecting a craft she is proud of from a technology she does not trust, and she suspects, correctly, that a careless rollout would deskill her. The plan fails her if it shames her into using AI fast, and it serves her if it shows her that the verification, alignment, and governance work is exactly where her judgment becomes scarce. Bring her in through the part of the job she already owns and respects, and the avoidance usually dissolves.

The confident, wrong user is the more dangerous of the two, precisely because he looks like a success story. He generates polished modules quickly, he is enthusiastic, and he ships content he never learned to verify, because nobody ever taught him the difference between fluent and correct. He is the living argument for centering verification: a team that celebrates his speed without building his verification capability has rewarded the exact behavior that ships a confident, wrong, accessible-looking module to thousands. The plan serves him by making verification, not generation, the thing that earns recognition, so his enthusiasm is pointed at the half of the job that actually protects the learner. Neither person is a problem to be managed around. Both are signals about whether the development plan is centering the right thing.

The Verification-First Team, Not the Fast Team

There is a seductive failure mode in upskilling a learning team on AI: training them to be fast. Run a workshop on prompting, show everyone how to generate a module draft in minutes, celebrate the speed, and you have built a team that produces plausible content quickly and verifies nothing, which is precisely the team most likely to ship a confident, wrong, accessible-looking module to thousands. Speed is the cheap, demo-friendly half of the capability. It is not the half that was scarce or valuable, because AI already made generation cheap.

The capability that matters, and the one your development plan must center, is verification. Can the team catch the hallucinated claim before it ships? Can they tell whether an AI-drafted item actually measures the objective or just looks well-written? Can they keep an AI-narrated video WCAG 2.2 AA conformant instead of retrofitting accessibility after a failed review? Can they produce a sign-off log that answers "who verified this" before anyone asks? Those are the skills the program teaches and the skills that became valuable precisely because AI made content cheap. An upskilling plan that trains speed without verification has trained the wrong half of the job and built a faster liability.

This is also where the team's own development becomes a credibility asset. When the L&D function can show that its members are not just AI users but AI verifiers, that every designer can ground a draft and produce a verification log, that the team operates a pipeline a compliance officer would accept, the function earns the standing to lead the company's literacy program. You are no longer the cobbler's children. You are the proof of concept, the function that did the rigorous thing first and can now teach it because it lives it.

A Worked Example: From Scatter to Pipeline

Watch a learning team move from "some of us use AI" to "we operate an AI-assisted pipeline."

Before (the scatter). The L&D function reports to leadership that it has "adopted AI." In practice, one designer generates polished drafts fast and ships them with light review; another refuses to touch the tools and is slower than ever; the learning technologist wired an AI feature into the LMS without anyone asking whether learner data trains the vendor's model; the facilitator ran an AI role-play that nobody bias-checked. When the board asks whether the team can run a verified, accessible, measured AI build, the head of learning cannot say yes, because there is no shared capability, only individuals at wildly different places. Worse, when a compliance officer pulls a recently shipped module, there is no verification log, because the fast designer never learned to produce one. The function's "AI adoption" is a collection of uneven, partly unsafe individual habits, and it cannot be defended as a capability.

After (the pipeline). The strategist runs the team's upskilling as a real program. A needs analysis places each person on the capability arc and identifies the role-scaled gaps. Objectives are concrete and demonstrated: every designer can ground a draft against a source of truth, validate that an item measures its objective, and produce a verification log; the learning technologist can answer the data-training question and confirm interoperability; the facilitator can run and bias-check an AI role-play; the manager owns the sign-off gates. The plan is sequenced from awareness to integrated practice, assessed on real builds, and measured to behavior, the team now ships differently, not just attended a workshop. Six months later the board asks the same question, and the head of learning answers with evidence: here is the capability map, here is a pipeline every member can run, here are the verification logs, here is the accessibility conformance, and here is the behavior change in how the function builds. The team is no longer the unprepared majority. It is the company's working example of what AI-literate, verification-first capability looks like.

Same team, same tools, opposite standing. The difference is that the second version treated the function's own development with the rigor it would demand of any program it built for the business, and centered verification, not speed.

The Development Plan as a Table

The plan is concrete enough to put on a page. It maps the program's capability arc to what each level means for your own team, the demonstrated objective that proves it, and the role it matters most for. This is the artifact you bring to leadership to show that L&D has upskilled itself, not just promised to.

Read the third column down the page. Every level is proven by something the person can do and show, on a real build, not by attendance or a comfort survey. That is the difference between a function that says it adopted AI and a function that can demonstrate it operates AI. The plan also reveals the floor and the ceiling: the AI-aware level is the non-negotiable floor for everyone, because a team member who cannot spot an untrustworthy module is a hole in the verification wall; the AI-strategic level is the ceiling only some need, but the function must have it covered, because the strategy and governance have to live somewhere on the team.

Prove your team upskilled itself the way you would prove any program worked: not "we ran a workshop," but "here is what every member can now do on a real build, and here is how the function ships differently than before."

The Strategist's Discipline, Stated Once

Everything in this lesson reduces to one principle. The L&D function cannot lead the company's AI-literacy work from a position of being less capable than the workforce it is meant to teach, so the strategist's first capability investment is the team itself, operationalized with the same rigor, evidence, and accountability the team demands of every program it builds for the business. The point is not that the team uses AI. It is that the team operates AI: grounds the draft, verifies the claim, validates the item, conforms the media, logs the sign-off, and measures the behavior, every member, every build. A team trained only to be fast is a liability accelerated. A team trained to verify is the company's proof that AI-literate, verification-first capability is real and teachable, which is the standing the whole strategy depends on.

So when the board member asks whether your own designers can run an AI-assisted build, verify it, and prove it worked, you do not deflect to how busy the team is or how fast they have become. You bring the capability map, the demonstrated objectives, the verification logs, and the behavior-change evidence, and you say: yes, and here is the proof, because we built our own function first, the way we will build everyone else's.

Key Takeaways

• L&D has a cobbler's children problem: it builds capability for everyone except itself, so its "AI adoption" is often a scatter of self-taught individuals and quiet avoiders, not a defensible function-level capability.
• Function-level capability is the difference between a few people who are good with AI and a team that can reliably run an AI-assisted pipeline, every member verifying, every gate owned, every build defensible.
• You cannot certify a literacy you have not built in yourself: the Article 4 program and the whole AI-learning strategy rest on L&D being the most capable function, not a member of the unprepared majority (about 71% touching AI, about 25% using it routinely).
• The development plan is the program's own arc operationalized for your team: from AI-aware, to AI-assisted, to AI-integrated, to AI-strategic, role-scaled to what each person actually does.
• Treat the team's upskilling as a real program: needs analysis, demonstrated objectives, assessment on real builds, accessible materials, and measurement to behavior, never "we ran a workshop."
• Center verification, not speed: a team trained only to generate fast produces plausible content and verifies nothing, which is the team most likely to ship a confident, wrong module, a liability accelerated.
• Prove each capability level by something the person can do and show on a real build (a grounded draft with a verification log, a conformance check, a sign-off log), not by attendance or a comfort survey.
• An L&D function that visibly upskilled itself, verification-first, becomes the company's proof of concept and earns the standing to lead the literacy program, full stop.