What Executives Get Wrong Before AI Goes Live

Enterprise architecture decides whether AI scales or stalls. Most executives approve AI budgets without the questions that determine which outcome they're funding.

A board approves a seven-figure AI budget. The vendor demo looked credible. The internal champion has a working prototype. Six months later, the pilot works in one department and breaks everywhere else. Nobody calls it an architecture failure. They call it a scaling problem, an adoption problem, a change management problem. The architecture was the problem.

The failure happens before the first model trains

The research on AI initiative failure points consistently to the same causes: poor data foundations, unclear ownership of data assets, and weak decision governance. Not algorithmic limits. Not compute constraints. The infrastructure, in most cases, performs exactly as the vendor promised. What fails is everything around it.

Aier et al. (2020) studied what structured enterprise architecture practice actually produces inside an organisation. The measurable output was not faster servers or cleaner code. It was shared understanding of data across business units, reduced redundancy, and clearer ownership of systems. Those outcomes sound administrative. For AI, they are load-bearing. A model trained on data that two departments define differently produces outputs neither department trusts. No vendor platform resolves that. No domain team fixes it on their own.

The vendor handles the infrastructure, not the ownership

There is a credible argument that modern cloud platforms have absorbed enough architectural complexity to make executive oversight unnecessary. If Azure OpenAI or AWS SageMaker handles infrastructure, security controls, and pre-integrated services, the thinking goes, the CEO's job is to evaluate the business case and fund the right teams. The architecture is pre-decided.

This argument holds at the infrastructure layer. It breaks at the governance layer. A managed cloud platform does not decide which business unit owns the training data. It does not resolve conflicting data definitions between finance and operations before a model ingests both. It does not determine who approves a model output when that output affects a regulated decision. Those are not platform problems. They are organisational problems that executives are positioned to create or prevent, depending on what questions they ask before signing the budget.

Business & Information Systems Engineering (2019) found that mature enterprise architecture practice produces faster coordination between business and IT units and higher standardisation of data across functions. Domain-driven teams operating independently, with deliberate architectural diversity, are structurally unlikely to produce that coordination on their own. The speed argument for decentralisation is real. The assumption that speed and governance are in direct competition is not supported by the evidence.

What you are actually approving

When you approve an AI investment, you are approving a set of architectural conditions whether or not you name them. Data ownership either exists or it does not. Integration design either accounts for existing systems or it does not. Governance over model outputs either has a named owner or it does not. The research documents that executive teams routinely approve AI spend without a reliable way to judge these conditions. The result is not bad luck. It is a predictable outcome of asking no questions about the foundations.

I have sat through enough vendor pitches where the integration slide shows five clean arrows between boxes to know that the arrows are doing enormous fictional work. Nobody in the room asks who owns the data sitting between those boxes, or what happens when the model's output contradicts the existing reporting system. The questions feel too basic to ask in a room full of technical people. They are not basic. They are the questions.

The practical decision frame is narrow. Before approving an AI investment, confirm that data ownership is assigned at the business unit level, that integration design accounts for existing systems rather than assuming greenfield conditions, and that a named governance owner exists for model outputs in regulated or high-stakes decisions. These are not technical questions. A CEO can ask them without knowing what a transformer model is.

Organisations that treat enterprise architecture as a strategic input to AI investment, rather than a post-purchase IT concern, gain measurable advantages: lower unit cost per AI use case, higher reuse of data pipelines, and fewer one-off integrations rebuilt from scratch for each new deployment. The compounding effect is real. The first use case is always expensive. The fourth is not, if the foundations were built to share.