The Analysys Mason Index identifies data preparation as the industry’s weakest link: among AI laggards, only 16% show at least moderate maturity in preparing and curating data for AI/ML models, compared with 100% of AI visionaries.
For COOs operating throughout diverse Asian markets in 2027, the implications are concrete. As agentic AI moves from reading data to writing back into operational systems—initiating mid-contract changes across CRM, charging, product catalogue, provisioning, and network layers—each system has a different definition of what constitutes a permissible action.
The risk is not hypothetical: Kore.ai‘s 2026 Agent Productivity Index reports that 72% of enterprises run AI agents under “unmanaged risk”, with 42% reporting revenue losses tied to agent failures.
The failure mode is silent. A network outage is visible immediately; a revenue leak surfaces in the monthly accounts. A semantic divergence — an agent executing a configuration change outside a contract variation window because the definition of that window differs across systems — may not surface for weeks, by which point operational and regulatory consequences can have accumulated unnoticed.
In an exclusive with FutureCOO, Shibu Abraham, vice president and APAC head of AI & Digital for UST, argued that the real bottleneck in data readiness is not the size of the data lake, but cross-domain semantic consistency and constraint-enforcement capability.
Start with the use case, not the data warehouse
Abraham adopts a deliberately demystifying stance on “model-ready datasets”. He does not accept the framing that they are necessarily the weakest link. Instead, he places them on a learning curve that enterprises traverse as they move from generative AI to agentic AI:
“Along the journey, as companies started moving from generative AI to agentic AI, one of the essential learnings was that it’s only as good as your data. A lot of the time, data was broken up.”
His core prescription is counter-intuitive: do not wait.
“There are large, multi-year MDM programmes that companies have undertaken, but that doesn’t mean your agentic AI journey should wait until all the MDM and data models are complete. You can start with the data you have, provided it is sufficient for AI agents to take action.”
This is not a dismissal of data governance; it is a adjustment of sequencing — and the distinction matters. Abraham’s advice applies where a single workflow’s data is internally consistent, even if the enterprise-wide estate is not. Use-case-first works at the scope of one workflow; it is not a licence to bypass MDM where cross-workflow consistency is required.
His method is specific: select a workflow with clear value and a clear business owner, then agree with the process owners what that workflow needs to understand.
“From an entity perspective, if it’s order management or supply chain, what are the 20 or 30 different entities that workflow interacts with? What do those entities mean in business terms? You should agree on what each one means with the process owners.”
“You need to document the definitions with the actual process owners. Then you map those entities to where the data lives.”
The deeper logic is to constrain the agent’s search space. When an agent functions within a well-defined semantic layer, “the agent can ask for and retrieve the right answer through that semantic layer”.
Reusability then becomes the critical lever: well-designed, the next workflow can reuse what’s already been built, and the semantic layer “becomes more mature based on real demand and can also help solidify your data models and MDM strategy”.
Abraham also flags a frequently overlooked cost dimension: “If the data being brought in is wrong, or the retrieval is wrong or ambiguous, you end up wasting tokens and potentially taking the wrong actions. Data retrieval accuracy is an important business control that you should build into this.”
From read permission to write-back governance
On multi-agent workflows — where one agent calls another — Abraham touches the most sensitive question in governance architecture: who owns the permission to act?
He restates a principle: “We always look at deciding what an agent is allowed to do as ideally being a business decision, not an IT decision, because the business knows what the agent is supposed to be doing. The person who owns the outcome of a process should own what an agent may do in that process and those decisions.”
Operationally, he describes a three-layer enforcement architecture.
First, a single policy layer that sits outside the agents and outside the systems. “This is where you check the agent’s actions against what is defined as permissible.”
Second, an agent registry. “Where do you identify each agent? It’s not a single-agent system anymore. It’s a large array of a lot of agents. You need to know what each agent is, its identity, and specifically what the least-privileged access you are giving it is.”
Third, full logging and traceability. “Every action should be logged and traceable. You should always be able to go back and see what the agent did, what it touched and why it did it.”
He issues a specific warning: “One common mistake we see is getting some of these permissions coded or encoded inside systems or prompts. Prompts are instructions. They are not controls, and there’s no guarantee that instructions will be followed 100%.”
On chained execution — a compliance agent, a pricing agent and an execution agent working together in accounts payable — Abraham anchors permission ownership firmly in the business function:
“The entities an agent can interact with and the permissions for each agent should reside with the specific business function, because they understand the intent and extent of each permission. The execution can remain with IT, but the strategy and permissions — what the agent needs to do, who it talks to, whether it needs to interact with each of these systems — belong to the process owners.”
This matters because it directly addresses the accountability question COOs will face. When IT makes permission decisions on the business’s behalf, “when it comes to accountability later, that can become a problem. They could say, ‘We didn’t make that decision from our side.'” Establish alignment of authority and accountability on day one of the agent permission architecture.
An underestimated risk category
A dimension Abraham does not expand upon — but one that COOs in 2027 need to watch — is the causal chain between constraint enforcement failure and semantic divergence.
TechTarget’s September 2026 analysis notes that as enterprise agents move from retrieving information to writing back into system records or triggering transactions, a core question emerges: when records conflict across systems, which record is definitive? An agent “should not decide authority based merely on the last system it queried or the record that appears most complete”.
In practice, authority may exist at the attribute level — the ERP governs billing status, the CRM owns sales preferences, another platform holds the most reliable customer identity. If these attribute-level authority rules are not explicitly encoded, an agent may initiate a contract change using a billing status that has already expired.
The more insidious risk lies in assuming that semantic understanding and constraint evaluation are the same capability. An agent may possess the correct data about a contract variation window (“the window is 30 days”) yet cannot evaluate whether the current constellation of facts satisfies that constraint (“today is day 28 from signature, but there is an unsettled adjustment item — does that adjustment reset the window?”). Execution may still be out of bounds.
Totogi’s Ontology white paper makes the point precisely: “Two operators may both be SID-aligned but implement it completely differently.” Standards describe what entities and interfaces should look like “in a compliance world”, but “they do not themselves encode the movement and dynamic dimensions of a specific operator’s assets”.
Abraham’s advocacy of business-owned permission definition is the governance precondition for addressing this risk. But governance principles alone are insufficient—business rules must be translated into machine-executable constraint forms, documented as the architecture he describes requires, “in a form that a machine can actually enforce”.
Reusable capability
In the latter part of the conversation, Abraham offers a criterion of immense operational value to COOs: “If you’re on your tenth use case and it still takes the same amount of time as your first one, you’re not actually building a reusable capability. You’re just building a portfolio of things in your catalogue.”
He distils reusability into four elements: a common event and data layer (the semantic layer as a repository of business entities, layered upon by each workflow); a shared catalogue of tools that agents can call, reusable by future workflows (“you don’t necessarily need to build a new agent every time”); shared guardrails and evaluations (reusable patterns for testing and monitoring); and a governance review for every new workflow, examining “reusability, value and risk”.
The behavioural implication is directional: “Teams know that if they come with a reusable architecture or workflow, they can get funded faster. That changes how people think. It encourages them to build things that can easily be put into production rather than building everything from scratch.”
The COO’s priority
Abraham returns repeatedly to a single theme: semantic consistency is an operational prerequisite, not an IT project. He notes a quiet shift in team structure to match platform and application teams are becoming more AI-centric, learning to use AI within existing systems — ERP, CRM, supply chain — rather than waiting for replacement.
For COOs operating across multiple Asian markets in 2027, this implies a concrete timetable: the semantic layer cannot wait for the MDM programme to finish.
Start with one cross-domain workflow that has a clear business owner and high friction. Define the 20 to 30 business entities that workflow requires. Agree definitions with process owners. Map entities to where the data resides. Establish a single policy layer and an agent registry. Ensure every action is traceable. Then, when the second workflow arrives, reuse the entities, tools and guardrails built for the first.
If the tenth workflow takes as long to prepare as the first, the semantic layer is not accumulating value. That is a measurable operational indicator — and the core AI readiness signal COOs should track in 2027.
