02-347-7730  |  Saeree ERP - ระบบ ERP ครบวงจรสำหรับธุรกิจไทย ติดต่อเรา

Claude ZDR (Zero Data Retention)

Claude ZDR (Zero Data Retention) สำหรับองค์กรไทย
  • 4
  • มิถุนายน

ZDR (Zero Data Retention) = ข้อมูลไม่ถูกเก็บที่ Anthropic หลัง API ตอบกลับ (default คือ 7 วัน) · ต้อง เซ็น signed addendum เพิ่ม · ครอบคลุม Claude API + Claude Code ที่ใช้ commercial org API key · ความเข้าใจผิดที่พบบ่อยคือ "ZDR ทำให้ Claude ลืม" — ไม่ใช่ เพราะ Claude API stateless อยู่แล้วทุก plan ทุก call ต้องส่ง messages history เสมอ ZDR แค่เปลี่ยน "Anthropic เก็บ log นานแค่ไหน" ไม่ใช่ "Claude จำได้ไหม" · Prompt caching ยังใช้ได้ปกติ กับ ZDR · ฝั่ง client ต้องจัดการ conversation state เองอยู่ดี

ZDR คืออะไร — ความหมายและขอบเขต

Zero Data Retention (ZDR) คือข้อตกลงเชิงสัญญาที่ Anthropic ไม่เก็บข้อมูล input/output ที่ผ่าน Claude API หลัง response ถูกส่งกลับมาให้ผู้เรียก เว้นแต่จะมีกฎหมายบังคับ หรือเพื่อตรวจการละเมิดนโยบาย (abuse)

เทียบกับ default retention ของ Anthropic — ตั้งแต่ 14 กันยายน 2025 Anthropic ลด API retention จาก 30 วันเหลือ 7 วัน (สำหรับ commercial customers) — ZDR ทำให้ retention เป็น 0 วัน (ลบทันที)

ZDR ครอบคลุมอะไรบ้าง

  • Claude API (Messages API, Files API) ที่ใช้ commercial organization API key
  • Claude Code เมื่อใช้ผ่าน commercial organization API key
  • Anthropic products อื่นๆ ที่ใช้ commercial org API key (ขึ้นกับนิยามของ Anthropic ในแต่ละช่วง)

ZDR ไม่ ครอบคลุมอะไร

  • Consumer interfaces: claude.ai web, Claude Desktop, Claude Mobile
  • Claude Team / Enterprise web app: ฝั่ง user ที่ใช้งานผ่าน UI ตรง (ไม่ใช่ API)
  • ฉะนั้นถ้าทีมในองค์กรใช้ claude.ai web ทำงาน — แม้องค์กรเซ็น ZDR แล้ว ก็ ไม่ครอบคลุม UI traffic นั้น

เงื่อนไขการขอ ZDR: ZDR ไม่ใช่ check-box ใน settings — ต้องเป็น eligible enterprise customer ของ Anthropic, ผ่าน approval จาก enterprise sales, และเซ็น signed addendum แยก Grand Linux Solution ช่วยจัดทำเอกสาร, review กับฝ่ายกฎหมายของลูกค้า, และประสานกับ Anthropic ให้

ความเข้าใจผิดที่พบบ่อย: "ZDR ทำให้ Claude ลืม — ต้องเล่าใหม่ทุกครั้งไหม?"

คำถามนี้พบบ่อยมาก และคำตอบที่ตรงไปตรงมาคือ — ZDR ไม่เกี่ยวกับ "Claude จำได้หรือลืม" เพราะ Claude API stateless อยู่แล้วโดยธรรมชาติทุก plan ไม่ว่าจะเซ็น ZDR หรือไม่

API stateless แปลว่าอะไร

หมายความว่าทุกครั้งที่คุณเรียก Claude API คุณต้องส่ง messages array เต็มของ conversation history ไปด้วย — Claude ไม่ได้ "จำ" ว่าคุยอะไรกับใครครั้งก่อน เพราะ API call แต่ละครั้งเป็น request อิสระ ไม่มี session

ตัวอย่าง — ถ้า user คุยกับ chatbot ของคุณ 3 turn:

# Turn 1
messages = [
  {"role": "user", "content": "สวัสดี ช่วยอธิบาย Claude หน่อย"}
]

# Turn 2 — ต้องส่ง history เต็ม
messages = [
  {"role": "user", "content": "สวัสดี ช่วยอธิบาย Claude หน่อย"},
  {"role": "assistant", "content": "Claude คือ AI..."},
  {"role": "user", "content": "แล้ว ZDR คืออะไร?"}
]

# Turn 3 — ส่ง history ทุก turn ที่ผ่านมา
messages = [
  ...(ทุกข้อความก่อนหน้า)
  {"role": "user", "content": "องค์กรเราเหมาะกับ ZDR ไหม?"}
]

นี่เป็น behavior มาตรฐานของ Claude API ทุก plan ไม่ใช่เฉพาะ ZDR — เพราะแบบนี้ ใครเก็บ conversation history? คำตอบคือ คุณ (ฝั่ง client) เก็บ ไม่ใช่ Anthropic

แล้ว default 7 วัน คืออะไร?

คือ log ฝั่ง Anthropic สำหรับ:

  • การตรวจการละเมิดนโยบาย (abuse detection)
  • Debugging ระหว่าง support ticket
  • Compliance/audit จากฝั่ง Anthropic เอง

ไม่ใช่ "memory" ของ Claude ผู้ใช้เรียก API ไม่ได้ใช้ log นี้ Claude ไม่ "อ่าน" log นี้ตอน generate response ใหม่

ดังนั้น การส่ง history เต็มทุก call เป็นสิ่งที่คุณต้องทำอยู่แล้วทุกกรณี ไม่ว่าจะเลือก ZDR หรือ default 7 วัน — ZDR แค่เปลี่ยน "Anthropic เก็บ log นานแค่ไหน" จาก 7 วันเป็น 0 วัน ไม่ได้เปลี่ยนวิธีที่ application ของคุณทำงาน

Prompt Caching ทำงานกับ ZDR ได้ปกติ

คำถามที่หลายคนกังวล — ถ้า ZDR ลบทุกอย่าง prompt caching (feature ที่ช่วยลดต้นทุนและเพิ่มความเร็วเมื่อมี system prompt หรือ context ซ้ำกัน) จะใช้ได้ไหม?

คำตอบ: ใช้ได้ปกติ — ทั้ง automatic caching และ explicit caching Anthropic ยืนยันว่า KV (key-value) cache representation และ cryptographic hash ของ cached content เก็บใน memory เท่านั้น ไม่ retain at rest ซึ่งถือว่าเข้านิยาม ZDR แล้ว

การเปลี่ยนแปลงสำคัญ 5 กุมภาพันธ์ 2026

ตั้งแต่ 5 กุมภาพันธ์ 2026 Anthropic เปลี่ยน prompt cache จาก organization-level isolation เป็น workspace-level isolation บน:

  • Claude API
  • Claude Platform บน AWS
  • Microsoft Foundry (beta)

ส่วน AWS Bedrock และ Google Vertex AI ยังคงเป็น organization-level เหมือนเดิม การเปลี่ยนแปลงนี้สำคัญสำหรับองค์กรที่มี multi-workspace setup ใต้ org เดียว — cache แยกตาม workspace ป้องกัน data leak ระหว่าง workspaces

ข้อดีและข้อเสียของ ZDR

ข้อดี

  • Privacy สูงสุด: ข้อมูลไม่ค้างที่ Anthropic แม้แต่ช่วงสั้น
  • Compliance: ตอบ regulator ได้ง่ายขึ้นในอุตสาหกรรมกำกับ (banking/healthcare/defense)
  • ลด breach surface: ถ้า Anthropic ถูก compromise ข้อมูลของคุณก็ไม่อยู่ที่นั่น
  • Data classification ง่ายขึ้น: legal review ของ prompts ผ่านง่ายเพราะไม่ persisted
  • Data sovereignty narrative: ใช้สื่อสารกับ board / customer ได้ตรงๆ
  • Prompt caching ไม่เสีย: ประสิทธิภาพ + ต้นทุน inference เท่าเดิม

ข้อเสีย

  • ต้อง enterprise tier + signed addendum: ไม่ใช่ option ของทุกคน
  • เสีย Anthropic abuse monitoring: ถ้า API key ถูกขโมยและใช้ในทางผิด Anthropic อาจไม่มี trail ช่วย investigate
  • Support troubleshooting ยากขึ้น: Anthropic ไม่มี log ของ request ที่ error → ต้อง reproduce ฝั่งคุณ
  • ไม่ครอบคลุม UI: ถ้าทีมใช้ claude.ai web อยู่ดี — ส่วนนั้นไม่ได้ ZDR
  • ภาระเก็บ log เองหนักขึ้น: ต้องมีระบบ audit log ของตัวเอง (เพราะ Anthropic ไม่มี)
  • Some features ใหม่อาจล่าช้า: features ที่ต้องอาศัย stored conversations อาจไม่พร้อมใช้ทันที

User ต้องเก็บ context เองยังไง — Architecture Pattern

เนื่องจาก Claude API stateless อยู่แล้ว และ ZDR ไม่เปลี่ยน behavior นี้ — application ของคุณต้องเก็บ conversation state เอง ทุกกรณี ต่อไปนี้คือ pattern ที่ใช้ได้กับทั้งกรณี default และ ZDR

1) Conversation persistence layer พื้นฐาน

เก็บ messages ใน database ของคุณ (PostgreSQL, MongoDB, DynamoDB, Redis ฯลฯ) แล้วประกอบ messages array ก่อนเรียก API ทุกครั้ง:

# Pseudo-code (Python + anthropic SDK)
def chat(conversation_id, user_message):
    # 1) โหลด history จาก DB ของคุณ
    history = db.get_messages(conversation_id)

    # 2) เรียก Claude API พร้อม history เต็ม
    response = anthropic.messages.create(
        model="claude-opus-4-7",
        max_tokens=1024,
        messages=history + [{"role": "user", "content": user_message}]
    )

    # 3) บันทึก turn ใหม่กลับ DB
    db.save_message(conversation_id, "user", user_message)
    db.save_message(conversation_id, "assistant", response.content[0].text)

    return response.content[0].text

2) Long conversation → summarization

เมื่อ conversation ยาวมากจน context window เริ่มเต็ม (Claude Opus 4.7 มี context ใหญ่ แต่ยังมีลิมิต และ token cost ก็ขึ้นตามความยาว) ใช้ rolling summarization:

  • เก็บ system prompt + summary ของ history เก่า + 10-20 turn ล่าสุด
  • เมื่อ history ครบ threshold สรุปเป็น "Up to turn N: [summary]" แล้ว reset memory window
  • ตัว summary นี้ผ่าน Claude เองได้ — เรียก API พร้อม "Summarize this conversation:" pattern

3) Cross-session knowledge → vector store + RAG

ถ้าต้องการให้ Claude "รู้" ข้อมูลถาวรขององค์กร (HR policy, SOP, product knowledge) — ไม่ใช่เก็บใน conversation แต่ใส่ใน vector database (pgvector, Pinecone, Weaviate ฯลฯ) แล้ว retrieve relevant chunks ใส่ใน prompt ตอน inference (RAG pattern)

4) ของสำคัญที่ต้องไม่ลืม — DB ของคุณคือ source of truth

เมื่อใช้ ZDR แล้ว conversation history ของคุณอยู่ที่คุณคนเดียว Anthropic ไม่มี backup ถ้า DB เสียหาย/ถูก ransomware — ข้อมูล recovery ไม่ได้ ดังนั้น:

  • Backup สม่ำเสมอ (พร้อม restore drill ทดสอบ)
  • Encrypt at rest (เพราะคุณคือผู้ถือข้อมูล sensitive แล้ว)
  • Access control เข้มงวด — ใครเข้าถึง conversation log ได้บ้าง
  • Retention policy ของตัวเอง — ถ้า ZDR ให้ Anthropic เก็บ 0 วัน คุณเก็บกี่วัน? นโยบายลบของคุณคืออะไร?
  • Audit log ฝั่งคุณ — ใครเรียก API เมื่อไหร่ ทำอะไร (Anthropic ไม่มี log ให้แล้ว)

ควรเลือก ZDR หรือไม่ — Decision Matrix

✓ ZDR เหมาะกับ ○ Default 7 วัน เพียงพอ
Banking · Healthcare · Defense · Government classified · กฎหมาย/legal services ที่ทำ pre-deployment review โดย legal/security · อุตสาหกรรมที่มี data classification policy ห้าม persisted ใน third-party · องค์กรที่ต้องรายงาน data sovereignty ต่อ board/regulator SME ทั่วไป · บริษัทเอกชนที่มี standard PDPA/ISO 27001 controls · ใช้ Claude ทำงาน productivity (เขียน/แปล/วิเคราะห์) · ไม่มี requirement เฉพาะจาก regulator · ต้องการให้ Anthropic ช่วย abuse monitoring + debugging อยู่

แนะนำ: อย่า default เลือก ZDR เพียงเพราะ "ปลอดภัยกว่า" — ZDR มีต้นทุน operational จริง (เสีย Anthropic abuse monitoring + ภาระเก็บ log เองหนักขึ้น) เลือกตาม risk profile จริงของ workload ที่จะใช้ Claude

ขั้นตอนการ enable ZDR ผ่าน Grand Linux Solution

  1. ปรึกษาทีมเรา — ตรวจ workload + risk profile ว่า ZDR คุ้มจริงหรือไม่ (บางองค์กรเลือก default 7 วันสุดท้ายเพราะ trade-off ดีกว่า)
  2. Enterprise eligibility check — ZDR ต้องเป็น enterprise customer ของ Anthropic ก่อน เราจะช่วยเตรียม use case + ปริมาณ + เอกสารยื่น
  3. Review addendum กับฝ่ายกฎหมาย — Anthropic ZDR addendum เป็นเอกสาร English เราช่วย review + brief ฝ่ายกฎหมายของคุณเรื่อง clause สำคัญ
  4. เซ็น addendum กับ Anthropic — เราประสานทั้งสองฝั่งให้
  5. Configure API + caching workflow — ตั้งค่า production environment ให้ถูกต้องตาม ZDR
  6. Conversation persistence implementation — บริการ Claude Integration ของเราช่วย implement layer เก็บ history + audit log ฝั่งคุณ ให้พร้อมรับมือกับ ZDR architecture

ดูเพิ่มเติม: Claude Enterprise สำหรับองค์กรไทย · Claude Integration & Solutions · ตั้ง Claude Team ให้ผ่าน PDPA ไทย

ZDR เปลี่ยนเพียง "Anthropic เก็บ log นานแค่ไหน" — ไม่ได้เปลี่ยนวิธีออกแบบ application ทุก application ที่ใช้ Claude ต้องเก็บ conversation state ฝั่ง client อยู่ดี เลือก ZDR เพราะ requirement จริง ไม่ใช่เพราะฟังดูปลอดภัยกว่า

- ทีมงาน Saeree ERP

สรุป

ZDR เป็นเครื่องมือเชิง compliance ที่มีพลัง สำหรับองค์กรในอุตสาหกรรมกำกับ — แต่ ไม่ใช่ default choice และไม่ได้แก้ปัญหา "Claude จะลืมไหม" เพราะ Claude API stateless อยู่แล้ว ทุก application ที่ใช้ Claude ต้องเก็บ conversation state ฝั่ง client อยู่ดี ZDR เปลี่ยนเพียง "Anthropic เก็บ log นานแค่ไหน" ซึ่งสำคัญต่อ compliance/breach posture แต่ไม่เปลี่ยนวิธีออกแบบ application

การตัดสินใจที่ถูกต้องคือ เลือก ZDR ถ้ามี requirement จริงจาก regulator/policy/board ไม่ใช่ default เลือก แล้วลงทุนในการเก็บ conversation log ฝั่งตัวเองให้มั่นคงและ encrypted — Grand Linux Solution พร้อมช่วยทั้งการตัดสินใจและการ implement

หมายเหตุข้อเท็จจริง: ข้อมูลในบทความนี้อ้างอิงจากเอกสาร Anthropic Privacy Center, Claude API Docs และ Claude Code Docs verified วันที่ 4 มิถุนายน 2569 (มิ.ย. 2026) — นโยบายและรายละเอียดเชิงเทคนิคของ Anthropic อาจเปลี่ยนได้ ตรวจสอบกับเอกสารทางการของ Anthropic ก่อนตัดสินใจระดับ contract

สนใจ Claude Enterprise + ZDR สำหรับองค์กรของคุณ?

Grand Linux Solution ช่วยตัดสินใจว่า ZDR คุ้มกับ workload ของคุณหรือไม่ จัดทำเอกสาร เจรจา addendum กับ Anthropic แทนคุณ และวาง architecture conversation persistence ให้พร้อม

ปรึกษาทีม Grand Linux

โทร 02-347-7730 | sale@grandlinux.com

Saeree ERP Author

เกี่ยวกับผู้เขียน

สุรีระยา ลิ้มไพบูลย์

กรรมการผู้จัดการ บริษัท แกรนด์ลีนุกซ์ โซลูชั่น จำกัด และผู้ก่อตั้ง Saeree ERP พร้อมให้คำปรึกษาและบริการด้านระบบ ERP ครบวงจร