Two Kinds of AI Strategy: Adopt or Adapt?

Which one will you choose?

Digital transformation has always been a challenge.

Re-engineering a business to use new technology carries real risk, and more so when the benefits aren't easily realized. That is the part the current AI conversation keeps skipping.

There are two ways to bring AI into a business, and they are not the same thing.

You can adopt it: take the technology as given and fit the business around it.

Or you can adapt it: start from the business you already have, with its obligations, standards, and commitments, and make the technology work for you, not the other way around.

Start with the claims for adoption. They are familiar. AI will substitute labour. It will improve speed and throughput. It will do it better at scale. These are traditional technology productivity plays. More specifically, they are platform plays. Transfer your workflow from one system to another and call it transformation. We have seen this before.

These productivity gains assume a greenfield. No friction, no obligations, no standards of performance already being met, and free of any negative consequences.

On that field, substituting labour and adding speed always nets out positive, because there is nothing on the other side of the ledger.

No real business is a greenfield. Every one is already meeting obligations, already holding standards, already regulating itself toward results. The benefit of technology has to be real on the field where the business operates, not on a straw man version of it.

This is the doorman's fallacy. You cut the doorman to save a salary, then find out he was also deterring theft, greeting regulars, signing for deliveries, and noticing the leak before it became a flood. The line item said "opens door." The job was everything around it. Substitute the visible task and you drop all the value that was created around it.

The economics of AI only get worse from there. It is not obvious there is a net benefit, particularly when the cost of AI is more likely to rise than fall. What will your token spend be? What are you giving up to get the claimed benefits? What will it cost to get there?

Adoption seldom considers the work needed to adapt. That is the part every adoption pitch leaves out: Change Management.

Here is what they get wrong. They treat the organization as the problem, not the technology. Any resistance is read as an obstacle, a sign of not being committed to AI.

But change is resisted even when it is good, because we build systems to resist it. We hire people to follow procedures without variation. We build processes to make sure the rules are followed. We use feedback to hold conformance and to course correct when necessary. This is not an organizational design failure. That is the design.

Organizations regulate, or govern, effort to advance intended outcomes, within constraints, so that value is generated, usually measured as margin. Resisting change is not a flaw. It is the standard of performance doing its job. The system you are being told to disrupt is the thing keeping the promises you have already made.

This is not friction to be eliminated, whatever they call it. Resisting variation is what it takes to reach the goals you want and avoid the ones you don't. AI does not understand this, and neither do many of the people pushing for its adoption.

Most of the AI conversation is about adoption. Very little of it is about adaptation. That is the gap, and closing it is where the real benefit lives.

So the real work is not adopting AI. It is adapting it to your business, and your business to it.

That takes people who understand how business works and how technology works. If that is not who is advising you, you are being sold a platform substitution, not real business benefits.

---

Raimund Laqua, P.Eng., PMP, is the founder and principal of Lean Compliance, an advisory practice serving highly regulated, high-risk sectors. Over more than 30 years he has built compliance and assurance programs across oil and gas, pharmaceuticals, medical devices, manufacturing, and financial services, treating compliance as promise-keeping rather than rule-following.

He is one of Ontario's first licensed software engineers, chairs the Digital Engineering Committee for Engineers for the Profession, and advocates for professional digital engineering licensure in Canada. He writes on AI governance, engineering assurance, and why technology should be adapted to the business, not the business to the technology.