Building an AI Project Is No Longer the Problem. Making It Part of Your Company Is.

For a while we had a fairly simple problem: working out whether artificial intelligence could produce any value inside a company. That question is starting to get less interesting.

BearingPoint, a consultancy, has just released a study carried out in August among 1,050 executives at public and private organisations in Europe, the United States and China. Of the organisations already using AI in their operations, 74% say they see a measurable effect on costs or revenue. Yet only 13% say they have scaled their projects fully in line with the plan they were approved on. That doesn’t mean the rest failed. Changing your mind is what a pilot is for.

There is a more interesting detail, though. According to the press release, the leading barrier is regulatory complexity. Right behind it comes integration with the systems and processes companies have been running for years, and more than half of the executives say that having data they can trust is critical. The model, in other words, has often already shown it can do the job. The trouble starts afterwards.

Numbers to Read with Care

These numbers need to be read with care. BearingPoint sells exactly the kind of work the study is about, and a survey of executives is not an official statistic, nor does it necessarily describe Italian companies. Italy is in the sample, but it shows up only in the infographic, inside an “Other Europe” bucket with Austria, Ireland, the Netherlands and Switzerland, and it never gets a figure of its own. The 74% deserves reading to the end as well. It is calculated on the 685 organisations that already have something in production, and the study page adds that for nearly half the effect stays below 4% of costs and below 2% of revenue.

For Italy an official statistic does exist, and its numbers are much lower. According to ISTAT, Italy’s national statistics office, 16.4% of companies with at least ten employees were using at least one AI technology in 2025: 53.1% of the large ones and 15.7% of the small and medium-sized. Of those that use it, one in three names no business purpose for doing so, up from 15.5% a year earlier. ISTAT’s own reading is that adoption is spreading but still has little structure to it.

The same care applies to the percentages that have been doing the rounds for two years about how many AI projects fail. The 95% attributed to MIT comes from a report that calls its own figures “directionally accurate”, because they rest on interviews rather than on official company data. The “more than 80%” usually cited as a RAND finding is an estimate RAND picked up from a 2022 Fortune article; its own 65 interviews were about why projects fail, not how often. The 30% from Gartner was a forecast for 2025, made in 2024. They measure different things, and lined up next to each other what they mostly show is that “how many fail” has no single answer. It can happen within a few hours, too. Reuters’ English-language report on the BearingPoint study says fewer than a third of companies managed to get beyond pilot projects. That figure is not in the press release, and the breakdown BearingPoint publishes says 65% of organisations already have something in production.

Some people also point out that the struggle of getting a new technology into a complex organisation is as old as business computing: we saw it with ERP systems and with the move to the cloud. Many companies are still at the exploring stage, and it is healthy for a project to change course when it finds that some of its starting assumptions were wrong. The study itself says almost three quarters either adjusted the original scope or scaled less than they expected, which is not the same as failing. I agree, and that is why I’m not building the argument on the idea that 13% is a small number. What interests me is where the problems that surface after the demo tend, more and more, to sit. I think they sit in the environment we expect the model to work in.

“Right, Now Let’s All Use It”

Anyone who has signed off a successful trial, in a company or a public body, knows the day when someone, pleased with the result, says: “Right, now let’s all use it.” From that moment the question changes. While it was a trial, it was enough for the system to work on fifty carefully chosen documents, with the person who built it sitting alongside. Now it has to work on the real documents, respect the rules about who can see what, cope with the exceptions, and stay understandable to people who had no part in the project.

Each stage answers a different question. The demo tells you whether the system can do a thing at all. The pilot checks whether it can do it on one part of our work, with real data and real users. Then we need to find out whether we can run it the same way every time, with costs and access under control. The last question is of a different kind: can we afford to depend on it? Once a task becomes part of everyday work, it isn’t enough for the system to work on average. You need to know who answers for it, how you notice that something is going wrong, what happens if the model stops responding, which version produced a given result, and how you roll back. What you see in the demo is only the start of the work.

The Pilot Works Because Someone Is Protecting It

A pilot can succeed precisely because, for a few weeks, it takes away almost everything that makes daily use hard. The data is clean, the users are the willing ones, the scope is narrow and the exceptions are known in advance. The technical team watches every step, and when something odd happens someone fixes it by hand before it turns into a problem.

Those conditions are extremely useful for finding out whether a capability exists, and they are the opposite of what comes next. The data will be whatever it is, the users will have had no part in anything, the technical team will be working on something else, and the system will have to explain itself the week its builder is on holiday. In a sense the pilot succeeds because the organisation shelters it, and daily use strips away exactly that shelter.

Writing the Proposal Was the Easy Part

Picture a mid-sized company that sells services to other businesses and wants an assistant to help its sales team prepare proposals. In the pilot the assistant is given the price list, ten proposals that have already gone out, the service descriptions and a document template. Within minutes it produces a surprisingly good draft, and the decision is made to give it to the whole sales department.

At that point it turns out that the official price list doesn’t always match the one actually in use. Some clients have special terms, agreed in an email thread and never recorded anywhere else. Some service descriptions exist in three versions, only one of them current. One service can’t be sold in certain combinations, and only people who have been at the company a long time know it. Some proposals need sign-off from whoever will have to deliver the work, or from the finance director. Others can go straight out.

The pilot had shown that the assistant could write a proposal. Rolling it out to the whole department shows that writing the proposal was the easy part, and that a system doing real work has to know the organisation. In a local health authority or a municipal office the list would have different items on it, and it would be at least as long.

What People Were Making Up For

I think AI is bringing to the surface problems that were already there: inconsistent data, knowledge scattered across people and their inboxes, permissions that have piled up over time, procedures nobody ever wrote down. As long as only people worked inside these processes, people made up for all of it, constantly. They asked a colleague, they remembered how it was done last time. They knew which value to copy by hand from one system to another, and which field to ignore.

Anyone who works on an ERP with ten years of history knows it can hold three fields called more or less “customer status”, and that only one of them tells the truth. An assistant can read all three perfectly well and has no way of knowing which one to look at. The flaw lies in how we have organised information over the years, and all the model does is make it visible in one go. That is why I think AI projects are mostly testing something no model controls: how legible a company is to someone who hasn’t worked there for years.

A Struggle Older Than Software

Some will say I’m giving a new name to plain old digital transformation. To a large extent that’s true, and it is the most useful thing to admit. For a few years we treated AI in companies as a world apart, with its own vocabulary and its own specialists. But when a system really becomes part of daily work, it runs into the same problems software has been dealing with for decades: data, access, integration, accountability.

The story is in fact older than software. In 1990 the economic historian Paul David, trying to understand why computers were not yet showing up in the productivity statistics, went back to look at what had happened with the electric motor. In 1899, nearly twenty years after the first power stations, electric motors supplied less than 5% of the mechanical drive in American factories. Getting to half took another twenty years, and the effect on productivity only showed in the 1920s. The motor worked from day one. The factories, though, had been built for water and steam power, with line shafts hung from the ceiling and belts running down to drive the machines, and as long as those plants were still serviceable it paid nobody to rebuild them. The gain came when each machine started getting its own motor and the building was designed around that.

Much the same happened with ERP. In a 2002 paper Erik Brynjolfsson, Lorin Hitt and Shinkyu Yang report that in a typical SAP R/3 installation, costing around twenty million dollars, hardware and software accounted for less than a fifth. The rest went on defining requirements, customising the software, redesigning processes and training people.

The difference this time is that the new component doesn’t always give the same answer to the same question, and we keep giving it more autonomy. That makes those problems more delicate and harder to put off. So the new part only works if the old part of the craft is done well.

The Rules Ask the Same Questions, in Writing

That is also why it doesn’t surprise me that the first barrier the study names is regulatory complexity. In healthcare or in a public body, the rules put in writing, and in advance, the questions daily work would raise anyway, starting with who answers for a decision and how you reconstruct it.

The AI Act does this almost word for word. Article 26 requires deployers of a high-risk system to assign human oversight to “natural persons who have the necessary competence, training and authority”, and to keep the logs the system generates for at least six months. The Digital Omnibus pushed these obligations back to December 2027, and I have already written about why the delay changes little for anyone building the system now: a record that doesn’t exist from day one can’t be reconstructed later.

There is a figure in the study that points the same way, to be taken with the same care as before. In the public and health sector almost half of organisations are still exploring or piloting. Among banks and insurers, which have at least as many rules to deal with, it is 22%, and that is the most advanced sector in the whole sample. I don’t know how much the size and budgets of the respondents count for. But if the rules themselves were the brake, I would expect to find banks and insurers at the back.

For whoever builds the system, the rules are a design constraint, and it pays to treat them that way from day one.

What Has Become Hard to Find

This also changes what is hard to find on the market. At the start, what counted was being able to show what AI could do for a company. I think that advantage is wearing away quickly: models get better and cheaper, and a convincing demo can be built in a few days. What remains hard to find is people who can understand a process and redesign it, connect systems that were never meant to talk to each other, decide who gets to see what, and support the people who will have to use the result. These are the long-standing disciplines of carefully made software, and they now have to make room for a component less predictable than the rest.

The same study notes that fewer than a third of organisations formally assess whether an AI project can be scaled before they start it. So the questions of architecture, data, accountability and how the work is organised often turn up once the project has already shown it works. That is the worst moment to discover them, because by then everyone expects it to be a matter of flipping a switch.

Where My Interest Lies

It is also why the projects I find most interesting often begin when the demo has already succeeded. By then the question about the model has an answer. What is left is to work out which systems it has to pass through, what data it may use, which exceptions it has to handle, and what needs to be in place before the company can afford to depend on it.

I have a direct interest in this. I work at a software company that makes its living on exactly the stretch of road between a successful pilot and a system a business or a public body can rely on. A study describing that stretch as the hardest one suits me as much as it suits the people who published it. So the test should be applied to us first.

In our company a machine already writes most of the code, from a specification we write ourselves, and review stays with a person. If writing code were all our craft amounted to, we would be among the first to see it lose value. The rest of the craft, the part I have described so far, has to be demonstrated project by project, and anyone who works with us is entitled to ask how we do it.

Not Every Pilot Needs to Become a System

There is one more consequence, less comfortable for anyone who makes a living from integration. Not every pilot deserves to become a company system. An assistant used by three people, saving them hours without touching anything else, can stay as it is, and that is a reasonable choice. Other times making a pilot dependable costs more than it will ever give back, and finding that out early is a good result, far better than spending three years defending a successful demo. Anyone who earns money by integrating has every reason to say that integrating is always worth it.

The yardstick I ask people to hold us to is this: saying, before anything is signed, how much it will cost to make a successful pilot dependable, and saying so even when the right answer is to leave it as it is.

To the people who make the decisions I leave one question. Which of your AI projects already works as a pilot, yet you still wouldn’t hand it to a hundred real users without the person who built it standing by?

The author

Andrea MargiovanniAI

I follow the relationship between AI and European regulation as a political fact, not a technical spectacle. I work with teams that have to make AI compliant with AI Act, CRA, NIS2 without reducing compliance to a checklist.

See the guide →