Here are six cyber/governance considerations that leaders should consider about model locations, data access, tool permissions, costs, resilience and runtime security

Enterprises in the Asia Pacific region (APAC) are moving AI from experimentation into production, and that shift is creating a governance problem that goes well beyond model quality.

The real challenge is how to manage multiple models, multiple environments and multiple toolchains without losing control over security, cost and data handling.

According to Mohan Veloo, Field CTO (Asia Pacific, China and Japan), F5, AI security now has to move closer to runtime, where the context of each prompt, API call and agent action can actually be assessed. “Static security will not work for this,” he told CybersecAsia.net, arguing that security needs to understand what is being sent to the model, what is coming back, which APIs are being called and whether that behavior is allowed.

Veloo also believes that “the real problem is that companies are moving fast on AI adoption without putting governance in place first. They are pushing AI into production before they have full visibility.”

These views are directionally useful. However, they remain one vendor’s interpretation of a broader market shift rather than settled fact. Let us examine the regional landscape and use these opinions as a starting point for deriving useful strategies that C-level leaders can apply.

A more distributed AI stack

The most realistic enterprise pattern is not a clean switch from public models to local ones. It is a hybrid stack that mixes frontier models for harder reasoning, smaller models for routine tasks, and private or local deployments for sensitive workloads. That makes AI less like a single application choice and more like a distributed operating model.

For APAC executives, the key point is that model selection is becoming a policy decision. Teams now have to decide not just what model to use, but where inference runs, which data can flow into it, and what happens when the preferred service is unavailable.

Veloo is on firm ground when he says the attack surface extends beyond the model itself. Once AI systems can query databases, call APIs, retrieve documents or trigger downstream actions, they become part of a connected workflow rather than a standalone chatbot. That creates exposure to prompt injection, insecure tool use, leakage of proprietary data and accidental execution of unauthorized actions.

The practical answer is not to treat the model as a trusted decision-maker. Enterprises need least-privilege access, strict tool permissions, explicit approval for high-impact actions, audit logs and separation between trusted instructions and untrusted content. Red-teaming should also include indirect prompt injection and agent misuse, not just model jailbreaks.

Governance, not just routing

The AI runtime is increasingly where risk, usage and policy need to be evaluated, because the relevant context includes prompts, data sources, API calls and resulting actions. The strategic point is that routing and policy need to be managed consistently across a growing model estate.

If developers hard-code model choices into application logic, every change becomes a rebuild. That is inefficient, and it also makes it harder to shift workloads for cost, compliance or resilience reasons. A better approach is to separate policy from application code so that organizations can change models, regions or tools without redesigning every workflow.

That said, the centralized control plane favored by Veloo is only one option. Alternatives include cloud-native policy controls; API gateways; identity and access management; service meshes; dedicated AI security tooling and workflow approval layers.

Different enterprises will be wise to combine various approaches depending on their specific regulatory exposure, hosting model and internal maturity.

What leaders should ask

• C-level teams should start with a few basic questions:
• Where are our models running?
• Which data classes are allowed into which systems?
• Who can approve tool use and downstream actions?
• What are the rate limits, fallback paths and spend controls?
• Have we tested what happens when an AI workflow is manipulated or overloaded?

The answers matter because AI risk is no longer confined to the model layer. It now includes identity, data flow, observability, budget discipline and operational resilience. The organizations that handle this well will not necessarily be the ones with the biggest models. They will be the ones with the clearest policy, the tightest controls and the most adaptable architecture.

Strategic takeaway

Veloo’s arguments are useful insofar as they highlight the operational burden created by distributed inference and runtime AI risk.

However, the broader lesson for APAC executives is bigger than one vendor’s architecture pitch. The real question is how to build an AI operating model that can support hybrid deployment, contain security risk and keep governance intact as models, tools and regulations continue to change.

The overarching viewpoint should not be that enterprises must adopt a specific platform or the solutions it pitches. Rather, AI governance now has to reach beyond the model itself and into the connected workflow around it.