AI data governance is the AI risk many companies notice only when it is too late. In the 2025 OWASP list of the top ten risks for applications built on AI language models, sensitive information disclosure ranks second, with an everyday scenario: a user asks the AI a question and receives another person's personal data.
In Vietnam this is also a legal matter: the Personal Data Protection Law has applied since 1 January 2026. Yet AI is still mostly judged by how fluent its answers are. A fluent answer does not show which data the AI read, on whose behalf, or from which version. Most answers are right, so trust grows fast, and the remaining errors look exactly like correct answers: a figure that mixes two branches, a discount from last year's policy, salary information reaching someone outside HR.
A smarter AI is not harder to control; one connected to data without rules is. This article covers the three layers to control, how to set AI data governance by role and purpose, the three risks of leakage, wrong context and overreach, and four management decisions to make before connecting AI to company data.
Three layers to control: the data, how the answer is built, and the action
Every AI answer passes through three layers. Each layer fails in its own way, so each needs its own control. Mixing them up leads to the wrong fix.
1. The data
What the AI can read: documents, sales orders, debts, payroll. The question here is scope and freshness: is it the right data, the current version, and allowed for this person?
2. How the answer is built
How the AI finds the relevant pieces and combines them. Correct data can still produce a wrong answer if the AI joins figures from two departments or two periods.
3. The action
What happens after the answer: someone acts on it, or the AI drafts or records something. This layer belongs to decision rights and approval.
Each ring needs its own control. A good answer in the middle ring does not fix a problem in the outer ring.
This article stays with the first two layers. Limits on action, approval and accountability are the subject of the previous article, When AI gets it wrong, who is accountable?
Common signs: once an AI assistant is connected to sales and accounting data, two directors pull in opposite directions. The sales director wants it to see as much as possible, so salespeople get full answers on prices, stock and customer debt without waiting for accounting. The chief accountant wants cost prices, credit limits and supplier terms seen only by those who need them. Meanwhile the errors look like correct answers: an overdue balance that adds a branch's figures to head office's, a discount scheme already replaced at the start of the year. Both directors are right about what they want. The gap is that nobody has made the AI data governance decision: which data, for whom, from which version.
These two errors sit in different layers. Adding the branch to the head office is a problem in how the answer was built. Quoting the old scheme is a problem in the data. Training staff to "ask more precisely" fixes neither.
The three layers matter less when the AI reads only public material, such as a product catalogue. They matter most where answers go straight into a quote, a payment or a reply to a customer.
Role- and purpose-based access: the core of AI data governance
The first question to ask about any AI assistant is simple: when it reads company data, whose rights does it use? There are two common answers, and they lead to very different risks.
| How the AI reads data | What happens | Risk |
|---|---|---|
| With its own broad account | Anyone who can ask the AI can reach whatever that account can see | A side door around the company's access rules |
| With the rights of the person asking | Each person gets answers only from data they are already allowed to see | The AI is only as tight as the existing access rules |
The OWASP list of top risks for applications built on large language models, maintained by a non-profit security community, advises the same: least-privilege access to sensitive data, the AI acting in the context of the logged-in user, and permissions enforced by the underlying system, not by the AI. In management terms, the AI should get no more data than the employee it is helping.
Role is not enough on its own. Purpose matters too. A salesperson may see a customer's debt to chase payment, but that does not mean they should see every customer's debt, or the debt of customers handled by a colleague. Good AI data governance asks what the data is for, not only who holds the title.
The same question returns different scopes of data depending on who asks and why.
There is a second effect CEOs often miss. An AI that reads with each person's own rights quickly exposes the access rules the company already has. If everyone can see everything, the AI will show it within days, because people now ask questions they never used to look up. The AI does not create the weakness; it makes it visible. So the first step of AI data governance is often a review of existing access rights.
Scattered data makes this harder. When sales keeps one spreadsheet, accounting another and the warehouse a third, the same question already has three answers: three people, three numbers. An AI connected to all three files does not settle which is right. It may produce a fourth. Keeping departments on one shared set of data, with one set of access rules, removes much of the problem before AI arrives. This is not unique to any vendor; most integrated management systems work this way. What matters is whether people actually work on the shared data or keep exporting it into private files.
Three files, three numbers: AI connected to all of them inherits the disagreement.
The trade-off is real. Tighter AI data governance means more answers of "you do not have access", and some staff will be frustrated. That frustration shows where access rules do not fit real work; review the rules rather than bypass them.
AI data governance needs data that is current, correct and traceable
An AI does not know which document is in force unless someone tells it. When it searches company material, it picks the passages that best match the question, not the newest or the approved ones. If last year's discount policy and this year's both sit in the same folder, the AI may quote either, with the same confidence.
The OWASP guidance names this directly: data combined from several sources can contradict itself, and the AI may not let newer information override what it already holds. The US National Institute of Standards and Technology (NIST), in its 2024 profile on generative AI risks, lists "confabulation" as a separate risk: confidently stated but false content that can mislead users. A stale source makes such answers harder to spot, because a real document stands behind them.
Three properties need to travel with the data the AI uses:
- Freshness: when was this figure last updated? Stock and debt read live from transactions differ from a report exported last week.
- Validity: is this document still in force, and has the replaced version been removed or clearly marked?
- Origin: which record or document did the answer come from, so that someone can check it in under a minute?
Data that comes straight from business transactions is fresh by nature: the order, the invoice and the payment are the record. The weak point is documents and files kept outside the system. How to keep procedure documents owned and up to date is covered in the fourth article of this series, If AI learns every process, do you still need your best people?
A policy without an effective date gives the AI no way to tell old from new.
Three risks when AI data governance is loose: leakage, wrong context and overreach
The risks of connecting AI to company data fall into three groups. They have different causes, so they need different controls.
Leakage
The AI gives data to someone who should not see it. OWASP describes a typical case: a user receives another person's personal data in an answer. Cause: the AI reads with broader rights than the person asking.
Wrong context
Correct, permitted data used in the wrong place: a branch's figures in an answer about head office. OWASP warns of context leaking between user groups sharing one data store.
Overreach
The AI can reach or do more than its task needs. OWASP calls this excessive agency: too many functions, too many permissions, too little independent approval.
Same symptom, a wrong answer, but three different causes and three different fixes.
Leakage is the most visible and also a legal matter. In Vietnam, the Personal Data Protection Law (No. 91/2025/QH15) has been in force since 1 January 2026. Data about employees and customers, such as salaries, ID numbers, addresses and health records, is personal data. An AI that hands it to the wrong person is still a disclosure by the company. NIST lists data privacy and information security as two separate risks of generative AI, alongside confabulation; each needs its own check.
Wrong context is the hardest to see, because no rule is broken: every figure was allowed and real. Only someone who knows the business catches it. Overreach links to the action layer, covered in the previous article; for AI data governance the point is narrower: the AI should not hold access "just in case".
Who notices a wrong answer: logs, error rates and refusals
A wrong AI answer looks like a right one, and the person asking is often least able to spot it: they asked because they did not know. So detection has to be designed, like any internal control.
NIST's generative AI profile asks organisations to put post-deployment monitoring plans in place, with ways to capture input from users, handle appeals and overrides, and respond to incidents, and to monitor specifically for confabulation. For a company of a hundred people this does not require a monitoring team. It requires four signals and an owner for each:
| Signal | What it tells you | Who looks at it |
|---|---|---|
| Log: who asked, which data the AI read, what it answered | Lets you trace any complaint back to its source | The person in charge of the AI project, when a case arises |
| Monthly sample check | Error rate on real questions, by area | The owner of each data area: sales, accounting, HR |
| Refusals: "you do not have access" | Whether access rules work, and where they do not fit real work | The person who sets access rights |
| Reports of wrong answers from staff | Errors nobody else would see | The data owner, with a reply to the reporter |
Wrong answers are caught by the people who know the business, if someone gives them the job.
Refusals deserve attention. Zero refusals in a month is not good news; it usually means the AI sees too much. A sudden rise in one department means either the rules are too tight for the work or people are looking outside their role. Both are invisible unless refusals are recorded.
The cheapest habit matters most: every report of a wrong answer gets a reply saying what was fixed. If reports vanish, people stop reporting, and the visible error rate falls while the real one does not.
Convenience versus safety is a choice, not a setting
Every control above costs some convenience: more refusals, someone deciding which documents are old, someone reading the logs. The temptation is to give the AI broad access first and tighten later. In practice, "later" arrives after the first incident.
The way out is AI data governance by data group, sorted by how much a mistake would cost:
| Data group | Examples | Reasonable starting point |
|---|---|---|
| Public or shared internally | Product catalogue, general procedures, holiday schedule | Open widely; check freshness |
| Business-sensitive | Cost prices, margins, credit limits, supplier terms | Only with the rights of the person asking; sample checks monthly |
| Personal data | Salaries, ID numbers, health records, customer contact details | Narrowest access; log every read; legal obligations apply |
The higher the cost of a mistake, the more convenience the company should be willing to give up.
NIST's AI risk management framework makes a point CEOs should hold on to: the qualities of a trustworthy AI system pull against each other, and a system that is inaccurate but secure, private and transparent is still undesirable. Security, accuracy and accountability are three different questions. A single "AI safety score" hides which one is failing.
Four management decisions for AI data governance
Classify data and set access by role
Sort data into a few groups by the cost of a mistake. For each group, decide who may see it and for what purpose. Make the AI read with the rights of the person asking, then review existing rights before switching it on.
Check sources and validity
Every document the AI uses has an owner and an effective date. Replaced versions are removed or clearly marked. Answers show where they came from, so a check takes a minute, not an afternoon.
Limit actions and set approval levels
Give the AI only the access its task needs, never "just in case". Which actions need human approval, and at what threshold, is a decision-rights question covered in the previous article.
Test regularly and watch for errors
Each month, the owner of each data area checks a sample of real answers. Before any change of data or rights, someone tries the sensitive questions with an account that should be refused. Every staff report gets a reply.
The rules for what AI may see are a management decision, not an IT setting.
Points to keep in mind
No system is absolutely safe. Access rules reduce risk; they do not remove it. A permitted answer can still be wrong or be copied elsewhere. Any claim of complete safety should be treated as a warning sign.
One shared data set is a condition, not a guarantee. It removes the problem of three numbers for one question. But if the shared data is wrong, everyone, including the AI, is wrong in the same way and at the same time. Shared data raises the value of keeping it correct.
The references here are frameworks, not measurements. NIST and OWASP describe risks and good practice; they do not measure how often these errors occur in Vietnamese companies, and no reliable public data on that exists yet. The legal point is a summary, not legal advice.
The direction Viindoo has chosen
A fluent assistant can be wrong twice in a row: adding a branch's balance to head office's, then quoting a discount scheme already replaced. Behind the disagreement between sales and accounting lies a question no one had settled: which data, for whom, in which version. The better the AI, the further such mistakes travel, because they are easy to believe.
For Viindoo, AI data governance is not a step added after AI arrives; it is the foundation that comes first. A company can only control its AI once it controls its own data: one version of the truth for every department, and clear rules on who may see what. Viindoo's Agentic AI business management platform starts from exactly there: bring the whole company onto one set of data, then let AI work within the scope the company has set for each person.
Seen through the three layers in this article, that direction answers each one. On data, branch and head office figures, old and new discount schemes, live in one set with clear validity. On the answer, AI works by the principle that it never sees more than the person asking, so cost prices and credit limits stay with those the chief accountant has approved. On action, what AI may do after answering is set by role and approval level, like for any employee.
For the salesperson, this access control is almost invisible: they ask AI as usual and get back exactly the part they are allowed to see, without waiting for accounting. Viindoo is the backbone underneath, so using AI is as easy as asking a colleague while the data stays stable and safe.
No platform is absolutely safe, and none can decide for a company which of its data is sensitive. Classifying data, setting access and reviewing it regularly remain management work.
Four questions to check where you stand
- Which data can our AI see, and whose rights does it use to read it?
- When an answer is wrong, who finds out, how, and how long does it take?
- When a price, policy or procedure changes, how does the AI stop using the old version?
- Has anyone tried asking the AI for salaries or cost prices using an account that should be refused?
Frequently asked questions
It is the set of decisions on which data the AI may read, for whom and for what purpose, how the company knows the data is current, and who checks the answers. It does not need a separate team; it needs data owners and clear access rules.
It depends on where the other answers go. A wrong answer about the holiday schedule costs little; a wrong credit limit or a salary sent to the wrong person costs a lot. Measure accuracy, access and accountability separately, by data group.
Usually not. It turns the AI into a side door around your access rules: anyone who can ask the AI can reach everything that account sees. Security guidance such as OWASP recommends least privilege and acting in the context of the user.
Yes. The Personal Data Protection Law (No. 91/2025/QH15) has applied since 1 January 2026. An AI that discloses employee or customer data to the wrong person is a disclosure by the company. Check specific obligations with a legal specialist.
Next in this series: all of this assumes the company has one AI it can see and govern. What if each employee already uses their own AI tool, with their own copies of company data, outside any rules? One AI per employee: is your company building an invisible operating system?
Sources
- National Institute of Standards and Technology (January 2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1.
- National Institute of Standards and Technology (July 2024). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1.
- OWASP GenAI Security Project (2025). OWASP Top 10 for LLM Applications 2025: LLM02 Sensitive Information Disclosure, LLM06 Excessive Agency, LLM08 Vector and Embedding Weaknesses.
- National Assembly of Vietnam (2025). Personal Data Protection Law No. 91/2025/QH15, in force from 1 January 2026. Summary: Ha Tinh Provincial Portal, 5 January 2026.
