Building the internal team

How to Build an Enterprise AI Champions Program

Bottom line: An enterprise AI champions program needs someone in charge, time people can actually use, clear responsibilities, and a simple way to choose, test, measure, expand, or stop ideas. Champions connect leadership priorities with the work inside teams. They are not there just to share tool news.

By Eyal Marcus | Published and updated August 13, 2026

What makes an enterprise AI champions program work?

Decide who is responsible before naming the program. Give Champions time to work, agree how ideas enter the process, and decide who can expand or stop a test. Without that, the community may stay busy without changing the work.

When do you actually need AI Champions?

Champions help when several teams need to find useful tasks, share what works, and connect local problems to leadership priorities. It is not a substitute for policy, ownership, or missing technical capability. In those cases, focused enterprise AI consulting may need to come first.

AI champion vs builder vs trainer

Champion

Finds needs, connects people, documents and shares learning.

Builder

Builds or configures within approved tools and access.

Trainer

Designs practice and learning for a group.

Who leads the program

Sets priorities, removes barriers, and approves decisions.

How to select internal AI champions

Look for influence, curiosity, work process knowledge, and the ability to explain. Technical seniority alone is not enough.

Who gives Champions time and clears blockers?

There is no universal percentage of protected time. Be clear about the responsibility, who can make decisions, and what happens when regular work takes over.

How does an idea reach a real decision?

Document the problem and audience.
Define a description of the current state and its caveat.
Test a small solution within policy.
Record learning and outcome.
Scale, revise, or stop.

Stopping an idea that is not useful is not a failure. It makes room for a better one.

What do Champions need to keep learning?

Use role onboarding, practice sessions, documentation, and reusable examples. Corporate AI training can support capability, but it does not replace ownership and process.

Is the group active, and did the work actually change?

Attendance and ideas tell you whether the community is active. Time, quality, consistency, or completion tell you whether a specific task may have improved. Do not mix the two. The AI training measurement framework explains the evidence structure.

Common mistakes in a Champions program

Recruiting volunteers without protected time
Using community size as proof of impact
Collecting ideas without a decision process
Expecting Champions to replace organizational rules or IT

Frequently asked questions

How much protected time do Champions need?

There is no universal percentage. Time should match the role, testing cadence, and manager support.

How should success be measured?

Separate signs that the group is active from changes in the tasks you chose to improve.

When is a champions program the wrong solution?

When nobody leads the work, people lack access, the rules are unclear, or the organization has not chosen a real work problem.

Selecting Champions without creating a closed club

Selection should combine manager nomination with an open path for employees to express interest. Managers understand responsibility and influence, but they may not know who is already developing useful working methods. An open application alone may attract mostly technology enthusiasts. Using both routes creates a more balanced group.

Assess four capabilities: work process understanding, peer trust, practical curiosity, and documentation. Technical expertise helps in some roles but should not be a universal requirement. If some ideas require complex building, keep the Champion role separate from the Builders or technical teams responsible for integrations and production systems.

Choose Champions around real work, not a ceremonial list of departments. A representative without a real problem to address may struggle to create value. Start where someone owns the problem, access is available, and the team can check what changed. Expand only after that works.

Short interview questions

Which recurring task creates friction in your team?
How would you test whether a new method is better?
When have you stopped an experiment that did not work?
How do you explain a process to a non-technical colleague?
Which information should never enter a tool without approval?

What usually goes wrong?

The group only shares AI news

The community shares product updates but changes no work processes. Require every update to connect to a task, audience, and decision. Product news adds useful context, but it is not the primary output.

Ideas accumulate without decisions

A long idea list can look impressive while nothing moves. Every idea needs someone responsible, a clear status, and a date for a decision. Remove the ones nobody is ready to own.

A personal solution is presented as regular use

One employee uses a method, but there is no documentation, permission model, or support for others. That is a personal test, not regular use. Before scale, test reproducibility, security, maintenance, and variation between users.

Champions burn out

The work sits on top of the existing role and managers remove nothing. Early signs include missed meetings, unattended backlogs, and disappearing documentation. More motivation is not the answer. Change the role, the priority, or the protected time.

Leadership demands ROI before evidence exists

Early stages can measure activity and how people perform the task before the change, but not always durable business outcomes. The NIST AI RMF is a voluntary AI risk management framework from the US National Institute of Standards and Technology. I use it here because it connects governance, context, measurement, and management across the AI lifecycle. It helps frame what an early metric can and cannot show. It does not validate this Champions model or prove that the program caused a business result.

What should you ask every quarter?

Periodically test whether the program still solves its original problem. Count work processes that reached a decision, not ideas added to a list. Check whether managers protect time, blockers reach someone who can resolve them, and employees outside the group can use the documentation.

Which work process moved from a manual process to a new working method?
Which idea stopped, and what did the organization learn?
Where is access, policy, or technical support missing?
Who uses an output beyond the person who built it?
Does the result persist beyond the demo week?
Does the group represent the next teams where this work could help?

If the program cannot answer these questions, do not automatically add more Champions. Fix how the program is run. You may need fewer Champions, fewer active experiments, or a lead who can actually make decisions.

When this model is not enough

A Champions program is not suitable for every organization. It depends on managers, time, information access, and decision capacity. It does not replace privacy, security, legal, or engineering specialists, and it cannot promise savings. Evaluate value one work process at a time.

A practical first 90 days

Managers need a clear role too

Champions cannot create protected time or settle cross-functional priorities on their own. Give managers a short note that explains the role, the monthly time commitment, who to contact when there is a blocker, and what the team should see before expanding a test. Ask managers to review one work process decision each month, not to approve every prompt. This keeps the rules connected to the work without making the community wait for approval on every small step.

For an international program, use the same basic questions everywhere and let local teams bring their own examples. Ask about the problem, audience, information boundaries, who leads the work, the starting point, test, result, and caveat. Then add local language, policy, and work process differences.

During the first month, decide who leads the program, what the role includes, which information is allowed, and how new ideas enter the process. Champions map recurring problems and propose small tests. Do not judge success by idea volume. Check whether the team described the problems clearly, has the right access, and recorded how the task works today.

Next, run a small number of tests. Each experiment has someone who owns the problem, a Champion, a measure, and a decision date. The test may use a prompt, template, work process, or prototype. It does not need to become a production system immediately. The goal is to learn enough to decide what happens next.

The third stage considers scale. Scaling requires documentation, permissions, support, and knowledge transfer. A solution that works for one employee is not automatically ready for a department. Test differences in roles, languages, information sources, and risk before expansion.

A review meeting that leads to a decision

Do not turn the review meeting into a line of demos. Show the problem, how the work looked before, what you tested, what changed, and what you still do not know. Leadership can expand the test, ask for another round, or stop it. The point is to make a decision, not keep every experiment alive forever.

Questions to ask before expanding a test

Is the work process described by the people who perform it?
Did you record how the task worked before the test?
Is the selected information and tool approved?
Can another employee repeat the method?
Is a caveat shown beside the result?
Who owns maintenance after the test?

International organizations should separate common principles from local implementation. A work process that succeeds in English may not transfer directly to Hebrew or another language. Permissions, documents, regulation, and operating habits may differ across teams and regions.

Use this approach in mid-market and enterprise organizations, in technology and other sectors, when teams need clear internal ownership. If the organization only needs awareness, choose a keynote instead. If a team needs practice, start with a workshop. Choose a Champions program when the organization genuinely needs ongoing internal capability.

How do you keep a Champions program alive after launch?

A strong kickoff is not enough. The program needs a rhythm people can actually maintain: a short list of active problems, a regular working session, and a clear route for issues the group cannot solve alone. Pick one or two real problems for each session. If everything stays open, nothing reaches a decision.

Managers are part of the model. A Champion without protected time will drift back to regular work. Agree on the time commitment, what the role includes, and when business pressure justifies a delay. Make that agreement visible to the program lead too (otherwise everyone assumes someone else is protecting the time).

Documentation another person can use

A useful output is more than a demo. It explains the problem, who owns it, which tool and information are approved, what was tested, what limitation remains, and what the team decided. Keep it short enough to use. Include the situations where the method should not be used.

What happens when a Champion changes roles?

Do not let one person become the only keeper of a work process. Give each tested work process someone who owns the problem, a short record, and a second person who knows the decision. When a Champion changes roles, hand over the work that was tested, not a generic list of AI tools. That is how the knowledge stays in the organization.

Is a Champions program the right move?

A short call can map ownership, protected time, and the first tasks, then clarify whether you need a workshop or support building the program.

לפנייה ויצירת קשר