AI wins the task. You still keep the person.

Put a person and an algorithm side by side on the same problem, and the algorithm usually wins. At Plainsight we have run that comparison at enough companies to say it out loud without flinching.

It is also the least interesting fact in the room. The comparison tells you which one is better at the thing you measured. It tells you nothing about what to do on Monday, and that second question is where AI plans quietly go wrong.

Two clocks, running at different speeds

The hard part of this has almost nothing to do with how good the models are. It is that technology and people run on different clocks.

The tech clock is fast. A capability that did not exist in March is in a product by September and in your competitor's process by January.

The human clock is slow, and reasonably so. Somebody who has been excellent at a job for twelve years does not rebuild what excellent means in a quarter. Teams need to see a thing work before they trust it. That is not resistance. It is how people work, and a plan that treats it as an obstacle will fail in a way nobody writes down.

The distance between those two clocks is the moment we are in. It is where the anxiety sits, where the panicked decisions get made, and where almost all of the opportunity is.

It also disposes of both popular answers. "AI will not take your job" is comforting and wrong. "AI will take your job" is dramatic and also wrong. What happens is that your job moves, and whether that ends well depends on how fast you and your employer move with it.

A task is not a job

When somebody runs the human-versus-model comparison, they are testing a task. Classify this ticket. Extract these fields. Score this review. Draft this summary. Clean, bounded problems with a right answer, which is exactly the shape a model is good at.

A job is not that. It is a bundle of tasks, plus the judgement about which one matters this week, plus the exceptions nobody wrote down, plus being the person a colleague walks over to when something looks off. When the algorithm wins, it won one line item out of that bundle. Reading that as "we need fewer people" is a category error, and an expensive one. You tend to discover what the person was also doing about six weeks after they leave.

Here is the shape we see most often, and I will describe it as a shape rather than as one company's anecdote, because we have now watched it happen often enough to trust it. A business has years of its own knowledge spread across SharePoint. In one deployment we run, eight terabytes of it. Finding anything in there is a task: you type a guess into the search box, get nothing useful, and go ask the colleague who has been there longest. So we put an assistant on top of the pile, one that answers from the company's own documents and shows where each answer came from. About three hundred people use it on real work every day. The looking up is finished.

Documents are only where it starts. The assistant plugs into the systems the work actually happens in, anything with an API or an MCP server, so the right intel turns up at the moment somebody needs it instead of after they go hunting for it. Same platform, completely different questions depending on who is asking. An HR lead pulling apart a process that takes too long. A service team answering a customer while the customer is still on the line. Somebody who simply needs to know how their own company does a thing. And once the assistant can reach those systems it does not have to stop at telling you. It can take the next step itself and ask you to confirm it, which is a small design decision that keeps a person on the hook for what happens.

Notice what that removed. Not a job. A task, and a fairly miserable one. What is left is the part that was always the real work, which is deciding what to do now that you have the answer.

It also does something people do not expect, which is send you to a human. Ask it something no document answers and the useful reply is not an apology, it is a name: here is the team that owns this, here is who did the last one. In a company of any size, most of the time lost to a question goes on working out who to ask rather than on asking them. So the assistant does not remove the colleague you would have walked over to. It gets you to the right one, including the one you did not know existed.

One person's day does change more than anybody else's, though, and nobody plans for that. Every company has a human search index, the colleague everybody asks because they know where things live and who to call. That informal role is the one the assistant takes over. Plan for it, because that person did not only lose a chore. They lost a bit of standing, and the right response is to hand them the work they are now free to do rather than congratulate them on the hours saved.

The task is the small prize

Everything so far has been about putting a model on a task, which is the easy version and the one most companies stop at. Take a process that was designed around people doing it by hand, find the three steps a model can take over, bolt an agent onto each of them. It works. It saves real time. It is also the least valuable thing you will do this decade.

The bigger prize sits one level up. Most processes were never designed at all. They accumulated. They are shaped by what was possible when they were built, by a system somebody bought in 2011, by a colleague who left in 2018 and whose workaround quietly became policy. Automate that faithfully and you have bought yourself a faster version of a shape nobody would choose today.

So the question worth asking is not which steps a model can take over. It is what this process would look like if you designed it now, knowing what these tools can do. That is not a technical question. No model can answer it, because answering it means knowing what the process is actually for, which of its rules are laws and which are only habits, and what a customer would notice if it changed tomorrow. It is imagination applied to something boring, and it is the most human thing in this whole conversation.

That is where the winners will come from. Not the companies that automated fastest. The ones willing to ask what they were doing all along.

The catch is that reshuffling a process means reshuffling the people in it. New handovers, new ownership, new definitions of done, and somebody who has to be told that the thing they were best at is now step four of something else. That is not a communication exercise you run at the end. It is most of the work, and it takes several steps.

What the model does not carry

Alongside that, three things stay stubbornly human in nearly every project we run, and they deserve better than "the human touch".

Somebody has to look at an answer and know it is wrong. Not check it end to end, that would defeat the point, but carry enough domain instinct to catch the answer that is confidently off. That skill is unevenly distributed, and it gets more valuable as the volume of machine-produced answers goes up.

Somebody has to handle the cases the model has never seen. Models are excellent on work that looks like their training data. The rest is where your margin, your reputation and your regulator live.

And somebody has to own the outcome. A model cannot sit across from a customer and be answerable for what happened. It cannot face an auditor. Someone has to hold the decision, and understand enough about how the answer was produced to defend it.

Strip a team past the point where anyone can do those three things and you have not automated the work. You have removed your ability to notice when it goes wrong.

The person stays. The job does not.

So here is the sentence I actually mean, with both halves attached. You keep the person. You do not keep the job in the shape it had.

Some tasks will need fewer people. Some roles as they are written today will not exist in five years. Saying otherwise to your team is a kindness with a short shelf life, and they can already tell. The useful response is speed, not reassurance: get people into the new version of the work while there is still room to learn it badly.

We are not standing outside this. Femke, one of our Power BI people, wrote about building report prototypes with Claude in minutes instead of hours. The time saved is the boring part. Prototyping used to get skipped because it was expensive, so the first honest conversation with a client happened after the report was built, which is the worst possible moment to learn you built the wrong one. The tool did not take a step out of her job. It moved the hardest part of it, getting the right feedback early, from something she rarely had time for to something she does every time.

The people who make that shift well share one thing, and it is not technical skill. Ask them what they do and they tell you what they are trying to achieve, not which steps they perform. Give that person a tool that removes half their steps and they get curious. Give the same tool to somebody whose identity is the steps and it lands as a threat, which is a fair way to feel and a problem you help them through rather than around.

There is a pace question under all of this, and I should be honest about my own bias in it. I am a jumper. Offered a careful sequence or a leap, I take the leap. Not blindly, not without thinking it through and keeping a second option in my pocket, but without much fear of landing face down first.

Luckily, most people are not like that. A company staffed entirely by people like me would be exciting and would not survive its first quarter. Most of us need steps. Stairs. Sometimes an elevator. A small push, a light that goes on, and then smaller jumps we pick ourselves.

The mistake is designing a transformation for jumpers because the person leading it is one. If your plan asks everybody to leap and most of your people need stairs, you have not built a plan. You have built a filter.

Done well, none of this lands on a smaller company. It lands on one where the questions people spend their day on are harder than the ones they spent it on before, and where the answer to "why did we decide that" is still a person who can explain it. Worth aiming at deliberately, because it does not happen by itself.

What this means for how you plan

The practical translation is fairly boring, which is usually a good sign.

Do not open an AI project by asking which roles it could remove. Open it by asking which question your business keeps answering slowly, or badly, or with one person's opinion. Find the instrument that answers it better. Then decide where the freed hours go, because hours nobody assigns get quietly absorbed and you see no return at all.

Bring the people who do the work into it early enough to shape it. Not as a change-management courtesy. It is the only reliable way to find out what the difficult cases look like, because the person doing the job is the only one who knows.

And give the slow clock the time it needs. Running a six-month technology change on a six-week people plan is the most common way this fails, and it never shows up as a failed AI project. It shows up as a tool nobody uses.

We walk into a company to make the work better and leave the team stronger than we found it.

If you are somewhere in this conversation inside your own company, talk to us about the question you keep answering badly.

The interview

This post grew out of a portrait of me that Emma Verplancke wrote for De Tijd in August 2026, covering Plainsight's first three years, the move to Ghent, and the step into the CEO role. A few of her questions stayed with me for days, which is the highest compliment I have for an interview.

You can read the original here: Bo Vande Sompele, CEO van Plainsight, in De Tijd (in Dutch).