Formichella & Sritawat - What Your AI Assistant Thinks It Knows About You

Personalization and Thailand’s PDPA

By Formichella & Sritawat

An AI assistant can turn an ordinary conversation into a lasting record of someone’s preferences, habits, or personal circumstances. That ability makes personalization useful. It also creates a privacy question that businesses can miss when they assess only the information submitted to the system: what has the assistant concluded about the person, and how will it use that conclusion later?
 

Consider a customer who asks an assistant to find a restaurant for dinner with a named friend who has a food allergy. The assistant answers the request. It might also retain a summary for future recommendations. If that summary attributes the allergy to the customer, it creates a misleading profile. If it correctly records the friend’s condition, the service may retain health information about someone who has never used it.
 

For businesses deploying AI in Thailand, the movement from conversation to profile deserves its own legal assessment. A product may serve one customer while processing information about several people. The Personal Data Protection Act B.E. 2562 (2019) (PDPA) requires attention to those individuals and to the uses of their information, even when the product presents everything through a single account.

The account holder may not be the data subject
An account gives a service a convenient way to organize interactions. It does not establish that every statement made through that account concerns its owner. A shared device may capture another person’s request. A customer may describe a family member, colleague, or guest. A recommendation may draw on information about someone who is absent from the conversation.
Under Section 6 of the PDPA, identifiability determines whether information is personal data. In the restaurant example, the relevant assessment must therefore consider the friend as well as the customer. The fact that one person supplied the information does not make it exclusively that person’s data.

That distinction affects the legal justification for processing. Section 24(3) concerns necessity for a contract to which the data subject is a party. The customer’s contract cannot automatically justify collecting a friend’s information. Nor does accepting the service’s terms, by itself, establish the friend’s consent.

Section 25 directly addresses collection from someone other than the data subject. Its consent route requires notifying the person without delay and within 30 days of collection, and obtaining that person’s consent. Alternatively, collection must fall within a consent exception under Section 24 or Section 26. The 30-day period governs notification; it does not dispense with consent. For ordinary information such as a booking name, legitimate interests under Section 24(5) may be relevant, but necessity and the balance against the individual’s fundamental rights still require assessment.

A named person’s allergy is health data. Section 26 requires explicit consent unless one of its own exceptions applies. Section 24 grounds, including legitimate interests, cannot substitute for those exceptions. Ordinary restaurant personalization does not itself establish an exception under Section 26. A food preference need not reveal a medical condition, but calling a recorded allergy a preference does not change its character.

The personal or household exemption in Section 4(1) may cover the customer’s own activity. It does not extend to the business’s processing simply because the customer uses the assistant at home.
 

A summary can change the meaning
Personalization often depends on reducing a conversation to information the system can use again. A summary can lose qualifications that mattered in the original exchange. A request for one evening can become an enduring preference. A statement about another person can become an attribute of the account holder.

The resulting record may accurately reflect what the system inferred while misrepresenting the individual. Section 35 requires the controller to keep personal data accurate, current, complete, and non-misleading. Under Section 36, a controller that declines a request to bring data into compliance must record the request and its reasons; the individual can seek an order from the Expert Committee. Attribution and context therefore matter when assessing what a profile conveys about someone.

Retaining an exchange as a record of a request and using a derived profile to shape later services involve distinct uses. Section 21 requires processing according to the purpose notified before or at collection. A different purpose requires notice and consent, unless the PDPA or another law permits it. A later use may fit the original purpose, but technical relevance to a new request does not establish that conclusion.

Suppose the assistant later retrieves the inferred allergy when the customer requests another restaurant. It filters the options and includes an allergy note in a booking sent to an outside provider. A mistaken assumption now shapes the service and reaches another business. Even if the original summary correctly described the friend, using it for the customer’s later booking raises questions about whose information the system is using and why. Section 27 bars use or disclosure without consent unless the data was collected under a Section 24 or Section 26 consent exception. For health data, disclosure requires the relevant person’s explicit consent unless a Section 26 exception applies.

 

A promise about training answers only one question
AI suppliers often distinguish customer use of a service from training the underlying model. That distinction matters, but businesses also need to understand how the product delivers personalization.

A system can retain preferences in a separate database and retrieve them during later interactions without changing the model itself. The Center for Democracy & Technology’s report on AI memory explains this distinction between information stored within a model and memory held separately. A commitment against model training can therefore coexist with persistent customer profiles.
 

Removing an original conversation does not necessarily remove a summary stored elsewhere.Section 33 provides a right to request erasure, destruction, or anonymization on specified grounds, subject to exceptions. Section 37(3) requires a controller to maintain a system for erasing personal data when the retention period ends, when the data is no longer needed for its purpose, or when the data subject requests erasure or withdraws consent. The statutory exceptions permitting continued retention still apply. Those duties require attention to retained profiles as well as source conversations. Deleting a separately stored profile does not inherently require retraining the underlying model; the actual architecture determines the technical task.

Who decides what becomes a profile
A business may purchase an assistant from one supplier while relying on another provider for parts of its operations. The customer sees a single service. Behind the scenes, different parties may decide what information becomes part of a profile, the purposes for which it remains available, and whether another service can use it.

Under Sections 6 and 40, actual decisions and instructions determine the parties’ roles. Section 40 expressly treats a processor that collects, uses, or discloses personal data outside the controller’s instructions as a controller for that processing. Supplying a model or making technical design choices does not, on its own, establish controller status for every activity.

Section 40 also requires an agreement between the controller and processor to govern the processor’s activities in accordance with its statutory duties. An agreement that covers handling conversations but leaves derived profiles unexplained may fail to describe a material part of the service. Where overseas providers participate, their access and use also connect with the issues discussed in Cross-Border Customer Data Under Thailand’s PDPA.

Before launch
In What the EU AI Act does not settle: drafting cautions for a risk-based AI statute, we examined how broad risk standards can leave the operative legal boundary uncertain. Personalization shows why a legal assessment should identify the conduct: creating a record about a person, retrieving it for a later purpose, and disclosing it to another recipient. Each activity provides a factual starting point for the assessment. The PDPA still requires interpretation, but the business can examine a specific use of information against an identified duty.

Adding memory to an existing assistant can change the privacy assessment even where the interface remains familiar. The service now carries information from one interaction to the next. As discussed in Thailand PDPA in Its Second Phase: What Recent Developments Really Indicate, operational accountability requires examining what a business actually does with personal data. For personalization, that includes the profile the system creates and the decisions or disclosures that follow.

A profile can be useful to a product while remaining wrong about an individual. Businesses deploying AI personalization in Thailand face exposure when an unsupported or misleading conclusion shapes a service or travels to another recipient. Reviewing prompts, training policies, or account terms alone can miss that conduct.

For further information on AI services and data protection in Thailand, please contact Formichella & Sritawat.

This article provides general information and commentary based on publicly available materials as of November 5, 2026. It does not constitute legal advice. The application of Thai law depends on the particular facts and processing activities.
© 2026 Formichella & Sritawat. All rights reserved.