The Hidden Economics of Enterprise AI

The falling cost of artificial intelligence is creating an unusual challenge for financial institutions.

Capabilities that would have required substantial engineering investment only a few years ago can now be demonstrated in weeks. Foundation models are readily accessible, specialist AI companies are proliferating, and internal technology teams can build increasingly impressive applications themselves. For executives allocating capital, this creates the appearance of abundant choice—and increasingly attractive economics.

But the apparent economics of Enterprise AI can be misleading.

Consider a wealth manager evaluating AI for an important institutional workflow. An enterprise platform offers extensive capability but carries a significant price. A smaller provider can deliver perhaps 70 or 80 per cent of the functionality at a fraction of the cost. The institution's technology team argues that, with foundation models and its existing engineers, it can build much of the capability internally for less still.

Evaluated as a conventional software decision, the trade-off appears familiar: determine how much capability is actually necessary, compare it with price, and avoid paying for sophistication the organization does not need.

That logic is entirely reasonable. It is also increasingly incomplete.

As AI moves from helping employees write, search and summarize into processes that influence investment decisions, suitability, risk, client recommendations and operational actions, the technology becomes part of the institution's decision architecture. Its limitations have to be compensated for somewhere else in the organization. Its actions have to be governed. Its use of data has to be understood. Decisions may need to be reconstructed months or years later. Humans need to know when to intervene. And ultimately, the institution remains accountable for the resulting outcomes.

That distinction has important consequences for how Enterprise AI investments should be evaluated.

There is nothing inherently wrong with accepting less capability for a lower price. Enterprises do this constantly, and rationally. Not every problem requires the most sophisticated technology available. An AI system used to summarize internal meetings should not be evaluated in the same way as one influencing portfolio recommendations or client outcomes.

The difficulty arises when the consequences of lower capability are excluded from the economic comparison.

A system that handles 80 per cent of a wealth management process may appear highly attractive until the remaining 20 per cent requires analysts to manage exceptions manually. A system that generates recommendations but cannot adequately incorporate the institution's investment philosophy or policies may require another layer of review. A solution optimized for a single use case may be inexpensive initially but require another point solution when the next use case arrives. Limited explainability may need to be compensated for through additional controls; weak integration through additional operational processes.

None of these necessarily makes the original choice wrong. But they change its economics.

Often it moves into people, processes, controls or additional technology.

The same reasoning applies to internal development. The cost of producing an AI application has fallen dramatically. With modern development tools and foundation models, internal teams can create sophisticated prototypes remarkably quickly, particularly when engineering resources are already part of the institution's cost base.

But the cost of creating an application and the cost of operating an enterprise capability are not the same.

Once an internally developed system becomes part of a consequential workflow, it requires integration, testing, evaluation, security, monitoring, data controls, model management, human oversight, auditability and continuing engineering as models and business processes change.

This does not make internal development unattractive. In many circumstances it may be the best strategic choice. But comparing a vendor's full commercial price with the apparent incremental cost of an internal development team can produce a distorted economic comparison.

The relevant question is not simply what it costs to build or buy the capability. It is what each approach costs to operate and evolve.

For financial institutions, regulation adds another dimension to this calculation.

Regulators around the world are taking different approaches to AI, but their direction increasingly converges around an important principle: financial institutions remain responsible for the systems they deploy and the outcomes those systems influence.

FINMA has highlighted issues including explainability, robustness, bias, data quality, cybersecurity and third-party dependencies. FINRA has emphasized that existing supervisory obligations continue to apply to the use of generative and agentic AI. Regulatory developments in the UK, Singapore and India similarly point toward greater attention to governance, accountability, oversight and risk management as AI becomes more deeply embedded in financial services.

The specific requirements will vary by jurisdiction, institution and use case. But the economic implication is broader than any individual regulation:

Nor does building intelligence internally remove that accountability.

As AI becomes more consequential, institutions increasingly need to answer questions that may have received limited attention during an initial technology evaluation. Can a recommendation be explained? Can the institution establish which data influenced it? Has the system been tested for unacceptable bias? How does it respond to erroneous or manipulated inputs? Can its actions be constrained or stopped? Where is human judgment required? And when external models, data or technology providers are involved, who remains accountable for the outcome?

Explainability, fairness testing, data lineage, robustness, intervention mechanisms, human oversight and third-party accountability are therefore more than compliance considerations. They are increasingly part of the operating architecture—and consequently the economics—of Enterprise AI.

If these capabilities are not inherent in the technology or architecture selected, the institution may have to create them elsewhere.

That effort rarely appears in the original purchase price or internal development estimate. It emerges later as additional engineering, controls, manual oversight, documentation, governance processes and organizational complexity.

Over time, this can create a form of regulatory and architectural debt: decisions that appeared economically attractive when evaluated narrowly become expensive to remediate once AI has become embedded in the institution.

This is why Enterprise AI increasingly requires a different investment framework.

The issue is not whether institutions should choose large providers over smaller specialists. A smaller company may have the stronger architecture or deeper domain capability. Nor is it whether institutions should buy rather than build. Internal development may offer strategic control and institutional specificity that an external platform cannot.

The more important distinction is between evaluating AI as a technology purchase and evaluating it as a long-term enterprise capability.

That requires at least four dimensions to be considered together.

Capability matters because the limitations of the system can create costs elsewhere in the operating model.

Control matters because consequential AI must increasingly be explainable, governable and subject to appropriate human intervention.

Architecture matters because successful AI rarely remains isolated. It connects to data, policies, workflows, employees, customers and eventually other AI systems. A tactical decision made for one use case can become part of the institution's operating architecture.

And economics must extend beyond the initial purchase or development cost to include integration, people, controls, governance, maintenance, future use cases, remediation and eventually replacement.

This does not mean the most capable or expensive option is necessarily the right one. Quite the opposite. There will be many situations where accepting less capability, choosing a specialist provider or building internally represents the best allocation of capital.

But those choices should result from a multidimensional decision rather than a simple convergence of price and apparent functionality.

As intelligence itself becomes cheaper, the economics surrounding intelligence become more important. Institutions will need to understand not only what an AI capability costs to acquire, but what its limitations cost to compensate for; what its decisions cost to govern; what its architecture costs to evolve; and what replacing it might eventually cost once it has become embedded in the operating model.

The question for management teams is therefore changing. Not simply: What will it cost us to build or buy this AI capability? But: What capability are we choosing, what are we giving up, and what will it cost us to operate, govern and evolve that decision over its lifetime?

The cheapest option may still be the right one. So may the less capable option. So may building internally.