Operators With Access

The story the industry is telling itself is that AI is transforming supply chain. The data says otherwise, and the reason has nothing to do with the technology.

The story the industry is telling itself is that AI is transforming supply chain. I do not think that is what is happening, and the data is fairly clear about it.

In January 2026, Boston Consulting Group and Alpega surveyed more than 180 logistics providers and shippers across Europe, North America, Asia Pacific, and the Middle East. About 40 percent of logistics service providers reported deploying AI beyond pilots. Only about one in ten had embedded it into core operations at scale. Just 13 percent reported measurable financial impact, and among shippers the figure was 7 percent.

Meanwhile more than 40 percent of shippers now weigh a provider's AI capabilities when selecting partners, while fewer than 10 percent treat it as a requirement. Expectation is running well ahead of delivery, which is the pattern in every technology cycle at this stage.

The most interesting finding is what respondents named as the obstacle. It was not cost and it was not technical complexity. Roughly 40 percent pointed to unclear return and internal capability gaps. Alpega's chief executive put it plainly, saying technology is no longer the bottleneck. What matters now is organization, capability, and getting it into daily operations.

That is the argument I want to make here, and it arrives from a logistics software executive with no reason at all to make my case for me.

If the technology is not the constraint, then the constraint is the distance between the people who understand the operations and the people who build the tools. And that is a much older problem than AI.

Every one of those failed pilots was built by somebody. Somebody specified it, somebody scoped it, somebody decided which cases mattered. In most cases that person had never run the operation the tool was built for. They interviewed someone who had, turned the interview into a specification, handed it to a developer, and had it tested by a team who had also never run the operation. Four handoffs, each one a compression, and the thing that gets compressed away is the exception, which is where the decision lives.

The pilot then performs well in a controlled demonstration and falls apart the first week somebody tries to run real work through it. Everybody concludes that AI is hard, when what actually happened is that the tool was built by people who did not know what the tool needed to do.

Here is what genuinely changed, and it is not the model.

The cost of building software collapsed. Not incrementally. Building a serious application used to require capital, an engineering team, infrastructure to buy and operate, and a translation chain from the person who knows the problem to the person who writes the code. Every one of those is now either cheap, rented, or unnecessary.

I know that because I did it. Thirty years in supply chain, carrier sales and operations and then technology sales, no engineering background whatsoever. What exists now is a platform running five categories with a matching engine, an audit layer, tenant isolation, and payments, built by one person who could not have written a line of it two years ago.

I am not telling you that to be impressive. I am telling you because if I could do it, the specific thing that made it possible is available to you right now, and you may not have noticed.

The scarce input was never the technology. It is knowing what the tool has to do.

You have that. If you have spent fifteen years in a dock, or a shop, or on a brokerage floor, or running a fleet, you know things about your operation that cannot be acquired by interview. You know which exception matters and which one is noise. You know what people actually do rather than what the process document says. You know which report gets printed daily and which one everybody claims to need and nobody opens.

That knowledge took years to accumulate, you already have it, and it does not transfer to somebody who reads about it.

Everything else on the list is now available. The infrastructure is a subscription. The identity and payments are somebody else's problem, run by companies with security teams you could not afford to hire. The learning happens while you build rather than before, and it happens at whatever pace you move at, with no expert whose time you are consuming and no embarrassment attached to asking the same question four times.

So over the next several weeks I am going to write down exactly how, in a series I am calling Building PreShiftIQ. I am writing it while I am still in the middle of it rather than from the far side, which I think makes it more useful and definitely makes it more accurate.

Some of it is the product. How the matching engine works, why it removes vendors before it ranks anything, and the day a beta partner ran three entirely reasonable requirements through it and got nothing back at all.

Some of it is the build. What took the longest, which was never what I expected. What broke, and how often. The day it felt like everything was failing at once and I stopped the build to find out why.

And some of it is about the tools themselves. What AI actually does, what it does not do, where it is confidently wrong, and how you learn when to take the answer and when to argue with it.

None of it is a highlight reel. The parts that went badly are more useful to somebody considering this than the parts that went well, so those are in here too.

What I would say to an operator reading this and wondering whether they could:

Start with the thing that annoys you most. Not the biggest opportunity. The specific recurring irritation you have worked around for years, that you have a strong opinion about, that everyone in your operation complains about and nobody fixes. Your advantage is that you already know exactly what correct looks like, and correct is the hardest thing to specify from outside.

Expect the domain part to go fast and the plumbing to go slow. You will be encoding what you already know, which moves quickly, and learning identity and permissions and deployment, which does not. Budget for that and do not read the slow part as a verdict on whether you belong here.

Expect the bad week. Three things will break because you fixed one, and it will feel like evidence that you are out of your depth. It is not. It is what building is, and the people who finish are not more talented, they just understood that the bad week was normal.

And decide up front what you are unwilling to compromise on, because that decision is much harder to make later under pressure. For me it was that nothing ships that I cannot explain, and that the record of what happened is never editable. Yours will be different. Have one.

The industry does not need more technology. It has plenty, and by BCG's numbers most of it is not landing. What it needs is more tools built by people who have actually done the work, and for the first time that group can build.

That is the shift, and it is not about AI. AI removed the last wall. What matters is who is standing on the other side of it, and for the first time in the history of this industry, it can be you.

If you have been sitting on something for years because building it was not available to you, that is no longer true. What follows is what it took me.

The first piece is called Why I Built It, and it covers the thing I could not stop noticing from the vendor side of the table: buyers choosing technology on sentiment, from a field too crowded to evaluate.

The full series lives at preshiftiq.com/building-preshiftiq, and the platform itself is at preshiftiq.com.

Sources

• Boston Consulting Group with Alpega, AI Is Already Moving the Logistics Industry Forward, March 2026, based on a January 2026 survey of more than 180 logistics providers and shippers across Europe, North America, Asia Pacific, and the Middle East.
• Daniel Cohen, Chief Executive, Alpega Group, quoted in the same report.