The safest-looking decision about artificial intelligence is usually this: take the processes that already work and bolt AI on top of them. In the view of João Paulo Batistella, it’s also the decision most likely to cost a company its relevance in the next few years — not because the tool fails, but because adapting the legacy solves the wrong problem.
The logic behind the rush to “put AI on everything” is understandable: the structure already exists, the processes already run, the team already knows the business — why not use what’s there? The problem is that structure was designed to operate without AI. It carries hierarchies built for slow human approval, systems that don’t talk to each other, and — the most critical part — processes that only exist as tacit knowledge in the heads of people who’ve worked there for years, never documented well enough for a new “employee” to learn how to execute them, even when that employee is a model.
The two routes to implementing AI
Nearly every company that decides to invest in AI picks, often without realizing it’s a choice at all, between two very different routes.
Route 1 — map the existing process and hand it to an AI agent. It’s the most common route, because it looks the cheapest: take the service, credit, or triage workflow that already exists, document it enough to train or instruct an agent, and replace human steps with automated ones. The limit of this route is structural, not technical — if the process was never formalized as data (it only lived in the experience of whoever ran it), there’s no foundation for AI to act on at all. And even when the process is documented, it still carries the biases and inefficiencies of the structure that produced it.
Route 2 — build a new operation, with no legacy, designed for AI from day one. Instead of adapting the existing structure, the company creates its own unit — team, processes, systems — serving a small, controlled slice of the business (a product line, a region, a customer segment), with explicit permission to grow on its own merit, measured against the same metrics as the traditional operation. This is the route Batistella argues for most strongly, precisely because it attacks the root problem: a structure built for AI from the foundation has nothing to unlearn.
The pattern already exists outside of AI
This parallel-operation model isn’t a theoretical invention — it’s the same pattern large banks already used to answer the threat of digital-first competitors, well before the current AI wave. Bradesco didn’t try to turn its entire branch network into a digital bank: it created next, a separate operation with its own product, brand, team and technology, competing for the same customer the traditional bank also serves. ABN AMRO followed similar logic with New10, focused on credit for small businesses. Neither is fully “AI-first” — they were built in response to digital, not generative AI — but the structural mechanism is identical to what the current moment requires: instead of convincing the old structure to transform itself, you build a new one that only has to prove it works better.
The difference between those cases and a genuinely AI-first unit is the starting question: there, the operating model was designed around digital as a channel; today, the design starts from asking what changes when a company has, for the first time, the equivalent of a bench of specialists available on demand — not “how do I automate what I already do,” but “what do I ask this resource to do that I never even considered before, because I didn’t have enough people or time.”
Adapting the legacy can be a tactic. It’s never the final strategy
That doesn’t make Route 1 useless. Mapping processes and automating them with AI can be the necessary tactical step to get started — generate cash, learn what the technology can actually do, buy time. The mistake is treating that tactical step as the final destination. While a company optimizes its old process, a version without that process — a new startup, or a competitor’s own parallel unit — is being built from scratch, with none of the weight of any legacy system, to compete for exactly the same customer. The question that decides the game isn’t “can we automate what we already do,” it’s “is someone, right now, building a version of our company without our legacy — and will that version be ours or someone else’s?”
In heavy physical-infrastructure sectors, the model is gradual — not absent
The caveat matters: you can’t “spin off a factory.” In manufacturing, infrastructure, or any operation with heavy physical assets, the parallel-unit logic doesn’t apply the same way — there’s no new production line that appears from nothing overnight. But even in those sectors, carving out a separate structure (a team, a project, a cell with real decision and budget autonomy) to operate differently from the parent organization creates the same healthy internal competition, just on a more gradual timeline. The principle doesn’t change; the schedule does.
How to start without betting the whole company
The most common objection to this model is risk: creating a parallel operation sounds like betting the entire company on an untested idea. It doesn’t have to. The design that reduces that risk has three elements:
1. Start small on purpose. A controlled slice of the business — 1% of the customer base, a single product line, one region — limits reputational and operational risk while the new structure is still learning.
2. Measure it against the same metrics as the traditional operation. If the parallel unit isn’t honestly compared to what already exists — same cost, revenue, and satisfaction criteria — no one can tell whether it’s actually working better or just looking more modern.
3. Give it explicit permission to grow on merit. This is where most attempts fail in practice: the parallel unit proves it works better, and the organization, out of survival instinct, caps its growth to protect the old structure. Without a conscious board decision that the new unit is allowed to grow past the original, the experiment stays permanently small — which, in practice, is the same as never having tried.
The question every leadership team should be asking isn’t whether a version of their own company without today’s legacy will exist. It will exist either way — inside the company, as a new unit with permission to grow, or outside it, as the startup born without either of the two problems that slow down everyone already established.
Follow Eleva Tecnologia for more analysis on technology applied to business: follow @ElevaTechno on X, @elevatechnologies on Instagram or Eleva Technologies on LinkedIn, or learn more about the group at elevatec.net/about.
