Why the distance between a working AI pilot and a production agent is governance, and how TechX closes it on AWS with Xora.

At AWS Cloud Day Vietnam 2026, TechX CEO Ngô Mạnh Hà presented a governed path from enterprise data to agent action on AWS. This article sets out the argument behind that session and explains how TechX puts it into practice with Xora, its Agentic AI Platform.

Migration is done. The pilots worked. Production is still empty.

Many enterprises in Vietnam, and banks and financial institutions in particular, have finished the hard infrastructure work. The landing zone is in place, core workloads run on AWS and a modern data platform is live. On top of that foundation, teams have built retrieval assistants, copilots and demonstration agents, and they have presented them to leadership with good results.

Yet when you ask what actually runs unattended against real customers, real money or real regulators, the answer is usually very little. The pipeline of pilots is full while production remains close to empty. This pattern is not a failure of ambition or of engineering. It points to a specific gap that most modernization programs were never designed to close.

The blocker is almost never the model

Picture a typical production readiness review. The model performs well on its evaluation set, and nobody in the room disputes the quality of its answers. Then the review reaches three questions, and each one comes back without an answer.

Nobody has stated an owner or an authority. The pilot ran on an exported table, and nobody can certify that this table is the system of record for the decision in question.

Nobody can reconstruct what the agent saw. The prompt, the schema and the underlying data all changed during the pilot, and none of them were versioned. When the agent gives a wrong answer, nobody can explain that answer afterwards.

Nobody has defined authority for the action. The agent is technically able to act, but the approval rules, the applicable policy and the evidence required were never specified.

At that point the risk committee stops the project. Engineering did not fail and the model did not fail. The organization simply could not answer the questions that a regulated business must answer before it lets software act on its behalf.

A dashboard has a human in the loop. An agent does not.

Why did data modernization not solve this? The modern data platform was built for a world of dashboards. It provides storage in a lake and a warehouse, a catalog with technical metadata, pipelines with quality checks, and access control with reporting on top. That design is exactly right when a person sits between the data and the decision. An analyst notices that a number looks wrong, knows which source to trust and applies judgment before anything happens.

An agent removes that person from the path. Before an agent may act, it needs four things that a dashboard never had to make explicit. It needs to know which data is authoritative for this specific decision, who owns that data and which policy applies, exactly what it saw, recorded as a versioned artifact, and who approves the action and how the result will be verified.

The gap between data modernization and agentic AI sits precisely where human judgment used to operate without being written down. Closing the gap means turning that judgment into something explicit, recorded and open to review.

Seven things that must point at the same use case

In TechX’s experience, a production agent depends on seven elements, and all seven must refer to the same business use case.

• Business use case: the decision the agent is allowed to support.

• Enterprise data: the sources that this decision genuinely depends on.

• Versioned artifact: the exact shape and snapshot of data that the agent consumed.

• Ownership: a named owner with a stated level of authority.

• Policy: the purpose, sensitivity and regulatory constraints that apply.

• Operational signal: evidence from the running system rather than opinion.

• Human authority: who approves, who can stop the agent and who verifies the outcome.

Most enterprises already hold most of these elements somewhere. The difficulty is that they live in different tools, belong to different teams and are not tied to any single decision. Xora connects them. It does not replace them.

XoraDataOps: start from the use case, not from the data

XoraDataOps turns this principle into a repeatable loop of five steps. The loop begins by identifying which data the use case truly requires, instead of trying to catalog everything first. It then evaluates that data for quality and for whether anyone has the authority to stand behind it. Next it maps the relationships, dependencies and blast radius around the data. It then prepares the data through approved activities that are coordinated with the data owners. Finally it packages the result as a data product with a contract, ready for an agent to consume.

The loop repeats, because data changes, policy changes and use cases change. Four pillars carry the work.

Artifact: what the agent saw, as a version you can open

Every data product has an artifact. The artifact records the sources, fields, filters and snapshot in scope, the stated contract and its version, the owner, the policy tags and the approval state, together with a comparison against the previous version.

Consider a credit limit review. Suppose version 14 of its artifact adds a repayment score calculated over 90 days and removes a regional filter. Both changes are visible, both are approved, and both are tied to the Credit Risk team as the owner. When someone later asks what the agent saw, the answer is a version number. Without an artifact, the honest answer is “we don’t know”, and that answer usually ends the program.

Governance: ownership, authority and policy attached to the data itself

Ownership means a named person or team that is accountable for the data product, rather than a department label. Authority states whether the data is a system of record, a derived copy or a best effort extract, because the agent must know which of these it is holding. Policy records purpose, sensitivity, retention and regulatory constraints, including the obligations under Vietnam’s Law on Personal Data Protection (Law No. 91/2025/QH15), which has been in effect since 1 January 2026.

When these tags travel with the data, the approval conversation stops being a debate and becomes a review.

Relationship: two questions most enterprises cannot answer quickly

The first question looks upstream. If this source is late or wrong, which use cases degrade, and how badly? For an agent that acts without a person checking each step, this blast radius is a measure of risk, not a diagram on a wall.

The second question looks downstream. If this use case goes live tomorrow, is every dependency owned and governed? A single ungoverned dependency is enough to fail the whole review.

XoraDataOps maps these relationships over the catalog, lineage and pipeline metadata that the enterprise already has, so answering them does not require a new documentation project.

Preparation: coordinated work that produces a data product

Every preparation activity is requested against a named use case, agreed with the data owner, executed in the tooling the team already uses, such as AWS Glue, Amazon EMR, Databricks or dbt, and recorded against the artifact version.

The output is a data product that is ready for agents. It has a defined contract and version, a named owner and policy tags, and a dependency map that is kept current. Its state is stated explicitly: approved for this use case.

Day two: a pilot that fails costs a demo. An agent that fails costs customers.

Getting an agent into production is only half of the story. Once an agent is live, it joins your operations. It sits in the incident path, either as the cause of a problem or as a dependency when something else breaks. When an alert fires at two in the morning, the investigation cannot rest on someone’s memory of how the system is wired. It needs service context and operational signals.

Xora Resolve addresses this second half of the journey with investigation grounded in evidence and recovery that stays under human control. It brings together service context, meaning what runs, what it depends on, which data products feed it and who owns each part. It adds operational evidence from the tools the enterprise already runs, including Amazon CloudWatch, application performance monitoring, logs and tickets. From there it forms root cause hypotheses, and each hypothesis must cite the evidence it rests on. If a hypothesis cannot cite its evidence, Xora Resolve does not show it.

Take a payments API whose latency suddenly climbs. Xora Resolve might surface a hypothesis that the FX rate data product has gone stale because an upstream Glue job ran late. The hypothesis links the latency metric in CloudWatch, the delayed job and the snapshot age recorded in the relevant artifact. The platform prepares a recovery action, such as a rollback, and a person approves or rejects it. The platform then checks whether the signal has returned to normal, so the loop is closed rather than assumed.

This is where the two halves connect. The artifacts that XoraDataOps creates before launch become the evidence that Xora Resolve relies on after launch. Throughout both, the platform builds the hypothesis and prepares the action, while authority stays with a person.

How to start: three steps, deliberately small

Discovery, one to two weeks. TechX works with your team on two or three candidate use cases and tests each one against the uncomfortable questions: what data, whose data, what authority and what policy. You leave with a ranked shortlist and an honest picture of readiness.

Assessment, three to four weeks. One use case is taken end to end through XoraDataOps on your own AWS account, using your existing tooling. You leave with a real data product, ready for agents, that your risk team can review.

Design Partner, one quarter. That use case goes into production with Xora Resolve alongside it, and the pattern is built with your team rather than for them. You leave with a repeatable pattern that your people own.

Three things to take with you

The gap is governance, not modeling. It sits exactly where a person’s unwritten judgment used to be.

The unit of work is the data product. It is versioned, owned, tagged with policy and approved for one use case.

Your toolchain stays. Everything runs on the AWS platform and the tools you already have.

“Most organizations do not have an AI problem. They have a question that nobody has answered yet: who stands behind this data, and who approves what the agent does with it. Once that answer is written down and versioned, the risk committee can review instead of refuse,” said Ngô Mạnh Hà, CEO of TechX.

TechX is opening a small number of Design Partner places this quarter, with priority for banking and financial services.