DPIA — Governed LINE-group full-thread memory (ADR-0143 Phase 3)
- Status: DRAFT — NOT signed off. Sign-off is a hard prerequisite for any Phase-3 build that stores group messages (ADR-0143 §D1). Engineering-supplied baseline; DPO + counsel must adjust + decide the open residuals (R1, R10).
- Date: 2026-06-23
- Reviewer: DPO + external counsel (pending)
- Sign-off required before: ADR-0143 §D1 implementation (group-message storage). The 1:1 channels (ADR-0140) are out of scope — covered by the conversation DPIA.
- Regulatory frame: PDPA TH §19 (consent), §24 (lawful basis), §26 (sensitive data), §28 (cross-border), §33 (erasure), §37/§39 (security + RoPA); GDPR Art 35 for any EU-resident members.
- Scope: the opt-in full-thread memory of a LINE group the tenant’s bot has been added to — i.e. storing all group messages (not just bot-addressed ones) to power summarization, search, and task extraction. The lighter mention-gated mode is lower-risk and partially covered here by contrast.
- Next review: on sign-off + annually, or sooner on any §6 trigger.
1. Description of processing
Section titled “1. Description of processing”DPO to confirm before sign-off. Engineering factual baseline below.
1.1 Nature of processing
Section titled “1.1 Nature of processing”- A tenant admin adds the tenant’s LINE bot to their own LINE group and opts in (records consent). Until opt-in, no group messages are stored (storage defaults OFF).
- Once opted in, the bot receives the group’s message webhook stream and stores messages (text; slip/doc images via the ADR-0043 pipeline) in D1/R2 under a tenant + group prefix, to power: on-demand thread summarization, KB-grounded Q&A, and action-item/task extraction.
- PII detectable on ingest (Thai national ID, phone, card number) is redacted before storage where the feature permits. Summaries are generated by Anthropic Haiku 4.5 under the Zero Data Retention contract; inputs are not retained by Anthropic.
- Bounded retention per group (conservative default, admin-configurable) with a hard-delete cron. Per-group + per-member §33 erasure.
1.2 Scope
Section titled “1.2 Scope”- Geographies: Thailand primary; group members may be EU/ASEAN. PDPA TH governs the tenant relationship; GDPR governs any EU-resident member.
- Audience (OPEN — ADR-0143 Q2): internal team groups (staff) vs customer-facing groups (external data subjects). The lawful-basis analysis differs materially between the two — this DPIA cannot be finalised until the audience is fixed.
- Volumes: engineering to fill once a design partner is live.
- Retention: conservative default (proposed 30–90 days), admin-configurable to a plan ceiling; hard-delete cron enforces it.
1.3 Categories of personal data
Section titled “1.3 Categories of personal data”- Identifiable: LINE group id, member user ids + display names, the full text of group messages (open-ended — may contain any personal data members type), attached images (slips, documents, faces).
- Special-category (§26 / GDPR Art 9): plausibly present and unsolicited — health, financial (payment slips), national ID numbers, possibly religious/political in free conversation. We cannot prevent members typing it.
1.4 Categories of data subjects
Section titled “1.4 Categories of data subjects”- Group members — the load-bearing concern: most did not individually consent; only the admin opted in.
- Tenant agents/admins (covered under their employment/contractor agreement).
1.5 Sub-processors
Section titled “1.5 Sub-processors”| Processor | Purpose | Data | Region |
|---|---|---|---|
| Cloudflare D1 / R2 / KV | message + summary store, slip images | message text, images, metadata | Singapore (APAC) |
| Cloudflare Workers AI | PII redaction / classifier (transient) | text + image bytes (transient) | global edge |
| Anthropic (via AI Gateway, ZDR) | summarization + Q&A + task extraction | text (transient) | US (EU optional) |
| EasySlip / SlipOK (if 3c enabled) | payment-slip verification | slip image + parsed fields | Thailand |
| Sentry | error monitoring | metadata only (content scrubbed) | EU + US |
2. Necessity & proportionality
Section titled “2. Necessity & proportionality”2.1 Lawful basis (the crux — needs counsel)
Section titled “2.1 Lawful basis (the crux — needs counsel)”- Admin consent (§19) authorises the tenant↔Puccha processing and the bot’s presence.
- Group members are separate data subjects. Thai PDPA prefers consent from each data subject. In a group, that is impractical; the realistic bases are (a) the controller-tenant’s legitimate interest (§24(5)) in running its own group with member-facing transparency (the bot’s on-join notice + opt-out), and/or (b) member consent inferred from continued participation after notice. Both are contestable. Counsel must decide whether full-thread storage of non-consenting members’ messages is defensible, or whether the mention-gated mode must be the default for customer-facing groups (internal staff groups have a stronger legitimate-interest + employment basis).
- §26 sensitive data: no reliable lawful basis for storing members’ unsolicited sensitive data → mitigated by redaction-on-ingest + retention limits + the option to disable storage; residual risk R1.
2.2 Necessity
Section titled “2.2 Necessity”- Full-thread memory is necessary for the headline value (summarize a real thread, recall past decisions, extract tasks) — the JTBD that mention-gating cannot deliver (ADR-0143 §D1).
2.3 Proportionality
Section titled “2.3 Proportionality”- Storage is off by default, opt-in only, retention-bounded, redacted on ingest, per-group/member erasable, and a mention-gated alternative exists for privacy-strict groups. These keep an inherently broad collection as proportionate as the JTBD allows — but proportionality of storing non-consenting members’ messages is the open question (R1/R10).
3. Risks identified
Section titled “3. Risks identified”| # | Risk | Likelihood | Impact | Mitigation | Residual |
|---|---|---|---|---|---|
| R1 | Storing non-consenting group members’ personal/sensitive data without a valid lawful basis | Medium | High | Opt-in + on-join transparency notice + member opt-out; redaction-on-ingest; retention limits; mention-gated mode for customer-facing groups; counsel to fix the basis per audience | OPEN — blocks sign-off until counsel decides |
| R2 | Cross-tenant leak (group A’s store readable by tenant B; bot answers from wrong KB) | Low | High | Tenant-scoped queries (P0 invariant), group↔tenant binding, cross-tenant test | Low |
| R3 | Sub-processor breach leaks stored thread | Low | Critical | Encryption at rest, breach SLA + 72h notification, incident runbook | Low |
| R4 | Sensitive data (ID, slip, health) persisted in plaintext thread store | Medium | High | PII redaction on ingest; slip data via vendor not stored raw; retention TTL; erasure | Medium |
| R5 | Retention creep / indefinite memory | Medium | Medium | Conservative default + hard-delete cron (non-removable); admin sees retention setting | Low |
| R6 | Member exercises §33 erasure but residue remains (summaries, backups, LLM) | Medium | High | Per-member erasure cascades to messages + redacts summaries; ZDR = no LLM residue; backup tombstoning per ADR-0053 | Medium |
| R7 | Secondary use / function creep (memory mined beyond stated purpose) | Low | Medium | Purpose-limit in tenant DPA; no model training on data; access audit-logged | Low |
| R8 | Admin opts in without authority to consent for the group | Medium | Medium | DPA warrants the admin has authority; on-join notice gives members opt-out; audit of consent record | Medium |
| R9 | Cross-border transfer (§28) of member data | Low (with SCCs) | Medium | DPA SCCs; APAC storage; ZDR LLM; residency-strict tenants → Thai-hosted model option (deferred) | Low |
| R10 | Member-consent validity (members unaware / didn’t read notice / minors) | Medium | Medium | On-join notice TH/EN, opt-out command, no minor targeting (cannot verify); tenant declares audience in DPA | Medium — accept only with counsel |
4. Consultation
Section titled “4. Consultation”- Engineering: ADR-0143 author (this DPIA accompanies it).
- Security: threat-model review TODO (new group-storage surface; pen-test scope to include the group webhook + store).
- DPO + Counsel: pending — must resolve R1 + R10 and fix the per-audience lawful basis before sign-off.
5. Conclusion (provisional)
Section titled “5. Conclusion (provisional)”NOT cleared. Phase-3 §D1 (full-thread storage) must not ship to prod until:
- Counsel fixes the lawful basis (R1) for storing non-consenting members’ messages, per audience — likely: legitimate-interest + transparency for internal groups; mention-gated default (or stronger member-consent UX) for customer-facing groups.
- The mitigations are implemented and verified: storage-off-by-default + opt-in, on-join transparency notice + opt-out, redaction-on-ingest, retention default + hard-delete cron, per-group/member erasure, tenant isolation test.
- DPO sign-off recorded.
Until then, only the mention-gated mode (no full-thread storage; transient on-demand summarization of explicitly-addressed content) carries a low-enough residual to consider an earlier, narrower pilot — subject to counsel agreeing even that is in scope.
6. Review schedule
Section titled “6. Review schedule”- On sign-off, then every 12 months, or sooner on: audience change, sub-processor change, lawful-basis change, retention change, or any breach.
Appendix — Open decisions blocking sign-off
Section titled “Appendix — Open decisions blocking sign-off”- Audience (ADR-0143 Q2) — fixes the lawful-basis path.
- R1 lawful basis for non-consenting members — counsel.
- Retention default number.
- Redaction coverage — which detectors are mandatory pre-storage.
- Member-notification + opt-out UX wording (TH/EN).
Addendum — Mention-gated Q&A storage tier (ADR-0149, 2026-06-27)
Section titled “Addendum — Mention-gated Q&A storage tier (ADR-0149, 2026-06-27)”The body of this DPIA assesses full-thread memory (storing the entire group stream), which stays blocked on R1.
ADR-0149 introduces a narrower, intermediate tier that is now shipped in code: only the bot-directed turns of an opted-in group are stored (the asker’s question + the bot’s answer), routed through the shared 1:1 core so they appear in the inbox/tickets/customers. No message from a member who did not address the bot is ever read or stored.
- Why this differs from the R1 blocker: R1 concerns storing non-consenting members’ messages. This tier stores only messages whose author explicitly addressed the bot (trigger word or @mention) in a group an admin opted in — i.e. two layers of explicit, per-interaction intent, analogous to the 1:1 lawful basis already accepted. Ambient/non-consenting members’ data is excluded by construction.
- Data minimisation: the asker’s question + the asker’s LINE display name (for support attribution — the name they already show in the group) + the bot answer. No ambient capture; consent + redaction/retention controls from
line_groupsapply. The display name is covered by the same per-interaction consent basis (the asker chose to address the bot). - Transparency: the on-join notice now states plainly that only questions sent to the bot are recorded for support; other group messages are not stored.
Status: pending counsel sign-off of this addendum. Engineering has shipped the capability behind the existing per-group consent gate; legal confirmation of the lawful basis for this specific tier is the outstanding gate (lighter than the full-thread R1 question). If counsel rejects it, the revert is mechanical (route the consented question back to a stateless reply).