Using AI on your own company data: private and PDPA-safe
Using AI on your own quotes, supplier prices and customer records raises fair questions about privacy. Here is where the data goes and how to keep control.
Key takeaways
- Know the data path. Your database, the snippets drawn from it, what is sent to a model provider per request, and the logs: each deserves a question.
- Ask vendors five things: training use, processing location, retention, access control with an audit trail, and export or deletion.
- Send less. Only the snippets needed for a request, with unnecessary personal data removed, shrinks the risk at the source.
- Two different issues: personal data falls under Thailand's PDPA, while supplier prices and margins are confidential business data. Protect both.
Once a company decides to use AI on its own records, the first question is rarely about features. It is usually this: if we put our quotes, supplier prices and customer details into an AI system, will they leak, or end up training somebody else’s model?
It is a fair worry, and it has a practical answer. This article explains where your data actually goes in an AI application, what to ask any vendor, how to design the system to reduce risk, and how Thailand’s Personal Data Protection Act applies in plain terms. It is general information, not legal advice.
Where your data actually goes in an AI application
“AI” is not one box. In a typical business application built on your own archive, data moves through four places, and each has its own risks.
- Your database. The archive itself: documents, jobs, suppliers, prices, customer records. This is where the master copy lives.
- The snippets. Short, structured extracts from your documents, used so the AI does not have to read raw files each time. Our guide to building an AI knowledge base from invoices and quotes explains why they are useful. They are derived from your data, so they carry the same sensitivity.
- The model provider, per request. When someone asks a question or generates a draft, the relevant snippets and the question are sent to a model run by a provider. This is the step people worry about, and it is also the step you can control most by deciding what to send.
- Logs. Applications record requests, answers and errors. Logs can contain the same sensitive text as the data itself, so they need the same protection and a retention period.
If a vendor cannot walk you through these four places for their own product, treat that as a warning.
Questions to ask any AI vendor
Put these to every provider and developer, in writing, before data goes in.
| Question | What a good answer looks like |
|---|---|
| Is our data used to train models? | A clear “no”, stated in the contract or terms for the exact service you use. |
| Where is it processed and stored? | A named region, and an honest account of any transfer of data to other countries. |
| How long is it retained? | A stated period for requests, outputs and logs, with a way to shorten it. |
| Who can access it? | Role-based access, so staff see only what they need, plus an audit trail of who did what. |
| Can we export and delete it? | Yes, in a usable format, including deletion on request and when the contract ends. |
On location: if personal data is sent to a provider whose servers are outside Thailand, that is a cross-border transfer, and the PDPA sets conditions for it. Ask where processing happens and have your adviser confirm what your situation requires.
Design choices that reduce risk
Many privacy problems are decided by how a system is designed, not which model it uses.
- Send only the snippets needed. A price question needs three or four relevant records, not the whole archive. Less sent means less exposed.
- Strip what you do not need. If the task is estimating a price, the AI does not need a customer’s phone number or a signatory’s name. Remove or mask personal data before it leaves your system.
- Roles and permissions. Sales staff, finance and management usually need different views. Margins may be visible to a few people only.
- Human review. A person checks anything that goes to a customer or changes a record. This protects accuracy and catches accidental disclosure.
- Keep the archive in a database you control. Your records should live in a system you can export from and delete from, not only inside a provider’s tool.
We apply this thinking when we build AI tools on a company’s own archive, as in the Bangkok Productions data platform, where the AI draws on a structured knowledge base of past jobs rather than loose files. This article makes no claims beyond that about how any particular system is secured; always ask your own vendor for specifics.
Thailand’s PDPA in plain terms
The Personal Data Protection Act B.E. 2562 (2019), known as the PDPA, governs how organisations collect, use and disclose personal data. The regulator is the Personal Data Protection Committee. In simple terms:
- Lawful basis. You need a valid reason to handle personal data. That may be consent, a contract, a legal obligation or a legitimate interest, among others.
- Purpose limitation. Collect and use data for stated purposes, and do not quietly reuse it for something unrelated.
- Data subject rights. People can ask what you hold about them and may have rights to access, correct, or request deletion in certain circumstances.
- Security measures. You must protect personal data with appropriate technical and organisational measures. A vendor does not remove that duty from you.
If you collect customer data through LINE, our article on connecting LINE to a CRM, including consent covers the practical side. For any specific question, such as whether your archive needs consent notices or how to handle overseas processing, ask a qualified adviser. The PDPC publishes official guidance and is the authoritative source.
Confidential business data is a separate issue
The PDPA covers personal data. Supplier prices, your margins, client lists and pricing strategy are confidential business information. The PDPA does not cover them, but a leak could still hurt your business badly.
So treat both: apply the PDPA to personal data, and use contracts, access controls and sensible limits on what you send for commercial information. A supplier price list can fall under both categories if it includes named individuals.
A practical checklist before you start
- Map the four places your data goes: database, snippets, model provider, logs.
- Decide which data is personal, which is confidential, and which is neither.
- Get vendor answers on training, location, retention, access, audit trail, export and deletion.
- Remove personal data the task does not need.
- Set roles and permissions, and switch on an audit trail.
- Keep a human review step wherever output reaches a customer.
- Set a retention period for logs and outputs.
- Ask a qualified adviser to check consent, lawful basis and cross-border transfer.
Next step
Start with the checklist, then choose one process to try. If you are unsure which, our guide to which business processes are worth automating with AI helps you rank them. To discuss an AI tool built on your own data, with privacy designed in from the start, look at our web and application projects or contact us and tell us what you hold and what you want to do with it.
Frequently asked questions
Will an AI provider train its models on our company data?
It depends on the provider, the product and the plan, so ask and get the answer in writing. Many business and API arrangements state that customer data is not used for training by default, but check the current terms of the exact service you will use.
Does the PDPA apply if our archive only has company quotes and invoices?
Possibly. Quotes and invoices often contain names, phone numbers, email addresses and signatures of individuals, and those are personal data. Where an archive contains none, the PDPA is less of a concern, but confidentiality still matters.
Is this legal advice?
No. This article is general information. For your own situation, speak to a qualified adviser familiar with Thai data protection law.