Most AI problems aren't technical

When AI disappoints, the cause is rarely the model. It is what surrounds it:

who owns the result, how the work changes, whether people can work with it, and how anyone will know it worked.

Most of the AI problems I see in organizations are not technical. The technology matters, and sometimes it does fail. When an AI initiative disappoints, the cause is more often the organization around the tool than the tool itself. That is good news, in a way. The things that most often decide whether AI pays off are things leadership teams already know how to manage.

Five ways it goes wrong

• Nobody is named to decide, explain or stop it. An AI tool is approved, configured and switched on, but no one person is accountable for what it produces. When an output looks wrong, people don't know who to ask, who can change it, or who can switch it off. Accountability spreads across IT, the business and the vendor until it belongs to no one.

• A new tool is added to an old way of working. The process stays as it was, with an AI step bolted on. Staff check the AI's work and then do the task the old way anyway, so the organization pays twice. The value comes from redesigning the work around what the tool can now do, not from adding it to the existing routine.

• People aren't sure whether they may question the output. If staff believe the system is meant to be right, they stop challenging it. If they don't trust it, they quietly work around it. Either way, the organization loses the human judgement it was relying on. People need to know when to rely on the tool, when to override it, and that overriding it is expected, not a sign of resistance.

• It works in the pilot, but no one planned to run it. A pilot runs on enthusiasm and a small team's attention. Running it every day needs support, monitoring, data that stays current, and someone who notices when performance drifts. Without those, results fade after launch.

• No one agreed what "good" looks like. If success was never defined before the tool went live, no one can say whether it worked. The discussion becomes a matter of opinion, and the decision to scale or stop is made on anecdote.

Why technology teams end up holding it. Technology teams are often asked to deliver AI before the business has agreed what it wants. They are then judged on outcomes they were never given the authority to shape: who owns the process, which roles change, and what counts as success. That is a management question, not an IT one.

The pattern isn’t new

I saw it long before AI. Over 25 years in operations and leadership roles, I have been part of major system changes, including an enterprise-wide system rolled out across an international organization. Each time, the lesson was the same: a new tool cannot make up for an unclear process or unclear responsibilities. What made technology pay off was always ownership, process, people and measurement.

AI raises the stakes, because it can now act as well as advise. When a system drafts, decides or triggers actions on its own, the questions of ownership and judgement can’t be left until later.

Five questions to ask first

I use five practical questions, grouped by who is involved, what changes, and why it is worth doing. Together they make up ORBIT, the method behind all my work.

Lens	Question	ORBIT domain
Who	Who answers for it?	R · Risk and governance
Who	Can people work with it?	I · Integration and adoption
What	Can we run it?	O · Operational readiness
What	What actually changes?	B · Business processes
Why	How will we know it worked?	T · Transformation and value

One test runs through all five: is this evidence we can see, or an assumption we have been told? If we can't see it: where does it sit, how do we find it, and who is responsible?

None of these questions needs a technical background to answer. They need the people who own the work in the room.

Where to start

Start with one process, not a programme. Pick a process where AI is being considered, or where it is already changing how work gets done, and work through the five questions with the people who own it and the people who do it. The gaps usually show up quickly, and they are far cheaper to close before a tool goes live than after.

Over the coming weeks I will take these questions in turn, starting next week with how Who, What and Why give business and technology teams a common lens.

Try it on one of your processes. Bring one process your team wants AI to help with, and we will work through it together in 90 minutes.

Work through one process

Patrick Stenson is the founder of Stenson Global.

He helps leadership teams make AI work in practice.