What is preventing promising agentic AI pilots in APAC from becoming dependable, everyday enterprise systems?

“Many pilots are designed to demonstrate capability rather than reliability. They use a narrow workflow, selected data and people who already understand the limitations. That is very different from putting an agent into a live environment where it encounters incomplete information, exceptions and systems that do not always behave as expected.

“The biggest gaps I see are usually around integration, data quality, accountability, and security, rather than the underlying LLM. An agent may perform well on the main workflow, but enterprises also need to know what happens when a source system is unavailable, the data conflicts, a user asks for something outside policy or the agent cannot determine the correct action. Before scaling, the enterprise needs clear boundaries around what the agent can access, decide and change. There should also be strong monitoring, traceability, and a practical way for employees to intervene when required.”

Which use cases are delivering measurable value today? What evidence distinguishes a successful deployment from an impressive demonstration?

“The most successful use cases are generally not the ones trying to automate an entire business function. The best use cases usually solve a defined problem where the inputs, decisions and expected results are reasonably clear. Customer service assistance, IT support, information retrieval, document review, and software development are practical examples.

“In application security, agentic workflows can help teams analyse findings, prioritise risk, propose fixes and validate changes. The value comes from reducing repetitive work while keeping developers or security teams in control of important decisions. Value should be measured by completed outcomes, not the number of agent interactions. Did the process become faster without reducing quality? Did error and escalation rates improve? Was rework reduced?”

What difficulties arise when agents need to work with established systems, fragmented data, and processes designed for people?

“Many established processes work because experienced employees fill in the gaps. They know which system is current, which field cannot be trusted and when the documented process should not be followed literally. Agents do not naturally have that organisational context. They may receive conflicting customer records from 2 systems or encounter an approval rule that exists only in an email thread.

“Even if the model interprets the information correctly, it may not have a dependable way to complete the action across legacy applications. This is why integration work often takes more effort than the AI component itself. Enterprises need to identify authoritative data sources, clarify process ownership and define how the agent should handle missing or conflicting information. There is also a security dimension. Each new connection gives the agent access to another system, identity or dataset. Those connections need to be inventoried and governed like other software dependencies. Otherwise, the agent becomes a new route through which a compromised instruction or account can affect several systems.”

How should enterprises decide whether to adapt an existing workflow for AI agents or redesign the workflow around what agents can do?

“I would start by asking whether the workflow itself is sound. If it consistently delivers the right outcome and has clear controls, the lower-risk approach is usually to introduce the agent in stages. It can begin by gathering information, analysing options, or recommending an action before being authorised to execute it. A redesign makes more sense when the existing process mainly compensates for disconnected systems or inefficient hand-offs. Even then, the workflow should not be built around the strengths or limitations of a single model. Models and platforms will change.

“The business logic, security boundaries, and evidence requirements should remain clearly defined outside the model. The key is to separate assistance from authority. An agent may be effective at collecting information, analysing options, and preparing a recommendation. That does not automatically mean it should approve a payment, modify a customer account, or deploy software without appropriate review.”

What can a use case in one APAC market teach an organisation about expansion into another—and which assumptions are most likely to fail?

“A successful deployment in one market can provide a useful implementation pattern. It can show how the organisation selected the use case, measured value, assigned ownership, handled exceptions and established controls. What should not be copied without validation is the local operating context. Regulatory expectations, data location requirements, cloud adoption, and business processes vary across APAC.

“Even within the same company, one market may rely on highly integrated digital systems while another still depends on manual approvals or older applications. Customer expectations also differ. The way an agent communicates, confirms a decision, or escalates a request may be accepted in one market and viewed as inappropriate in another. Enterprises should therefore reuse the control framework but retest the assumptions. That includes local data, language, permissions, customer interactions, and failure scenarios. Regional scale is achieved through a common foundation with deliberate local adaptation, not by copying one successful pilot everywhere.”

How do differences in language, customer expectations and ways of working affect an agent’s performance across the region?

“Language performance should be evaluated in the actual business process, not through a generic conversation test. An agent may translate accurately but still misunderstand local terminology, product names, or industry specific language. Mixed language conversations are also common across APAC, particularly when technical terms remain in English while the rest of the interaction takes place in another language.

“The different ways of working matter just as much. Some processes depend on formal confirmation and layered approval. Others rely on faster, less formal collaboration. Customer expectations around tone, response detail and escalation can also differ. For high impact use cases, enterprises need local test data and local reviewers. They should examine whether the agent understood the intent, used the correct information, took an appropriate action and communicated it in a way the user expected. In APAC, localisation is an operational and risk exercise. It is not only a language exercise.”

What technical and operational controls must be in place before an agent can take action across systems at scale?

“Identity- Enterprises need to know on whose behalf the agent is operating and whether it uses a shared identity, its own service identity or delegated user access. Least privilege- An agent that prepares an invoice does not necessarily need the authority to approve or pay it. Permissions should be narrow, time-bound where possible and separated by action. Verification- Important actions should be checked against policy, system state and business context before execution. High-impact or irreversible actions should require human approval.

Monitoring and auditability are equally important. The enterprise should be able to reconstruct what the agent received, which systems and tools it used, what it decided and what action was taken. Finally, security testing must cover the complete agentic application, including its code, models, prompts, open-source components, data sources and tool connections. Enterprises should treat agents, MCP tools, models, open-source components, and dependencies as part of the broader AI application lifecycle that requires governance and security testing.”

Beyond time saved, which measures best show whether agentic AI is improving service, resilience or business performance?

“The right measures depend on what the agent is expected to improve. In customer service, enterprises should look beyond response speed to first-contact resolution, repeat contacts, complaints, and whether the customer received the right outcome. For internal operations, completion rates, rework, process failures, and human intervention are more meaningful. Reliability also matters. The agent should handle incomplete information and unavailable systems safely, while allowing the organisation to detect and correct unexpected actions quickly. For software development and security, success means fixing meaningful risks faster, validating changes, and reducing duplicate or low value work for developers. At Black Duck, we similarly focus on combining automation with validation and retaining human approval before source-code changes are merged. Ultimately, enterprises must measure the whole process. Speed is not progress if it creates more errors or work downstream.”

Who should own an agentic AI deployment once it moves beyond the pilot: the technology team, the business unit or a cross-functional group? How should they share responsibility?

“Agentic AI deployments are cross-functional by nature. They affect business processes, customer outcomes, technology architecture, data access, security and compliance. The business unit should remain accountable for the purpose of the deployment and the quality of the outcome. It understands the process, the customer impact and when human judgement is required. The technology team should manage the platform, architecture, integrations and operational reliability.

“Security, privacy, legal and risk teams should establish the boundaries and evidence required for deployment. However, shared responsibility should not mean unclear accountability. There should be a named executive sponsor, a business process owner and a technical service owner. The organisation should also define who can pause the system, approve an expansion, or accept the remaining risk. A cross-functional group works when responsibilities are explicit. It fails when every team participates, but no one is ultimately accountable for the agent’s decisions and impact.”

If you were advising an APAC enterprise planning to scale its first agentic AI deployment, what would you insist it prove before expanding to another team or market?

“Before expanding, I would expect evidence in four areas:

• Value. The deployment should improve a defined business measure after integration, model and oversight costs are included.
• Reliability. The enterprise should test incomplete data, conflicting instructions, system outages and unusual user requests. It needs to understand how the agent behaves outside the normal path.
• Control. Permissions, approvals, monitoring, audit records and human intervention should work in practice. They should not exist only in design documents.
• Portability. Before moving to another APAC market, the enterprise should identify which assumptions depend on local language, regulation, infrastructure and working practices.

“I would also look at software and supply chain visibility. The organisation should know which models, components, tools and external services the agent depends on, because changes or vulnerabilities in any of them can affect the deployment.

“Agentic AI changes the risk discussion because the system is no longer only producing information. It may be selecting tools, accessing data and carrying out actions. That does not mean enterprises should slow experimentation. It means the proof required for production should reflect the impact of those actions.

“A low risk internal assistant does not need the same controls as an agent that can change code, update a customer account or initiate a financial process. Enterprises should use a proportionate approach. Start with narrowly defined authority, observe real behaviour and expand access only when the evidence supports it. Maintain visibility into the models, software components, data and tools behind the agent so that changes can be assessed properly. The focus should not be on deploying the largest number of agents. It should be on deploying agents that produce dependable outcomes and can be trusted within clearly defined limits.”

Kelvin Lim, Head of Security Engineering (APAC) at Black Duck.

Kelvin Lim serves as the head of security engineering for APAC at Black Duck where he leads regional teams of sales engineers and solutions architects in delivering application security solutions to APAC enterprises. He has more than two decades of experience in IT operations, networking, security, application development, cloud computing, and business continuity.

Kelvin brings a unique combination of experience as a leader in both vendor and end-user environments. He previously led pre-sales and consultancy services at leading vendor companies. Kelvin has also served as the global head of IT Infrastructure and Cloud computing for a major financial institution, giving him first-hand knowledge of the challenges that enterprise IT teams face.

Kelvin has an EMBA from Southern Illinois University and an MSc. Nanyang Technological University’s Information Studies and a B.Comm from Curtin University. Kelvin has served as an industry advisor to start-ups as well as an industry mentor for mid-career executives looking to transition into the IT industry.