Enterprise AI Needs Executive Direction Before It Needs Another Tool Or Pilot

CIOs need to lead AI transformation from the top. That means deciding what the business wants AI to change and putting a number on it before any tool is picked or any pilot is launched. Then, rebuilding the work around that number.

That order is what lets the systems connect and keeps security, data, and ownership clear from the start. Start with the tool and the company ends up with pilots that never link up, cost more than a single connected system would have, and show no measurable return.

Laszlo Nagy is the Founder and CEO of DuoClarity, an advisory firm that builds production AI systems for enterprise leadership teams and growth-stage companies. He was formerly SVP of AI Product Management at IgniteTech, an enterprise software company that runs its own operations on AI, and before that held global product ownership for cybersecurity infrastructure at a multinational manufacturer. Over more than two decades, he has helped build and exit multiple technology businesses. He now advises CEOs and owners on the AI decisions they cannot hand to anyone else.

"If the top doesn't have it right and they don't know the strategy, it just becomes using AI for the sake of AI," Nagy said. Companies adopt anyway. The pressure usually comes from outside the business.

• Goal before tools: "It's the FOMO that drives it all. 'Everyone is using AI, and we're not, so let's use it, otherwise we're going to be left behind,'" Nagy said. Budget goes to whichever team asks first. Each group solves for its own narrow task, and several teams end up paying separately to solve versions of the same problem. Together those builds cost more than a single connected system would have, and they stay proofs of concept because none was designed to carry production work. Some CIOs have started consolidating onto one platform instead of separate point solutions for that reason. Larger organizations get the worst of it, since more teams hold budget authority and fewer people can see what the others are building.

• Integration comes last: Pilots often get built without the security and data privacy rules the company applies to everything else. Those reviews already run on other systems, so the requirements exist before the project starts. They just don't reach the pilot until the end, when it has to connect to what the business already runs on. "In enterprises it's much harder, because cybersecurity and data privacy come up as soon as they want to connect it to their central system. Then it hits them in the face, and the answer is that AI is not an option," he said. Settling those requirements before the first build avoids the problem, because the first project clears review and the ones after it connect the same way.

• Set the target first: "You have a business vision and a business goal. You have to have the same for AI. What do you want to achieve?" Nagy said. The target can be headcount, revenue, or a backlog the company has the work for but not the people to clear. Each of those gives leadership a number to measure the program against. The number then moves down through the business one level at a time, and each level adds what it is responsible for, including security and compliance. By the time it reaches the teams doing the work, they know what they are building toward and what it has to satisfy. Programs that skip this reach review with no business case to defend.

Projects get canceled before production for reasons that have little to do with what the models can do. What sinks them is who agreed to the success metric and who answers for the output when it goes wrong. Neither gets settled unless someone senior sets the direction at the start.

• Name the owner: "You might have a perfectly tweaked prompt today, and it might work differently in a week or in a month. It needs maintenance like any other system. It's not set and forget," Nagy said. A model update changes how the system behaves, and the data feeding it changes too. The process it supports gets revised, and nobody updates the system to match. So every deployment needs one named person who understands how it was built and checks it on a schedule. Executives are still split on who owns AI at the top, and the same question goes unanswered at the system level. That work needs seniority, because it depends on noticing what has drifted. Without it, output gets worse for weeks before anyone catches it, which is a common reason deployments do not survive past launch.

• Rebuild the process: Maintenance only helps if the process was designed for the system running it. Most companies add AI to a workflow built around people passing work to each other, which automation does not do. Automation moves in single steps, each performed the same way every time, so the process has to be laid out for that before anything gets built. "The whole process has to be redesigned and rebuilt to adapt the AI, otherwise it's the next failure in line," Nagy said. Two questions come before the build. Which work do people repeat most often and least want to do, since that is what moves over. And what the technology needs in order to do it, in steps small enough to hold quality and with input data clean enough to use. Companies that rebuild the workflow around AI get more out of it than the ones attaching it to what they already have.

There is no framework available to copy. Two competitors in the same industry need different processes and different systems, which is why borrowed frameworks fail even when they are executed faithfully. Outside help can shorten the process, though it works best when the advice covers the business case and the technology together. The judgment still sits with the people inside the company. "You can take all the input, but you still have to make it your own," Nagy said.