Successful AI adoption creates a second implementation that companies rarely plan for – Unite.AI

About three years ago I purchased my first paid AI subscription and started testing what it could actually do for me. Gradually, what started as personal experimentation turned into a small internal project, then into enterprise-wide business subscriptions, and finally into an AI implementation that spanned nearly every department: development, finance, legal, marketing, and support.

The first phase essentially worked. Our internal development speed has increased about five times in about six months. At the same time, another number has increased: Our spending on AI has increased by about 15 times.

That’s when I realized that effective adoption of AI could create problems of its own. Once the technology was widely used, the rules we started with no longer worked. Costs could get out of hand as AI accessed more company data and took up more tasks, while many of the tools themselves were still controlled by external vendors.

So, what should a CEO do when AI adoption is working, but the company no longer has full control over how it is used? Let’s try to answer.

Stop equating active use of AI with business results

What I noticed right away was that during the first implementation, the adoption metrics, such as the number of active users or frequency of use, made sense. As a leader, you want to know whether employees are using the tools, which ones in particular, and whether AI actually saves them time. However, once usage spreads throughout the company, these numbers become much less useful.

We saw it ourselves. Once people had access to powerful models, they started using them for almost everything. At one point, employees started asking AI what time it was in New York. Of course, the example is ridiculous, but it shows how quickly usage can grow without creating any substantial value for the company.

Shopify ran into a similar problem after integrating AI so deeply that its internal agent, River, now processes up to half of its production code pull requests. Yet CEO Tobi Lütke recently warned of what he calls “slop grenades”: AI-generated work that employees pass along without properly vetting it, leaving someone else to review, correct or even summarize the result.

In other words, increased AI activity can easily produce more work rather than more value. A business can have impressive usage numbers and huge amounts of output, while some of that output simply creates another business for someone else.

This is what CEOs need to change. Requests, logins, and token consumption show a lot of activity within the workflow. However, they don’t show whether the AI ​​is actually paying for itself.

Speed ​​creates a new bottleneck

There is a saying: haste wastes. I think it applies to AI too, as we’ve learned that making people “faster” with AI doesn’t necessarily mean you suddenly have less work to do.

In development, AI now allows our team to produce much more code in the same amount of time, but the main thing is that all that code still needs to be vetted before it goes live. Without a doubt, automated review helps.

Yet, it’s still far from something I would trust completely. So while developers spend less time writing everything themselves, they now have much more output to review, test, and make decisions.

In other words, work doesn’t disappear. It simply presents itself in another guise.

This makes our fivefold increase in development speed seem a little less overwhelming, as the amount of code requiring human attention increases along with it. The real cost of an AI-enabled workflow also includes the time spent verifying what the AI ​​produces and, more importantly, deciding whether that output can be trusted in the first place.

The second throw is imperative

From my perspective, companies need what I would call a “second” AI implementation.

The first launch is very much about adoption: giving people access, finding use cases, seeing where the technology actually helps and where it doesn’t. But after several months of real use, you already have something much more valuable than hypotheses: your evidence about where costs are growing, which teams produce better results, and where people spend too much time checking AI results.

So, this is where I think it makes sense to redesign the rules around AI instead of simply pushing its broader use. In practice I would focus on three things:

• Match the template to the activity. Routine requests can be directed to smaller, cheaper models, while more complex work goes to models that justify the additional cost. The ultimate goal is to avoid paying frontier-model prices for low-value tasks.
• Identify where human control is mandatory. For production code, legal documents, or other high-impact output, define where a human must approve the result before it proceeds further in the workflow. Set access rules for sensitive data separately so employees know which models can receive it and which cannot.
• Build a backup plan even if you think you don’t need it. If a critical workflow depends on an external vendor, document model-specific requests, integrations, data flows, and dependencies thoroughly enough to allow the workload to be migrated to another vendor in the event of an emergency.

This is the difference between the first and second AI launches. The first question: where can we use artificial intelligence? The second question: where should we use it, with what rules and at what cost?

Check your implementation before scaling it again

Once the AI ​​adoption works and the first implementation appears to be successful, I wouldn’t continue to scale it the same way for another year. After about 90-180 days of real use, I would stop and check out what the company has actually built.

This means measuring accepted business outcomes, matching the model and its cost to the actual value of the business, identifying where human review is still mandatory and where a workflow may be somewhat closer to full automation.

The first launch proves that AI can make the business run faster. The second is what prevents that speed from turning into unnecessary spending, uncontrolled access, or dependencies on vendors that the company never knowingly agreed to.