Something interesting is happening inside car dealerships. People are starting to build things themselves.
A sales manager creates a GPT to help write follow-ups. Someone in marketing uses Claude to improve vehicle listings. An analyst vibe-codes a stock dashboard. Someone connects an API to a spreadsheet because they are tired of producing the same report every Monday. Another person starts using AI to summarise calls or analyse customer conversations.
Most large organisations call this Shadow AI, which already makes it sound like something that needs to be stopped. I think that is the wrong instinct.
Most Shadow AI begins because somebody understands a problem well enough, and cares enough, to try to fix it. Those are exactly the people dealerships should be encouraging. They know which processes are painful, which reports nobody trusts, where information gets lost, and which tasks consume hours for no obvious reason.
AI has suddenly given those people the ability to do something about it without waiting for a software vendor or a six-month IT project.
That is a huge opportunity.
The problem starts when the thing somebody built to solve a local problem quietly becomes part of how the dealership actually operates.
When experimentation becomes infrastructure
The first version of a Shadow AI tool usually looks incredibly cheap.
Twenty pounds for ChatGPT. A Zapier subscription. A quick app in Lovable. Some Claude Code. A spreadsheet connected to an API. The ROI can look obvious because the person building it knows exactly what they are trying to remove.
But imagine that happening independently across a dealer group.
One person builds some lead logic. Another automates customer follow-ups. Someone connects an LLM to CRM data. A department creates its own service workflow. Another team builds its own reporting layer. Different people choose different models, prompts, integrations and ways of storing customer information.
Six months later, nobody really knows how many of these systems exist.
More importantly, nobody knows which ones the business has started depending on.
That is the Shadow AI Tax.
You pay it when three teams unknowingly solve the same problem three different ways. You pay it when a useful prototype starts handling an important workflow but has no monitoring, documentation or owner. You pay it when a model changes and the workflow changes with it. You pay it when customer data travels through systems that were never designed to become production infrastructure.
And eventually you pay it when the person who built something leaves and everyone discovers that a business process had quietly become dependent on their laptop.
None of this means people should stop building.
It means dealerships need to get better at distinguishing tooling from infrastructure.
There are hundreds of things an internal builder should be able to create. Dashboards, analysis, reporting, workflow helpers, internal interfaces, prototypes and automations can all be incredibly useful. In many cases the person doing the job is better placed to design the first version than an external software company. Give those people access. Give them sensible guardrails. Let them experiment.
But there is a point where a useful tool starts becoming part of the dealership’s operating system.
Customer conversations are infrastructure. Lead handling is infrastructure. CRM orchestration, customer memory, booking logic, escalations, production integrations and the movement of data between systems are infrastructure.
Once something is sitting in the middle of those processes, the question changes from “does this work?” to “can the business depend on this?”
Those are very different standards.
The new undifferentiated heavy lifting
Jeff Bezos famously used the phrase undifferentiated heavy lifting to describe the infrastructure every technology company once had to build for itself.
Before AWS, if you wanted to start an internet company, you also had to become reasonably good at buying servers, managing data centres, configuring networks, handling backups and keeping machines alive. None of that was the reason your company existed. It was simply work you had to do before getting to the interesting part. AWS abstracted much of it away.
I think AI is creating a similar question for businesses now.
The fact that it has become incredibly easy to build software does not mean every business should suddenly own every piece of software it can build.
Dealerships should absolutely develop technical capability. They should have people internally who understand AI, data and automation. They should encourage builders. They should prototype aggressively and encode what they know about their customers and processes.
But dealerships are not software companies.
There is little competitive advantage in every dealer group independently figuring out production agent infrastructure, model routing, monitoring, evaluation, permissions, cross-channel memory, failure handling and hundreds of integrations into automotive systems.
Being able to build something has become much easier. Owning it for the next five years has not.
The other AI tax
There is an equal and opposite mistake, though, which is why simply centralising AI is not the answer.
A vendor arrives with an impressive demo. There is an AI strategy presentation. The product has agents, copilots, assistants and a large enterprise price tag.
Everyone agrees the organisation now needs to “adopt AI”.
Six months later, somebody asks the awkward question.
What actually changed?
Did we sell more cars? Did we recover more leads? Did more customers book appointments? Did we answer more calls? Did we reduce administrative work? Did response times improve? Did we lower the cost of serving a customer?
Sometimes the answer is difficult to find.
That is just another kind of tax.
You can avoid Shadow AI completely and still spend enormous amounts of money on AI that produces very little economic value.
The underlying mistake is the same in both cases: treating AI adoption as the objective.
It isn’t.
The objective is ROI. AI is only interesting when it changes the economics or operation of the dealership.
That might mean converting more existing leads instead of buying more leads. It might mean answering demand that currently goes unanswered. It might mean increasing workshop bookings, reducing repetitive administrative work, improving stock quality or allowing the same team to handle significantly more customer interactions.
There should eventually be something measurable on the other side. Otherwise AI itself has become the project.
Build, buy or ignore
The more I think about this, the more I believe dealer groups need a fairly simple framework for AI.
For any opportunity, there are really three options:
Build it. Particularly when it is lightweight tooling, analysis, internal workflow improvement or something that captures knowledge unique to the business. These are exactly the areas where internal builders can move incredibly quickly.
Buy the infrastructure. If something is going to sit inside core customer journeys or become part of the operating system, there needs to be a very good reason to own the engineering and operational burden yourself.
Ignore it. Probably the least fashionable answer, but often the right one. Not every process needs an agent. Not every AI demo deserves a pilot. And not every pilot deserves a contract.
The decision should be driven by the problem and the expected return, not by whether the technology is exciting. This also changes what an AI strategy should look like. Instead of starting with a list of models or vendors, start by finding the friction inside the dealership.
Where is demand being lost? Where is expensive human time being spent on repetitive work? Where are customers waiting? Where are teams rebuilding the same thing? Where has somebody internally already found a better way of doing something?
Then work backwards into the technology.
Why we created Ombox Labs
This is part of the thinking behind Ombox Labs.
Ombox’s core work is building the AI operating layer for automotive retail. We handle the parts that increasingly become infrastructure: customer conversations, lead conversion, orchestration, integrations, memory and the production systems required to make agents useful inside a dealership rather than impressive in a demo.
But as we have worked more deeply with dealerships, another need has become obvious. There is an enormous amount of AI opportunity outside that operating layer, and increasingly there are people inside dealerships capable of finding it themselves.
Those people do not need us to tell them to stop building. They need help turning that energy into something useful for the wider organisation.
Labs is our way of working with dealer groups to find those builders, identify the real operating problems, prototype quickly and work out what deserves to go further. Sometimes that means helping an internal team build something. Sometimes it means turning an experiment into a more robust capability. Sometimes it means pointing to infrastructure that already exists rather than rebuilding it.
And sometimes it means saying that an AI idea probably isn’t worth doing at all.
The common filter is ROI.
We don’t think dealerships need more AI for the sake of having more AI. And we definitely don’t think every useful AI experiment needs to become another SaaS subscription or another piece of production infrastructure maintained internally.
The dealerships that get this right will probably sit somewhere between the two extremes.
They will have lots of people experimenting with AI rather than a small central team controlling everything. They will build useful tooling themselves. They will use shared infrastructure for the parts of the business where reliability, integration and scale actually matter. And they will be increasingly difficult to sell AI to unless somebody can explain where the return comes from.
That feels like a much healthier destination than either banning Shadow AI or letting a thousand disconnected agents bloom.
Keep the builders. Keep the experimentation. But be ruthless about the ROI, and don’t accidentally rebuild your operating system along the way.