Rushing Into AI Leaves Enterprises Paying a Long-Term Complexity Tax

Many organizations rush to adopt artificial intelligence without defining the problem they actually want to solve. The tools arrive before the principles, and the strategy follows, if it comes at all. When adoption is driven by impulse rather than intent, the gap rarely stops at a single failed initiative. It quietly compounds across systems, budgets, and teams.

José Freitas is the Lead Enterprise Architect at the International Air Transport Association (IATA). Before joining IATA, he spent nearly a decade at IBM as Chief Architect across banking markets in DACH, Benelux, and Central and Eastern Europe, followed by three years as a Lead Specialist in Enterprise Architecture at Deloitte Consulting. He believes what separates architects who transform organizations from those who simply pass through them is the discipline to align every architectural decision to business intent, govern change with clarity, and keep complexity in check. Without all three, transformation rarely sticks.

"One of the core objectives of enterprise architecture: prevent complexity as much as possible," says Freitas. For most organizations, even holding complexity steady would represent a meaningful step forward. Getting there starts with understanding what the organization actually does.

For most enterprises, building that understanding is a harder sell than funding something new. There is no immediate revenue return on architectural clarity, no visible win. Organizations that have grown project-by-project have accumulated redundant applications, fragmented knowledge, and an increasingly unclear picture of what actually supports their core business. Where capability mapping was attempted at all, it was typically a byproduct of a major transformation, treated as a point-in-time exercise and quietly forgotten. Modern architecture platforms like LeanIX or Ardoq exist to address that exact pattern, maintaining a living view of capabilities and the tools that support them. But they only help if practitioners are willing to build on what already exists rather than starting over.

• Ego over architecture: "If you start with a blank sheet, it's because you already started wrong," says Freitas. "Reusability isn't a shortcut, it’s the discipline of standing on what works rather than rebuilding what already exists." The words were passed down by a seasoned IBM architect to a room full of aspiring architects. Simple advice for any era, but the instinct to skip that foundational work runs deeper than any framework can fix.

For many enterprises, the architecture foundation phase (or discovery phase) is the first casualty of urgency. Establishing a clear picture of the current state, what exists, what it costs, what it actually does, gets compressed or skipped entirely in favor of moving straight to implementation. Rushing that baseline analysis directly contributes to the project failure rates and depleted returns on AI investments that frustrate executives. The consequences rarely stop at a single initiative. They cascade across portfolios, eroding confidence in both the technology and the teams responsible for it.

• Ready, fire, aim: "What I need is a small discovery and design phase, just enough to start building as soon as possible," says Freitas. What every product owner really wants is one answer: "When can I have it?" That pressure for speed to value is legitimate business constraint, not a failure of patience. The question is never whether to move fast, but whether the cost of moving without clarity is understood. "A focused discovery phase takes weeks. Recovering from a solution built on the wrong foundation can take years, and often never fully happens."

• Runaway train: When the objective isn't clear, and the value isn't defined, "we do it agile" becomes less a methodology and more a justification. What follows is rarely a clean failure. "Projects that launch without proper foundations tend to go over time and over budget, and then keep running anyway, sustained by sunk cost and organizational inertia."

• The complexity tax: The cost of a bad solution isn't what you spend to implement it, it's what you spend to keep it alive. "A bad solution will continue to consume a huge number of resources, creating availability problems and technical debt you have to sustain for the rest of that product's lifecycle," says Freitas. "And you never know when it ends." That ongoing drain is what he calls the complexity tax: a compounding liability that outlasts the project that created it, and one that makes every initial shortcut far more expensive than it appeared.

For AI initiatives, that tax compounds faster. Fragmented architectures produce fragmented data siloed, inconsistently labeled, poorly documented. An AI model trained on that data doesn't just inherit the business problem; it inherits the architectural dysfunction behind it. In regulated environments, where data flows across dozens of systems and countries, a model built without governed data lineage is unacceptable.

The consequences of rushed, fragmented projects don't stop at budget overruns. They entrench into architectural debt, cultural paralysis, and strategic drift. IT inefficiency is a symptom. The disease is organizational: a governance culture that mistakes technical ownership for strategic accountability. Without a recognized architectural practice and a shared language bridging IT and the business, architecting a data core and rethinking measurement and governance becomes much harder. This is especially true for AI, where regulatory obligations don't wait for architectural maturity. Model explainability, bias auditability, and data traceability are all required under frameworks like the EU AI Act, and in fragmented environments, retrofitting these in is far harder than building from scratch.

Freitas experienced this as culture shock. In environments where no common vocabulary existed, every workshop became a translation battle, and siloed teams defaulted to self-protection rather than transparency. The same culture that resists shared visibility also tends to defer the hard decisions, including knowing when to retire a system rather than keep maintaining it.

• Silos of self-interest: "Leaders purposely hide data behind artificial barriers and manufactured complexity. To avoid being measured against peers, or to prevent transparency on how they operate," says Freitas. The pattern surfaced repeatedly across organizations: business unit leaders running autonomous verticals would systematically conceal performance data, not out of negligence, but to prevent cross-site comparisons that could expose inefficiencies and invite scrutiny. The data existed. Sharing it was simply not in their interest. What looked like an information gap was, in reality, an information strategy.

• Hoarders, enterprise edition: The structural response is disciplined application lifecycle management, applied consistently across technical solutions and business applications alike. The goal is straightforward: eliminate solution sprawl where multiple applications deliver the same capability, and hold complexity to a single governing principle, one in, one out. If complexity cannot be reduced, it must at least be held at net zero. Architecture review at qualification only governs entry. It says nothing about exit. "When you introduce a new solution, the decommissioning plan belongs on the same roadmap to be treated with the same rigor and the same accountability," says Freitas. "Define the transition period and execute it. When it's done, you kill it. Without that discipline, you're not replacing a system. You're just adding to it."

The discipline required to map capabilities, enforce decommissioning, and maintain cross-domain visibility only holds when architecture is treated as a business function, not a technical one. For Freitas, everything in enterprise architecture starts with the "what" and the "why," not the "how." That mandate is not a license to dictate. Enterprise architecture must operate as a partner with the business, understanding its challenges and enabling it to achieve its own goals, not owning the solution. Capability maps, shared terminology, and governance boards are simply mechanisms to keep those questions front and center. Real enterprise architecture value flows from the top down, and that requires both positioning and mandate, not just good architecture practice.

"No framework delivers results without mandate. Authority, not methodology, is the deciding factor," says Freitas. "Even the most elegant architecture model falters when the people responsible for it lack the mandate to enforce it." But where that mandate exists, the results speak for themselves. Organizations that treat architecture as a strategic function, not a technical afterthought, don't just avoid the complexity tax. They build the foundation that makes transformation, including AI, actually deliverable. "Governance isn't a barrier to growth. It's what makes sustainable growth possible."