2026 marks a notable shift in how enterprises in Vietnam need to think about data, cloud infrastructure, and AI.
Where compliance used to focus mainly on protecting personal data and ensuring information security, from 2026 the picture has widened considerably. The Personal Data Protection Law No. 91/2025/QH15 and Decree 356/2025/NĐ-CP take effect on 01/01/2026; the Artificial Intelligence Law No. 134/2025/QH15 takes effect on 01/03/2026; and Decree 142/2026/NĐ-CP guiding the AI Law takes effect on 01/05/2026.
Together with the Data Law No. 60/2024/QH15 and its implementing Decree 165/2025/NĐ-CP - already in force since 2025 - these regulations are gradually forming a new governance framework, one in which data not only needs to be protected, but enterprises must also understand and control how their data is processed, by whom, on which infrastructure, and in service of which AI systems.
For enterprises using cloud infrastructure, GPU Cloud, AI Platforms, or AI-as-a-Service, this is no longer purely a matter for the legal or compliance team. These changes are becoming part of technology architecture decisions.
Data residency is necessary, but not enough
One of the most common questions when enterprises evaluate a cloud provider is: "Is the data stored in Vietnam?"
It's an important question. But in today's cloud and AI landscape, the location of the data center solves only part of the problem.
An AI system can involve source data, prompts, embeddings, a vector database, models, model artifacts, logs, backups, and many other processing components. Data can also pass through technical support systems, monitoring tools, or various third-party service providers throughout its operational lifecycle.
Enterprises therefore need to go beyond "where is the server located?" and be able to answer three questions:
- Storage: Where do the data, backups, logs, datasets, and model artifacts actually reside?
- Control: Who has the right to access data, administer infrastructure, control encryption keys, and decide what the data is used for?
- Jurisdiction: Which legal entity provides and operates the service, and which legal system can exert influence over the provider or the data?
This is not just a theoretical question. A provider with a data center located in Vietnam but that is a subsidiary of a US technology group can still be subject to extraterritorial laws such as the CLOUD Act. Under it, US law-enforcement authorities can request access to data the company holds or controls, regardless of where the data physically resides. In other words, "data located in Vietnam" and "data governed only by Vietnamese law" are two entirely different things. (Learn more about how the CLOUD Act affects businesses in Southeast Asia.
These are also the three layers that distinguish data residency from a broader concept: data sovereignty.
- Data residency tells us where the data is.
- Data sovereignty adds a further question: who actually has the right to control that data?
When data enters AI, the scope of governance changes too
AI makes the data problem considerably more complex.
A set of personal data fed into an AI application is not simply "stored." During operation, that data may be collected, analyzed, turned into embeddings, used for retrieval, fine-tuning, or inference, and used to generate new outputs.
For this reason, the data flow map of an AI system needs to reflect the entire processing chain: where the data comes from, what it is used for, where the workload runs, which models and vector databases are involved in processing it, where logs are stored, whether any cross-border data transfer occurs, and how the data will be edited, extracted, or deleted.
This carries an important implication for enterprises:
Choosing a cloud provider is no longer only a decision about price, performance, and SLA. Cloud infrastructure has become a component of the enterprise's data and AI governance program.
The AI Law adds a new layer of responsibility
Vietnam's Artificial Intelligence Law introduces a risk-based approach to governing AI systems.
This means the compliance question does not end when a model is put into production.
Enterprises need to view AI across its entire lifecycle: defining purpose and risk before deployment; controlling safety, security, and human involvement during deployment; monitoring and maintaining an audit trail in operation; and reassessing whenever the model, data, functionality, or intended use changes significantly.
With Decree 142/2026/NĐ-CP, the AI governance capabilities of the provider and the deploying party also become a factor enterprises need to weigh when choosing a platform.
That does not mean every enterprise is "required to use a Vietnamese cloud," or that every GPU provider automatically bears all the obligations of an AI system provider.
The more important point is to correctly identify the role of each party.
A provider offering only IaaS/GPU plays a different role from one offering a managed AI platform or AI-as-a-Service. As a provider becomes more deeply involved in managing the AI system, the data, or the databases serving the AI, the scope of responsibility, and the information the customer needs to request, changes accordingly.
Enterprises should change how they evaluate Cloud and AI providers
Instead of only asking the provider:
- "Which GPU?"
- "How many tokens per second?"
- "What's the SLA?"
- "Is the data center in Vietnam?"
the Technology, Security, Procurement, and Compliance teams should together add another set of questions:
- How is the data processed?
- Where are datasets, prompts, embeddings, logs, model artifacts, and backups stored and processed?
- Can the AI workload be automatically moved to another region?
- Who has access to the customer's data and environment?
- How much control does the customer have over IAM, network policy, and audit logs?
- Who manages the encryption keys and their lifecycle?
- Are the customer's data or prompts used to improve or train models?
- When the AI model or platform changes, how is the customer notified?
- Can the provider supply the information and logs needed when the enterprise conducts a risk assessment or investigates an incident?
- When the service ends, how can the enterprise export and request deletion of data, model artifacts, and related copies?
These questions turn "data sovereignty" from a relatively abstract concept into criteria that can be verified, written into contracts, and used as evidence.
From Data Sovereignty to Sovereign AI
If data sovereignty is the ability to maintain control over data, then as enterprises begin deploying AI at scale, the scope of sovereignty needs to expand.
It is not only data that must be controlled.
Enterprises also need to understand and control where AI workloads are executed, which models are being used, who can access the models and data, which logs are generated, who controls the encryption keys, and how far AI decisions can be traced.
That is why the concept of Sovereign AI is becoming increasingly important.
And a Sovereign AI Cloud should not be understood simply as "GPUs placed in a data center in Vietnam."
A true Sovereign AI platform needs to support enterprises across at least three layers:
- Residency: The enterprise knows and can determine where its data, AI workloads, backups, logs, and model artifacts are stored or processed.
- Jurisdiction: The enterprise understands the legal entity providing the service, where the infrastructure is operated, and the legal framework governing the service.
- Control: The enterprise retains the ability to govern access rights, encryption keys, network policy, audit logs, the purpose of data use, and the lifecycle of AI workloads.
These three elements form an important principle:
Where data is stored is the starting point. Data sovereignty is the capability to control it. Sovereign AI is how that control capability extends across the entire lifecycle of data, infrastructure, and AI.
Compliance isn't just "meeting the rules" - it's the ability to prove it
From a DPO and Compliance perspective, one of the most important changes is the requirement for accountability.
Having a policy does not necessarily mean an enterprise can prove that the policy is actually being enforced.
For example, if an enterprise commits that data is only processed within a defined scope, it needs the architecture and the logs to prove it.
If an enterprise stipulates that only certain roles may access a dataset or model, the IAM system needs to enforce and record that access.
If an enterprise commits to deleting data when the processing purpose ends, the cloud architecture must enable the enterprise to carry out - and verify - that deletion.
If an AI system requires human oversight, the enterprise needs mechanisms that let a human genuinely review or intervene in the appropriate cases.
So, from 2026 onward, enterprises should not ask their Cloud/AI provider only: "Does your solution meet the compliance requirements?" but rather: "How will you help me prove compliance?"
How GreenNode approaches the Sovereign AI Cloud challenge
This is also how GreenNode views the Sovereign AI Cloud challenge: not merely providing compute capacity but building a platform that lets enterprises maintain control over their data and AI workloads throughout operation.
Under its current direction, GreenNode Sovereign AI Cloud focuses on the three pillars of Residency – Jurisdiction – Control: data and workloads are governed to meet deployment requirements in Vietnam; the infrastructure and operating model sit within the Vietnamese jurisdiction; and customers retain control over their data and encryption keys.
At the AI layer, the platform capabilities and AgentBase are oriented toward supporting governance mechanisms such as consent management, purpose limitation, and human review - helping enterprises build governance requirements directly into the process of developing AI applications.
What GreenNode wants to solve alongside customers is not to replace the enterprise's DPO, Legal, or Security roles. On the contrary, the role of a Sovereign AI Cloud provider is to create the infrastructure layer and technical evidence so that an enterprise's regulatory-compliance commitments can be implemented, verified, and proven in practice.
From 2026 onward: shifting from "Cloud-first" to "Control-first"
Cloud and AI still need to be fast, flexible, and cost-effective.
But in the new legal environment, enterprises need one more criterion: control by design - the ability to control, engineered in from the very start.
That requires the Technology, Security, Data, Legal, Compliance, and Procurement teams to stop evaluating Cloud and AI independently of each other.
A good architecture from 2026 onward doesn't only answer the question:
"Does the system run well?"
It must also answer:
Where is the data? Who can access it? Who is responsible? Which law governs it? What purpose is the AI using the data for? And when a regulator, an auditor, or the customer themselves ask - does the enterprise have the evidence to answer?
That is the moment data sovereignty and Sovereign AI shift from a legal-and-technical concept into a business capability.
And this is only the beginning. In the next installments, GreenNode will go deeper into each layer of this challenge with enterprises - from Sovereign AI Cloud architecture to data and AI governance, to turning legal requirements into controls and evidence that can be deployed in practice.
