Why AI Training Matters More Than Buying AI Licenses

It is surprisingly easy to roll out AI to an organization.

You negotiate the agreement, work through the security and privacy questions, configure the tenant, provision the accounts, send an announcement, and schedule an hour of training to show everyone what the tool can do. Then you wait for the productivity gains.

A few people immediately find ways to use it constantly. Others use it occasionally, for writing or summarizing. Some open it once, get a mediocre answer to a vague question, and decide the excitement was overblown. A lot of people never really start.

Technically, the rollout was successful. Everyone has a license.

Operationally, very little has changed.

This is one of the biggest mistakes organizations make with AI. We treat deployment as adoption, and they are not the same thing. Buying licenses is a procurement exercise. Getting people to use AI effectively is a change-management problem. If the goal is to change how work gets done, the training has to start with the work, not the tool.

Start with the work, not the tool

Most AI training starts in exactly the wrong place: a prompt box on the screen, a lesson on roles, context, and output formats, a demo of summarizing a document or drafting an email. None of that is bad information, but it leaves employees to make the hardest connection themselves: what does this have to do with my job? That connection is where adoption happens.

I would rather start by asking people what they actually do. What takes too long? What do they write over and over? What do they wish they had time to do better?

Before I run a department’s training, I want a few real workflows in hand, not “plan a vacation” or “write a poem,” but that team’s repetitive work. A short conversation with the manager and a couple of team members is usually enough to find good candidates: meeting notes that always turn into the same kind of follow-up email, a report that gets read and mined for the same categories of information every time, a first draft that follows the same shape every time it’s written.

Then we work through one of those, together: what does the process look like today, which parts require judgment, where could AI help, and where does a person still have to decide. Sometimes the answer is a simple prompt. Other times it’s a reusable Project or a repeatable Skill, or AI turns out to be useful for only one small piece of a longer process. That’s fine. The goal was never to inject AI into everything. It was to find the work where it actually helps.

You still have to be the expert

This is the most important thing I teach about using AI: don’t let it become the expert in the room.

AI is genuinely useful for working past the edges of what you already know: it can suggest an angle you hadn’t considered, or challenge an assumption you didn’t know you were making. But there’s a real difference between using AI to extend your expertise and handing your expertise over to it.

When I’m working in an area I know well, I can tell when the model has misunderstood the problem or handed me something polished that would never actually work. My experience is the filter. The danger shows up when fluency with AI creates confidence without expertise: a well-written answer can feel authoritative even when it’s wrong, outdated, or built on an assumption that doesn’t apply to your situation.

So training has to teach one specific thing: a polished answer is not a verified answer. If AI recommends a network configuration, I still check it against current documentation. If it summarizes a contract, whoever understands the contract still owns the interpretation. If it does financial analysis, the source numbers still get checked. AI can get me there faster. It cannot transfer responsibility for being right.

One exercise works better than any generic prompting lesson: have people use AI on something they already know cold, and instead of being impressed by the response, hunt for what it got subtly wrong. Once someone has caught AI being confidently wrong in their own area of expertise, they get far more careful about trusting it in areas where they’re not the expert.

Build verification into the workflow, not onto the end of it

I would not teach verification as a disclaimer tacked onto the end of a training session. It has to be part of how people are taught to work with AI from the start. What it looks like depends entirely on the stakes. Rewriting an internal email just needs a careful read before you hit send. A factual claim needs its source pulled up and actually read, not just cited. If it’s numbers, check the source data, not just the summary. And if it touches security, legal exposure, finances, or personnel decisions, the bar goes up, often with another qualified person in the loop.

We already do this instinctively in other parts of work: we don’t review a casual email the way we review a financial statement. AI shouldn’t change that. Training needs to make the calculus explicit instead of assuming people will apply it on their own.

Use free resources for the foundation

Organizations don’t need to build an entire AI curriculum from scratch. Anthropic’s AI Fluency: Framework & Foundations is a 12-lesson course (roughly three to four hours) built around four competencies: Delegation, Description, Discernment, and Diligence. Discernment, evaluating AI output rather than just accepting it, is the one most relevant to everything above. It’s model-agnostic, and no paid subscription is required to complete it. For nonprofits specifically, Anthropic and GivingTuesday offer AI Fluency for Nonprofits at no cost, aimed at people new to AI and covering grant writing, program evaluation, donor engagement, and organizational efficiency.

I’d use resources like these for the fundamentals, then add what’s specific to the organization on top: the approved platform, the data-handling rules, the governance process, examples pulled from real work. Finally, department-specific workflow training. That’s a much better progression than one generic class: fundamentals, then boundaries, then application.

Give people a safe place to experiment

There’s a real tension between governance and adoption. We want people experimenting, because that’s how useful workflows get discovered. But we don’t want experimentation to mean uploading confidential information to whatever tool someone found online. The answer can’t just be “be careful with AI.” People need an approved place to try things, with clear guidance on what’s off-limits and where to ask when they’re unsure. Someone should be able to think “I wonder if AI could help with this” and have an obvious, low-friction place to try it. The moment an experiment touches a new vendor, sensitive data, or an automated action, it moves into the governance process. That’s the fence around the playground.

Give people something reusable and measure what actually changed

The weakness of one-time training is that everyone leaves excited and forgets most of it by the following week. A department should leave a session with three or four real workflows built during it: a Project that knows the team’s writing guidelines, a Skill for a repeatable research task. Not a list of fifty generic prompts. The verification step belongs inside those artifacts too: a research Skill that requires source links, a reporting workflow that flags which numbers need checking.

And the measurement has to match the goal. If fifty people get licenses and forty-five log in this month, that tells me almost nothing about whether the investment worked. I care about what changed: did a recurring process get faster, did a first draft get better, did a workflow that used to require several handoffs get simpler. That evidence starts out qualitative: ask people for examples, have them estimate before-and-after time. But it’s the real signal. Ten documented examples of work genuinely improving matter more than a dashboard celebrating ten thousand prompts. Prompt volume is activity. Changed work is adoption.

The rollout isn’t finished when the accounts are created

Buying the tool matters. Security and governance matter. But none of it guarantees adoption. People have to understand where AI fits into their own work, feel safe enough to experiment, and know how to evaluate what comes back. They need to hear one thing early and often: you are still responsible for knowing whether the work is right.

My preference is to start small: use good free material instead of recreating it, teach the organization’s rules, find real workflows, build verification into the process from day one, and give people a safe place to try things. Then repeat it with another department.

Over time, AI stops being a tool employees were told to use and becomes another capability they know how to reach for when the work calls for it. That’s the difference between deploying AI and adopting it.

And if I had to choose between spending the next dollar on another AI license or helping the people who already have one get better (and more responsible) at using it, I know where I’d start.