The hardest part of adopting AI isn't the models — it's the people

When companies talk about AI, the questions are mostly technical: which model, how much it costs, how it connects to the ERP. Two talks at this year's AI Summit in Barcelona were a reminder that projects rarely fail there. They fail on people and organisation.

That matches what we see ourselves. The technical side of a pilot can be built in a few weeks today. What decides whether a pilot becomes an everyday tool or a forgotten demo is almost always something else: whether someone owns it, whether the people using it trust it, and whether it fits the way the company actually works.

Hybrid builders

Mantu spoke about people they call hybrid builders. They bridge two worlds: they understand a business process, whether accounting, sales or logistics, and know enough technology to build something with AI that actually works. They are not necessarily developers, but they are not just users either.

An example everyone recognises: the procurement officer who, a few years ago, built a spreadsheet with macros for tracking orders that half the company now uses. She knows where the process hurts, knows the exceptions, and knows what people actually do rather than what the procedure says. When a person like that gets support for AI, the results are almost always better than when the project is led by someone who knows the process only from a diagram.

Mantu described the path to such people in three steps, which we translate into practical terms here:

1. Find the people already crossing boundaries. Every company has someone who built the spreadsheet everyone uses, or who tries every new tool first.
2. Develop the missing half of their skills. Automation and data basics for the business person; an understanding of process and money for the technical one.
3. Give them time, a clear roadmap and ownership. A hybrid builder doing AI “on the side”, without a mandate, rarely gets past the pilot.

For smaller companies this is good news: you don't need an AI department. You need one right person with a mandate — and a partner who covers the technical side until they grow into it.

Fear is information

Laurence Nguyen, a leadership advisor, spoke about the other side: what happens inside people when AI enters their work. Her message is that fear should not be suppressed. Fear tells you what is under threat — a job, status, expertise someone spent years building. If you ignore it, you make decisions with half the information.

In practice: before you introduce an agent into accounting, ask the accountants what worries them. The answers are almost always useful — about the people and about the process. “I'm afraid it will get reversals wrong” is both an expression of fear and a precise description of an edge case the system has to handle.

That conversation doesn't need to be formal. An hour with the people who do the process every day and a few open questions is enough:

• Which part of your work takes the most time and matters least to you?
• Where do mistakes usually happen — and who usually catches them?
• What would worry you if a system did that part of the work?
• What must it never do without you?

The last question is especially valuable. The answers to it are almost literally the list of checkpoints the system needs.

Protect the friction

Her second piece of advice sounds counterintuitive at a time when everyone wants to speed everything up: protect the friction. A conclusion forms in a split second; friction is what makes it possible to stop and reconsider. Automation that removes every pause also removes the moment when someone would have noticed that something is off.

That is why good AI processes have deliberate checkpoints: a review before sending, a confirmation before posting, a quick check when an amount looks unusual. They are not brakes — they are the places where judgment is preserved. The skill is in having few of them, in the right places — where a mistake is costly, not everywhere.

Build the collective story

The third message: individual awareness does not survive a system in which the old behaviour is still the most reasonable choice. If one person learns to work differently while processes, deadlines and incentives stay the same, they slide back. Change needs a shared story: why we are doing this, what changes for whom, and what success looks like.

A good story is short and concrete. “We are adopting AI as part of our digital transformation” is not a story. “We no longer retype supplier invoices by hand, and the time we save goes into chasing customer payments, which are currently two weeks late” is — because everyone knows what changes, why, and what is expected of them.

The role of an outside partner

Most smaller companies won't do all of this on their own, and they don't need to. But it's worth being clear about what a partner does and what it shouldn't. A partner builds the technical side, brings experience from other projects and teaches the hybrid builder inside the company. What a partner should not own is the process itself: decisions about what gets automated, where the checkpoints are and what counts as success must stay in the company.

A good test is simple: if the partner disappeared tomorrow, would the company know what the system does, how to change a rule and whom to call when something breaks? If the answer is “no”, the company hasn't adopted AI — it has rented a dependency. That is why documentation, access to the code and data, and time spent teaching people in the company are not extras, but part of the job.

The first 90 days

How do you put all of this into a plan? This is the framework we use with clients for their first AI process — short enough to see a result, long enough to learn something real.

Days 1–30: choose and prepare. Pick one process with a measurable problem — not the most interesting one, but the one where savings or errors can be counted. Appoint a process owner who has time and a mandate, not just a title. Write down how the process works today and how long it takes, because without a baseline you can't later claim anything improved. And hold the conversation about concerns before anyone builds anything.

Days 31–60: pilot. Small scope, but real data — a pilot on made-up examples proves nothing. Checkpoints go where mistakes are costly. Measure three things: how long the process takes, how many errors occur, and how often a person had to correct the system. Once a week, a short review with the team: what works, what gets in the way, what we change.

Days 61–90: decide. Based on numbers, not impressions, you decide: scale, change or stop. Stopping is a perfectly legitimate outcome — you learned something for little money. If you go ahead, document the rules and exceptions, tell the story to the rest of the company, and choose the next process.

Common traps

• The eternal pilot. A pilot without a decision date never becomes a success or a failure — just a cost.
• A tool without an owner. When something breaks or needs to change, nobody knows whose job it is.
• Measuring only savings. Speed without tracking errors and corrections paints a nice but wrong picture.
• Top-down rollout without the people in the process. A system designed by people who don't do the work gets bypassed by those who do.

Where to start

• One process, not ten — the one where the pain is greatest and the result measurable.
• One person from that process, with time and a mandate, alongside a technical partner.
• An open conversation about concerns before the pilot, not after.
• Deliberate checkpoints in the process, especially where mistakes are costly.
• A short, shared story about the goal that anyone on the team can repeat.

Next year's models will be better and cheaper. Companies that by then have built the people and habits to work with them will have an advantage that money can't buy.