Your AI Ambition Has
Outrun Your Architecture
The next phase of investment should close that gap before it expands the portfolio.
Enterprise AI is moving from experimentation to execution. In many organisations, the architecture, governance and accountability required to support that shift have not moved with it. The next phase of investment should close that gap before it expands the portfolio.
Most organisations have a high AI ambition based on the experimental phase for AI implementation in those organisations. However, that AI ambition exceeds the architecture available to deliver it. The ambition is visible in new use cases, copilots, agent programmes and executive commitments.
The architecture was designed to record transactions, support applications, produce information for people. It was not designed to provide automated systems with governed access to enterprise data, business context, decision authority, and an auditable route from recommendation to action.
This mismatch explains why many AI programmes show substantial activity without producing a proportionate operating result. Models are capable, pilots often work and employees can demonstrate useful applications. The difficulty appears when an organisation attempts to move from isolated use to repeatable enterprise performance.
Data definitions conflict, business rules remain implicit, controls assume a person is acting through an application, and model choices are made independently by separate teams. The ambition is enterprise wide. The supporting architecture is still organised around individual systems and projects.
The consequence is not simply technical debt. It is an operational constraint.
An organisation cannot scale automated decisions if its architecture cannot establish which information is authoritative, which context may be applied, what authority has been granted, how an action is recorded and what that action costs to produce.
Legacy Architecture Is Now
Constraining AI Scale
Most enterprise estates were designed around systems of record. The ERP records the financial transaction. The CRM records the customer interaction. Operational platforms record events within their respective domains. Integration moves information between them, and reporting consolidates it for human interpretation. Accountability follows the application and the person using it.
AI applications and agents operate differently. They draw information from several sources, apply context which may not exist in structured form, select an action and, in some cases, execute that action across multiple systems. Their reliability depends on decisions which no individual system of record was designed to make.
The first decision concerns data authority. When the ERP, customer platform and operational system contain different versions of the same entity, an automated process must know which definition takes precedence.
The second concerns business context. The system must have access to the policies, exceptions and commercial logic employees apply when interpreting the data.
The third concerns control. The organisation must be able to establish what authority was granted, which policy applied and how the action can be reviewed. The fourth concerns model routing and cost. Different tasks may require different models, service levels and control requirements, and those choices require an enterprise policy rather than a series of local decisions.
These responsibilities sit between systems of record and systems of action. In many organisations they are distributed across technology, data, risk and business teams. Each team owns a component. No one owns the combined result. AI has not created that gap. It has made the gap operationally significant.
Local Workarounds Are
Masking an Enterprise Gap
An architecture which has fallen behind the ambition produces a consistent set of symptoms. AI initiatives repeatedly prepare the same data because no authoritative enterprise definition has been established. Pilots perform well on selected inputs but require manual verification before their output can be used.
Business context is reconstructed for each use case because proprietary knowledge is not governed as an enterprise asset. Controls are added after an application is built because the authority model was never defined at the architecture level. Inference costs grow across teams without a consolidated view of unit economics.
Each symptom can be managed locally, which is why the underlying constraint can remain hidden. A team can reconcile the data manually. A process owner can review the output. A risk function can approve an exception. A budget owner can absorb the initial run cost.
These measures keep an individual initiative moving, but they do not create a reusable enterprise capability. The next initiative encounters the same conditions and funds the same work again.
If every initiative must rebuild those foundations, the organisation is increasing activity rather than capability.
The Evidence Points to
Operating Conditions, Not Model Capability
The available research does not suggest that the primary constraint is a lack of experimentation. MIT's Project NANDA reported in 2025 that roughly 95% of the organisations in its evidence base had not achieved measurable profit and loss impact from generative AI initiatives within the study period. McKinsey reported that 88% of organisations were using AI in at least one business function, while nearly two thirds had not begun scaling it across the enterprise. Gartner forecast that more than 40% of agentic AI projects would be cancelled by the end of 2027 because of escalating costs, unclear business value or inadequate risk controls.
These findings should not be interpreted as evidence that AI is failing. They point to a more specific problem: adoption is moving faster than the operating conditions required to convert model capability into controlled business performance. Cost, value and control are not downstream reporting issues. They are design requirements and need to be established before scale is attempted.
Executives Need Four Answers
Before Funding the Next Phase
A board or executive committee does not need to approve a detailed technical design. It does need to know whether the organisation has established the conditions under which its AI ambition can be delivered. Four questions provide a practical test.
A credible answer requires authoritative definitions, source precedence, lineage and an accountable data owner.
That requires governed knowledge sources, access controls and a named business owner.
That requires explicit decision rights, policy enforcement, an evidence trail and a review process.
That requires a routing policy, usage reporting, unit economics and a budget owner.
A weak answer to any one of these questions does not justify reducing the ambition. It identifies the architectural gap the next investment should address. The direction remains valid. The sequence changes.
The Next Investment Should
Create Reusable Capability
The common response is to begin with another platform decision: which data cloud, lakehouse, agent framework or model provider should be selected. Those decisions matter, but they do not resolve the underlying position on their own. A platform can implement lineage, model gateways and policy controls. It cannot determine the organisation's authoritative business definitions, supply its proprietary context or assign executive accountability for an automated decision.
The first decision is therefore an operating model decision. The organisation must define ownership across data authority, business context, control and model economics, and name the executive accountable for the combined result.
The architecture should then implement that accountability across the existing estate, using vendor capabilities where they meet the requirement and retaining enterprise responsibility where they do not.
This does not require an enterprise wide redesign before further AI work can proceed. It requires a clear target state and a disciplined sequence. Select the highest value use cases, identify the foundations they share, and fund those foundations as reusable enterprise capability. Each new initiative should begin from a stronger base than the last rather than recreating the same data, control and context work.
The Decision Is Architectural,
Not Technological
The relevant executive question is not whether the organisation should be more or less ambitious about AI. It is whether the architecture, governance and accountability required to deliver that ambition have been established. If the answer is no, adding use cases will expand the portfolio without increasing the organisation's ability to scale it.
AI ambition should set the direction. Architecture should make that direction executable. Where ambition has moved ahead, the next phase of investment should close the gap between them. Until it does, enterprise AI will remain dependent on local workarounds, manual control and repeated foundation work, regardless of the capability of the models being deployed.
The next investment decision should strengthen the operating foundations shared by the portfolio,
not add another isolated use case.
The organisations that establish data authority, business context, control and model economics as enterprise capability will scale their AI ambition. The organisations that fund another isolated use case will fund the same foundation work again.
Decision Inc. is an advisory-led cloud & AI partner that works with over 300 organisations annually to build and scale enterprise data platforms across financial services, retail, telecoms, manufacturing and the public sector.
Book an Architecture Diagnostic
Test your organisation's readiness against the four questions and identify the architectural gap the next phase of investment should close.