The Missing Half of Enterprise AI Adoption: Measuring What Employees Build

Companies are investing heavily in enterprise AI adoption. They’re buying licenses, training employees, appointing AI champions, and encouraging teams to experiment with new tools.

And naturally, they want to know whether it’s working.

How many employees are using AI? How often? How much time are they saving?

These are reasonable ways to measure AI adoption. But as AI tools become capable of doing more than answering questions and generating content, I think there’s another question worth asking: What happens to the things employees create with AI?

From using AI to building with it

For most employees, the introduction to AI started with familiar tasks. Summarizing meetings, writing emails, analyzing documents, or preparing presentations. The work stayed largely the same, but AI made parts of it faster.

Now employees are starting to do something different. Instead of asking AI to help them complete a task, they’re asking it to build a tool that does the task for them.

A salesperson creates a pricing calculator tailored to their company’s process. Someone in HR builds an onboarding assistant. A finance employee puts together a workflow that automates a repetitive reconciliation process.

These are the kinds of requests that would traditionally end up in an IT backlog, require purchasing another software product, or simply remain unresolved because they were too specific to justify the effort.

Today, an employee can open a chat, describe what they need, and have a working version surprisingly quickly.

For organizations investing in AI adoption, this is an exciting development. Employees aren’t just becoming better users of technology. They’re becoming creators of it.

But it also introduces a challenge that training programs alone can’t solve.

The experiment worked. Now what?

Imagine an employee who just completed an internal AI workshop. They were encouraged to identify a problem in their daily work and build something useful.

They did exactly that.

They built a small application that saves them a few hours every week. Their colleagues see it and want to use it too.

What happens next?

Perhaps they share a link from the AI platform where it was created. Perhaps they send the code to IT and ask someone to deploy it. Or perhaps they simply keep using it themselves because sharing it feels too complicated.

None of these outcomes necessarily reflects a failure of the AI training program. The employee learned something valuable and solved a real problem.

But the organization might be missing most of the opportunity.

The same problem could exist in five other teams. Another employee might be building an almost identical solution. And the original application might disappear entirely when its creator changes roles or leaves the company.

The gap isn’t in employees’ ability to create. It’s in the organization’s ability to share, govern, and reuse what they create.

AI champions can’t do it alone

Many organizations are introducing AI champions: employees who receive additional training, help their colleagues experiment, and identify opportunities to use AI across the business.

I think this is a particularly interesting approach because the best opportunities often come from people who understand the day-to-day work, not from a central technology team.

But there’s a limit to what an AI champion can accomplish if every successful experiment creates a new deployment problem.

An employee builds an internal AI agent that needs access to company information. Another creates a skill that colleagues want to reuse. Someone else builds an application that should be available to an entire department.

Suddenly, the questions aren’t about prompting or choosing the right AI model.

They’re about access, permissions, ownership, deployment, and maintenance.

These are familiar questions for IT and engineering teams, but those teams weren’t necessarily prepared to support a growing number of tools created by employees across the organization.

And asking every employee to become familiar with software deployment isn’t much of a solution either.

If we want more people to build with AI, we also need to make it easier for their creations to become usable by others.

Adoption should create something that lasts

There’s a meaningful difference between using AI to save yourself an hour and building something that saves ten colleagues an hour every week.

Both are valuable. But the second creates something that can continue delivering value beyond the person who originally built it.

That changes how we should think about AI adoption.

It’s no longer just about giving employees access to powerful tools and teaching them how to use them. It’s also about creating an environment where employee-built applications, agents, skills, and workflows can become shared company assets.

Employees should be able to build with the AI tools they prefer. The organization should be able to decide what gets deployed, who can use it, what information it can access, and how it’s managed over time.

Those two things shouldn’t be in conflict.

And perhaps that’s the next challenge for enterprise AI adoption.

Not just measuring how many employees are using AI, or how many experiments they’ve completed, but understanding how much of what they create actually becomes part of the way the organization works. A simple way to start: count how many of the tools employees build are used by someone other than the person who built them.

Because the real opportunity isn’t just having more employees who know how to use AI. It’s having an organization that can benefit from what they build.