Thailand's PDPA (Personal Data Protection Act B.E. 2562 / 2019) requires data processors to implement "appropriate technical safeguards" for personal data, but does not specify particular encryption methods. AES-256 is a symmetric cipher approved by the U.S. federal government, FIPS 197, and ISO/IEC 18033-3, and is widely adopted in practice as the baseline for "appropriate measures." This article is intended for IT and development teams operating AI products at Thai local entities, and provides an end-to-end overview of AES-256 implementation patterns for PDPA compliance—from selecting what to encrypt through key management and audit readiness. A separate article covers the overall PDPA compliance checklist (consent acquisition, DPO appointment, cross-border transfers, etc.); this article focuses exclusively on the technical implementation layer.

Under Thailand's PDPA, data controllers are required to implement appropriate technical and organizational security measures to prevent the loss, unauthorized access, use, alteration, or disclosure of personal data. Since no specific encryption algorithm is prescribed in the statutory text, the adoption of AES-256 should be understood as a practical implementation choice.

Reading the PDPA's statutory language reveals many abstract provisions, making it difficult to determine exactly what must be implemented to achieve compliance. This section clarifies the PDPA's requirements, the positioning of AES-256 within that framework, and the division of scope between this article and existing PDPA compliance checklist articles.

Thailand PDPA Section 37(1) obliges Data Controllers to "implement appropriate technical and organizational security measures to prevent the loss, unauthorized access, use, alteration, or disclosure of personal data." The structure of this provision is broadly equivalent to EU GDPR Article 32, and since full enforcement, guidelines issued by Thailand's PDPC (Personal Data Protection Committee) have listed encryption, pseudonymization, and access control as "expected measures."

Violations may give rise to statutory penalties, administrative actions, and civil remedies respectively. The specific caps and statutory classifications should be confirmed against the latest version of the legislation before being cited.

AI systems handle large volumes of personal data, and sensitive personal data in particular—such as health information, beliefs, and biometric data—is subject to strict additional protections under Section 26.

In practice, what constitutes "appropriate technical safeguards" depends on industry standards. International standards such as ISO/IEC 27001, ISO/IEC 29100, and controls from NIST SP 800-53 are commonly referenced, and AES-256 is positioned as a recommended algorithm across all of these standards.

The rationale for adopting AES-256 as an "appropriate measure" is supported by multiple official endorsements. AES-256 is standardized under NIST FIPS 197 and is treated as an algorithm suitable for protection up to the Top Secret level under the NSA's CNSA Suite, making it straightforward to justify in practice. That said, demonstrating its adequacy in a PDPA audit requires a comprehensive explanation that encompasses the threat model, key management, access controls, and audit trails. AES is a symmetric block cipher standardized under NIST FIPS 197 and is widely referenced in international standards. When citing specific standards, the applicable version and official status should be verified and stated accordingly.

Cloud KMS and TLS 1.3 are useful mechanisms underpinning current standard cryptographic operations. However, since TLS 1.3 cipher suites and the default behavior of each cloud KMS vary by service, the latest specifications from each vendor should be confirmed at the time of adoption. While the Thai PDPC has not issued guidelines specific to AES-256, alignment with international standards makes it easier to explain the choice as a "reasonable decision" during an audit.

Conversely, adopting legacy ciphers other than AES (such as DES, 3DES, or RC4) or proprietary in-house encryption significantly raises the burden of proving "appropriateness" in an audit. The primary practical advantage of choosing AES-256 is that it minimizes the need to justify the selection decision.

PDPA compliance must advance on two fronts—technical and organizational—and combining both in a single article reduces the depth of coverage for each. This article focuses on the technical implementation layer, specifically encryption and key management. Organizational and contractual considerations are addressed in a separate article; however, notification workflows and responsibility allocation should be reviewed and updated regularly in line with the latest PDPA operational practices.

This article focuses on the technical implementation layer not covered there—specifically encryption and key management. The two articles are intended to be used together: development teams that have first established their organizational framework using the checklist article, and are left with the implementation of "technical safeguards" as an outstanding task, can turn to this article at that stage.

The recommended reading flow is as follows. In the early phase of launching a PDPA compliance project, refer to the checklist article to put the DPO and contract templates in place. When the development team is ready to begin concrete encryption implementation, return to this article. Once the technical implementation is complete, revisit the checklist to verify the continuity of organizational operations—this back-and-forth approach reflects practical reality.

In AI systems, personal data can be present in prompts, responses, logs, embedding vectors, and training data. Therefore, the system must be designed with separate storage, access controls, and retention periods for each layer. Whether encryption is required should be determined by balancing searchability and audit requirements.

The misconception that "we only send data to an external LLM via API, so encryption in our own DB is unnecessary" is a typical PDPA violation pattern. The following organizes the four AI-specific layers into two H3 sections based on data characteristics.

Users often write personal data into AI system prompts without realizing it. Inputs such as "My name is [X], and last month I was told [Y] at a health checkup. How should I interpret this data?" occur routinely in AI usage scenarios. If prompts are stored in plaintext in a database, that entire database falls under PDPA governance.

The response side similarly has the potential to reproduce personal data. When using RAG (Retrieval-Augmented Generation), internal documents—such as performance reviews, customer lists, and medical records—are returned as search results, meaning the response text itself may contain personal data. If responses are stored as conversation history, that storage location also becomes subject to encryption requirements.

Log files are an easy oversight. It is common practice to output prompts and responses to plaintext logs for debugging purposes and retain them for months or even years. Logs tend to "grow unnoticed, with vague deletion policies," making them a typical data breach vector in PDPA violations. It is advisable to encrypt logs according to their sensitivity level, establish a retention period policy, and properly delete logs once they are no longer needed. Retention periods must be aligned with business requirements and any statutory retention obligations.

Embedding vectors stored in vector databases (such as Pinecone, Supabase pgvector, and Chroma) carry the risk of allowing partial reconstruction of the original text. Therefore, when sensitive information is involved, the storage approach must be carefully designed. Balancing this against search requirements, the recommended approach is to combine encryption, access controls, and retention period management.

Conversation history (chat history) varies widely in retention period—from a few hours to several years depending on the product—but to satisfy PDPA retention limitations (deletion after the purpose is fulfilled), a design that incorporates both encryption and a deletion policy is necessary. For Postgres, the pgcrypto extension; for MySQL, InnoDB TDE; and for NoSQL, KMS integration options represent the standard patterns.

Training data (fine-tuning corpora, RAG documents) is the highest-risk category, as it frequently contains large volumes of business data. Training data should be designed so that it is "decrypted only at runtime," remaining encrypted at rest under normal conditions. When decrypting during a cloud-based training job, it is important to verify that no data has been left behind in temporary storage (e.g., /tmp) and to include post-job cleanup in the scope of auditing.

AES-256 does not become secure simply by "choosing the algorithm name." Confidentiality and integrity are only guaranteed when the three elements—mode, initialization vector (IV), and authentication tag—are correctly combined. An incorrect selection during implementation can result in AES-256 being used in a way that is effectively no different from plaintext.

In practice, the most frequently encountered questions concern choosing between GCM and CBC, and ensuring consistency between data in transit and data at rest. Each of these is addressed in the two H3 sections below.

Multiple block cipher modes are defined for AES, but for new implementations, adopting an AEAD mode such as GCM is generally recommended as a baseline. Depending on the environment, other AEAD schemes may be more appropriate, so the selection should be made taking into account performance requirements and compatibility with existing assets. GCM is an AEAD (Authenticated Encryption with Associated Data) scheme that generates an authentication tag simultaneously with encryption. This allows tampering with the ciphertext to be detected at the decryption stage.

CBC (Cipher Block Chaining) mode has historically been widely used, but since it lacks an authentication function, tampering cannot be detected without separately appending an HMAC. Using GCM leaves less room for implementation errors than building a CBC + HMAC combination from scratch. Unless compatibility with an existing legacy system is required, there is little reason to adopt CBC for new implementations.

The biggest pitfall when using GCM is IV (initialization vector, nonce) reuse. Encrypting two plaintexts with the same key and the same IV creates a critical vulnerability in which the plaintexts can be recovered via XOR relationships. In implementation, always generate the IV using a cryptographically secure random number generator, and follow counter management practices to avoid reuse with the same key, or adhere to the recommended patterns of dedicated libraries (e.g., Node.js crypto.createCipheriv, Python cryptography.hazmat).

To ensure encryption throughout the entire data lifecycle, you need to cover both data in transit and data at rest. Implementing only one side will inevitably create a gap where plaintext is exposed.

For data in transit, use TLS 1.3 as the baseline, and select cipher suites according to your environment and vendor configuration policies. AES-256-GCM is a strong candidate, but should not be treated as the universal default for TLS 1.3 as a whole. Configure CDNs and reverse proxies to permit only TLS 1.3 + AES-256-GCM, and disable TLS 1.2 and below, as well as legacy ciphers such as RC4 and 3DES.

For data at rest, apply AES-256 across all three layers: database column encryption (Postgres pgcrypto, MySQL InnoDB TDE, SQL Server Always Encrypted), file storage encryption (AWS S3 SSE-KMS, Google Cloud Storage CMEK, Azure Storage CMK), and backup encryption (KMS-integrated snapshots).

Logs, temporary files, and development environment dumps are easy to overlook. When copying a production DB to a development environment, regularly review whether data is being stored in an unencrypted state. What PDPA audits examine is not "encryption by design" but "whether encryption is maintained in actual operations."

The practical security of AES-256 is determined almost entirely by key management, not the algorithm itself. The moment you store keys in plaintext in a code repository or configuration file, even the strongest encryption becomes meaningless. Combining KMS, HSM, and tenant isolation is the baseline in modern practice.

Three decision axes are critical when designing key management: which service to use (KMS / HSM), how to handle rotation, and how to enforce isolation in a multi-tenant environment.

In cloud environments, the standard approach is to use a key management service (KMS) — such as AWS KMS, Google Cloud KMS, or Azure Key Vault — as the first choice. A KMS controls key generation, storage, and usage via API, enabling encryption and decryption without ever handling plaintext keys in application code. Because KMS internally implements what is known as "envelope encryption" (a two-tier structure in which a Key Encryption Key (KEK) encrypts a Data Encryption Key (DEK)), it is well-suited to balancing both performance and security.

An HSM (Hardware Security Module) is a mechanism that protects keys within a dedicated hardware boundary. When adopting one, you need to verify on a per-product basis whether it is compliant with FIPS 140-2 or FIPS 140-3. HSMs may be a regulatory requirement for financial institutions, healthcare organizations, and government projects, but HSM usage is not a mandatory requirement under Thailand's PDPA alone.

As a practical guideline: KMS is sufficient for general AI products; HSM should be considered when handling sensitive personal data (health, beliefs, biometrics, etc.) or when industry regulations such as those in finance or healthcare also apply. HSMs are available through AWS CloudHSM and Azure Dedicated HSM, but operational costs are one to two orders of magnitude higher than KMS, so the decision should be weighed against business requirements.

Key rotation is an essential operational practice for limiting the damage in the event of a key compromise. AWS KMS and Google Cloud KMS both offer key rotation functionality, which can be enabled according to your operational design. Rotation intervals vary by service and key type, so configure them in accordance with the latest specifications of the cloud provider you use. You should also prepare procedures for immediate manual rotation in the event of a suspected compromise.

Key separation is a design principle of using different keys for different purposes and environments. For example, issue separate keys for "DB column encryption," "log encryption," and "API token encryption," and use different keys across production, staging, and development environments. This way, if one key is compromised, the blast radius remains limited.

Another practical technique is key hierarchization. Store the master key (KEK) within KMS, and have the application temporarily retrieve and use the Data Encryption Key (DEK). By structuring DEK handling through the KMS Encrypt/Decrypt API via the KEK, the DEK does not linger in memory for extended periods, making it less likely to be exposed even in the event of a core dump or memory dump.

When seriously designing PDPA compliance for a multi-tenant SaaS, "per-tenant key management" — where each tenant holds its own independent key — is strongly recommended. This avoids the worst-case scenario where a single key compromise exposes all tenants.

In AWS KMS, a design that uses a separate Customer Managed Key (CMK) per tenant is a strong approach. The choice between a single key, environment-specific keys, or per-tenant keys should be made with cost and operational overhead in mind.

Each tenant's DB rows are encrypted with a DEK that has been envelope-encrypted using that tenant's CMK. If code attempting to decrypt Tenant A's data mistakenly accesses Tenant B's data, it will be unable to decrypt it because it cannot invoke the correct CMK.

For multi-tenant infrastructure based on PostgreSQL, combining Row-Level Security (RLS) with encryption is a strong design approach. If you are using Supabase, you should verify the current permission model and available encryption options before finalizing your design. Implementation costs are higher than with RLS alone, but this provides a powerful basis for demonstrating the "adequacy of technical safeguards" under PDPA.

In projects that have implemented AES-256, failures flagged during PDPA audits tend to concentrate on "operational gaps" rather than algorithm selection. The three most common patterns are: plaintext backups, data leakage via third-party SaaS, and inadequate audit logs.

These issues are difficult to spot during the technology selection phase and are often discovered only after operations have begun. The following two H3 sections summarize common failures and key points for audit readiness.

Even when a production DB is encrypted with AES-256, it is surprisingly common for backup pathways to remain in plaintext. SQL files exported via pg_dump, CSV exports stored locally on a weekly basis, snapshots copied to development environments for QA validation — if these "derived data" assets are not encrypted, the encryption of the production environment loses half its value. Use KMS-integrated snapshot features and ensure that dump files are also encrypted with AES-256.

Data leakage via third-party SaaS is another typical blind spot. In many cases, prompts and responses flow in plaintext to error monitoring tools (Sentry), APM solutions (Datadog, New Relic), and product analytics platforms (Mixpanel, Amplitude). While these services encrypt data on their end, the critical question is "who holds the keys." Rather than relying solely on SSE (server-side encryption), consider CSE (client-side encryption), and adopt a pattern where PII is masked or hashed at the application layer before transmission.

Implementing a shared library that "strips PII before sending to external SaaS" and routing all telemetry through it creates a system that prevents leakage even without requiring individual developers to think about it.

What PDPA audits examine is not only "is data currently encrypted?" but also "is encryption being continuously maintained in operations?" The foundation for this is audit logs and periodic reviews.

KMS usage logs are recorded in AWS CloudTrail or Google Cloud Audit Logs. Set up alerts for key usage frequency, access during unusual hours, and calls from IAM roles that differ from the norm. In AI products, development teams are prone to anti-patterns such as temporarily "passing keys via environment variables instead of through KMS," and regularly reviewing logs for such traces makes it easier to catch issues before they escalate.

For annual reviews, set a minimum baseline of five items: an inventory of data subject to encryption, key rotation history, the encryption status of backup pathways, updates to third-party SaaS encryption policies, and alignment with updated guidelines from the PDPC. In addition, operation logs related to responses to PDPA data subject rights (disclosure requests and deletion requests) should be retained at the same level as encrypted data. In most cases, audits can be navigated successfully if evidence trails exist — and those trails themselves serve as the visible proof of PDPA compliance.

The following addresses frequently asked questions from development teams regarding AES-256 and PDPA implementation — all points where a lack of awareness can lead to significant rework.

Q1: Does implementing AES-256 fully satisfy PDPA's technical protection measures? Not entirely. AES-256 is merely the baseline for encryption; it only constitutes "appropriate measures" when combined with other layers such as access control (RBAC/IAM), audit logs, data classification, deletion policies, and employee training. PDPA does not require encryption alone — it examines the entire data protection framework comprehensively.

Q2: Is AES-128 insufficient for PDPA requirements? AES-128 is also a FIPS 197-approved algorithm and is accepted under many regulations. AES-256 has an advantage over AES-128 in terms of "resistance to future cryptanalysis," but at present, either is likely to be judged as an "appropriate measure" for PDPA compliance. If an existing system uses AES-128 and the cost of replacement is high, continuing its use is a reasonable decision. For new implementations, choosing AES-256 is the safer approach.

Q3: If TDE (Transparent Data Encryption) is enabled on an existing DB, is additional implementation unnecessary? TDE is effective for "protection against physical disk theft," but since it decrypts transparently for users with SQL access, it does not prevent leakage from insider threats or SQL injection attacks. For sensitive columns, layering column-level encryption (pgcrypto, application-layer encryption) on top of TDE is an implementation that is easier to explain during a PDPA audit.

Q4: Should quantum-resistant cryptography be considered right now? Practical attacks on AES-256 by quantum computers have not yet materialized. NIST has published quantum-resistant cryptography standards (ML-KEM, ML-DSA), but these are primarily focused on replacing public-key cryptography (RSA, ECDH); symmetric encryption such as AES is considered safe for the foreseeable future by maintaining a key length of 256 bits. Only when handling long-term retention data (10 years or more) should a future re-encryption plan be considered.

As the core measure for satisfying Thailand PDPA's "appropriate technical protection measures," AES-256 is the most straightforward choice to justify in practice. However, simply "using AES-256" is not enough to pass an audit on its own. Only by designing all of the following as an integrated whole does a PDPA-compliant technical foundation emerge: the scope of encryption (four layers: prompts, responses, vectors, and training data), mode selection (GCM as the first choice), key management (KMS, tenant isolation, rotation), protection against leakage via backups and SaaS, and audit logs with ongoing reviews.

This article has focused on the technical implementation layer, but PDPA compliance must be advanced in tandem with organizational measures. Organizational and contractual matters — such as consent acquisition, DPO appointment, cross-border transfer agreements, and handling requests from data subjects — are covered in our "Thailand PDPA Compliance Checklist for Balancing Compliance and AI Utilization." Governance design for AI systems as a whole is addressed in "What Is AI Governance? A Practical Guide from EU AI Act Compliance to Internal Rule Development," and general security risks are covered in "Latest Trends in AI Cybersecurity" — please refer to these as well.

The next action is to take inventory of the data handled by your AI product across four layers (prompts, responses, vectors, and training data) and map the current encryption status of each layer. Once the gaps are made visible, implementation priorities will naturally become clear.