"We came looking for AI, and found out we first had a digital transformation and automation problem." I hear this from manufacturers, and the same goes for local authorities and care organisations.
AI doesn't fix a badly wired process on its own. It makes it faster, flaws included. You first need to understand how information flows, remove re-keying, automate what is repetitive, and only then put AI where there is still a judgement to make on text.
Order matters. Each stage prepares the next, and many gains arrive before the first line of AI.
I follow a real file from start to finish, with the people who handle it. We note every re-entry, every wait and every back-and-forth, application by application. That's the lean audit: it shows where time goes, before buying anything.
What is repetitive and predictable gets solved without AI: flows between applications, scheduled imports and exports, connectors, simple rules. It is less spectacular, but that's where re-keying disappears.
AI comes in where a judgement on text remains: sorting requests, extracting information from a document, summarising a file, drafting minutes. By then it relies on clean data and a process that holds up.
The most reliable sign is re-keying. Staff still copy-paste between applications in 2026, and administrators type the same file into three tools that don't talk to each other.
Every re-entry costs time and adds a risk of error, and nobody has the full picture of the file.
The cause is rarely unwilling teams. It often lies in the business software itself, especially in HR and finance, when vendors lock their market and expose no API. Data gets in, but it doesn't get out easily.
A language model can read, summarise, classify and write. It can't repair a data flow that doesn't exist. Put on top of a process where information is typed in three times, it produces a fourth copy, faster, with its own errors thrown in.
It's a common trap: buying an AI tool hoping it will make an organisational problem disappear. You pay for a licence, the demo impresses, and a few months later teams are back to their old habits because the tool doesn't fit anywhere in their actual work.
Training teams is useful, and I do it myself as a speaker. Training shows what is possible, but changing the process takes different work. One executive put it plainly: "Training is fine, now we have to do it for real, in projects."
The question that matters comes a few months later: who uses AI every week, on which task, and what has it changed? If nobody can answer, the tool hasn't found its place in a real process.
It's a common situation in the public sector and in health and social care, and it has solutions. Depending on what the contract and the vendor allow, I use scheduled exports, direct read access to the database, or as a last resort user-interface automation, which replays a user's clicks. That last option stays fragile, so I keep it for cases where nothing else works.
The lasting lever is in the contracts. At the next renewal or the next tender, require a documented API and a data reversibility clause. Otherwise every re-entry you remove today will keep depending on the vendor's goodwill.
With health data, caution comes first: minimise what flows, keep a record of every access, and use certified health data hosting (HDS in France).
I measure few things, but I measure them before and after: the number of re-entries per file, end-to-end processing time and the share of the team using the tool every week. If those three indicators don't move, the project changed nothing, however good the demo was.
With mapping, then automation. AI comes last, on tasks where a decision on text remains. Starting with AI often means speeding up a process that already re-keys the same information three times.
It's a record of how a file actually moves through the company: who handles it, in which applications, with which re-entries and waits. You do it one process at a time, starting with the one that causes the most re-keying, with the people who run it day to day.
Training shows what is possible, but changing the process takes different work. As long as AI isn't part of a real task with accessible data, teams go back to their habits. You then need to deploy one or two concrete uses in real projects and measure how much they are used.
With scheduled exports, read access to the database when the contract allows it, or as a last resort user-interface automation. In the longer run, require an API and a reversibility clause at the next renewal of the vendor contract.
Not necessarily. An internal team can do it if it takes the time to follow a file end to end without blaming anyone. An outside view helps when there are many applications, when departments pass responsibility back and forth, or when you have to choose between automation, AI and a change of tool.
We start from a process that costs you re-keying, and look together at what calls for automation and what calls for AI.
