If your business operates in Thailand, Saudi Arabia, India, or most of Southeast Asia, you are likely subject to at least one data protection regulation — and possibly several simultaneously. When you connect an AI tool to your customer support inbox, that tool is processing personal data on your behalf. You need to know how.
This checklist is for B2B SMEs evaluating AI support tools. It is not legal advice. Use it as a starting point for your due diligence conversations.
The relevant frameworks
Thailand PDPA (Personal Data Protection Act): Covers all personal data processed about Thai residents. Consent or legitimate interest required. Data subjects have rights to access, correct, and delete.
Saudi Arabia PDPL (Personal Data Protection Law): Covers personal data processed within Saudi Arabia or about Saudi residents. Explicit consent required for sensitive data. Cross-border transfer restrictions apply.
India DPDP (Digital Personal Data Protection Act): Covers personal data of Indian residents. Consent-based framework. Significant penalties for breach.
Singapore PDPA: Consent, purpose limitation, and retention requirements. Generally considered well-established and relatively predictable for compliance planning.
What to ask any AI support vendor
Data storage and residency
- Where is customer data stored? In which cloud region and country?
- Is there an option to restrict storage to a specific region (e.g. Singapore, UAE)?
- Does the vendor offer a Data Processing Agreement (DPA) that specifies residency commitments?
Data retention
- How long is raw email and message content retained?
- Can retention periods be configured per customer or per data type?
- Is there an automated deletion process, or is it manual?
Data access and subprocessors
- Which third parties (subprocessors) process the data? This includes AI model providers.
- Are subprocessors listed in the DPA?
- Are subprocessors themselves subject to the same data residency requirements?
AI model data usage
- Is customer data used to train AI models?
- If so, is this opt-in or opt-out?
- What is the data handling policy for the underlying model provider?
Subject rights
- Can you fulfill a data subject access request (DSAR) — i.e., provide a customer with all data held about them?
- Can you fulfill a deletion request for a specific customer?
- Does the vendor provide tooling to support these requests, or is it a manual process?
Red flags
- No DPA available or unwillingness to sign one
- Vague answers about subprocessors ("we use standard cloud providers")
- No clarity on whether data is used for model training
- No data export or deletion capability
What "compliant" actually means in practice
Compliance is not a binary certification — it's a set of ongoing obligations. A vendor can be "PDPA compliant" in a meaningful sense or in a marketing sense. The questions above will tell you which.
The most important practical step: get a signed DPA that specifies the data types processed, the subprocessors used, the retention periods, and the deletion obligations. Without that document, you have no contractual basis for your compliance posture.