An introductory session can create awareness. A demonstration can create enthusiasm. The harder question is what someone can do the following week, when their information is incomplete, the example does not fit, and the person delivering the training is unavailable.
My work on an agent-building cohort made that question concrete. In the recommendations and diagnostic I developed, I looked beyond the content to the conditions around learning: setup, confidence, relevance, time, practice, feedback, and support after the course ended.
The useful question was whether the participant could keep progressing. A person who needs help installing a tool has a different problem from someone who cannot identify a worthwhile use case. Someone concerned about permissions needs a clear explanation and an appropriate way to experiment. Another video will not resolve all three situations.
Enterprise AI literacy has the same challenge. A single training pathway can hide important differences between roles, starting points, and responsibilities. People need a common foundation, followed by opportunities to practice the decisions their work requires.
For employees using AI to prepare content, that may include selecting appropriate information, checking claims, and recognizing when an output is unsuitable. For managers, it includes redesigning work, assessing results, and making space for learning. For builders and owners, it includes permissions, testing, exceptions, maintenance, and the consequences of changes.
Leadership literacy also deserves attention. Senior leaders need enough direct experience to question an impressive demonstration, understand what a usage metric establishes, and recognize when a proposed benefit depends on an organizational change. Delegating technical implementation does not remove the need to understand the decisions being made.
I would measure progress through demonstrated capability. Can the person define a useful task, provide appropriate context, evaluate the result, and explain what still requires judgment? Can they recognize a boundary and ask for help? These are more informative than knowing whether they attended a session.
That changes the design of learning. Begin with a worked example, give people a partially supported task, and then ask them to adapt the approach to their own work. Include a result that needs correction. The moment someone explains why an output is inadequate can reveal more understanding than a polished demonstration.
Champion networks can help this practice travel across the organization. Their value comes from proximity to real work. A colleague who understands the team's deadlines, information, and recurring frustrations can translate a general capability into something relevant.
Choose champions for curiosity, sound judgment, and willingness to help others, alongside technical confidence. Give them time and access to support. If the role exists only as an additional expectation on already busy people, the organization is relying on personal generosity to sustain an enterprise capability.
Be explicit about the role's limits. Champions can help colleagues discover uses, practice, and surface problems. They should have a route to people who can resolve questions about access, policy, quality, or integration. They should not become an unofficial approval authority simply because everyone knows to ask them first.
A community of practice gives those experiences somewhere to accumulate. Its most useful sessions can center on an actual piece of work: what someone tried, what happened, where the output failed, and what they changed. A failed experiment with a clear lesson can be more valuable to peers than another flawless demonstration.
Capture reusable knowledge carefully. A shared example should explain its purpose, inputs, limits, and how to judge the result. A collection of prompts without that context can be difficult to adapt responsibly. Give someone responsibility for maintaining examples as tools and policies change.
There is an opportunity to use the network as a source of organizational intelligence. Repeated questions may reveal an unclear policy, inaccessible information, or a process that needs redesign. Those patterns should reach the teams with authority to change the conditions, rather than leave champions answering the same question indefinitely.
Managers make reinforcement credible. They can allocate time for practice, discuss how work changed, recognize thoughtful evaluation, and make it safe to report that an AI approach was unhelpful. If every conversation celebrates usage, people may learn to conceal the evidence that would improve the program.
I would also check what remains in use after the initial support ends. In my course diagnostic work, I proposed a later pulse asking whether participants were still using what they had built and what had broken or been abandoned. The answers would guide support and reveal whether the program had changed behavior.
At enterprise scale, that follow-through belongs in the operating rhythm: review useful practices, identify recurring friction, refresh guidance, and adjust learning to what people are actually trying to accomplish.
Think about the last AI training your team attended. What can they now do independently, and where would they turn when the example stops matching the work? Those two answers tell us a great deal about what the literacy program needs next.