Companies have been quick to adopt AI models, assistants and agents, but are much slower to change the way their entire organisation operates. The more they try to automate, the clearer it becomes that the biggest obstacle is not the quality of the algorithms, but the chaos surrounding processes, data, applications and responsibilities.
According to a McKinsey survey, 88 per cent of organisations regularly use AI in at least one business function, but only around a third have begun to scale up their programmes. A mere 39 per cent of respondents recognise the impact of AI on the organisation’s overall operating performance. The technology is therefore present, but it still rarely changes a company’s bottom line.
This gap between the availability of AI and its impact on results restores the importance of enterprise architecture. However, this does not mean a return to elaborate diagrams, multi-year plans and committees that spend months approving every change. Companies need architecture as a dynamic decision-making framework: where AI can operate, what data it should use, which systems it should interact with, and who is accountable for the outcome.
An agent is not just another application
A traditional application operates within specific boundaries. It has defined users, functions, input data and rules. An AI agent can independently select tools, analyse information from multiple sources, plan next steps and initiate actions in other systems.
A sales support agent can simultaneously retrieve data from the CRM, check product availability in the ERP, analyse correspondence, create a quote and send it to the customer. From the user’s perspective, it is a single tool. From the company’s perspective, however, it links several systems, sets of permissions, data owners and technology providers.
As the autonomy of AI increases, so does the significance of the boundaries of its operation. An out-of-date record in the CRM, incorrectly assigned permissions or faulty integration are no longer just a local problem within a single system. An agent can carry the error through to subsequent stages of the process and carry out an actual business action based on it.
This is why organisations cannot scale agents without first organising their data architecture and integrations. McKinsey points out that reliable agent systems require high-quality data, a clearly defined source of information, common governance principles, and an architecture capable of handling real-time decisions.
The issue also extends to infrastructure. In a Google Cloud survey, 83 per cent of over 1,400 IT leaders acknowledged that their organisations need to modernise their infrastructure to run production-grade autonomous systems. Existing environments were not designed for software that not only answers questions but also moves autonomously between systems.
For businesses, this means that AI agents cannot simply be added to the existing environment. Without common rules for access, integration, monitoring and accountability, every new project creates another layer of technical debt.
Architecture is making a comeback, but in a new role
Traditional enterprise architecture focused primarily on applications, infrastructure and the target state of the IT environment. In the age of AI, this view is insufficient, as it does not show the entire chain leading from data to business decisions.
A company needs to know not only what systems it has, but also what processes they support, what data they use, which models are employed within them, and who is responsible for the consequences of their operation. It must know the suppliers of individual components, the costs of executing the process, the level of AI autonomy and how to shut down the system in the event of an error.
The unit of design is therefore no longer a single application. It becomes the complete workflow.
This is a fundamental change for the CIO. Until now, it was possible to develop CRM, ERP, analytics and communication tools independently. An agent operating across these systems forces a view of the entire process, as the effectiveness of automation depends on the weakest link in the chain.
McKinsey identifies two paths for change: the gradual integration of agents into the existing architecture, or a broader restructuring of the environment around AI-powered processes. In practice, most companies will need to combine both approaches. They cannot wait for a complete modernisation of their systems, but neither should they connect further agents to every tool without a common plan.
The most sensible solution is domain-based modernisation. A company selects the processes most critical to its bottom line, maps their data, applications, integrations and responsibilities, and then creates an architecture for them that allows AI to be safely implemented.
This approach does not require the replacement of all legacy systems. ERP and CRM systems can still perform transactional functions effectively. However, they must make data and operations available via controlled interfaces that allow the company to specify who — a human, an application or an agent — is authorised to perform a given action.
A company needs a shared platform, not a series of pilot projects
Early AI implementations were usually initiated by individual departments. Marketing would launch a content creation tool, customer service would test a chatbot, and IT would experiment with code generation. On a small scale, this model allows the capabilities of the technology to be tested quickly.
The problem arises when an organisation tries to integrate these tools with its core processes. Each independent project creates its own integrations, authorisation system, monitoring mechanisms and agreements with suppliers. The company ends up funding the same elements repeatedly, yet still lacks control over the whole picture.
The transition from experimentation to scale requires a shared technology layer. This should provide access to approved models, agent identity management, controlled connections to corporate systems, activity logging, response quality assessment and the ability to quickly disable a solution.
A single catalogue of AI applications is also required. Without it, senior management does not know how many agents are operating within the company, what data they use, who owns them, or what risks they pose. However, the register itself will not add value if it is simply another spreadsheet updated once a quarter. It must be linked to the application architecture, data, processes and the risk management system.
A shared platform increases the cost of launching an AI programme, but reduces the cost of each subsequent implementation. It allows the same integrations, security mechanisms and monitoring tools to be reused. As a result, the competitive advantage does not stem from the number of pilot projects launched, but from the speed with which a company can roll out new applications on existing foundations.
An architectural decision becomes a financial decision
The cost of AI is more difficult to calculate than that of a traditional application. It encompasses not only the licence or model usage, but also the cloud, databases, search, integrations, monitoring, security, data storage and team labour.
According to a report by the FinOps Foundation, 98 per cent of organisations surveyed are already managing their AI expenditure, compared with 31 per cent two years earlier. Investments are not limited to the public cloud, but also include SaaS, data centres and private environments.
Without an architecture that links technical resources to business processes, a company cannot determine how much a specific application costs, nor whether its value is growing as quickly as infrastructure consumption. Nor does it know which components are shared and which it is funding multiple times across different projects.
Enterprise architecture, FinOps and investment portfolio management are therefore beginning to form a single system. The choice of model, integration method or data processing location is not purely a technical decision. It affects the unit cost of the process, profit margins, security and the ability to switch providers.
Governance should accelerate, not hinder
Growing regulatory requirements further heighten the need for an up-to-date view of the AI environment. The AI Act, the NIST AI Risk Management Framework and ISO/IEC 42001 base risk management on the continuous identification of systems, their applications, responsibilities and operational impacts. NIST organises this process around four functions: managing, mapping, measuring and responding to risk, whilst ISO/IEC 42001 requires the establishment and continuous improvement of an AI management system.
However, this does not mean that every project should go through a lengthy manual approval process. Such a model would quickly become a bottleneck. In a SAP LeanIX survey, architectural decisions took a month or longer in 51 per cent of organisations.
Effective architecture should not lead to a proliferation of committees. It should establish approved patterns, components and automatically enforced rules. A team can act quickly if it uses an authorised model, the correct data source, standard integration and the required monitoring mechanism.
Governance built into the architecture speeds up deployments, as most decisions have already been made. Control that only comes into play before going live, on the other hand, leads to delays, costly fixes and conflicts between business, IT, security and legal teams.
The CIO becomes the architect of how the company operates
AI means that technological decisions can no longer be separated from organisational ones. Determining which systems an agent has access to is, at the same time, a decision on the division of responsibilities. Setting the level of human oversight changes the course of the process. The choice of data influences the quality of the decision and accountability for its outcome.
The CIO should therefore not start by building an architecture for the entire organisation. Instead, they should select a few processes of greatest significance to revenue, costs or risk, and map out the full chain of operations for them: data, applications, models, suppliers, integrations, permissions, costs and owners.
The board, for its part, need not ask which model has the most parameters. It should know in which processes AI merely advises and in which it performs actions, who is responsible for the outcome, how much the entire process costs, and whether a supplier can be replaced without overhauling the environment.
The most important measure of maturity is not the number of tools implemented. It is the ability to rapidly roll out new applications without a proportional increase in costs, risks and complexity.
Enterprise architecture is therefore making a comeback, but not as technical documentation. It is becoming a system that integrates strategy, processes, data, technology, finance and accountability. Without it, companies will have more and more agents and less and less control over how the business actually operates.
AI does not scale through successive pilot projects, but through an architecture that allows their results to be replicated securely and cost-effectively across the entire organisation.
