How We Stopped Leaving AI to Volunteers

By John Marshall

A year ago, Artificial Intelligence at our company was whatever individual people decided to do on their own. Some people at our 120-employee, $30 million manufacturing operation had ChatGPT accounts. A few had Claude. What training existed was whatever I did in passing: Showing somebody a technique between meetings, working through a problem with whoever asked. Nothing was written down, and I could not have told you who was using what or for which tasks.

We wanted more from AI. It was clear, however, that we needed a game plan to get started. Here’s what we did.

We wrote the standard before we bought anything

We scored potential AI work as unacceptable, expected, or exceptional across seven corporate tasks: leadership, sales, marketing, finance, operations, HR, and technology. “Expected” means AI assists or performs tasks that get reviewed and approved by humans.

For instance, in finance,  AI could issue variance narratives and memo drafts, with every number verified. Unacceptable would be trusting AI math without reconciliation. In operations, expected tasks would include SOP drafting, troubleshooting research, and scheduling scenarios, while unacceptable would be AI-set specs, tolerances, or safety procedures without engineering review.

Final judgment stays with the person, never the tool. And confidential data—deal terms, financials, payroll, employee records—never goes into an unapproved tool.

You should write those rules before use spreads, not after. Decide which tools are approved, what information is off limits, and who enforces it. Telling people to be careful is not a policy.

We applied the standard where it fit the work. A machine operator and a buyer do not have the same job.

Then we went looking for where we actually stood

We surveyed 14 managers about six months in and found the results were uneven,. One had built somewhere between 45 and 60 recurring tasks he now runs this way, several as reusable setups he made himself. Another was at roughly 20. Most sat in a broad middle. Two were just getting started. One had nothing to report.

That spread is what informal coaching produces. The people who got my time got good at it. The people who did not, did not. Nobody had done anything wrong.

The manager with nothing to report taught us more than the one with 60. When we looked into it, part of the gap was how we had asked. Our inventory relied on people searching their own history, and their work was scattered across general chat history and several tools with nothing to go back and find. Mine sat in one place, so I could reconstruct eight months of it. We changed how we asked—walking people through their own quarters and their own deliverables rather than making them search—and more real work surfaced. 

Where the work is stored determines whether you can ever find it, review it, or measure it.

Two decisions came out of those thin results

The first was to make training mandatory for everyone in a leadership seat. The opening session was one hour long, show the leaders how to use AI as a thinking partner. This wasn’t a class on how to write prompts for AI to follow; prompt engineering has reached the point where you pretty much can have AI create its own prompts. The obstacle now is knowing which problems are worth bringing to it.

The second session involved application. Every person brought the two biggest issues in their department as pre-work, along with what they had actually done following the first lesson. That second requirement mattered more than the first. You can order people to attend a meeting and earn a task, but what people do afterward is coached rather than ordered. You win the willing first and let results pull the skeptics along. What you do not do is let people quietly opt out of finding out.

The biggest surprise was our IT department. The programmers had been the most resistant—they knew enough to be skeptical, and skepticism from people who understand the technology is harder to argue with than skepticism from people who do not. Once they engaged, they went further than anyone. That changed how I think about who to start with.

The second decision was to give somebody the job. Our executive assistant took the AI specialist role at half time—she was reassigned internal capacity, not a new hire and definitely not a new department. She was the right pick for unglamorous reasons. I already had been working with her on more advanced techniques. She was interested, and staffing changes had freed up part of her week. She also sees across every department, which most people here do not.

She tracks progress and usage through the administrative tools already built into the business versions of these platforms. Most owners do not realize those are sitting there. What she does not do is the work. The moment your specialist becomes the person who runs everyone else's AI tasks, you have bought an expensive bottleneck instead of a capability.

We are further along on the standard than on the rollout, and I would rather say that than describe a program further along than it is. The problems that came out of that second session decide which department she takes first.

Summary

1. Write the standard before you buy anything: What is expected, what requires review, what is never allowed.

2. Apply it where the work fits. Not every job needs it, and pretending otherwise costs you credibility.

3. Teach judgment, not prompts. The tool writes the prompt. Knowing what to bring it is the skill.

4. Require the learning and coach the use, then make people show you what they did with it.

5. Whoever owns it, keep them out of doing the work. Their job is to build capability, not to absorb it.

   
   

Thus process may be slower than a company-wide rollout, but it the only version I have seen actually stick. Keep in mind, the tools are in your building already, approved or not.

Along with running his own consulting firm, AI Growth Partners, Marshall is CEO of Tara Pools & Outdoor Products in Owens Cross Roads, AL.