Is AI just automation with a new label?

Introduction

I hear it more and more often in conversations with managers, product owners and architects: “We want something with AI.”

And then after ten minutes it turns out that it is actually something very recognizable. Less manual work. Reporting faster. Fewer errors. Better lead times. More grip.

All good goals. Only: much of what is now sold as an “AI initiative” could also have been solved with classic automation and well-designed software. Sometimes smarter. Sometimes cheaper. Sometimes more reliable.

This is not an attack on AI. On the contrary. It is a plea for maturity: we need to get better at choosing where AI adds value, and where it is mainly noise.

A recent KNIME-analysis set that choice very clearly by distinguishing between traditional automation, generative AI and agentic variants, including when which approach makes sense.

The confusion begins with the word “AI”

“AI” has become a container concept. It stands for:

• A chat interface on top of existing systems
• A model that summarizes texts
• An agent performing actions
• A developer who writes code faster
• A classification model that recognizes exceptions
• And sometimes just a workflow with smart rules

If you call it all “AI”, you automatically get a weird discussion. Then it seems like you have to be for or against AI, while the real question is: what problem do we solve, and what is the most appropriate mechanism?

Old wine in new bags, and why that’s okay

Let me say it unpopularly: a lot of “AI-use cases” are old wine in new bags.

Examples that I often see by:

• “AI reports” that need a good BI model at its core
• “AI data analysis” that mainly requires data quality, definitions and a semantic layer
• “AI process optimization” that starts better with workflow, integration and clear decision rules

What AI can add in such situations:

• A more pleasant interface (asking questions in regular language)
• Summaries and explanations for humans
• Explore variants faster (hypotheses, scenarios, draft texts)

But if the outcome has to be reproducible, auditable, and without surprises, then you often want something other than a probabilistic system.

In short: if the answer always has to be the same, then “classic” is often just better.

The difference that many organizations miss: AI as an engine versus AI as an accelerator

There are roughly two ways AI can deliver value:

1) AI as an engine in your solution

Then AI does substantive work in the process, for example:

• Classification of free text
• Extraction from documents
• Recommendations
• Support of employees with context and knowledge
• Handle exceptions where rules fall short

This is where AI is really part of the operation. You build a solution that can’t do the same without AI.

2) AI as an accelerator of your software development

Then AI is not in your product, but it helps your team to build faster:

• Write code faster
• Generate tests
• Summarize documentation
• Explore alternatives
• Propose refactor

That can be valuable. Only: the end result is often just “software”. Not an AI product. No AI application. Just a better or faster delivery.

It is important to keep that distinction fair, because it determines your expectations and your governance. If you mainly use “AI” to accelerate development, then you should not pretend that your organization suddenly works “AI-driven”. You mainly work more efficiently.

And even that is not automatic profit. A METR-RCT among experienced open-source developers showed in 2025 that AI tools in that context led to longer lead times on average, while the developers thought they were faster.

The nuance is important: AI can help, but not everywhere, not always, and not without discipline.

Why “AI where automation is enough” happens so often

There are three reasons why organisations use AI for problems that are actually deterministic.

1) The label opens budgets

When something is called “AI”, it feels strategic, innovative, future-proof. This makes it easier to release resources. That is human. Only: it doesn’t make the content better.

2) One wants speed without laying the foundation

Reporting and analysis are often slow because definitions are missing, data is scattered, ownership is vague. Solving that takes work.

AI then seems like a shortcut: “let the model summarize it.” That sometimes works, but it masks the real cause. And you pay the bill later.

3) One confuses “talking about data” with “steering on data”

With AI, you can quickly generate texts that sound like you have a grip.

But grip only arises when you can trace, explain and steer it. That often requires standardisation, data models and clear KPI definitions.

An mature decision-making framework: automation-first, AI-where-needed

This is the simple framework that I use myself to keep conversations with management and teams practical.

Choose automation if:

• The outcome must be reproducible
• Audit, compliance or traceability weighs heavily
• The input is already structured
• The process mainly consists of fixed rules and predictable steps
• Mistakes are expensive and variation is low

Choose AI (or AI as an assistant) if:

• The input is unstructured (mail, documents, minutes, free text)
• There are many exceptions and variation
• Your employees mainly struggle with interpretation, summarize, search
• You want speed in knowledge work, with human control where necessary

Choose hybrid if:

• AI helps with interpretation or proposal
• Automation carries out
• Man decides and guarantees at higher impact

This hybrid approach is also reflected in recent analyses that make the distinction between traditional automation, generative AI and agentic solutions practical, including when “agents” are mainly overkill.

A few recognizable examples (without magic)

Reports

If your monthly reports are now manual work, the problem is usually:

• Definitions differ
• Data is fragmented
• The process of “closing” is not tight

AI can then help with:

• Summary of deviations
• Narrative generation (“what stands out and why?”)
• Answer questions about numbers

But the underlying figures must be deterministic. Otherwise you get a report that sounds good and is wrong. And that is a very expensive kind of deception.

Data Analysis

When you mean: segments, trends, KPIs, drill-downs, then classic analytics is often the basis.

AI can help formulate hypotheses and articulate insights faster, but you then want to “make those hypotheses hard” with normal analysis.

Process optimization

If the goal is: fewer transfers, less waiting time, less repair work, then you often already win with:

• Process standardization
• Workflow
• Integrations
• Clear ownership

AI only becomes interesting if you have a lot of free text, or when exceptions dominate the process. Then AI can make the difference by sorting or routing those exceptions faster.

The real gain: being honest about what you are doing

The most mature organizations I see are doing something simple:

• They just call automation automation
• They only call AI AI when it really plays a role in the operation
• They limit pilots, steer by value, and also dare to stop

And most importantly, they don’t use AI to destroy existing structures, but to make them smarter. Portfolio choices remain portfolio choices. Architecture remains architecture. Governance is still needed. Only the accents become different.

Conclusion: “AI application” is not the goal, result is

If AI only helps build software faster, that’s fine. If AI only helps to make reports more readable, that’s fine too. If AI is not really needed anywhere, but you do provide value with automation, that’s fine.

The only thing I find a shame is when the label “AI” clouds the discussion, inflates expectations and makes the organization unnecessarily insecure.

The question you can ask yourself is simple:

Should this be predictable, or can it be probabilistic?

Once you have that sharp, the rest often falls into place surprisingly quickly.

Do you want to put this framework on your processes, without hype and without theater? Then that’s exactly what I do in a short clarity session: per process we determine automation-first, AI-where-needed, and what is a sensible first step.