What Enterprise AI Teams Can Learn From the Auto Industry

Every enterprise architect chasing AI adoption is wrestling with the same problem: how do you add intelligence to a system that was never designed to have a central point of control? It happens another industry has already had to answer that question at scale – and the pattern that it found itself in is something to explore, whatever your stack is or isn’t.

For decades, automobiles have been designed one function, one isolated component at a time, and so has much enterprise software. Then there are a dozen or more purpose-built modules that were added to the system over the years, with their own logic and their own blind spots. It scaled nicely as features were independent. It halted its scaling after the intelligence required to cover the entire system. Current AI systems are used in virtually all aspects of the vehicle, and a disjointed system cannot support the cross-system reasoning that is needed.

The answer was not to add more single-use modules. It was to be a united force. The industry is moving toward one AI vehicle software platform that is central and has much more reach — a handful of powerful, much larger, platforms that don’t talk to each other. The platform draws on data across the entire vehicle rather than one narrow slice of it, and the same architectural thinking now extends into physical AI more broadly — that is, systems which sense and act in the physical world. It’s an indication of a larger trend in AI: intelligence not bolted on, but baked in.

That’s the situation that enterprise AI teams are facing today, except that it involves services and APIs, not control units.

The model isn’t the hard part — the boundaries are

Most enterprise AI failures aren’t due to the model’s quality. They are from the murky edges, where a given AI capability is allowed to see what data, for example, or where a given capability is actually supposed to make a decision, or where a single pilot has to communicate with three systems, none of which were designed to show him that information. A widespread approach to model calls in an application creates the software equivalent of a car with a dozen isolated control units: for each new capability, you have to modify a dozen unrelated locations, and no one can see the full picture of what the system is doing.

The solution is similar to what automotive architects came up with: create a real orchestration layer rather than wiring AI into the business logic where it fits in nicely. A new layer of the system to handle routing, retrieval, permissions, and fallback behavior provides a liberal level of visibility for all downstream capabilities, without the need to have each team solve access control, observability, and versioning issues on its own.

Centralization is a speed decision, not just a cleanliness one

You might want to call this sort of consolidation “housekeeping” — nice to have but not urgent. However, the real returns are speed. The cost of shipping the 5th capability is not simply the cost of shipping the 1st one, since there are hard aspects (data access, security boundaries, model versioning), which get solved once, rather than once per team.

Those teams that put off doing this work generally don’t notice the resulting loss in the short term. When every new AI capability relies on the same set of legacy integration points and when shipping something that’s supposed to take two weeks takes two months, but without the fanfare.

Someone has to own the foundation before anyone builds on it.

Perhaps the most significant takeaway from the change of vehicle architecture has been the fact that it was not a natural evolution. It needed to be decided in its early stages as to what the base system should be like—before additional features were added upon it. There’s rarely a clean-slate opportunity like this. Still, organizations can choose when to stop deploying each new AI capability in an “Ad hoc” fashion and instead adopt an “AI Boundary Layer” that makes the next ten AI features more affordable than the first.

It is important to note that the organizations that are benefiting from AI in their day-to-day operations are not the ones with the most pilots operational. It was they that treated architecture as the actual project – and let the individual features come second.