In most companies, automations are multiplying. A script here, an AI assistant there, a connector between two tools. Each one renders a real service, and that is good news.
But an automation that works well eventually drops off the radar. Nobody thinks about it any more. Its cost, though, does not disappear: it shifts, over time and onto other people.
A successful automation becomes invisible
The shift is massive. According to Microsoft and LinkedIn's 2024 Work Trend Index, 78% of AI users at work bring their own tools. The figure reaches 80% in small and mid-sized companies.
That figure does not describe a drift. It describes energy. Teams know their own friction points better than anyone, and AI finally gives them the means to address them themselves.
The paradox lies in the success itself. A tool that breaks down draws attention. A tool that works fades away. After a few months, it is part of the scenery, and nobody really knows how it works any more.
The cost shifts over time
An automation does not erase a cost, it transforms it. The time saved today is real. But part of the effort is deferred: maintenance, fixes, updates, taking it back in hand.
The mechanism is that of technical debt. You borrow speed in the present and repay it later, often with interest. Nothing serious, as long as that debt is known and chosen.
The difficulty appears when nobody knows it exists. The cost then falls neither at the right moment, nor on the right person. What costs you is not the automation. It is the automation you no longer see.
Five concrete risks, each with its countermeasure
These risks are in no way spectacular. They are ordinary and likely, and that is exactly why they deserve to be named. Each one calls for a simple response.
- Silent errors. An AI can produce a plausible and wrong answer, with no warning. Two safeguards are enough: automated checks, and human validation of doubtful cases, as with reading invoices.
- Usage costs that drift. Subscriptions, calls to paid models, volumes that grow quietly. All it takes is knowing each tool's monthly cost, and setting a threshold that triggers an alert.
- Dependency on one person or one account. The tool rests on the person who built it, sometimes on their personal account. Name an owner, move the access to company accounts, write down the bare minimum.
- Data that travels without a framework. Customer files, contracts or internal figures pass through external services, without anyone always knowing where. The prerequisite is knowing which data goes where, before choosing services whose hosting and terms you control.
- Know-how that fades. For a task automated long ago, the team no longer always knows how to do it, nor how to explain the rule. Writing the business rule down outside the tool makes it possible to take it back, or to change it.
An ordinary example: customer reminders
Take a fictional but common case. Someone in sales administration automates the reminders for unpaid invoices. An AI assistant drafts the messages, a connector sends them from the management software.
The tool works very well. Reminders go out on time, the tone is careful, late payments go down. For months, nobody has any reason to take an interest in it. Then the person who created it moves to another job.
The connector runs on their personal account, and nobody knows where anything is set any more. The model vendor changes its pricing, the tone of the messages shifts after an update. Nothing serious has happened, but the company depends on a tool it never decided to make critical. It would have taken very little: an owner, a company account, a page describing the rule, a cost that is tracked.
An inventory is enough to start
The first step has nothing technical about it. It consists in making visible what already exists. A simple shared list will do, provided you ask four questions about each tool:
- Who owns it, and who could take it over?
- What data goes into it, and where does that data go?
- What does it cost each month, subscriptions and usage included?
- What happens if it stops tomorrow?
This work often brings three groups to light. Tools to drop, because their use has disappeared. Tools to keep as they are, simple and with nothing at stake. And a few tools that have become critical, and deserve to be secured, documented, or even rebuilt properly.
This sorting protects the teams' momentum. It is not about banning anything, but about deciding knowingly what deserves the care given to production software.
A visible automation becomes an asset
You do not need an audit to know where you stand. Put the question differently: which of your automations have become critical without anyone deciding it?
Take them one by one. If the person who built it left tomorrow, would anyone know how to run it, fix it or stop it? When the answer is no, the tool is not at fault. It is its visibility that needs restoring.
Automation is not the problem. It becomes an asset as soon as you know what it does, what it costs and who answers for it.