AI does not care what it amplifies. You should.
By Jonas Astrup Beck · April 2026

AI does not care what it amplifies. You should.
A year ago I was not an AI-tech person. I am still not sure I am one now — but something has shifted. What changed was not understanding the technology — it was experiencing what it could actually do, in my own work, with my own problems. And once I could see the value clearly, I also saw something else: the systems perspective matters now more than ever.
Most conversations about AI in organisations focus on the technology — which tools, which models, which vendors. But the more important conversation is the one almost nobody is having: what problem are we actually solving, and for whom?
In an earlier piece I wrote about the danger of using AI to do the wrong things faster. This article goes a step further: how do you know whether AI is being used the right way in your organisation — and what are the system conditions that determine whether that is even possible?
This is a reflection I have been working through about how AI fits — or does not fit — into organisations designed around purpose. It draws on the Vanguard Method and on my own experience this past year of working directly with AI in my consulting practice. Later articles in this series will introduce the principles and method questions that enable you to understand how and where AI can actually help your organisation. This one starts with the important broader questions. This is not about the tools.
The predictable failure
There is a tension running through every AI conversation in most organisations right now. AI tools — and the way most organisations are deploying them — are expressions of what John Seddon would call command and control logic. They are about efficiency, standardisation, faster throughput, measuring outputs. That is the management thinking that systems thinkers have spent decades critiquing.
The consequences are already visible in everyday life. You read about an organisation’s AI transformation — faster response times, efficiency gains, customer satisfaction scores up. Then you contact that same organisation and find yourself trapped in an AI chatbot that cannot understand your situation, will not connect you to a person, and loops you back to the same three options that do not apply. The press release and the lived experience are describing two different realities. And the bigger the organisation, the wider this gap tends to be.
A systems thinker would not call this a paradox. It is entirely predictable. The system condition driving the design is a cost-per-contact measure. AI has been deployed to reduce contact, not to serve need. The customer’s problem — the actual reason they contacted the organisation — is an inconvenience to the system, not the point of it. The AI is doing exactly what it was designed to do. That is precisely the problem.
And yet AI is genuinely powerful. So the question is not whether to use it. The question is not what AI can do. It is what you are using it to do — and why.
“Every system is perfectly designed to get the results it gets.”
— W. EDWARDS DEMING
Deming wrote that long before AI existed. It has never been more relevant. Organisations reach for AI to improve efficiency, deliver more value to customers, or build new capability. But whatever the motivation, if the current system itself is poorly designed, AI does not fix it. It amplifies the dysfunction — with unintended consequences in the short and the long term.
Consider a government benefits agency that automated its application decisions online. Applicants submitted their own information; the system made instant rulings. The organisation was proud of its automation rate. But applicants did not understand the rules well enough to know which information to submit — particularly those in complex situations with many exceptions. The result was a predictable stream of incorrect automated decisions, followed by manual clean-up at cost to the organisation and frustration for the citizen. When the agency finally studied its demand, seventy percent was failure demand. The automation did not cause the problem. But it scaled it, reliably, every single day. You have to wonder: how many organisations right now are doing the same thing with AI?

This is not a moral judgment. Automating a well-understood, well-designed process is perfectly sensible. The distinction is whether you have studied the work before you automate it — whether you know what the value steps are and whether they actually serve the customer. The danger is not AI itself. It is AI applied to work you have never looked at closely.
Where AI belongs: supporting the value work
Consider an insurance company. A customer calls to make a claim. Her car was hit in a car park — a straightforward case, except that nobody’s situation is entirely straightforward. There is damage to a child seat. She has questions about a courtesy car. She is worried about her renewal premium.
In a well-designed system, the person handling this claim has the knowledge and authority to deal with her situation end-to-end. They understand the customer’s need — not just the facts of the claim but what matters to her. They conceive the right response — assessing the claim, deciding on the child seat, arranging the courtesy car. They execute — putting the right things in motion without handing her off to three departments. And they review — was this handled well? Did the original policy sale set her up for a smooth claim, or did it create confusion?
Now imagine AI in this picture. Not replacing that person. Not routing the customer through an automated triage. Instead: helping the handler see the full history instantly, flagging that the child seat is a safety item requiring specific handling, surfacing the relevant policy details so the handler spends less time searching and more time thinking. The AI is removing friction from the value work. The human still understands what they are doing and why.
That sequence — understand, conceive, execute, review — is not accidental. Ibby Hussain, from Vanguard, identified these as the underlying principles after years of studying how service organisations actually work. An acronyms connoisseur, he called it UCER: a way of describing the value steps at the heart of any service organisation. The insurance example above maps directly to it. And UCER gives us a structural answer to where AI belongs.
AI belongs wherever it helps people do value work better. It does not belong as a layer of control imposed between the worker and the work.

AI that sits outside these steps and serves no customer purpose — monitoring compliance for its own sake, reporting on activity, controlling behaviour — is control logic wearing a technology mask.
The system conditions that limit everything
There are two legitimate positions on AI. The first: you are improving efficiency — doing what you already do, only faster. This is valid if your value steps genuinely serve the customer and removing friction helps. The second: you are building new capability — using AI to solve problems you could not previously solve, understanding demand at scale, making invisible patterns visible, supporting judgment in complex situations, or meeting customer needs that were simply going unmet before. Both can be right. What matters is whether you are making an informed choice about what problem you are solving and for what purpose.
But here is the harder truth. The system conditions of a traditionally designed and managed organisation will eventually become the limiting factor — and no amount of AI changes that. These conditions are not abstract. They are specific, recognisable, and almost certainly present in your organisation right now.

If underwriters do not truly understand risk and need before you automate the assessment, faster execution just scales the wrongness. If your service is generating significant failure demand — contacts driven by unmet need, confusion, or broken processes — AI will only process that failure demand more efficiently than before — not understand and remove the causes of it.
The central risk of AI adoption without systems thinking is not that AI will fail, but that it will succeed — at the wrong thing.
Three questions before you start
If you are a leader feeling the pressure to act on AI — from your board, your peers, your staff — here is where I would start. Not with technology. Not with a vendor demo. With three questions, asked in sequence.

Most leaders assume they know. The data almost always tells a different story. Until you understand demand, you cannot know whether AI is solving the right problem or scaling the wrong one.
You can only answer these questions by first studying your own system — that is the how. And the answers will determine the scope and ambition of the problem your organisation will try to solve. The first question names your current reality. The second asks what good would actually look like — for the people you serve, not just for you. The third surfaces the gap between where you are and where you want to be. By the time you have answered all three, you understand and own the problem — and you are in a position to make informed choices about what action to take. That is where lasting change starts.
The organisations that get lasting value from AI will not be the fastest adopters. They will be the ones who asked the harder question first: do we actually understand the work we are asking AI to support?
What I am increasingly sure of is this: the organisations racing to adopt AI without first studying their own systems are not solving problems. They are automating them. And AI will do that very efficiently indeed.
So here is the question I want to leave you with — the one that matters most before you do anything else.
Do you actually know why people contact your organisation — and how much of that contact should never have happened?
In the next article, we go and look.
ABOUT THE AUTHOR
Jonas Astrup Beck is Director and Partner at Vanguard Scandinavia. He has worked with the Vanguard Method since 2006 and is co-author, with Kristian Astrup Nielsen, of Riv servicefabrikkerne ned — a book about why service organisations fail when they are designed like factories, and what to do instead. This is the second article in a series on AI and the systems perspective.