When you ask Southeast Asian technology leaders what worries them about AI, the first word you hear is often governance. Not reliability or cost.
Yadi Narayana, Datadog’s field chief technology officer for Asia-Pacific and Japan, is not surprised. He says it comes up first almost everywhere. “It’s the default mindset of trying to have some sort of ability to give that response back to auditors,” he adds.
Governance covers two different things. The first is a policy, an owner and a paper trail for the regulator. The second is an operational control plane: the permissions, approvals, rollback procedures and telemetry that decide what a system may do at 3 a.m., when nobody is watching.
ASEAN is buying the first and calling it the second. Narayana will not describe the region as a single AI market, because operational maturity differs sharply between countries, but the same confusion turns up in all of them.
Narayana traces the reflex to how AI arrived in these companies. The programs came down from the board, he explains, so the people handed them reach first for a control they can show upward. He has argued elsewhere that visibility alone does not create trust. A policy document creates even less.
The difference starts to matter as soon as somebody asks what the AI actually achieved.
The metric almost nobody has
Ask an enterprise how much AI it uses and the numbers come fast: seats, prompts, tokens, and dollars. Ask whether any of it worked and the room goes quiet.
“I think most of them have that kind of visibility,” Narayana says. “But I think the most important question, in my view, is did the AI actually improve the outcome they were looking for.”
He lists the checks that rarely exist. Did the developers write better code? Did the number of incidents fall, when those incidents were the original problem? Did rework go down? Did reliability improve, or did the system create a new risk instead?
“The question should not be, how much AI we are using,” Narayana says. “It should be, is the AI really producing safe and useful and cost effective work for me?”
His point is not that seats and tokens are the wrong numbers. They are simply the only numbers most companies have. His replacement metric is one line long: cost per successful outcome.
He also admits the metric is hard to measure, which vendors rarely do. “Now, again, how do we measure [cost per successful outcome]?” he says. “That’s a different challenge by itself.”
So where does a company start? Narayana agrees that success has to be defined before a program begins, not after it, and goes back one step further, to why the program started at all. Was this something a board mandated, or something the business needed? Locking the right use case, in his framing, comes before any metric.
Only then does it make sense to name the outcome for each function: a resolved ticket, an accepted pull request, a closed claim, an approved loan, or whatever unit the business already argues about at quarter end. Choose the unit, then price it.
Skip that step and a second cost appears: visibility dies at the handoff. An agent writes code, drafts a fix, or summarizes a case. The work then passes into a human process, and from that point nobody can trace what the agent contributed.
The money leaves through the middle
An agent’s contribution is hard to trace because production AI has more moving parts than most dashboards were built to watch. Datadog’s State of AI Engineering 2026 found 69% of companies running three or more models. Its analysis of customer traces in February 2026 showed that 5% of LLM call spans returned an error, and 60% of those errors came from exceeded rate limits. Adoption of agent frameworks doubled in a year. The data comes from Datadog’s own customers, so the real figures across the market are probably higher.
The model layer is the easy part to watch. Response time, token counts and error rates already sit on somebody’s dashboard. Narayana places the operational risk one level above that, in orchestration and in the handoffs between agents. Why did the system choose model two over model one? Why did it retry? Why did latency triple on Tuesday?
“The question should not be, how much AI we are using. It should be, is the AI really producing safe and useful and cost-effective work for me?” — Yadi Narayana @ Datadog
Retries are where budgets quietly die. A request times out, hits a rate limit, or fails a tool call. Every attempt spends tokens, adds delay and writes more logs. Datadog’s own report describes how framework code adds steps, retries and branches beneath the surface, until engineers can no longer see what happens while the system runs. The report gives no figure for how much of a company’s spend those retries consume. Neither does anyone else, which is why the number has to come from a company’s own telemetry.
Those logs are the part CDOs own, and the ownership is worth claiming. Production AI generates far more operational data than ordinary software: prompts, responses, traces, tool calls, retries, model errors and security events. Teams need it to debug problems and explain how a system behaved, which Narayana calls non-negotiable, but storing all of it forever is expensive and creates compliance problems of its own. He calls both instincts anti-patterns: storing everything, and cutting visibility blindly to save money.
What remains is a four-part decision Narayana sets out plainly. What gets retained, what gets sampled, what gets redacted, and where the data has to sit physically. Datadog’s answer at DASH in June 2026 was Bring Your Own Cloud for logs, which indexes data inside the customer’s own storage. Underneath that launch sits a quieter admission: AI now generates more evidence than most companies can afford to keep.
Where paperwork governance stops working
The gap between the two kinds of governance is widest in security. A policy can name an owner and write a rule. It cannot see what an agent did on its fourth step. Narayana says security is only now arriving as a serious concern, because teams are realizing that AI needs a different kind of protection from the systems they are used to.
The threat rarely arrives as a hostile prompt. It usually arrives inside something the agent reads: a document, a support ticket, or its own stored memory.
“The first action might look absolutely harmless. The second might look normal,” Narayana says. “But after several steps, the agent might access the wrong data or trigger the wrong workflow.”
Older security thinking assumes a boundary around the system. “I can put a security camera outside and observe, but that’s not how AI systems behave,” he says.
None of this is new, he argues. No responsible company gave automation tools unlimited access to production on the first day of cloud. Those teams wrote rules, set permissions and kept rollback plans, and AI needs the same discipline. So he raises an agent’s autonomy in stages instead of granting it at once. First, let agents investigate and recommend, and do nothing else. Second, allow actions that a human approves before they run. Third, and only then, allow the agent to act on its own, and only on low-risk tasks that can be reversed.
The line that matters most runs between what an agent may recommend and what it may execute. An agent might be allowed to suggest restarting a service, Narayana says, but it should not restart that service by itself unless a human is present.
Every stage needs the same controls around it: a named owner, permissions set at the tool and API level, approval steps for high-risk actions, audit trails, a rollback plan, rate limits, and a way to switch the agent off.
“Give an agent enough context to be useful,” Narayana says, “but not unlimited authority to start with.” The goal, in his words, is a trusted operational control plane around AI, so that autonomous systems can investigate, triage and act safely. That is the second kind of governance, built rather than written.
Singapore has begun building one at scale. GovTech is creating a registry of AI agents for roughly 150,000 public officers, recording which agents are in use and who owns them, and blocking them from deleting files or emailing people outside government. Narayana points to it as his example, because it sets ownership, permissions and limits on what an agent may touch, rather than describing them in a document.
The questions that have no owner yet
Agents do not stay in one place, which is why Narayana says they should not be treated as point solutions. Push them across a live workflow and they expose process that three decades of building wrappers on top of wrappers had kept out of sight. Much of it turns out to be redundant.
The same thing happens to the checks a company relies on. Narayana offers a deliberately basic example. If AI now generates all of a company’s code, who does the code review?
“Give an agent enough context to be useful, but not unlimited authority to start with.” — Yadi Narayana @ Datadog
The old answer was another developer, and it worked because a human wrote the first draft and a colleague checked the reasoning behind it. Neither condition holds now. Reviewers face volume no team was staffed for, and the work they are checking cannot explain its own reasoning. Human review is still the answer. What nobody has settled is who does it, at what depth, and with what evidence in front of them.
Narayana does not pretend to have solved it. “I don’t have a definitive answer,” he says. His point is the layer, not the answer. “When we start getting into this mode, we need to think about every layer,” he says, and he suspects the missing layer sits above the CTO, where a company decides what it actually wants from AI before anyone maps it to technology.
Three moves before the next steering committee
The code review question will not be settled in a policy document. Neither will the question of who decides what a company actually wants from AI. What can be settled now is smaller and more concrete, and each of the three moves below needs an owner before the meeting ends.
Start with the handoff, the point where the trail goes cold. Trace one agent action all the way through to the business record that closes it: the ticket marked resolved, the pull request merged, or the claim paid out. One complete trace is the difference between counting what AI did and knowing what it finished. It is also the precondition for any cost per successful outcome, because a company cannot price work it cannot follow. Give this to the team that runs the AI platform.
Then measure retries. Nobody publishes a benchmark, so stop waiting for one. For each workflow, measure how many of its requests are retries, and track that figure for a month. This needs no definition of success, so it can run before the first move is finished, and it produces a number the industry does not have. Give it to whoever owns the AI budget, because that person has to explain the bill.
Then settle the retention rule. Retain, sample, redact, reside. Writing the rule is the easy part. Naming the person who signs it is the work, and that signature belongs to the CDO. If nobody owns the rule, the decision still gets made, by default, on storage cost alone.
Narayana’s warning concerns the shape of the cost curve more than the size of the bill. Adopt first and govern later, as companies did with cloud, and the line does not stay straight. “The cost of this mistake would be exponential,” he says. “It’s not even flatter or predictable.”
Governance answers to the auditor. Observability answers to reality. ASEAN, right now, is much better at the first.
Image credit: iStockphoto/Deagreez