Blog Deploying AI isn't enough: the tool alone doesn't transform the work

Blog / AI & organization

Deploying AI isn't enough: the tool alone doesn't transform the work

AI & organization · Updated September 11, 2026 · 8 min read


Copilots, assistants, text or code generators: few companies have launched nothing. AI is deployed, and often well adopted. The economic results, though, are slow to come.

This gap isn't a paradox, it's a signal. Spreading a tool and transforming the work are two different things. Value doesn't come from access to AI, it comes from what you do with it.

AI has entered the processes, teams are following more slowly

A 2026 Kyndryl study, reported by Le Monde Informatique, surveys more than a thousand executives about their readiness for AI. A large majority say they have integrated AI into their processes. Only a minority consider their teams ready.

Few organizations reach the goals they had set. Access to the tool is no longer the subject: the gap is widening between usage and readiness.

Look at what your dashboards track today. The number of licenses, the number of active users, sometimes the volume of requests. Almost never what those uses have changed in a process.

Spread reassures, maturity is won elsewhere

A widely used tool gives the feeling of a transformation underway. That's reassuring, and it's normal to settle for it for a while. But usage proves nothing about the value created.

A generative system handles language fluently, and that ease impresses. It says nothing about the reliability of the answer, nor about its effect on a real process.

At the scale of the organization, the gap is the same. An available AI isn't an integrated AI. Spread is visible and fast. Maturity is slow, quiet, and far harder to achieve.

Electricity changed everything the day the workshop was rethought

AI isn't one more tool in a list of tools. It's a layer of infrastructure, running through the organization without being seen.

Infrastructure doesn't create value by its mere presence.

Electricity changed nothing as long as it was bolted onto workshops designed for steam. Value came when the workshop was rethought around it, and not before.

AI follows the same logic. Grafted onto an unchanged process, it speeds up one step and stops there. Integrated into rethought work, it changes how information flows and how decisions are made.

Each person saves a few minutes, and the process stays the same

A team adopts an AI tool to draft its reports, its emails, its product sheets. Each person saves a few minutes per task, and says so.

The gain is real, but it stays local. The better-written report still goes through the same approvals, and someone still re-enters it somewhere else. The process itself hasn't moved.

A few months later, disappointment sets in. The tool is used, even appreciated, but the overall result hasn't changed. And you are the one who has to explain to the executive committee what the spending produced.

The gain stays fragile as long as the way of doing things doesn't move. A tool becomes stable when that way of doing things is itself reworked, in short iterations, fed by users' feedback. It's that work, and not the tool, that makes it last.

Before adding AI, break the work down and decide what to remove

Start by breaking real work down into tasks, before adding anything at all. Then decide, for each one: removed, simplified, assisted, or kept under human responsibility.

Often, the most useful step isn't to automate. It's to remove.

An approval that has become pointless, an avoidable re-entry, a document no one reads: AI shouldn't speed them up, it should make them superfluous. That's the kind of decision no tool will make for you.

The time saved then changes in nature. It's no longer a few minutes on a task, it's a step that disappears from the process.

What we did on our own inbound request pipeline

We walked this climb on ourselves, on our own pipeline for handling incoming requests. It all starts far from the code. We prepare the idea, the plan and the instructions with advanced conversational AIs, such as Fable 5 or ChatGPT.

Then comes a prototype of a particular kind. At its core, a reference base that describes the business, its rules and its way of working. Around it, commands that automate entire steps. This reference base isn't a dead document: we test it, we correct it, we enrich it in short iterations.

When the tool proves its value, it leaves the hands of a single person. We build a web application connected to an AI model. What lived in an expert's tool becomes a tool the whole team uses every day.

Then we connect this application and its reference base to the company chat, Teams or Slack. The team, its messaging, the application and the reference base all end up connected. The tool comes to where people already work, instead of waiting for them to come to it.

The reference base then keeps living, fed by users' feedback. Every real use refines a rule, fills a gap, fixes a forgotten case. The tool improves along with the people who use it.

The final step adds supervised automation. Agents analyze a request, propose a decision, execute it within a bounded scope, then check the result. The human keeps a hand on the wheel: setting the rules, approving sensitive actions and taking responsibility.

A step-by-step climb, where every step protects your budget

This path is nothing specific to our business. It maps out a route open to any company: a chosen scope, a step-by-step climb, value measured before widening.

At every step, two things stay protected. Your budget, because you only industrialize what has proven its value. And your control, because you keep a hand on your data, your decisions and your ability to take the tool back.

AI deployed everywhere gives an impression of movement. The movement that counts is elsewhere, and it shows less: it lies in reorganizing the work around the tool.

So the right question isn't “where to put AI”, but “what work do you want to transform”. The first scatters uses. The second changes a process.

Take AI out of one of your processes, mentally, and look at what is missing. If you only lose the speed of a step, you equipped a task. If the process itself becomes heavier again, you've begun to transform it.

Author · M.Baudoux - Senior developer & founder of GDN