If an AI agent changes an order based on outdated inventory data, it may efficiently execute the wrong decision. If other systems then treat that change as reliable information, the consequences of the mistake will spread. The scope of AI autonomy should therefore grow in line with data quality and the company’s ability to control the consequences of its actions.
This relationship is examined in Closing the data architecture gap: The path to autonomous advantage, a report prepared by the IBM Institute for Business Value in collaboration with Oracle. The report was published on 2 October 2026. It combines an assessment of data environments, an analysis of governance and security, a comparison of more and less advanced organizations, and an action plan for leadership.
Its central argument concerns the order in which capabilities develop: expanding autonomy requires preparing the data, permissions, and ways of responding to errors. The survey findings support this argument, although their scope is narrower than some of the authors’ strategic claims. For smaller businesses, it will be particularly useful to distinguish the principles worth retaining from the scale of investment, which needs to fit their own capabilities.
Data must be sufficient to carry out an action
Agentic AI here means systems that decide on and carry out successive actions using the tools available to them. An agent can retrieve information, choose the next step, and trigger a change in another system. Its degree of autonomy depends on the permissions it has been granted and the rules for oversight.
IBM and Oracle describe a shift from architecture designed for analysis to architecture that supports execution. In an analytical setting, a person could spot a discrepancy between a report and the actual situation. With automated action, that same discrepancy must be detected early enough, or its consequences contained. The freshness of information, consistency of definitions, and ability to check where data comes from become important.
The report’s empirical basis is a cross-sectional survey conducted by IBM IBV in collaboration with Oxford Economics among 1000 executives across 14 geographies and 21 industries. Respondents had to be familiar with the use of AI in their own organizations and involved in decisions about data and technology. In this group, 53% felt that their current data architecture did not support agentic AI at scale. Nearly 60% reported a need to correct agents’ actions manually.
Further figures help explain the source of the difficulties. The report states that only 28% of agent actions in production environments were supported by real-time data. The denominator here is actions, and the method of aggregating them across organizations was not disclosed. Meanwhile, 35% of organizations had a layer establishing a shared meaning for terms in the data. These two findings concern different aspects of readiness: the freshness of information and consistency in how it is interpreted.
A simple situation illustrates this: the status “closed” in one system means that order processing is complete, while in another it means that an individual ticket has been resolved. An agent that treats both labels as equivalent may take the wrong action even with instant access to data. Aligning meanings is therefore part of preparing the process, just as ensuring that information is sufficiently up to date is. Simply connecting the systems does not solve both problems.
Oversight helps define the boundaries of autonomy
The next part of the report describes how errors accumulate. An agent may correctly execute an instruction based on a flawed premise and pass the result on. In the survey, 57% of executives reported agent errors arising from earlier data inconsistencies. The authors link this to the need for oversight covering the entire course of an action, from input information to its consequences.
This is the intended role of governance: rules for accountability, data quality, access, auditing, and the escalation of problems. The report treats these as part of the infrastructure that enables greater autonomy. A company must be able to establish the basis on which an agent acted, who is responsible for the data it uses, and when an action should be stopped or handed over to a person.
The gap between the stated need and available capabilities is clear. In the figure on governance, 77% of executives identify real-time monitoring, together with the ability to trace data provenance, as necessary for the safe use of agentic AI. Yet 39% of organizations report having a mechanism in production that makes it possible to trace an AI decision back to its source data — referred to as lineage. A record of system messages can help with error analysis; on its own, however, it does not provide that link.
In the section on security, the authors identify four related capabilities: shared identity and access controls, monitoring of activity with an audit trail, mechanisms to stop actions and contain damage, and consistent management of these safeguards. The practical purpose of this structure is clear: before an agent is granted broader permissions, the company should be able to detect an error and prevent its further consequences.
It is also worth noting that security, privacy, and compliance were cited as barriers more often by the survey’s leader group than by respondents overall: 78% and 62%, respectively. The authors interpret this as greater risk awareness in more advanced organizations. These percentages describe perceived barriers, not the frequency of incidents.
The leaders’ advantage is clear, but its cause calls for a more cautious assessment
IBM and Oracle introduce the concept of an agent viability frontier — a conceptual boundary marking readiness for agents to act reliably. On one side, they place fragmented data, frequent interventions, and accumulating errors; on the other, consistent data, effective oversight, and the ability to expand autonomy. This is a useful conceptual model. The report provides no numerical threshold beyond which a company would have verified readiness.
The comparison of organizations is based on an index comprising five equally weighted dimensions: agentic AI adoption, data and cloud modernization, data architecture modernization, data reliability, and the intensity of autonomous activity. The leaders therefore form a group with a more advanced profile of adoption and supporting infrastructure. The study design itself does not isolate the influence of architecture from the other elements of that profile.
In its figure on business outcomes, the report compares nine areas: revenue, decision-making, manual work, accuracy, innovation, customer experience, process efficiency, productivity, and costs. In all of them, leaders more frequently report a beneficial impact from agentic AI. Three examples show the scale of the differences:
| Reported impact of agentic AI | Architecture leaders | Other respondents |
|---|---|---|
| Increasing revenue growth | 91% | 32% |
| Reducing manual work | 95% | 40% |
| Reducing operating costs | 93% | 43% |
Source: the IBM and Oracle report, Figure 4 on p. 15. These are the percentages of respondents reporting an impact in each area. 91% does not mean 91% revenue growth, and 93% does not mean a 93% reduction in costs. For revenue, the report describes a moderate to high impact; for the other items, the figure does not provide the full response scale or the threshold for inclusion.
In the methodology section, the authors stipulate that the results represent reported practices and statistical associations, not causal relationships. This matters when assessing the report’s stronger claim about an advantage arising from the sequence of investments. A cross-sectional study cannot establish how much of the difference comes from data modernization and how much from skills, management, the choice of use cases, or available funding. The report provides neither a separate measurement of the impact of spending nor audited financial results for these groups.
These data provide grounds for treating data preparation and governance as part of an investment in agents. They are not sufficient to promise a particular return after buying a platform or carrying out modernization. The nature of the publication is also worth bearing in mind: its authors represent IBM and Oracle, and the document also describes their partnership and services. This is a reason to distinguish carefully between research findings and vendor recommendations, without automatically dismissing the observations presented.
The bank case shows the scope of the change, but not its full cost breakdown
The only extended example in the report concerns Taiwan Business Bank. Working with IBM, the bank modernized its core infrastructure, data synchronization across platforms, and access to customer information. The program also included cloud backups and rules for AI governance — from data preparation to compliance and model control.
According to the report, the time required to access data on a customer’s contribution to the bank’s financial results fell from a full day to seconds, while loan application assessment time dropped by 40%. The customer case study published by IBM specifies that the latter result concerns the Enjoy e-Loan service. This is a vendor’s account of a program encompassing multiple changes. It provides no budget, total cost, team size, or measurement that would isolate the effect of autonomous agents from the effects of modernization.
The example shows a connection between improving access to data and changing how work is done. Its usefulness as a financial benchmark is limited. Taiwan Business Bank serves small and medium-sized enterprises, but the case describes an implementation at a bank, not at a typical small business.
The leadership action plan connects technology with accountability
The report places these recommendations in the context of expectations of growing autonomy. It cites a forecast under which agents would handle 23% of routine enterprise tasks by 2028 and 38% by 2030. These figures come from separate, unpublished IBM IBV data collected from 2500 executives in August 2026, not from the main survey of 1000 people. They describe expectations; the report does not provide the full methodology for this additional dataset.
The proposed action plan has two horizons: the next 90 days and capability building over 12 months. The board is expected to treat modernization as a business priority, assign accountability, and link funding to measurable improvements in readiness. Technology leaders are expected to identify the workflows most exposed to errors caused by data delays and fragmentation, then modernize the infrastructure supporting them. Those responsible for data and AI are expected to ensure shared definitions, quality control, and the ability to trace data provenance.
The security component covers permissions, boundaries of autonomy, monitoring, and escalation thresholds. Those responsible for workflows, in turn, are expected to redesign processes, assign owners, and establish how exceptions, rollbacks, and failures will be handled. The report distributes these responsibilities among leadership roles; it does not set out a plan to hire five new executives.
The common thread in these recommendations is to make further deployments conditional on improvements in data reliability and control. The stated periods are planning horizons, not a promise of a return in 90 days or of completing the entire transformation in a year.
Commentary for smaller businesses: a scope that fits the money and time available
For a smaller business, I would suggest starting with a process where it can identify the data involved, the cost of handling the work, and the consequences of an error. This allows the investment decision to be tied to actual work that needs improving. The scope of the solution should also depend on the availability of people to maintain it and the ability to restrict permissions safely.
Applying the report’s findings in this way requires a change of scale. The IBM and Oracle study does not disclose the distribution of company sizes, establish that it is representative of Polish SMEs, or provide implementation costs for them. Useful context comes from the OECD’s 2025 report AI adoption by small and medium-sized enterprises. It identifies four groups of conditions for adoption: connectivity, resources such as data and computing power, skills, and financing. Needs also depend on the company’s digital maturity, the complexity of the use case, and the breadth of its use.
The options below are my own proposals for different resource situations, based on this analysis:
| Company situation | Possible scope of use | Investment and feasibility requirements |
|---|---|---|
| Limited funds, little time for technical work, fragmented data | A ready-made feature that helps draft a reply based on verified documents, with employee review before it is sent | A tool fee, if required, plus time to organize materials, learn, and check results. Someone must be able to assess the reply. The benefit depends on how much work remains after a draft is generated. |
| Well-organized data in one system, a process owner, and available integration support | One workflow: access current data, prepare an action for approval, and possibly carry out actions independently where the consequences are minor and reversible | The cost of connecting systems, configuring permissions, logging activity, and testing, plus ongoing service costs. The process owner must have time to assess results and handle exceptions; access to data and a way to stop the action must be ensured. |
| A small, skilled technical team, valuable data of its own, and funding for maintenance | A tailored agent for a selected business function, with tools suited to its work | Development work, data preparation, integrations, safeguards, and repeated quality assessments. The budget must also cover service usage, changes to systems, and handling errors after launch. |
Headcount alone does not define the limits of what is possible. The OECD describes a B2B wholesale microbusiness in Tokyo that uses its own agents for questions and answers, negotiation support, and multilingual communication. This is an example of a functionally focused application, with no disclosed budget, team size, or independent measurement of outcomes. It illustrates a possible class of solution, not a cost estimate for another microbusiness.
In each of these situations, I would suggest limiting data preparation to the dependencies of the selected process, provided it can genuinely be isolated. Updating the company’s entire environment may be unnecessary for a tool that supports one task. At the same time, a narrow interface does not guarantee narrow risk: changing an order can affect inventory, billing, and customer communication. These dependencies need to be identified before write permissions are granted.
Similarly, the requirement for up-to-date information should follow from the consequences of the action. Answering a question based on an approved document and changing an order require different kinds of information checks. The report does not specify a single acceptable delay for all processes. Proportionality here means matching controls to the use case while retaining the ability to detect and stop an error.
Cost calculations should cover completing a case correctly
The price of a license or model usage is only part of the investment. A company also pays for data preparation, integration, training, quality assessment, exception handling, and maintenance. The OECD notes that small businesses find it harder to take employees away from revenue-generating work for training. A project may therefore fit the purchasing budget while still exceeding the team’s available time.
In a small organization, one person may be responsible for several of the functions described in the report, and some technical work can be outsourced. Even in that arrangement, it is necessary to establish who assesses data accuracy, who resolves exceptions, and who can stop the process. Combining responsibilities or buying support does not automatically increase the time available to carry them out.
Choosing a simpler solution can reduce the scope of development. OpenAI’s A practical guide to building agents allows for standard rule-based automation where it is sufficient, as well as starting with a single agent equipped with tools. It also describes model selection through assessments of quality, latency, and cost. This is design guidance from a vendor, not quantitative evidence of savings for SMEs. It does, however, justify a question worth asking before investing: how simple can the solution be while still doing the required work correctly?
When evaluating a pilot, I would suggest measuring the time from the start of a case to its correct completion, the work involved in corrections and exceptions, the cost per case handled, and the consequences of errors. Generating a reply faster may not shorten the whole process if an employee has to spend a long time checking it. Only this kind of calculation makes it possible to compare the benefit with the money and time the company actually commits.
Autonomy should grow in line with the ability to sustain it
The IBM and Oracle report convincingly sets out the relationships between data, governance, and the ability to expand what agents do. Its survey data show clear differences between organizational profiles. The limits of the study, however, require those differences to be kept separate from promises of modernization’s causal impact on financial results.
For smaller businesses, this points to the possibility of gradually expanding use cases in line with the data, money, and staff time available. A well-isolated process may justify a narrower investment, and human oversight may remain a permanent part of the solution. It makes sense to grant further autonomy when the company can show that the current level works correctly, delivers benefits after full costs are accounted for, and can be sustained with the resources available.
